Re: [galaxy-dev] HOWTO share tool parameter settings?
Hi John, I see that in my last email I replied to you with the fourth (and not the third) option in mind :(. Just to come back to this related to the third option (i.e. Have a dummy tool to produce a settings file and allow the users to choose this file when running the real tool): I don't like this option so much because the file is never as clear as the tool form that produced it. If users are used to looking at the tool form for seeing details about the set parameters and now they will have to look at a text file, this will be confusing. It is not a huge problem, but it is one that I am trying to avoid. I.e. it would be best if users are presented with only one way of checking parameters of executed processes. In the scenario I am proposing, the settings files are disseminated just as they are (e.g. a text file) either by sharing them in the normal ways or by placing a number of them in pre-defined folders in Galaxy. The tool form would allow the user to select one and would then fill in the values of the parameters accordingly. I'm guessing similar binding logic is also happening right now when a user clicks rerun on a step in his history. Best regards, Pieter. -Original Message- From: John Chilton [mailto:jmchil...@gmail.com] Sent: donderdag 9 oktober 2014 15:45 To: Lukasse, Pieter Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] HOWTO share tool parameter settings? How would this be different then the third option you listed? You want it to work with all tools and you as the developer want to be able to construct these files without needing a dummy tool to produce the values? How would imagine these setting files would be disseminated to users and then selected by users? -John On Thu, Oct 9, 2014 at 9:34 AM, Lukasse, Pieter pieter.luka...@wur.nl wrote: Hi, Do we have a way (or plans) for sharing tool parameter settings in Galaxy? I know the following workarounds : · Share a history with all users: so users can import your step and do “rerun” to run on their own file with your settings · Wrap the step in a workflow with all parameters set and publish this workflow: users can run this “workflow” · Have a dummy tool to produce a settings file and allow the users to choose this file when running the real tool · Use a conditional and many macros that are basically a copy of each other, only differing in the parameter values But what I would like to have is a way to define bindings between a settings file and the parameters in the tool form. Any plans, ideas? Thanks, Pieter Lukasse Wageningen UR, Plant Research International Department of Bioinformatics (Bioscience) Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB, Wageningen, the Netherlands T: +31-317481122; M: +31-628189540; skype: pieter.lukasse.wur http://www.pri.wur.nl ___ 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/
[galaxy-dev] Help with Galaxy server migration
Dear all, I'm trying to migrate our local Galaxy server from a standalone server running on CentOS 5 to a setup that runs Galaxy in a Docker container (bgruening/galaxy-stable). Due to Docker and the setup of the container, almost all data, tools, configs etc. have to move to a different place. Since our old server is pretty cluttered up anyway, I would like to move just user data (logins, histories, datasets ...), but none of the tool installations, tool data or configs. My plan was to start with a fresh and clean new Galaxy installation, transfer the datasets and the database and then reinstall all tools through the toolshed (of course there are many more small odds and ends that need fixing). The problem is that after transfering the database, I always get an error when going to Manage installed tool shed repositories (see end of the mail). I tried just overwriting the pg_data directory (PostgreSQL versions are identical) and also exporting to sql (pg_dump) and importing in the new DB. Both times I made sure to run manage_db.sh upgrade afterwards. The error stays the same. I can't make much sense of the error message, my only guess is that it looks for something that's not there. However, I really don't want to transfer the tool directories and tool configurations, because that will get messy and difficult, since many paths need to be adjusted. There's a high chance for error and this way I also carry over the clutter. So is there a way to remove all tool installation information from the database, before I transfer it? Can this even be disentangled from the histories and datasets? Any help or other ideas on how to do this migration are highly appreciated! Thanks, Sarah 10.1.5.190 - - [16/Oct/2014:09:54:35 +] GET /admin_toolshed/browse_repositories HTTP/1.1 500 - http://deep2:8080/admin/index; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Error - type 'exceptions.UnicodeDecodeError': 'ascii' codec can't decode byte 0xe2 in position 393: ordinal not in range(128) URL: http://deep2:8080/admin_toolshed/browse_repositories File 'lib/galaxy/web/framework/middleware/error.py', line 149 in __call__ app_iter = self.application(environ, sr_checker) File '/galaxy-central/eggs/Paste-1.7.5.1-py2.7.egg/paste/recursive.py', line 84 in __call__ return self.application(environ, start_response) File '/galaxy-central/eggs/Paste-1.7.5.1-py2.7.egg/paste/httpexceptions.py', line 633 in __call__ return self.application(environ, start_response) File 'lib/galaxy/web/framework/base.py', line 132 in __call__ return self.handle_request( environ, start_response ) File 'lib/galaxy/web/framework/base.py', line 190 in handle_request body = method( trans, **kwargs ) File 'lib/galaxy/web/framework/decorators.py', line 87 in decorator return func( self, trans, *args, **kwargs ) File 'lib/galaxy/webapps/galaxy/controllers/admin_toolshed.py', line 167 in browse_repositories return self.installed_repository_grid( trans, **kwd ) File 'lib/galaxy/web/framework/helpers/grids.py', line 306 in __call__ kwargs=kwargs ) File 'lib/galaxy/web/framework/webapp.py', line 771 in fill_template return self.fill_template_mako( filename, **kwargs ) File 'lib/galaxy/web/framework/webapp.py', line 786 in fill_template_mako return template.render( **data ) File '/galaxy-central/eggs/Mako-0.4.1-py2.7.egg/mako/template.py', line 296 in render return runtime._render(self, self.callable_, args, data) File '/galaxy-central/eggs/Mako-0.4.1-py2.7.egg/mako/runtime.py', line 660 in _render **_kwargs_for_callable(callable_, data)) File '/galaxy-central/eggs/Mako-0.4.1-py2.7.egg/mako/runtime.py', line 692 in _render_context _exec_template(inherit, lclcontext, args=args, kwargs=kwargs) File '/galaxy-central/eggs/Mako-0.4.1-py2.7.egg/mako/runtime.py', line 718 in _exec_template callable_(context, *args, **kwargs) File '/galaxy-central/database/compiled_templates/base.mako.py', line 66 in render_body __M_writer(unicode(next.body())) File '/galaxy-central/database/compiled_templates/grid_base.mako.py', line 91 in render_body __M_writer(unicode(self.load())) File '/galaxy-central/database/compiled_templates/grid_base.mako.py', line 120 in render_load __M_writer(unicode( h.dumps( self.get_grid_config( embedded=embedded, insert=insert ) ) )) File '/galaxy-central/database/compiled_templates/grid_base.mako.py', line 303 in render_get_grid_config value = column.get_value( trans, grid, item ) File 'lib/tool_shed/galaxy_install/grids/admin_toolshed_grids.py', line 106 in get_value return suc.get_tool_shed_repository_status_label( trans.app, tool_shed_repository ) File 'lib/tool_shed/util/shed_util_common.py', line 829 in get_tool_shed_repository_status_label elif tool_shed_repository.tool_dependencies_being_installed: File 'lib/galaxy/model/tool_shed_install/__init__.py', line 408 in tool_dependencies_being_installed for tool_dependency in
Re: [galaxy-dev] Help with Galaxy server migration
Hmm hopefully someone more knowledgeable about the tool shed than me responds also but I had a couple quick thoughts. The first is a warning - workflows may break. At very least workflows that depend on the previous instance having gone through tool migrations instead of tool install. My understanding is tool migrations cause links to the older versions of the tools to be created so workflows continue to operate - just installing the same version of the tool again doesn't set this up. Also - in theory if you resinstall the same versions of tools tool re-runs and stuff should still work - but I am not confident and I have not tested it myself - so if that functionality is important to you, you test it out before throwing out the old configuration. Next - I am a little bit concerned about this error. It would seem to point to some sort of encoding problem with the way the database was transferred - different table encodings or something? I don't really know anything about encoding and postgres though. That said I am not surprised there are problems with the tool shed. There are all sorts of implicit dependencies between what is on disk and what is in the database. If you really do want to start fresh I would clear out all of the tool shed tables before continuing. These tables including - tool_shed_repository,repository_repository_dependency_association, repository_dependency, tool_dependency, tool_version, tool_version_association, migrate_tools. Rather than truncating the existing tables - you could also just have Galaxy target a completely separate database for tool shed install stuff by creating a new postgres database, setting install_database_connection in your galaxy ini file (either universe_wsgi.ini or galaxy.ini depending on what version of Bjoern's docker image you are targetting) - or in the newest version of that Dockerfile you can just make sure your docker run includes a -e GALAXY_CONFIG_INSTALL_DATABASE_CONNECTION=postgresconnectionstring. You will also want to make sure that database gets populated - I think either of the following would work ./create_db.sh install ./migrate_db.sh install upgrade Sorry I have not definitive answers - but hopefully this is helpful. Good luck with the migration. You should let the list know how the Docker container thing goes for a production server. -John On Thu, Oct 16, 2014 at 8:36 AM, Sarah Diehl di...@ie-freiburg.mpg.de wrote: Dear all, I'm trying to migrate our local Galaxy server from a standalone server running on CentOS 5 to a setup that runs Galaxy in a Docker container (bgruening/galaxy-stable). Due to Docker and the setup of the container, almost all data, tools, configs etc. have to move to a different place. Since our old server is pretty cluttered up anyway, I would like to move just user data (logins, histories, datasets ...), but none of the tool installations, tool data or configs. My plan was to start with a fresh and clean new Galaxy installation, transfer the datasets and the database and then reinstall all tools through the toolshed (of course there are many more small odds and ends that need fixing). The problem is that after transfering the database, I always get an error when going to Manage installed tool shed repositories (see end of the mail). I tried just overwriting the pg_data directory (PostgreSQL versions are identical) and also exporting to sql (pg_dump) and importing in the new DB. Both times I made sure to run manage_db.sh upgrade afterwards. The error stays the same. I can't make much sense of the error message, my only guess is that it looks for something that's not there. However, I really don't want to transfer the tool directories and tool configurations, because that will get messy and difficult, since many paths need to be adjusted. There's a high chance for error and this way I also carry over the clutter. So is there a way to remove all tool installation information from the database, before I transfer it? Can this even be disentangled from the histories and datasets? Any help or other ideas on how to do this migration are highly appreciated! Thanks, Sarah 10.1.5.190 - - [16/Oct/2014:09:54:35 +] GET /admin_toolshed/browse_repositories HTTP/1.1 500 - http://deep2:8080/admin/index; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Error - type 'exceptions.UnicodeDecodeError': 'ascii' codec can't decode byte 0xe2 in position 393: ordinal not in range(128) URL: http://deep2:8080/admin_toolshed/browse_repositories File 'lib/galaxy/web/framework/middleware/error.py', line 149 in __call__ app_iter = self.application(environ, sr_checker) File '/galaxy-central/eggs/Paste-1.7.5.1-py2.7.egg/paste/recursive.py', line 84 in __call__ return self.application(environ, start_response) File '/galaxy-central/eggs/Paste-1.7.5.1-py2.7.egg/paste/httpexceptions.py', line 633 in __call__ return
[galaxy-dev] Login issue with a nginx proxy
Hello galaxians,
I'm currently trying to set up a production galaxy and make it available to
the public but I face a weird issue, probably because of my nginx proxy
configuration.
Galaxy is on a kvm virtual machine running on a host using nginx as proxy.
to make it a bit clearer:
172.30.24.35 (client) --- http://172.30.24.63/machine1 (Host nginx
proxy) --- http://192.168.122.254:8080/ (virtual machine)
I can connect to galaxy but when logging in, the virtual machine redirects
me on 192.168.122.254:8080, which is unreachable from the 172.30.24.0
network. If I log in from the Host, it's all fine.
in the universe_wsgi.ini, i've set:
# Define the proxy-prefix filter.
[filter:proxy-prefix]
use = egg:PasteDeploy#prefix
prefix = /machine1
...
# [filter:proxy-prefix] section above.
filter-with = proxy-prefix
as described in the documentation.
My virtual machine nginx conf file:
user galaxy;
worker_processes 2;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pidlogs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local]
$request '
# '$status $body_bytes_sent $http_referer '
# '$http_user_agent $http_x_forwarded_for';
#access_log logs/access.log main;
sendfileon;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
gzip on;
gzip_http_version 1.1;
gzip_vary on;
gzip_comp_level 4;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml
application/xml text/javascript application/json;
gzip_buffers 16 8k;
gzip_disable MSIE [1-6].(?!.*SV1);
upstream galaxy_app{
server localhost:8080;
}
server {
client_max_body_size 10G;
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location /machine1 {
proxy_pass http://galaxy_app;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /machine1/static {
alias /home/galaxy/galaxy-dist/static;
}
location /machine1/static/style {
alias /home/galaxy/galaxy-dist/static/june_2007_style/blue;
}
location /machine1/static/scripts {
alias /home/galaxy/galaxy-dist/static/scripts/packed;
}
location /machine1/favicon.ico {
alias /home/galaxy/galaxy-dist/static/favicon.ico;
}
location /machine1/robots.txt {
alias /home/galaxy/galaxy-dist/static/robots.txt;
}
location /_x_accel_redirect/ {
internal;
alias /machine1;
}
#error_page 404/404.html;
#redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
And my host configuration :
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name localhost;
location / {
try_files $uri $uri/ =404;
}
location /machine1 {
proxy_pass http://192.168.122.254:8080;
}
}
___
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] Help with Galaxy server migration
Dear John, thank you very much your help and the warnings! I'm testing it with a second database and so far it seems to work :-). I was also suspecting the encoding to be the issue, that's why I did it through pg_dump and specified the encoding of the new server for the dump. The error stayed the same and so far I have just seen it in the context of toolshed operations. I don't know what else I could do to ensure proper encoding. Best regards, Sarah - Original Message - From: John Chilton jmchil...@gmail.com To: Sarah Diehl di...@ie-freiburg.mpg.de Cc: galaxy-dev@lists.bx.psu.edu List galaxy-dev@lists.bx.psu.edu Sent: Thursday, October 16, 2014 3:17:39 PM Subject: Re: [galaxy-dev] Help with Galaxy server migration Hmm hopefully someone more knowledgeable about the tool shed than me responds also but I had a couple quick thoughts. The first is a warning - workflows may break. At very least workflows that depend on the previous instance having gone through tool migrations instead of tool install. My understanding is tool migrations cause links to the older versions of the tools to be created so workflows continue to operate - just installing the same version of the tool again doesn't set this up. Also - in theory if you resinstall the same versions of tools tool re-runs and stuff should still work - but I am not confident and I have not tested it myself - so if that functionality is important to you, you test it out before throwing out the old configuration. Next - I am a little bit concerned about this error. It would seem to point to some sort of encoding problem with the way the database was transferred - different table encodings or something? I don't really know anything about encoding and postgres though. That said I am not surprised there are problems with the tool shed. There are all sorts of implicit dependencies between what is on disk and what is in the database. If you really do want to start fresh I would clear out all of the tool shed tables before continuing. These tables including - tool_shed_repository,repository_repository_dependency_association, repository_dependency, tool_dependency, tool_version, tool_version_association, migrate_tools. Rather than truncating the existing tables - you could also just have Galaxy target a completely separate database for tool shed install stuff by creating a new postgres database, setting install_database_connection in your galaxy ini file (either universe_wsgi.ini or galaxy.ini depending on what version of Bjoern's docker image you are targetting) - or in the newest version of that Dockerfile you can just make sure your docker run includes a -e GALAXY_CONFIG_INSTALL_DATABASE_CONNECTION=postgresconnectionstring. You will also want to make sure that database gets populated - I think either of the following would work ./create_db.sh install ./migrate_db.sh install upgrade Sorry I have not definitive answers - but hopefully this is helpful. Good luck with the migration. You should let the list know how the Docker container thing goes for a production server. -John On Thu, Oct 16, 2014 at 8:36 AM, Sarah Diehl di...@ie-freiburg.mpg.de wrote: Dear all, I'm trying to migrate our local Galaxy server from a standalone server running on CentOS 5 to a setup that runs Galaxy in a Docker container (bgruening/galaxy-stable). Due to Docker and the setup of the container, almost all data, tools, configs etc. have to move to a different place. Since our old server is pretty cluttered up anyway, I would like to move just user data (logins, histories, datasets ...), but none of the tool installations, tool data or configs. My plan was to start with a fresh and clean new Galaxy installation, transfer the datasets and the database and then reinstall all tools through the toolshed (of course there are many more small odds and ends that need fixing). The problem is that after transfering the database, I always get an error when going to Manage installed tool shed repositories (see end of the mail). I tried just overwriting the pg_data directory (PostgreSQL versions are identical) and also exporting to sql (pg_dump) and importing in the new DB. Both times I made sure to run manage_db.sh upgrade afterwards. The error stays the same. I can't make much sense of the error message, my only guess is that it looks for something that's not there. However, I really don't want to transfer the tool directories and tool configurations, because that will get messy and difficult, since many paths need to be adjusted. There's a high chance for error and this way I also carry over the clutter. So is there a way to remove all tool installation information from the database, before I transfer it? Can this even be disentangled from the histories and datasets? Any help or other ideas on how to do this migration are highly appreciated! Thanks, Sarah 10.1.5.190 - - [16/Oct/2014:09:54:35 +] GET
[galaxy-dev] Create select list parameter from input
Hi all, Is it possible to read id's from a column of an input dataset and create a checkbox parameter with the unique id's of that column within the same tool? The only remotely similar action that I found is on the sorting tool where it reads the number of the columns of that dataset and creates a dropdown select list. Bests, Nikos ___ 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] Galaxy Training Network
Hello all, We are pleased to announce the *Galaxy Training Network (GTN) https://wiki.galaxyproject.org/Teach/GTN*, a network of trainers who teach bioinformatics using Galaxy, or teach about Galaxy itself. The GTN aims to make it easy to find Galaxy trainers https://wiki.galaxyproject.org/Teach/Trainers, and to share and discover the wealth of training resources available for Galaxy. This includes training materials https://wiki.galaxyproject.org/Teach/Resources, a trainer directory https://wiki.galaxyproject.org/Teach/Trainers,best practices https://wiki.galaxyproject.org/Teach/BestPractices, and guidance on computing platforms https://wiki.galaxyproject.org/Teach/ComputingPlatforms for teaching with Galaxy. The Galaxy Training Network is accessible to the entire community. If you teach with Galaxy, then please consider adding your organization https://wiki.galaxyproject.org/Teach/Trainers#Add_a_Trainer, materials https://wiki.galaxyproject.org/Teach/Resources#Add_a_Training_Resource, and best practices https://wiki.galaxyproject.org/Teach/BestPractices. The Trainer Directory https://wiki.galaxyproject.org/Teach/Trainers already includes 16 organizations and there may be one (or 6!) near you http://bit.ly/gxytrnmap. Thanks, The Galaxy Training Network (GTN) https://wiki.galaxyproject.org/Teach/Trainers -- http://galaxyproject.org/ http://getgalaxy.org/ http://usegalaxy.org/ https://wiki.galaxyproject.org/ ___ 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] Galaxy instance file upload problem
Hi folks, I encountered the problem in file upload. The error message is like below 'Failed: Not found (404)'. Attached is the screen shot for this error message. Any idea? Thanks! Best, Bongsoo ___ 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] question about GALAXY_SLOTS
Hi, this is just to make sure: the GALAXY_SLOTS environmental variable set by Galaxy when running tools will always be a number = 1 with 1 being the default if nothing else is configured in the job runner settings ? Correct ? Thanks, Wolfgang ___ 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] Galaxy instance file upload problem
Hey Bongsoo, Does this happen on usegalaxy.org? Also does this happen with other files too? Thanks, Sam On Thu, Oct 16, 2014 at 2:49 PM, Bongsoo Park bx...@psu.edu wrote: Hi folks, I encountered the problem in file upload. The error message is like below 'Failed: Not found (404)'. Attached is the screen shot for this error message. Any idea? Thanks! Best, Bongsoo ___ 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] Galaxy instance file upload problem
Aysam, Thanks for your reply. It works well on usegalaxy.org, but it doesn't work in the Galaxy instance I've developed. I downloaded the latest Galaxy version, and installed on the Redhat 6.5 system. I created a galaxy user, and just ran it as usual. I have to update any part of the configuration? I have to allow any specific port to use file upload function? Thanks! Best, Bongsoo On Thu, Oct 16, 2014 at 6:25 PM, Aysam Guerler aysam.guer...@gmail.com wrote: Hey Bongsoo, Does this happen on usegalaxy.org? Also does this happen with other files too? Thanks, Sam On Thu, Oct 16, 2014 at 2:49 PM, Bongsoo Park bx...@psu.edu wrote: Hi folks, I encountered the problem in file upload. The error message is like below 'Failed: Not found (404)'. Attached is the screen shot for this error message. Any idea? Thanks! Best, Bongsoo ___ 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] question about GALAXY_SLOTS
Hi Wolfgang,
\${GALAXY_SLOTS:-4} in this case will default to 4 if you have not
configured it in job_conf.xml. Otherwise yes, it will be 1.
Ciao,
Bjoern
Am 17.10.2014 um 00:05 schrieb Wolfgang Maier:
Hi,
this is just to make sure: the GALAXY_SLOTS environmental variable set
by Galaxy when running tools will always be a number = 1 with 1 being
the default if nothing else is configured in the job runner settings ?
Correct ?
Thanks,
Wolfgang
___
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] CloudMan auto-scaling - Use spot instance for worker node?
No it is not. The thinking was that autoscaling should be responsive and spot instance are not necessarily predictable so we decided against it. We can revisit that idea though if you're keen? Cheers, Enis On Wed, Oct 15, 2014 at 11:05 AM, Petit III, Robert A. robert.pe...@emory.edu wrote: Hi all, I realize when you manually add a node you can request that it be a spot instance. Is it also possible to use spot instances for auto-scaling? Thank you very much, Robert -- This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments). ___ 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/
