Re: [galaxy-dev] Keeping Galaxy up to date
Hi Nate, Thank you very much for enlightening me - I tried to get an impression on Ansible playbooks for the last two minutes and I am really exited about it. Principle and syntax are close to what we are doing in plain BASH plus config files, but the respective scripts are for sure more complex, because we have to write explicitly the tasks which are 'ready to use' modules in Ansible (and I really like YAML btw :) ). I am really looking forward to your updated article on the wiki - in the meantime I will forward the verve to my colleagues ;). Maybe we manage to switch on the playbook principle before the planned update. Cheers & thanks again, Sebastian > Hi Sebastian, > > As for Galaxy Main (usegalaxy.org), our process is automated with Ansible, > the playbook for which can be found here: > > https://github.com/galaxyproject/usegalaxy-playbook > > A bit of documentation on what you should look for (new versions of > universe_wsgi.ini.sample, datatypes_conf.xml.sample, etc.) would certainly > be helpful, so I'll expand the "keeping up to date" page on getgalaxy.org > into a new page and add more details. > > On Tue, Sep 9, 2014 at 6:55 AM, Sebastian Schaaf < > sch...@ibe.med.uni-muenchen.de> wrote: > >> Hi Thomas, >> >> We had this topic at the GCC this year, especially within the Galaxy >> Admins BoF. The truth is (please correct me anyone if this is not the >> case >> anymore!) that you are touching an unresolved point. Keeping track of >> tools, settings etc. across the versions is not given. People have their >> 'home-brew' solutions for this, e.g. keeping a (maybe virtual) machine >> in >> spare in order to invest several hours up to some days to test (with or >> without participation of the users) applicability to local >> constraints/histories/workflow/tools. The more testing is automated and >> the less users (or non-default pieces) the faster the update procedure >> can >> be. But there are also instances which did not receive updates for >> months >> or even years. >> >> On our side we will be facing reality within the next two weeks as we >> really need the update. Although preconditions are pretty good (few >> users, >> not that deep modifications, high grade of automation) we expect some >> issues. happy to have a virtualized environment... >> >> To wrap up my answer in a nutshell: no, there is no best practice guide >> and no migration tool, but every single contribution is warmly welcome >> :). >> >> It would be *very* interesting how updates are handled at Galaxy >> Main...? >> >> Cheers, >> >> Sebastian >> (very interested in further feedback) >> >> >> > Hello, >> > >> > I try to keep our Galaxy instance up to date. >> > Very often, some tools disappear and other do not work anymore. This >> > breaks some users workflows. >> > >> > I may miss something. Is there a "best update pratice" to keep a >> Galaxy >> > instance and the tool-sheds fully functionnal ? >> > >> > Regards, >> > >> > Thomas >> > >> > -- >> > Thomas Bellembois, Network and System Administrator, IGFL (France) >> > http://perso.ens-lyon.fr/thomas.bellembois - +33 4 26 73 13 67 >> > (IGFL internal IT doc: http://itdoc.igfl.ens-lyon.fr/itdoc) >> > ___ >> > Please keep all replies on the list by using "reply all" >> > in your mail client. To manage your subscriptions to this >> > and other Galaxy lists, please use the interface at: >> > http://lists.bx.psu.edu/ >> > >> > To search Galaxy mailing lists use the unified search at: >> > http://galaxyproject.org/search/mailinglists/ >> > >> >> >> -- >> Sebastian Schaaf, M.Sc. Bioinformatics >> Faculty Coordinator NGS Infrastructure >> Chair of Biometry and Bioinformatics >> Department of Medical Informatics, >> Biometry and Epidemiology (IBE) >> University of Munich >> Marchioninistr. 15, K U1 (postal) >> Marchioninistr. 17, U 006 (office) >> D-81377 Munich (Germany) >> Tel: +49 89 2180-78178 >> >> ___ >> Please keep all replies on the list by using "reply all" >> in your mail client. To manage your subscriptions to this >> and other Galaxy lists, please use the interface at: >> http://lists.bx.psu.edu/ >> >> To search Galaxy mailing lists use the unified search at: >> http://galaxyproject.org/search/mailinglists/ >> > ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Keeping Galaxy up to date
Hi Thomas, We had this topic at the GCC this year, especially within the Galaxy Admins BoF. The truth is (please correct me anyone if this is not the case anymore!) that you are touching an unresolved point. Keeping track of tools, settings etc. across the versions is not given. People have their 'home-brew' solutions for this, e.g. keeping a (maybe virtual) machine in spare in order to invest several hours up to some days to test (with or without participation of the users) applicability to local constraints/histories/workflow/tools. The more testing is automated and the less users (or non-default pieces) the faster the update procedure can be. But there are also instances which did not receive updates for months or even years. On our side we will be facing reality within the next two weeks as we really need the update. Although preconditions are pretty good (few users, not that deep modifications, high grade of automation) we expect some issues. happy to have a virtualized environment... To wrap up my answer in a nutshell: no, there is no best practice guide and no migration tool, but every single contribution is warmly welcome :). It would be *very* interesting how updates are handled at Galaxy Main...? Cheers, Sebastian (very interested in further feedback) > Hello, > > I try to keep our Galaxy instance up to date. > Very often, some tools disappear and other do not work anymore. This > breaks some users workflows. > > I may miss something. Is there a "best update pratice" to keep a Galaxy > instance and the tool-sheds fully functionnal ? > > Regards, > > Thomas > > -- > Thomas Bellembois, Network and System Administrator, IGFL (France) > http://perso.ens-lyon.fr/thomas.bellembois - +33 4 26 73 13 67 > (IGFL internal IT doc: http://itdoc.igfl.ens-lyon.fr/itdoc) > ___ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > http://lists.bx.psu.edu/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ > -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Concept for a Galaxy Versioned Fasta Data Retrieval Tool
Damion, Thanks a lot - consequently treating the toppic of 'reproducable science' is a competition, but absolutely required. Björn really touched my mind when he gave the linked talk in Chicago (GCC 2012). Although for a longer time things got stuck, I think that Galaxy is still a (the?) key to it, because the principal structures allow it - it's somehow native to it. Since some important and powerful elements came up (think of e.g. the API), the gap for reaching reproducability also from the reference side using 'on-board tools' of the framework (without bending or disassembling the code too strong) has hardly narrowed. Due to the medical context our instance is in, we really need features like this. In some particular detail I would maybe implement the respective functionalities a bit different (due to performance), but in vast majority I agree: this sounds attractive! Marius' remark on data managers (which are brand new as far as I understood the GCC talks) sounds reasonable, although I did not get in touch with it yet. So, count me in, I'm already a bit excited :). Cheers, Sebastian Dooley, Damion schrieb: Ok, I'll be very happy to see what you've accomplished there. I will read through what you've done when I return from vacation in a week! A key need is to have whatever data comes in show up as linked data in one's history to avoid server overhead; a second objective was to not need to modify existing workflows - as long as they could work of data in history that is typed appropriately. So your 'select type' solution sounds intreguing! And certainly interested in your use of git - I tried using git, using a 1-line fasta data format, but git seemed to choke on protein fasta files? And did it run into performance problems with larger files? That was my experience. I think I read its authors say that its upper limit was 15gb. That was the motivation for writing a simple key-value master file diff system that seems to have the same I/O as git on smaller files, but more reliable for the fasta data case, and no problems with larger files - it outputs a new version in the same time it takes to read a master file. It has drawbacks though - incoming data to compare master with must be sorted in 1 line fasta format first. Thanks for your input; looking forward to your project writeup... Damion Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada From: Björn Grüning [bjoern.gruen...@gmail.com] Sent: Saturday, August 23, 2014 12:17 AM To: Dooley, Damion; galaxy-dev@lists.bx.psu.edu Cc: Hsiao, William Subject: Re: [galaxy-dev] Concept for a Galaxy Versioned Fasta Data Retrieval Tool Hi Damion, the idea sounds fantastic! Can we go a step further and use a specific datatype that keeps entire fasta files versioned and the user can choose which version he wants to use, in any tool? Please have a look at my talk at GCC2012. Maybe you are interested in the (old) patches. I would be very interested to restart this old project. https://wiki.galaxyproject.org/Events/GCC2012/Abstracts#Keeping_Track_of_Life_Science_Data Am 23.08.2014 um 03:24 schrieb Dooley, Damion: We are about to implement a fasta database (file) versioning system as a Galaxy tool. I wanted to get interested people's feedback first before we roll ahead with the prototype implementation. The versioning system aims to: - Simple makeblastdb or bowtie-build commands, or more specific workflows that include dustmasker etc can be implemented. Does this sound attractive? I think all of the use cases are covered by the old project mentioned above. But I did not create a new tool I have created a new 'select type' everyone can use in all tools. It was using git underneath (yeah, I have the entire PDB in git and it is working fine :)) but we can probably change git with a database if you like. To answer your question: Yes, very attractive! We're hoping such a vision could handle Fasta databases from 12mb to e.g. 200Gb (probably requires makeblastdb in parallel at that scale). Preliminary work suggests this project is doable via the Galaxy API without galaxy customization - does that sound right?! Yes, as long as the User has an API key. Cheers, Bjoern ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department
Re: [galaxy-dev] Announcing the UK Galaxy Community
Not to say 'exemplary' - really great :). @Björn: phone call within the next days? Cheers, Sebastian bjoern.gruen...@googlemail.com schrieb: Amazing! All the best from Germany! Bjoern 2014-08-14 15:21 GMT+02:00 graham etherington (TSL) <mailto:graham.ethering...@sainsbury-laboratory.ac.uk>>: Dear UK Galaxy-devs, We're delighted to announce the launch of the UK Galaxy Community. Please visit the site and have a look around: http://galaxy-community.org.uk/ The aims of Galaxy-UK are: * To bring the Galaxy community in the United Kingdom closer together * Identify and address the needs of the community * Encourage interaction and collaboration. Galaxy-UK is also an information hub for events such as: * UK based Galaxy training courses * UK based talks involving Galaxy * Information on the location of UK Galaxy servers * Anything else that might be pertinent to bring the UK Galaxy users/admins together as a community We will be organising both online meetings and physical meetings, so keep an eye on the site for these events. Best wishes, The Galaxy-UK Team. ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Careful data migration
Hi Hans-Rudolph, Thanks for that. I think you are right that there is no peace of code for that, but it could have been the case (no intend to trigger something like 'rtm' ;) ). My script basically creates the NFS mount points, mounts the network target directories, shuts down Galaxy if running, edits the universe.wsgi file according to the new directories (here: the mount points, according to those five 'bulky parameters') and starts Galaxy again if previously running. The primary purpose is to setup a completely new system from scratch (the NFS section is just a part of a longer script), but I would like to redirect the bulky directories also in our main instance (which is in use). The symbolic links are an adequate workaround I was already aware of, but anyway I am interested in what other developers may have experienced. The situation should not be too exotic..? Best, Sebastian Hans-Rudolf Hotz schrieb: Hi Sebastian I am also not aware of any such documentation. It is probably impossible to write it, as each such situation is different. I don't quite understand what your 'script' is doing, but in your situation, I recommend the following: First of all, make sure you have a backup of your PostgreSQL (or MySQL) database. Don't make any changes to 'universe.wsgi', but move the bulky directories to new locations on the NFS share and replace them with symbolic links. This has also the advantage, that you can do it step by step (ie directory by directory). Regards, Hans-Rudolf On 01/13/2014 05:33 PM, Sebastian Schaaf wrote: Hi @ all, I would like to know if anyone could give me some guidance or hint on how to migrate data 'correctly' if Galaxy already wrote files, worked on the database etc. The situation is that we set up an instance, it was already in use and wrote files e.g. into the directory 'galaxy-dist/database/'. The local space is quite small, but more storage is available via a NFS share. I already wrote a bash script for setting up the connections (and editing the 'universe.wsgi' file accordingly) for the entries 'genome_data_path, 'ftp_upload_dir', 'file_path', 'new_file_path' and 'job_working_directory'. Those should address the most bulky features... The application of that script is fine as long as the Galaxy system has never started before. While applying that on a system that already 'did something', e.g. the files in the 'database/' subdirectory remain there and are not transferred. Anyhow, if Galaxy is started up after the application of the new settings, no error is reported. I wonder how Galaxy now deals with that situation: * Handling data from both sources? (read and/or write?) * Automatic movements of the 'historic' data when touched the next time? * Crashes if those older objects are intended to be read/edited? * Removes them silently from the database? => Is there a procedure/module to used in order to migrate the data? Is it sufficient (and appropriate) just to move all contents of the old folders to the new locations? Did I miss any existing documentation on that issue? The answer(s) may diverge, depending on to which of the five parameters announced above those questions are addressed... Any help appreciated before blowing up our production instance :). Thanks in advance, Best regards, Sebastian -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Careful data migration
Hi @ all, I would like to know if anyone could give me some guidance or hint on how to migrate data 'correctly' if Galaxy already wrote files, worked on the database etc. The situation is that we set up an instance, it was already in use and wrote files e.g. into the directory 'galaxy-dist/database/'. The local space is quite small, but more storage is available via a NFS share. I already wrote a bash script for setting up the connections (and editing the 'universe.wsgi' file accordingly) for the entries 'genome_data_path, 'ftp_upload_dir', 'file_path', 'new_file_path' and 'job_working_directory'. Those should address the most bulky features... The application of that script is fine as long as the Galaxy system has never started before. While applying that on a system that already 'did something', e.g. the files in the 'database/' subdirectory remain there and are not transferred. Anyhow, if Galaxy is started up after the application of the new settings, no error is reported. I wonder how Galaxy now deals with that situation: * Handling data from both sources? (read and/or write?) * Automatic movements of the 'historic' data when touched the next time? * Crashes if those older objects are intended to be read/edited? * Removes them silently from the database? => Is there a procedure/module to used in order to migrate the data? Is it sufficient (and appropriate) just to move all contents of the old folders to the new locations? Did I miss any existing documentation on that issue? The answer(s) may diverge, depending on to which of the five parameters announced above those questions are addressed... Any help appreciated before blowing up our production instance :). Thanks in advance, Best regards, Sebastian -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Licensing Galaxy workflows; are they software or documents?
Hello Peter, First of all, interesting question :). Generally, I would suppose both approaches are correct: on the one hand those workflows are a defined set of processing rules in an explicit format, like software is the implementation of algorithms. More detailed, it is a script, processed by an interpreter (= Galaxy). On the other hand, those rules are on a more or less abstract level (does that matter?) and carry somewhat creativity (well, just the uplink to *Creative* Commons...). I would redirect your question to the counter question "How similar is the saved workflow to software code?". Means: is there a file or a database entry, which is comparable to an (interpreted) programming language (-> software)? Or is it more similar to a markup language like XML, which is indeed the case for some other basic elements in Galaxy (-> document)? Hope that helps... Looking forward to some more replies, Cheers, Sebastian Peter Cock schrieb: > Hello all, > > A philosophical question - for my Galaxy tools and wrappers, > I have been using open source software (OSS) licences, e.g. > the MIT license, or GPL. > > For licensing my Galaxy workflows, should I also treat them as > software and do the same, or as a protocol document and go > for something like one of the Creative Commons licenses? > e.g. CC BY, or CC BY-SA > > Thanks, > > Peter > ___ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > http://lists.bx.psu.edu/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ > -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Proxy error while testing FASTX tools?
Hi all, I've got a relatively fresh installed Galaxy instance running within a locked network, where internet access is allowed only via a proxy. So far, so simple; indeed I get internet access via a terminal (e.g. calling Google with lynx), also wget and mercurial have the chance to access target URL's. The variables $http_proxy, $https_proxy and $ftp_proxy are set. My problem occurs when I try to execute the automatic tests (using 'run_functional_tests.sh') for the FASTX toolbox, described here right at the end: http://hannonlab.cshl.edu/fastx_toolkit/download.html The calls of the scripts generally end up in an error block of the following scheme: # functional_tests.py DEBUG 2013-06-25 14:15:40,406 Attempting to serve app on randomly chosen port: 8720 functional_tests.py INFO 2013-06-25 14:15:40,468 Embedded web server started base.asserts DEBUG 2013-06-25 14:15:40,506 base.asserts.text base.asserts DEBUG 2013-06-25 14:15:40,506 base.asserts.tabular base.asserts DEBUG 2013-06-25 14:15:40,506 base.asserts.xml functional_tests.py INFO 2013-06-25 14:15:40,506 Functional tests will be run against localhost:8720 nose.plugins.manager DEBUG 2013-06-25 14:15:40,518 DefaultPluginManager load plugin nosetestdiff = nosetestdiff.plugin:NoseTes tDiff nose.plugins.manager DEBUG 2013-06-25 14:15:40,520 DefaultPluginManager load plugin nosehtml = nosehtml.plugin:NoseHTML Uncollapse ( cshl_fastx_uncollapser ) > Test-1 ... ERROR == ERROR: Uncollapse ( cshl_fastx_uncollapser ) > Test-1 -- Traceback (most recent call last): File "/home/galaxy/galaxy-dist/test/base/twilltestcase.py", line 53, in setUp self.home() File "/home/galaxy/galaxy-dist/test/base/twilltestcase.py", line 1141, in home self.visit_url( self.url ) File "/home/galaxy/galaxy-dist/test/base/twilltestcase.py", line 1324, in visit_url tc.code( 200 ) File "/home/galaxy/galaxy-dist/eggs/twill-0.9-py2.6.egg/twill/commands.py", line 133, in code should_be)) TwillAssertionError: code is 403 != 200 -- Ran 1 test in 0.011s FAILED (errors=1) # For me it reads like there is problem while testing to call the URL in self.url, which resolves to 'localhost:9441'. URL and port are drawn from the environment in the script ".../galaxy-dist/test/base/twilltestcase.py": # class TwillTestCase( unittest.TestCase ): def setUp( self ): [...] self.host = os.environ.get( 'GALAXY_TEST_HOST' ) self.port = os.environ.get( 'GALAXY_TEST_PORT ) self.url = "http://%s:%s"; % ( self.host, self.port ) [...] # I could neither observe any process listening to port 9441 during the test script execution, nor any of the text files within the galaxy root dir contained '9441' as part of a configuration option. Finally I'm a bit confused what that means to me, beyond just not to be able to use the test suite. Anyone an idea what could and/or should be fixed or checked? Thanks in advance, Sebastian -- Sebastian Schaaf, M.Sc. Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Panels disappearing when choosing tools
Hi all,
Again a question from my side in connection with setting up a new Galaxy
instance within an closed network (including a proxy) an SLES 11 SP2.
After some struggeling with the Apache config finally Galaxy was
accessible, but behaves somewhat strange compared to another instance
which is running for a long time without complains (and which was
recently updated to the june release).
When I choose a tool from the panel on the left side everything works
fine until I click on the corresponding link. Unlike the usual case the
tools 'GUI' (so the wrapper web page) appears within Galaxy's central
pane this side get's 'full screened', means: the panels left (tools),
right (history) and on the top side (navigation) are not shown any more.
It does not matter wether I'm logged in or not (Galaxy can be accessed
by guests currently).
Due to the Apache stuff before I compared the access logs of this new
instance an the established one: they definitly look different...
'correct':
[IP1] - galaxy [19/Jun/2013:19:11:22 +0200] "GET
/galaxy/static/style/library.css?v=1370962215 HTTP/1.1" 200 1237
"https://[url]/galaxy/tool_runner?tool_id=upload1"; "Mozilla/5.0 (X11;
Linux i686)
AppleWebKit/537.4 (KHTML, like Gecko) Ubuntu/12.10 Chromium/22.0.1229.94
Chrome/22.0.1229.94 Safari/537.4"
'somewhat strange':
[IP2] - - [19/Jun/2013:19:23:16 +0200] "GET
/galaxy/tool_runner?tool_id=upload1 HTTP/1.1" 200 35869
Access was performed from the same maschine, using the same browser.
What I see is that on the one hand the second field which follows the IP
(removed here) is filled with 'galaxy' in the first case, but empty
('-') in the second one. On the other hand it is obvious that most of
the info around e.g the accessing browser etc. is missing. The error log
does not note anything during this access.
Due to the fact that I'm nearly right the opposite of a webserver god
(but willed to learn) I would really appreciate your help to fix this.
Thanks in advance,
Sebastian
--
Sebastian Schaaf, M.Sc. Bioinformatics
University of Munich
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Clone Galaxy from repository: mercurial from behind proxy?
Thanks for the hint - that may be due to the fact that mercurial as package only comes via a repository dating back to SLES 11 SP1 - there seems to be no newer one. I just looked up the version: instead of current v2.6.2 it's v1.0.2 (!) On the other hand I'm glad that this reads like it does not affect galaxy. btw: just started the server up, no complains yet. Dannon Baker schrieb: On Tue, Jun 18, 2013 at 10:54 AM, Sebastian Schaaf <mailto:sch...@ibe.med.uni-muenchen.de>> wrote: Thus, the cloning process as the LDAP user (did not want to store the foreign username/password explicitly in the galaxy user files) worked, although I get this message: "*** failed to import extension hgext.imerge: no module named imerge" (once at the process' beginning and once at the end) Anyway, this seems to be more a warning than an error. I found possibility to silence it, but would like to understand what the missing may cause. Any clue, anyone? Imerge is an old extension that used to ship with mercurial. Check your .hgrc file for the [extensions] section and make sure there's no line for imerge. If there is, remove it -- recent versions of mercurial don't use this anymore. -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Clone Galaxy from repository: mercurial from behind proxy?
Hi Saket,
First of all thanks a lot for your really quick reply. To sum it up: you
were right.
After ensuring the SSH out (works) your comments led me to the idea to
test the 'hg clone' command with a user account, which is neither root
nor galaxy. These two are local users, while my personal account is from
a LDAP server. Your hint to include username and password into the
http:proxy variable was the key: only LDAP users seem to be allowed to
pass the proxy or better: if those users are already logged in, username
and password are already implicitly deposited.
Thus, the cloning process as the LDAP user (did not want to store the
foreign username/password explicitly in the galaxy user files) worked,
although I get this message:
"*** failed to import extension hgext.imerge: no module named imerge"
(once at the process' beginning and once at the end)
Anyway, this seems to be more a warning than an error. I found
possibility to silence it, but would like to understand what the missing
may cause.
Any clue, anyone?
Saket Choudhary schrieb:
You might want to ssh out and check if that is allowed. If you can ssh
out,
you should be able to clone from bitbucket ssh too [ Though you might
not be able to push, depending on whether or not you own the repository]
On 18 June 2013 19:59, Saket Choudhary <mailto:sake...@gmail.com>> wrote:
Hi Sebastian,
I work behind a proxy too(In my case I have to supply a username
and password too )
I have the following thins setup in my ~/.bashrc:
export http_proxy= http://username:password@proxy-url:proxy-port/
then source it:
$ source ~/.bashrc
or maybe relogin .
and the .hgrc settings that you have specified usually work for
me smoothly.
Here are few links that I remember using . I am no longer behind a
proxy , so would not be able to verify this now, Though I remember
pushing and pulling from behind proxy using the above settings
1.
http://www.jameswampler.com/2010/06/10/configure-mercurial-hg-to-use-a-proxy-server/
2.http://stackoverflow.com/questions/8991608/configuration-for-using-mercurial-with-bitbucket-from-behind-a-certificate-rewri
On 18 June 2013 19:48, Sebastian Schaaf
mailto:sch...@ibe.med.uni-muenchen.de>> wrote:
Hi all,
I'm currently trying to set up a galaxy-dist instance on a
SLES server within an 'encapsulated' network (hospital
environment; here all sensitive data is stored and handled).
Within this network, clients are only capable of accessing the
internet via HTTP/HTTPS and FTP, using a proxy - adress and
port (8080) are the same for all three protocols.
Mercurial (which I had to set up in advance) is accessible and
more or less in default configuration (more on that down below).
What I get after executing the command 'hg clone
https://bitbucket.org/galaxy/galaxy-dist#stable'
is
"abort: error: _ssl.c:491: error:140700FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol"
Google search indicates something more general, so outside the
exclusive scope of Galaxy. On top, no connection to Galaxy was
listed, also not in this mailing list's archive.
Following some hints I just tried to set the proxy via a
'.hgrc' file in the galaxy user home like this:
---
[http_proxy]
host = url:port
[https_proxy]
host = url:port
---
(re-login after that) and also set the system variables
'$http_proxy' and '$https_proxy'. Another approach described
was to call
'hg --config http_proxy.host=url:port clone
https://bitbucket.org/galaxy/galaxy-dist#stable'
Nothing worked out.
Does anyone experienced similar behaviour or has got some
ideas how to solve this?
Thanks in advance,
Sebastian
--
Sebastian Schaaf, M.Sc. Bioinformatics
University of Munich
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
--
Sebastian Schaaf, M.Sc. Bioinformatics
Faculty Coordinator NGS Infrastructure
Chair of Biometry and Bioinformatics
Department of Medical Informatics,
Biometry and Epidemiology (IBE)
University of Munich
Marchioninistr. 15, K U1 (postal)
Marchioninistr. 17, U 006 (office)
D-81377 Munich (Germany)
Tel: +49 89 2180-78178
_
[galaxy-dev] Clone Galaxy from repository: mercurial from behind proxy?
Hi all, I'm currently trying to set up a galaxy-dist instance on a SLES server within an 'encapsulated' network (hospital environment; here all sensitive data is stored and handled). Within this network, clients are only capable of accessing the internet via HTTP/HTTPS and FTP, using a proxy - adress and port (8080) are the same for all three protocols. Mercurial (which I had to set up in advance) is accessible and more or less in default configuration (more on that down below). What I get after executing the command 'hg clone https://bitbucket.org/galaxy/galaxy-dist#stable' is "abort: error: _ssl.c:491: error:140700FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol" Google search indicates something more general, so outside the exclusive scope of Galaxy. On top, no connection to Galaxy was listed, also not in this mailing list's archive. Following some hints I just tried to set the proxy via a '.hgrc' file in the galaxy user home like this: --- [http_proxy] host = url:port [https_proxy] host = url:port --- (re-login after that) and also set the system variables '$http_proxy' and '$https_proxy'. Another approach described was to call 'hg --config http_proxy.host=url:port clone https://bitbucket.org/galaxy/galaxy-dist#stable' Nothing worked out. Does anyone experienced similar behaviour or has got some ideas how to solve this? Thanks in advance, Sebastian -- Sebastian Schaaf, M.Sc. Bioinformatics University of Munich ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Re-starting Galaxy
If you refer to using one machine as master AND host simultaneously, which you never tried: let me tell you it does work well with SGE/OGE. I have it running, and it just works out great. It enhances the load control on that machine, due to the great configuration possibilities on queue level (max. cores, queue ranking, user restrictions etc.). I did not connect it to Galaxy yet (which is also installed on the same machine), but I do not see a reason why that should not work out. Indeed, the reason for acting like this was the need to set up a modularized system, using defined interfaces. Currently everything is physically in on one machine, but that will change. Galaxy for example does not care, where and how a cluster is set up physically, it just connects to a given ressource. Regarding the initial question: at least jobs in the cluster queue will indeed finish, because after submission those jobs are decoupled from Galaxy, by definition; it's like submitting from a desktop machine, which can be switched off afterwards. Additionally, I would wonder if Galaxy (which has really great fail safe mechanisms) would not be able to reconnect to the cluster, asking for jobs, which were submitted before restart and not noted as "finished" or "picked up" after restart (noted internally within the DB). I would say test it and get back to the mailing list :). Best, Sebastian Langhorst, Brad schrieb: > Unless something has recently changed, you will need to set up a cluster > to get jobs to persist across galaxy restarts. > > You can do this with just a single node acting as both queue master and > job runner using sun grid engine (i think, I have not tried this myself) > > Brad > On Aug 27, 2012, at 12:51 PM, > kauerb...@comcast.net<mailto:kauerb...@comcast.net> wrote: > > Hello, > > > > If I were to stop and re-start the Galaxy server with the run.sh script > would jobs that are aleady running or are in the queue be lost when the > server is re-started? If so, is there another method to use which would > not lose the running or queued jobs? > > > > Thank you. > > > > > ___ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ > > -- > Brad Langhorst > langho...@neb.com<mailto:langho...@neb.com> > 978-380-7564 > > > > > ___ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ -- Sebastian Schaaf, M.Sc. Bioinformatics Chair of Biometry and Bioinformatics Department of Medical Information Sciences, Biometry and Epidemiology University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Local Galaxy concept system: hardware spec questions
this first concept, but in the back of my
mind for a longer time :). In the standard CPU setting/environment I
would suppose also the I/O between CPU and RAM to be a bottleneck for
tasks which are not that CPU intensive (more details down below).
3. Regarding the architectural differences (strengths, weaknesses):
Would an AMD- or an Intel-System be more suitable?
I really can't answer which processor line is more suitable, but
I think that having enough RAM per core is more important. Nate shows
that main.g2.bx.psu.edu has 4 GB RAM per core.
4. How much I/O (read and write) can be expected at the memory
controllers? Which tasks are most I/O intensive (regarding RAM and/or
HDDs)?
Workflows currently write all output to disk and read all input from
disk. This gets back to previous questions on benchmarking.
Inspired by a tool calling BWA several times ('Stampy') on one
memory-mapped file our idea was that, due to the HDD bottleneck, RAM
should be available as much as possible. Therefore our medium-term idea
would be to optimize I/O-intensive workflows by wrappers enabling
memory-mapping as far as possible.
As far as I understood until now, the CPU<->RAM I/O would be a
bottleneck in case of trimming, simple filter steps etc. - everything
were masses of data/strings don't really challenge the CPU. As long as
the source data is already in the main memory and not to be loaded from
disk.
5. Roughly separated in mapping and clustering jobs: which amounts of
main memory can be expected to be required by a single job (given
e.g.
Illumina exome data, 50x coverage)? As far as I know mapping should
be
around 4 GB, clustering much more (may reach high double digits).
Nate's presentation shows that main.g2.bx.psu.edu has 24 to 48 GB per
8 core reservation, and as before it shows that there is 4 GB per core.
Than I should be quite save with 128+ GB of RAM. Sure, if one core has
to request RAM outside of it's own adress space, via a neighbored core,
speed goes significantly down. But this should appear rarely in our setting.
6. HDD access (R/W) is mainly in bigger blocks instead of masses of
short operations - correct?
Again, this all depends on the tool being used and could help with some
benchmarks. This question sounds like it's mostly related to choosing the
filesystem - is that right? If so, then you may want to consider a
compressing file system such as ZFS or BtrFS. You may also want to consider
filesystems like Ceph or Gluster (now Red Hat). I know that Ceph can
run on top of XFS and BtrFS, but you should look into BtrFS's churn rate -
it might still be evolving quickly. Again, a ping to the Galaxy Czars call
may help on any and possibly all of these questions.
It was less about considering the filesystem (we recently abolished ZFS
due to issues, which afterwards turned out to (maybe) refer back to some
strange hardware behaviour), we go for EXT4 currently. Gluster or Ceph
may get interesting when we go for an extended system, after having
built up a working stand-alone concept. I'll come back to you for that.
And also to the Czars group where this topic came up as one of the first
ones.
Good luck!
-Scott
Thanks, I'll need some of that.
UPDATE: in the meantime I had this meeting, we gained some more days. At
least until mid of next week. Anyway, if someone could offer some
measured values or experiences I would be very glad.
Thanks,
Sebastian
--
Sebastian Schaaf, M.Sc. Bioinformatics
Chair of Biometry and Bioinformatics
Department of Medical Information Sciences, Biometry and Epidemiology
University of Munich
Marchioninistr. 15, K U1 (postal)
Marchioninistr. 17, U 006 (office)
D-81377 Munich (Germany)
Tel: +49 89 2180-78178
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] Local Galaxy concept system: hardware spec questions
Yes, thanks, I should have mentioned that. I posted in both forum and dev-list, because I don't expect the forum members and the dev-list subscribers to be a 100% identical... Sorry for any inconvenience... Peter Cock wrote: On Mon, Aug 13, 2012 at 11:23 AM, Sebastian Schaaf wrote: Hi all, I have a couple of question around the topic "hardware requirements" for a server which is intended to be bought and used as concept machine for NGS-related jobs. It should be used for development of tools and workflows (using Galaxy, sure) as well as platform for some "alpha" users, who should learn to work on NGS data, which they just began to generate. ... Duplicate thread on the SEQanswers forum: http://seqanswers.com/forums/showthread.php?t=22456 Peter -- Sebastian Schaaf, M.Sc. Bioinformatics Chair of Biometry and Bioinformatics Department of Medical Information Sciences, Biometry and Epidemiology University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
[galaxy-dev] Local Galaxy concept system: hardware spec questions
Hi all, I have a couple of question around the topic "hardware requirements" for a server which is intended to be bought and used as concept machine for NGS-related jobs. It should be used for development of tools and workflows (using Galaxy, sure) as well as platform for some "alpha" users, who should learn to work on NGS data, which they just began to generate. This concept phase is planned to last 1-2 years. During this time main memory and especially storage could be extended, the latter on a per-project basis. We will start with a small team of 3 people for supporting and developing Galaxy and system due to the user's requirements, and the first group of users will bring in data, scientific questions and hands-on work on their own data. Main task (regarding system load) will be sequence alignment (BLAST, mapping tools like BWA/Bowtie), and after that maybe some experimental sequence clustering/de novo assembly for exome data. Additionally variant detection in whatever form are targeted. Only active projects will be stored locally, data no more in use will be stored elsewhere in the network. So far for the setting, regarding the specs the following is intended: - dual-CPU mainboard - 256 GB RAM - 20-30 TB HDD @ RAID6 (data) - SSDs @ RAID5 (system, tmp) Due to funding limitations it may be the case that RAM has to be decreased to 128 GB, not solved is currently the question, if it will be enough for those SSD bundle in RAID5, maybe we have to go for only two of them in RAID1. What we try to find out is, where in those described tasks the machine would run into bottlenecks. What's pretty clear is that I/O is everything, already by a theoretical point of view. But we also observed that on a comparable machine (2x 3,33 Ghz Intel 6-core, 100GB RAM, 450 MB/s R/W to data RAID6). The question of questions is right at the beginning of configuring a system, if one should go for an AMD or an Intel architecture system. The first offers more cores (8-12) at a lower frequency (~2,4 Ghz), the latter less cores (6) with higher frequency (~3,3 Ghz). Due to the data sheets, the Intel CPUs are on a per-core basis ~30% faster with integer operations and ~50% faster with floating point. The risk we see with the AMDs is on the one hand that the number of cores per socket could saturate the memory controller, and on the other hand those jobs, which can not or only poorly be parallelized need more time. To bring all this to some distinct questions (don't feel forced to answer all of them): 1. Using the described bioinformatics software: where are the potential system bottlenecks? (connections between CPUs, RAM, HDDs) 2. What is the expected relation of integer-based and floating point based calculations, which will be loading the CPU cores? 3. Regarding the architectural differences (strengths, weaknesses): Would an AMD- or an Intel-System be more suitable? 4. How much I/O (read and write) can be expected at the memory controllers? Which tasks are most I/O intensive (regarding RAM and/or HDDs)? 5. Roughly separated in mapping and clustering jobs: which amounts of main memory can be expected to be required by a single job (given e.g. Illumina exome data, 50x coverage)? As far as I know mapping should be around 4 GB, clustering much more (may reach high double digits). 6. HDD access (R/W) is mainly in bigger blocks instead of masses of short operations - correct? All those questions are a bit rough and improved (yes, it IS a bit of a chaos currently - sorry for that), but any clue to a single question would help. "Unfortunately" we got the money to place the order for our own hardware unexpectedly quick, and we are now forced to act. We want to make as few cardinal errors as possible... Thanks a lot in advance, Sebastian -- Sebastian Schaaf, M.Sc. Bioinformatics Chair of Biometry and Bioinformatics Department of Medical Information Sciences, Biometry and Epidemiology University of Munich ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy Czars: Web conference Monday, July 9th 9 am
Hi Ann, Just to be sure: you wrote that the web conference will take place at 9:00 AM Central Time (which should be 4:00 PM here in Munich). After clicking on the "join meeting" link to I was wondering that there the timepoint was noted as "May 4, 2012 10:00 AM - May 3, 2013 11:00 AM" (equals 5:00 PM here). Is this due to the daylight saving time or is there another reason for the one hour shift? Looking forward, thanks for the organization! Sebastian Ann Black-Ziegelbein schrieb: Thank you to everyone who helped provide doodle poll input for the first Czars web conference! We have set the date: *Date: *Monday, July 9th *Time: *09:00 AM Central Time* Web Conference (this will be recorded and posted for playback): *We will be using a Blackboard Collaborate web conference. See the section below for more tips on how to use Blackboard Collaborate (Elluminate Live) if you have not used it before. https://globalcampus.uiowa.edu/join_meeting.html?meetingId=1262330108904 * Agenda:* * Logistics: Address how we want to tackle these calls. Go over generic agenda. Frequency of calls * Presentation: Galaxy at Iowa: Discuss our issues with big data, how NGS tools take in/output data and finding the right storage server solution. * Group Goals: what do we want to accomplish with this group beyond discussions/sharing? * Open Mic & recruit new volunteers for the next call. *Blackboard Collaborate (Ellumiate Live!) Tips: *For our web conferences we will try out Blackboard Collaborate web conferencing software. You do not need any special client, just a web browser and java installed (the client will run as a java web start app). You don't need to use a headset, but if you have one it does improve your audio. I will try to open up the session 15 minutes early for people to join and try out the technology. A couple of things to mention, when you launch your session - you can tune your connection speed: Talking works like a walkie-talkie ... you have to select "Talk" (see capture below) to open up your audio line. There can only be 6 simultaneous talkers. Please only select the talk button when you need to actually talk to reduce background noise and to free up lines for others to participate. Thanks! Ann Black-Ziegelbein University of Iowa -- Sebastian Schaaf, M.Sc. Bioinformatics Chair of Biometry and Bioinformatics Department of Medical Information Sciences, Biometry and Epidemiology University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78229 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Interested in speaking with other institutions deploying Galaxy locally?
Thanks Ann for your quick reply, sounds good. I just submitted my info in reply to the online survey. Regarding your issues: don't worry, I think we all suffer from the same things, basically :). No need to apologize. As I stated in the submitted web form we had similar problems with file systems and big data. Maybe a topic for our conversations. Sebastian Ann Black-Ziegelbein schrieb: Hi All - I have dropped the ball on this one. We at Iowa have gotten bogged down in storage issues with galaxy (our existing storage was crashing) and have been spending all my time evaluating different storage solutions under load: zfs, gluster, lustre, nfs for our galaxy and high performance compute cluster. This week our testing and evaluation is almost completed. I have a proposed agenda for our first call I need to circulate as well I have lined up an online web conference solution for us to try which will allow our calls to be recorded and posted for playback. I am actually talking to Dave today and hopefully I will get something out for a call in early to mid July. Sorry folks, I have been busy and it has been hard to get back to this. Ann On 6/28/2012 4:14 AM, Sebastian Schaaf wrote: Also hello to everyone, As I browsed through those tabs which are open for weeks I rediscovered the online survey "Interested in Deploying Your Own Local Galaxy?" connected to this thread here. The last response I could find in this context was the one below which was written by Ann. To make it short: did anything happen in the meantime, has there been any telephone conference, is there still any interest out there? I filled out the survey and ask myself wether it makes still sense to submit the form. Regarding the fact I can participate in this year's Galaxy Developers Conference (GCC in Chicago) I would be quite happy if some contacts may arise from this thread or the conference or both in a mutual way (which would be somewhat perfect). The heavily discussed topic regarding time zones should not prevent us from going ahead. Best regards and thanks in advance, Sebastian Schaaf (Munich, Germany) Ann Black-Ziegelbein schrieb: Hello everyone! Here is a link to a brief survey about how you are using, or plan to use Galaxy locally. If you could take a moment to complete the survey, it will help steer the teleconferences as we get going (and also alleviate having to spend time on the call providing the same background info). The results of the survey will be made public off of a new wiki site that Galaxy's Dave Clements is arranging for the group - thanks Dave! Web Survey: https://docs.google.com/spreadsheet/viewform?formkey=dGJZcmxEWDQ3aERPNmlBaDl1eHVsQ3c6MQ Once the teleconference infrastructure details are in place and finalized, I will send out a web poll to see if we can find a time that works for the majority. Thanks, Ann Black-Ziegelbein On 4/27/2012 2:14 PM, Ryan Golhar wrote: This is a great idea. On Fri, Apr 27, 2012 at 2:45 PM, Ann Black-Ziegelbein mailto:annbl...@eng.uiowa.edu>> wrote: Hi everyone - Here at the University of Iowa we are working on deploying Galaxy locally for campus wide access. I am interested in forming a community of other institutions trying to deploy Galaxy locally and mange/operate it on a broad level. Is anyone else? If there is enough interest, possibly we could have a community conference call every other month to have an open discussion on how we are all deploying galaxy, customizations we are making, problems we are encountering, bugs, and any add-on operations management for galaxy being developed, etc. Would love to hear from others operating Galaxy or in process of standing up a local deployment. Thanks! Ann Black-Ziegelbein ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ -- Sebastian Schaaf, M.Sc. Bioinformatics Chair of Biometry and Bioinformatics Department of Medical Information Sciences, Biometry and Epidemiology University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78229 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Interested in speaking with other institutions deploying Galaxy locally?
Also hello to everyone, As I browsed through those tabs which are open for weeks I rediscovered the online survey "Interested in Deploying Your Own Local Galaxy?" connected to this thread here. The last response I could find in this context was the one below which was written by Ann. To make it short: did anything happen in the meantime, has there been any telephone conference, is there still any interest out there? I filled out the survey and ask myself wether it makes still sense to submit the form. Regarding the fact I can participate in this year's Galaxy Developers Conference (GCC in Chicago) I would be quite happy if some contacts may arise from this thread or the conference or both in a mutual way (which would be somewhat perfect). The heavily discussed topic regarding time zones should not prevent us from going ahead. Best regards and thanks in advance, Sebastian Schaaf (Munich, Germany) Ann Black-Ziegelbein schrieb: Hello everyone! Here is a link to a brief survey about how you are using, or plan to use Galaxy locally. If you could take a moment to complete the survey, it will help steer the teleconferences as we get going (and also alleviate having to spend time on the call providing the same background info). The results of the survey will be made public off of a new wiki site that Galaxy's Dave Clements is arranging for the group - thanks Dave! Web Survey: https://docs.google.com/spreadsheet/viewform?formkey=dGJZcmxEWDQ3aERPNmlBaDl1eHVsQ3c6MQ Once the teleconference infrastructure details are in place and finalized, I will send out a web poll to see if we can find a time that works for the majority. Thanks, Ann Black-Ziegelbein On 4/27/2012 2:14 PM, Ryan Golhar wrote: This is a great idea. On Fri, Apr 27, 2012 at 2:45 PM, Ann Black-Ziegelbein mailto:annbl...@eng.uiowa.edu>> wrote: Hi everyone - Here at the University of Iowa we are working on deploying Galaxy locally for campus wide access. I am interested in forming a community of other institutions trying to deploy Galaxy locally and mange/operate it on a broad level. Is anyone else? If there is enough interest, possibly we could have a community conference call every other month to have an open discussion on how we are all deploying galaxy, customizations we are making, problems we are encountering, bugs, and any add-on operations management for galaxy being developed, etc. Would love to hear from others operating Galaxy or in process of standing up a local deployment. Thanks! Ann Black-Ziegelbein ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ -- Sebastian Schaaf, M.Sc. Bioinformatics Chair of Biometry and Bioinformatics Department of Medical Information Sciences, Biometry and Epidemiology University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78229 ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
