- galaxy-dev - lists.galaxyproject.org

Resolved toolshed mercurial authentication issue, public name change issue remains
by Guest, Simon 16 Sep '13

16 Sep '13

Hi Greg, I finally got to the bottom of the reasons for my abort: authorization failed message when trying to push tool updates into my local toolshed using hg command line (rather than web interface), having given up for a while, and just come back to it. Since my authentication agent (apache LDAP module using corporate Active Directory) was providing bare usernames to the Toolshed, I had been relying on the remote_user_maildomain feature to turn this into an email address. However, it seems this function is not triggered when using hg command line access, so I had to change my rewrite rule which sets up the apache REMOTE_USER in my apache conf file for the toolshed, from this: RequestHeader set REMOTE_USER %{RU}e to this: RequestHeader set REMOTE_USER %{RU}e(a)agresearch.co.nz Now I can push updates directly from hg, and it's much more convenient. I didn't have to change anything in that toolshed middleware (although some temporary log messages I added there were the key for me solving the problem). However, that bug remains where I can continue to change my public name in the web user interface, even after I have created repos. I know not to do this. If there's more information you want from me to try to track down what is going wrong here, just say what you need, and I will endeavour to provide it. But for me, this is now a minor issue, so don't do anything just on my account. Thanks for your help. cheers, Simon > -----Original Message----- > From: Greg Von Kuster [mailto:greg@bx.psu.edu] > Sent: Friday, 6 September 2013 1:00 p.m. > To: Guest, Simon > Cc: galaxy-dev(a)lists.bx.psu.edu > Subject: Re: [galaxy-dev] Bug in toolshed: changing public name breaks > repo path > > Hello Simon, > > The tool shed middleware basically consists of 2 files in > ~/lib/galaxy/webapps/tool_shed/framework/middleware: hg.py which handles > authentication when pushing from the command line. The remoteuser.py file > handles remote user authentication, but I cannot guarantee it properly > handles hg push from the command line since I don't have an environment > set up that way. That would be the place to take a look though, and if > you discover problems let me know and we'll apply a patch. > > Thanks very much, > > Greg Von Kuster > > > On Sep 5, 2013, at 4:53 PM, "Guest, Simon" <Simon.Guest(a)agresearch.co.nz> > wrote: > > > Hi Greg, > > > > I just changed the public name on the web interface, where you click on > the User dropdown, and choose Public Name. Something about my environment > let it happen, when it apparently should have not been possible. > > > > I suspect the reason lies in some mismatch between my apache user > authentication and toolshed userids. See my previous email for the > details of what I've been doing with that. I don't understand the > connection between userids (email addresses) used for authentication, and > public names, which appear to be used by the mercurial server inside the > toolshed (by inference from the public name appearing in the allow_push in > the toolshed repo). Is there a layer of toolshed middleware that maps > between the two? > > > > I am going to investigate other ways of doing the authentication, as I > don't think passing in REMOTE_USER from apache is working (for me). I > would like to know how others are doing that. > > > > cheers, > > Simon > > > >> -----Original Message----- > >> From: Greg Von Kuster [mailto:greg@bx.psu.edu] > >> Sent: Friday, 6 September 2013 1:17 a.m. > >> To: Guest, Simon > >> Cc: Dave Bouvier; galaxy-dev(a)lists.bx.psu.edu > >> Subject: Re: [galaxy-dev] Bug in toolshed: changing public name > >> breaks repo path > >> > >> Hello Simon, > >> > >> > >> On Sep 4, 2013, at 5:13 PM, "Guest, Simon" > >> <Simon.Guest(a)agresearch.co.nz> > >> wrote: > >> > >>> Hi Dave, Greg, > >>> > >>> Thanks for your reply. > >>> > >>> I'm running a recently checked out stable branch. hg log shows this > >> tip: > >>> changeset: 10473:c42567f43aa7 > >>> tag: tip > >>> user: greg > >>> date: Mon Aug 19 13:19:56 2013 -0400 > >>> summary: Filter invalid objects when generating the list of > >> repository_dependencies objects that are associated with a tool shed > >> repository installed into Galaxy. > >>> > >>> I wonder if this problem is related to my more fundamental problem > >>> of > >> being unable to get mercurial push authentication working properly. > >> I care much more about that, as that's blocking me (whereas the > >> problem I reported has an easy work-around). > >> > >> Even though you've found a work-around to the problem that results > >> when you change your public user name in the tool shed after you have > >> created a repository that uses it, it is extremely important that we > >> get a fix ffor the issue committed to the tool shed code. Can you > >> let us know how you went about changing your public user name? The > >> only way we've been able to do it is by manually updaing the database > >> table record using a sql statement. If you have discovered another > >> way to do it, please let us know the steps we can take to reproduce > >> it so that we can get a fix as soon as possible. If this is, in > >> fact, a bug, then it is a very critical one. > >> > >> Thanks, > >> > >> Greg Von Kuster > >> > >> > >> > >>> Here is more information about my environment. > >>> > >>> I'm using apache for digest authentication, with the htdigest file > >> containing email addresses for usernames (so it matches what the > >> toolshed wants). It passes it through to the toolshed using > >> REMOTE_USER. (We have something like this working well for our main > >> Galaxy instance.) I can access the toolshed just fine via the web > >> interface, and I can do e.g. hg outgoing on the command line against > >> a toolshed repo to see what needs pushing. But when I try hg push, I > get abort: authorization failed. > >>> > >>> Looking inside the hgrc file inside my toolshed repo, I see it has > >>> allow_push = simon-guest (i.e. my public name, not my email address). > >>> This isn't going to match the REMOTE_USER passed in from apache, > >>> which is an email address. So I think to get this working with my > >>> authentication framework, public name has to match the email address. > >>> (I tried hacking the allow_push in hgrc to be the email address, but > >>> that didn't work.) > >>> > >>> Is anyone else using a toolshed behind apache with authentication > >> handled by apache, like this? Should I expect hg push to work in > >> this configuration, or am I outside the bounds of what has been tested > so far? > >>> > >>> Thanks for your help, much appreciated. > >>> > >>> cheers, > >>> Simon > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Dave Bouvier [mailto:dave@bx.psu.edu] > >>>> Sent: Thursday, 5 September 2013 1:07 a.m. > >>>> To: Greg Von Kuster > >>>> Cc: Guest, Simon; galaxy-dev(a)lists.bx.psu.edu > >>>> Subject: Re: [galaxy-dev] Bug in toolshed: changing public name > >>>> breaks repo path > >>>> > >>>> Simon, > >>>> > >>>> I am unable to reproduce this behavior on my local tool shed > >>>> installation, which revision are you running? > >>>> > >>>> --Dave B. > >>>> > >>>> On 09/04/2013 06:57 AM, Greg Von Kuster wrote: > >>>>> Hello Simin, > >>>>> > >>>>> Bjoern is correct - if this is possible (which it looks like it is > >>>>> from > >>>> your traceback), then a bug has been introduced somewhat recently. > >>>> We'll take a look at this today and get a fix committed. Thanks > >>>> for reporting this. > >>>>> > >>>>> Greg Von Kuster > >>>>> > >>>>> On Sep 4, 2013, at 3:17 AM, Bjoern Gruening > >>>>> <bjoern.gruening(a)gmail.com> > >>>> wrote: > >>>>> > >>>>>> Hi Simon, > >>>>>> > >>>>>> you are right. Public usernames, or usernames associated with a > >>>>>> repository can't be changed. If you can that is a bug, please > >>>>>> fill a trello card with it. The reason is to guarantee > reproducibility. > >>>>>> If anyone has installed your repository the triple > >>>>>> (username,revision,toolshed) is saved to reinstall that > >>>>>> repository at any time, if needed. > >>>>>> > >>>>>> Cheers, > >>>>>> Bjoern > >>>>>> > >>>>>>>> It looks like it's trying to use the public name in the repo > >>>>>>>> path, which isn't going to work very well if public names can > >>>>>>>> be > >> changed. > >>>>>>>> > >>>>>>>> Changing my public name back to what it was before made it > >>>>>>>> start working again. > >>>>>>> > >>>>>>> To reply to my own post, I see now that when you create a user, > >>>>>>> a > >>>> comment on that page says: "You cannot change your public name > >>>> after you have created a repository in this tool shed." > >>>>>>> > >>>>>>> Does this mean: "If you change your public name after you have > >>>>>>> created a repository in this tool shed, those repositories won't > >>>>>>> work any more" or some such ;-). Or is there actually some > >>>>>>> code to stop the user changing their public name in this case, > >>>>>>> which would imply my toolshed is somehow broken in a way unique to > me? > >>>>>>> (I'm currently struggling to push tools into my toolshed using > >>>>>>> mercurial command line, through my apache front end, with the > >>>>>>> various layers of authentication, without it saying abort: > >>>>>>> authorization failed.) > >>>>>>> > >>>>>>> cheers, > >>>>>>> Simon > >>>>>>> > >>>>>>> > >>>>>>> ================================================================ > >>>>>>> == > >>>>>>> == > >>>>>>> === > >>>>>>> Attention: The information contained in this message and/or > >>>>>>> attachments from AgResearch Limited is intended only for the > >>>>>>> persons or entities to which it is addressed and may contain > >>>>>>> confidential and/or privileged material. Any review, > >>>>>>> retransmission, dissemination or other use of, or taking of any > >>>>>>> action in reliance upon, this information by persons or entities > >>>>>>> other than the intended recipients is prohibited by AgResearch > >>>>>>> Limited. If you have received this message in error, please > >>>>>>> notify > >> the sender immediately. > >>>>>>> ================================================================ > >>>>>>> == > >>>>>>> == > >>>>>>> === > >>>>>>> > >>>>>>> ___________________________________________________________ > >>>>>>> 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/ > >>>>> > >>>>> > >>>>> ___________________________________________________________ > >>>>> 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/ > >>>>> > >>> > >>> ==================================================================== > >>> == > >>> = > >>> Attention: The information contained in this message and/or > >>> attachments from AgResearch Limited is intended only for the persons > >>> or entities to which it is addressed and may contain confidential > >>> and/or privileged material. Any review, retransmission, > >>> dissemination or other use of, or taking of any action in reliance > >>> upon, this information by persons or entities other than the > >>> intended recipients is prohibited by AgResearch Limited. If you have > >>> received this message in error, please notify the sender immediately. > >>> ==================================================================== > >>> == > >>> = > >>> > >>> ___________________________________________________________ > >>> 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/ > > > > > > ====================================================================== > > = > > Attention: The information contained in this message and/or > > attachments from AgResearch Limited is intended only for the persons > > or entities to which it is addressed and may contain confidential > > and/or privileged material. Any review, retransmission, dissemination > > or other use of, or taking of any action in reliance upon, this > > information by persons or entities other than the intended recipients > > is prohibited by AgResearch Limited. If you have received this message > > in error, please notify the sender immediately. > > ====================================================================== > > = > > > > ___________________________________________________________ > > 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/ ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================

2 1

Conditional and validator: refresh_on_change without validation
by Kahlke Tim 14 Sep '13

14 Sep '13

Hi I'm using the <validator> tag for simple sanity checks of a tool input. But I realized that any conditional in the form will automatically call refresh_on_change which also validates all fields and prints errror messages. So questioin: is there a more galaxy-like way of checking input parameters? I am aware of the possibility to do sanity checks through custom code (http://wiki.galaxyproject.org/Admin/Tools/Custom%20Code) but the page states it should only be done if there is no other way. Regards, Tim

2 1

A proposed modules extension for toolshed wrappers
by Guest, Simon 13 Sep '13

13 Sep '13

> > Another vote for the excellent modules system from us at AgResearch > > Galaxy's dependency injection works in a similar way, without requiring > all the external dependencies. We don't need unload since we compose a > unique environment for every tool execution. This is much cleaner that > loading everything into the environment before running Galaxy, we want > tools to be executed with as clean an environment as possible. Setting the environment for each tool just prior to running the tool is clearly better. What I'm doing currently is loading an environment module just before running a tool in Galaxy. So far, I have done this in the tool XML file by prefixing the command with a module load command, e.g. <command>. /etc/profile; module load EMBOSS/5.0.0; infoseq -sequence [snipped] </command> The ugly ". /etc/profile" is needed for technical reasons. I don't like this, as it's a bit hacky, but what it achieves is useful and flexible. I envisage an extension to the tool XML syntax which would let me write it like this, say: <requirements><requirement type="module" version="5.0.0">EMBOSS</requirement></requirements> <command>infoseq -sequence [snipped] </command> This will enable my native EMBOSS wrapper to run the defined version of the (system-installed) EMBOSS suite. However, it would only be worth me writing this extension if there's a likelihood of getting it into Galaxy. Is there? Here's where I'm coming from. I already have most of the applications I want installed on my system. I am working on updating the RPMs to support side-by-side installs of multiple versions, with version selection by the environment modules facility. This is a small change (and improvement) on what I have today. It's a work in progress, but it's a manageable amount of work. It's looking likely that this multi-version packaging approach may be adopted by an official CentOS Scientific Repo, and this could change the landscape in terms of packaging of scientific applications for major Linux distributions. Who knows, that's all in the future. In the meantime, there's work going on in Galaxy land to package every application wanted in Galaxy, by writing install scripts, encapsulating environment variables in tool XML files, etc. (There is difficulty here in writing install scripts which work on every platform, which I have commented on previously.) The big question is, will the Galaxy team accept contributions to Galaxy to support different ways of solving this packaging problem? In particular, allowing for environment modules to be loaded as part of running a tool, and having this functionality in the toolshed? cheers, Simon ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================

3 2

Circumvent "Show all" button
by Gromobir 13 Sep '13

13 Sep '13

Hey guys, Just one short question: Is there any way to circumvent the "Show all" dialog within galaxy, if the data I would like to display is too large? I would like to display some xhtml files, which can really have a lot of lines and I don't want the users of my tool to click on this button every time before accessing the page. Any hints are highly appreciated. Best regards, Gromobir

2 2

toolshed tool versions and tool panel
by Lukasse, Pieter 13 Sep '13

13 Sep '13

Hi Greg, When updating the version number of a tool I noticed that, as expected, both the old version and the new version of the tool become available in the Galaxy environment. What I did not expect is that the new version resulted in a new entry in the menu bar (see screenshot): [cid:image001.png@01CEB07A.3ECB90B0] If I remember correctly, you showed in Oslo that the tool version becomes a choice in the tool itself, something like the screenshot below: [cid:image002.png@01CEB07A.9929B870] Is this a setting somewhere or are we facing a bug? Best regards, Pieter. Pieter Lukasse Wageningen UR, Plant Research International Departments of Bioscience and Bioinformatics Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB, Wageningen, the Netherlands +31-317480891; skype: pieter.lukasse.wur http://www.pri.wur.nl<http://www.pri.wur.nl/>

2 1

Viewing old nightly test results on the (Test) Tool Shed
by Peter Cock 13 Sep '13

13 Sep '13

Hi all, I was wondering if the web interface for the Tool Shed could allow us to look back at old test results? This would be useful in connection with explicit revisions to the tool concerned, but also when something changed which was external to the tool (e.g. a change in Galaxy itself, or the system running the tests, e.g. a library version change). Right now I'm wondering what happened to this tool, which from memory was working, but which failed last night following me updating it yesterday: http://testtoolshed.g2.bx.psu.edu/view/peterjc/clinod Previously this was installing correctly (and I remember debugging the tests themselves due to the number of threads available), but now I seem to have a failed installation: Tests that failed Tool id: clinod Tool version: clinod Test: test_tool_000000 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterj…) Stderr: Fatal error: Exit code 1 () Error: Unable to access jarfile /ToolDependencies/clinod/1.3/peterjc/clinod/1d09534d6dcd/clinod-1.3.jar Traceback: Traceback (most recent call last): File "/var/opt/buildslaves/buildslave-ec2-1/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 171, in test_tool self.do_it( td, shed_tool_id=shed_tool_id ) File "/var/opt/buildslaves/buildslave-ec2-1/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 102, in do_it self.verify_dataset_correctness( outfile, hid=elem_hid, maxseconds=testdef.maxseconds, attributes=attributes, shed_tool_id=shed_tool_id ) File "/var/opt/buildslaves/buildslave-ec2-1/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 782, in verify_dataset_correctness self._assert_dataset_state( elem, 'ok' ) File "/var/opt/buildslaves/buildslave-ec2-1/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 606, in _assert_dataset_state raise AssertionError( errmsg ) AssertionError: Expecting dataset state 'ok', but state is 'error'. Dataset blurb: error Regards, Peter

1 1

Creating Galaxy Admin / Local Install Mailing List - Updates?
by Adam Brenner 12 Sep '13

12 Sep '13

Howdy, I know this has been discussed before, but I can not find the email threads on this...but what was the status on creating a galaxy admin / local install mailing list? The Devel list is very chatty and while my filters do a good job, I think it will be easier for others to find help on their own if it was on a separate mailing list.... It would be easier to search and look back at previous threads. However, the added benefit of having the devel list is that we get feedback from Galaxy Developers.... As the saying godes: Just food for thought, -Adam -- Adam Brenner Computer Science, Undergraduate Student Donald Bren School of Information and Computer Sciences Research Computing Support Office of Information Technology http://www.oit.uci.edu/rcs/ University of California, Irvine www.ics.uci.edu/~aebrenne/ aebrenne(a)uci.edu

3 2

(Test) Tool Shed rending bug with non-ASCII characters in README.rst
by Peter Cock 12 Sep '13

12 Sep '13

Hello all, Another day, another bug report :( Yesterday I updated this repository, including the README file which now uses reStructuredText markup: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/fd0c284a245c After that change, I couldn't view this repository on the Test Tool Shed: >> return render_render_readme(context,readme,pad,parent,row_counter) Module _webapps_tool_shed_repository_common_mako:988 in render_render_readme >> __M_writer(unicode( rst_to_html( readme.text ) )) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1009: ordinal not in range(128) A unicode error. Sigh. As can be seen here, there was a obvious non-ASCII character in the references (Götz) listed in this README.rst file, which renders nicely on BitBucket: https://bitbucket.org/peterjc/galaxy-central/src/7f03d0b7eaa9d002c7389a94a0… In the short term I have replaced "Götz" with "Goetz" - which I was able to do by entering the upload URL by hand, giving: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/0f2fc13ce5fc >> return render_render_readme(context,readme,pad,parent,row_counter) Module _webapps_tool_shed_repository_common_mako:988 in render_render_readme >> __M_writer(unicode( rst_to_html( readme.text ) )) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1138: ordinal not in range(128) Progress - the error is now later in the file, which turned out to be a long-dash in a reference, also edited, and now it works: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/9b6482bd1222 The commit in my repository for 'fixing' the tool: https://bitbucket.org/peterjc/galaxy-central/commits/0d329a0e28171754c2d17d… My hunch is this is related to this recent commit in Galaxy, https://bitbucket.org/galaxy/galaxy-central/commits/535d8ed52369a8bf02ce5e3… In the medium term I would like to revert back to "Götz", and also replace "Bjoern Gruening" with "Björn Grüning" too (both in my README.rst files and in the RST markup within the tool XML files). Regards, Peter

2 4

Re: [galaxy-dev] HOWTO for making new toolshed package
by Greg Von Kuster 12 Sep '13

12 Sep '13

Hello Pieter, Please send questions like this to the galaxy-dev(a)bx.psu.edu or galaxy-dev(a)lists.bx.psu.edu mailing list rather than individual email addresses to ensure optimal, timely responses. The Tool Shed wiki contains all of the information you need: http://wiki.galaxyproject.org/Tool%20Shed This page provides a nice overview of repository features: http://wiki.galaxyproject.org/ToolShedRepositoryFeatures See additional specific pages below for each item you've listed: On Sep 11, 2013, at 11:52 AM, "Lukasse, Pieter" <pieter.lukasse(a)wur.nl> wrote: > Hi Greg, > > I want to make a toolshed package with the following contents: The above "package" is actually a mercurial repository in the tool shed. > · A number of tools The following pages will provide all of the information you'll need for building Galaxy tools for the Tool Shed. http://wiki.galaxyproject.org/ToolShedToolFeatures > · Some workflows The following pages provide information for enabling workflow sharing via the Tool Shed. http://wiki.galaxyproject.org/ToolShedWorkflowSharing > · Datatypes Datatype features in the Tool Shed are described in the following pages: http://wiki.galaxyproject.org/ToolShedDatatypesFeatures > · Installation configurations for installing external tools like R, Gnuplot and X!Tandem The above information is document in the "ToolShedToolFeatures" section of the wiki, specifically in the following pages: http://wiki.galaxyproject.org/ToolShedToolFeatures#Automatic_third-party_to… > · Dependencies configurations to other packages If by "packages", you are referring to other tool shed repositories, then the documentation describing defining these relationships is located in the following pages: http://wiki.galaxyproject.org/DefiningRepositoryDependencies > > Is there a HOWTO wiki page where I can find exactly which files I should add to the .zip file and how they should be named? Or maybe an example package which I could use? > > Regards, > > Pieter Lukasse > > Wageningen UR, Plant Research International > > Departments of Bioscience and Bioinformatics > > Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB, > Wageningen, the Netherlands > > +31-317480891; skype: pieter.lukasse.wur > > http://www.pri.wur.nl > >

3 9

Scaling and hardware requirements
by Nikos Sidiropoulos 12 Sep '13

12 Sep '13

Hi all, I have a couple of questions regarding a server setup dedicated on Galaxy. The idea is to buy a 64 core 256GB RAM server. From my experience I believe that Galaxy will be able to scale up to 64 cpu's but I would like some more feedback on this. Also, is 4GB RAM per CPU core enough for NGS data? (including de-novo assembly) Bests, Nikos

4 7