Re: [galaxy-dev] Galaxy - Cloudman

[Alessia Deglincerti]

Hey Dannon,

I am using Galaxy (Cloudman) to analyze RNA seq data. I have a bunch of 
datasets that I ran TopHat on. I am now trying to run Cufflinks etc. I used the 
same data and workflow yesterday to run Cufflinks etc and that worked fine. I 
used my own reference annotation (Homo sapiens hg38) that I imported from UCSC 
but I wanted to compare to some older data I have and so now I  trying to run 
it on hg17. I also have some other datasets in the queue. All my jobs are gray 
and have been waiting to ran for the past 24+ hours. I am seeing the error as I 
am waiting for my jobs to run, I get a notification at the top of my 
queue/history saying that there was a problem getting updates and to contact a 
site administrator if the problem persists (I've seen the notification a few 
times) and when I click the "details" link in the notification it prompts me 
with the details pasted below. 

I am using all of the default options for my jobs and the same workflow has 
been working fine for me in the past on the same datasets. 

Thanks for any help you can give me!

Alessia 



> On Apr 24, 2014, at 10:24 PM, Dannon Baker  wrote:
> 
> Hey Alessia,
> 
> I'd love to help, but I need a little more context here.  Where are you 
> seeing this error, what exactly are you doing when it appears, and can you 
> tell me a little bit more about the Galaxy configuration you're working with?
> 
> -Dannon
> 
> 
>> On Thu, Apr 24, 2014 at 8:37 PM, Jennifer Jackson  wrote:
>> Posting to the galaxy-...@bx.psu.edu mailing list.
>> https://wiki.galaxyproject.org/MailingLists
>> 
>>> My instance of Galaxy seems to be stuck (same place since last night) and I 
>>> have received the error message several times now.  
>>> 
>>> Pasting the error message below:
>>> 
>>> Details
>>> user
>>> username
>>> adeglincer
>>> quota_percent
>>> 68
>>> total_disk_usage
>>> 184947273683
>>> nice_total_disk_usage
>>> 172.2 GB
>>> email
>>> xxx
>>> is_admin
>>> false
>>> tags_used
>>> 
>>> model_class
>>> User
>>> id
>>> xxx
>>> source
>>> HDACollection(xxx)
>>> xhr
>>> readyState
>>> 4
>>> responseText
>>> {"err_msg": "Uncaught exception in exposed API method:", "err_code": 0}
>>> responseJSON
>>> err_msg
>>> Uncaught exception in exposed API method:
>>> err_code
>>> 0
>>> status
>>> 500
>>> statusText
>>> Internal Server Error
>>> responseHeaders
>>> Date
>>> Thu, 24 Apr 2014 20:51:39 GMT
>>> cache-control
>>> max-age=0,no-cache,no-store
>>> Server
>>> nginx/1.4.7
>>> Connection
>>> keep-alive
>>> Transfer-Encoding
>>> chunked
>>> Content-Type
>>> application/json
>>> options
>>> data
>>> 
>>> parse
>>> true
>>> emulateHTTP
>>> false
>>> emulateJSON
>>> false
>> 
>> ___
>> 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/Cloudman Compute Nodes User

[Jim McCusker]

Actually, both of these help. I'm putting a boto.conf file into
/mnt/galaxy/galaxy-app and setting the BOTO_PATH environment variable from
the python script that needs it, so it will work in dev (non-clusterman
setup) and production.

Jim


On Fri, Apr 25, 2014 at 11:20 AM, Dannon Baker wrote:

> Ahh, sorry about that, I misread the bit about it actually needing to be
> in the user's directory.  You could use a worker_post_start_script to
> configure things like this (creating/copying .boto at boot from the shared
> space in the script).  See
> https://wiki.galaxyproject.org/CloudMan/UserData for how to specify that
> in your UserData.
>
> -Dannon
>
>
>
> On Fri, Apr 25, 2014 at 11:13 AM, Dannon Baker wrote:
>
>> Hi Jim,
>>
>> /mnt/galaxy is shared via NFS with all cluster workers -- this (or a
>> subdirectory) should work for you.
>>
>> -Dannon
>>
>>
>> On Fri, Apr 25, 2014 at 10:56 AM, Jim McCusker <
>> jmccus...@5amsolutions.com> wrote:
>>
>>> Hi all,
>>>
>>> I need to add a .boto file to the user that galaxy jobs get exec'ed as
>>> on cloudman nodes. I thought it would copy over what the galaxy server has
>>> in its home directory, but that doesn't seem to happen. How can I get
>>> things like my .boto file to migrate over to new cloudman nodes when they
>>> are spun up?
>>>
>>> Thanks,
>>> Jim
>>>
>>> ___
>>> 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/Cloudman Compute Nodes User

[Dannon Baker]

Ahh, sorry about that, I misread the bit about it actually needing to be in
the user's directory.  You could use a worker_post_start_script to
configure things like this (creating/copying .boto at boot from the shared
space in the script).  See
https://wiki.galaxyproject.org/CloudMan/UserDatafor how to specify
that in your UserData.

-Dannon



On Fri, Apr 25, 2014 at 11:13 AM, Dannon Baker wrote:

> Hi Jim,
>
> /mnt/galaxy is shared via NFS with all cluster workers -- this (or a
> subdirectory) should work for you.
>
> -Dannon
>
>
> On Fri, Apr 25, 2014 at 10:56 AM, Jim McCusker  > wrote:
>
>> Hi all,
>>
>> I need to add a .boto file to the user that galaxy jobs get exec'ed as on
>> cloudman nodes. I thought it would copy over what the galaxy server has in
>> its home directory, but that doesn't seem to happen. How can I get things
>> like my .boto file to migrate over to new cloudman nodes when they are spun
>> up?
>>
>> Thanks,
>> Jim
>>
>> ___
>> 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/Cloudman Compute Nodes User

[Dannon Baker]

Hi Jim,

/mnt/galaxy is shared via NFS with all cluster workers -- this (or a
subdirectory) should work for you.

-Dannon


On Fri, Apr 25, 2014 at 10:56 AM, Jim McCusker
wrote:

> Hi all,
>
> I need to add a .boto file to the user that galaxy jobs get exec'ed as on
> cloudman nodes. I thought it would copy over what the galaxy server has in
> its home directory, but that doesn't seem to happen. How can I get things
> like my .boto file to migrate over to new cloudman nodes when they are spun
> up?
>
> Thanks,
> Jim
>
> ___
> 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] Galaxy/Cloudman Compute Nodes User

[Jim McCusker]

Hi all,

I need to add a .boto file to the user that galaxy jobs get exec'ed as on
cloudman nodes. I thought it would copy over what the galaxy server has in
its home directory, but that doesn't seem to happen. How can I get things
like my .boto file to migrate over to new cloudman nodes when they are spun
up?

Thanks,
Jim
___
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 - Cloudman

[Dannon Baker]

Do you have Cloudman admin access on this instance?

The first thing I'd check would be http:///cloud to verify
that your instance has free disk space and to look for any errors in the
log.  Then, check out the admin service list
(http:///cloud/admin)
to see if there are any service issues.  Next to the SGE service, you
should see a 'qstat' link that'll show you the status of any jobs submitted
to the cluster.  If you're not running any extra worker nodes, check this
page to verify that the master is set to run jobs.

If you look through this stuff and nothing looks obvious, feel free to ping
me off list and I can try to take a look with you.

-Dannon


On Fri, Apr 25, 2014 at 2:18 AM, Alessia Deglincerti <
adeglin...@mail.rockefeller.edu> wrote:

> Hey Dannon,
>
> I am using Galaxy (Cloudman) to analyze RNA seq data. I have a bunch of
> datasets that I ran TopHat on. I am now trying to run Cufflinks etc. I used
> the same data and workflow yesterday to run Cufflinks etc and that worked
> fine. I used my own reference annotation (Homo sapiens hg38) that I
> imported from UCSC but I wanted to compare to some older data I have and so
> now I  trying to run it on hg17. I also have some other datasets in the
> queue. All my jobs are gray and have been waiting to ran for the past 24+
> hours. I am seeing the error as I am waiting for my jobs to run, I get a
> notification at the top of my queue/history saying that there was a problem
> getting updates and to contact a site administrator if the problem persists
> (I've seen the notification a few times) and when I click the "details"
> link in the notification it prompts me with the details pasted below.
>
> I am using all of the default options for my jobs and the same workflow
> has been working fine for me in the past on the same datasets.
>
> Thanks for any help you can give me!
>
> Alessia
>
>
>
> On Apr 24, 2014, at 10:24 PM, Dannon Baker  wrote:
>
> Hey Alessia,
>
> I'd love to help, but I need a little more context here.  Where are you
> seeing this error, what exactly are you doing when it appears, and can you
> tell me a little bit more about the Galaxy configuration you're working
> with?
>
> -Dannon
>
>
> On Thu, Apr 24, 2014 at 8:37 PM, Jennifer Jackson  wrote:
>
>>  Posting to the galaxy-...@bx.psu.edu mailing list.
>> https://wiki.galaxyproject.org/MailingLists
>>
>>  My instance of Galaxy seems to be stuck (same place since last night)
>> and I have received the error message several times now.
>>
>>  Pasting the error message below:
>>
>>  *Details*
>>
>> user
>>
>> username
>>
>> adeglincer
>>
>> quota_percent
>>
>> 68
>>
>> total_disk_usage
>>
>> 184947273683
>>
>> nice_total_disk_usage
>>
>> 172.2 GB
>>
>> email
>>
>> xxx
>>
>> is_admin
>>
>> false
>>
>> tags_used
>>
>> model_class
>>
>> User
>>
>> id
>>
>> xxx
>>
>> source
>>
>> HDACollection(xxx)
>>
>> xhr
>>
>> readyState
>>
>> 4
>>
>> responseText
>>
>> {"err_msg": "Uncaught exception in exposed API method:", "err_code": 0}
>>
>> responseJSON
>>
>> err_msg
>>
>> Uncaught exception in exposed API method:
>>
>> err_code
>>
>> 0
>>
>> status
>>
>> 500
>>
>> statusText
>>
>> Internal Server Error
>>
>> responseHeaders
>>
>> Date
>>
>> Thu, 24 Apr 2014 20:51:39 GMT
>>
>> cache-control
>>
>> max-age=0,no-cache,no-store
>>
>> Server
>>
>> nginx/1.4.7
>>
>> Connection
>>
>> keep-alive
>>
>> Transfer-Encoding
>>
>> chunked
>>
>> Content-Type
>>
>> application/json
>>
>> options
>>
>> data
>>
>> parse
>>
>> true
>>
>> emulateHTTP
>>
>> false
>>
>> emulateJSON
>>
>> false
>>
>>
>> ___
>> 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 - Cloudman

[Dannon Baker]

Hey Alessia,

I'd love to help, but I need a little more context here.  Where are you
seeing this error, what exactly are you doing when it appears, and can you
tell me a little bit more about the Galaxy configuration you're working
with?

-Dannon


On Thu, Apr 24, 2014 at 8:37 PM, Jennifer Jackson  wrote:

>  Posting to the galaxy-...@bx.psu.edu mailing list.
> https://wiki.galaxyproject.org/MailingLists
>
>  My instance of Galaxy seems to be stuck (same place since last night)
> and I have received the error message several times now.
>
>  Pasting the error message below:
>
>  *Details*
>
> user
>
> username
>
> adeglincer
>
> quota_percent
>
> 68
>
> total_disk_usage
>
> 184947273683
>
> nice_total_disk_usage
>
> 172.2 GB
>
> email
>
> xxx
>
> is_admin
>
> false
>
> tags_used
>
> model_class
>
> User
>
> id
>
> xxx
>
> source
>
> HDACollection(xxx)
>
> xhr
>
> readyState
>
> 4
>
> responseText
>
> {"err_msg": "Uncaught exception in exposed API method:", "err_code": 0}
>
> responseJSON
>
> err_msg
>
> Uncaught exception in exposed API method:
>
> err_code
>
> 0
>
> status
>
> 500
>
> statusText
>
> Internal Server Error
>
> responseHeaders
>
> Date
>
> Thu, 24 Apr 2014 20:51:39 GMT
>
> cache-control
>
> max-age=0,no-cache,no-store
>
> Server
>
> nginx/1.4.7
>
> Connection
>
> keep-alive
>
> Transfer-Encoding
>
> chunked
>
> Content-Type
>
> application/json
>
> options
>
> data
>
> parse
>
> true
>
> emulateHTTP
>
> false
>
> emulateJSON
>
> false
>
>
> ___
> 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] Galaxy - Cloudman

[Jennifer Jackson]

Posting to the galaxy-...@bx.psu.edu mailing list.
https://wiki.galaxyproject.org/MailingLists

My instance of Galaxy seems to be stuck (same place since last night) 
and I have received the error message several times now.


Pasting the error message below:

*Details*

user



username



adeglincer

quota_percent



68

total_disk_usage



184947273683

nice_total_disk_usage



172.2 GB

email



xxx

is_admin



false

tags_used



model_class



User

id



xxx

source



HDACollection(xxx)

xhr



readyState



4

responseText



{"err_msg": "Uncaught exception in exposed API method:", "err_code": 0}

responseJSON



err_msg



Uncaught exception in exposed API method:

err_code



0

status



500

statusText



Internal Server Error

responseHeaders



Date



Thu, 24 Apr 2014 20:51:39 GMT

cache-control



max-age=0,no-cache,no-store

Server



nginx/1.4.7

Connection



keep-alive

Transfer-Encoding



chunked

Content-Type



application/json

options



data



parse



true

emulateHTTP



false

emulateJSON



false


___
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 CloudMan release - Tophat does not work

[Enis Afgan]

Not quite next week, but an update to the tools volume and CloudMan itself
was just released so things should be working now. Sorry for the trouble
and the delay and let us know if how things are going for you now.

Cheers,
Enis


On Sat, Jul 13, 2013 at 9:27 AM, Enis Afgan  wrote:

> Next week, we'll update the underlying snapshot to correct those symlinks
> and get Tophat working. Sorry for the trouble.
>
>
> On Fri, Jul 12, 2013 at 9:23 PM, Ravpreet Setia  > wrote:
>
>>  I see you are experiencing the same problem as I am. The reason these
>> programs cannot be found is because the "default" symlink is broken. The
>> following page describes how the symlink is used by Galaxy:
>>
>>  http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies
>>
>>  Suppose you wish to fix Tophat, then you will need to go to
>> /mnt/galaxy/tools/tophat. Type 'ls –l' and you will notice that the
>> 'default' symlink points to a directory in "/mnt/galaxyTools". Recall that
>> this update merged galaxyTools and galaxyData into a single volume – but
>> the symlink was not modified to account for this. Therefore, the symlink
>> should instead point to /mnt/galaxy/tools/tophat/.
>>
>>  Then, go into the directory of the version you specified and modify the
>> env.sh file so it also has the proper path.
>>
>>  Let me know if Tophat works for you, even after doing this it fails to
>> run properly for me. However, at least now Galaxy can find the programs.
>>
>>
>>   From: Mohammad Heydarian 
>> Date: Fri, 12 Jul 2013 14:21:23 -0400
>> To: Microsoft Office User 
>> Cc: Enis Afgan , Galaxy-dev 
>> Subject: Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work
>>
>>  Cufflinks, Cuffcompare, and Cuffdiff are also failing to run because
>> they can not be found. I am using the newly released version of Cloudman
>> 2.0 (ami-118bfc78).
>>
>>  Any help would be appreciated.
>>
>>  Cheers,
>> Mo Heydarian
>>
>>
>>  On Mon, Jul 8, 2013 at 5:02 PM, Ravpreet Setia <
>> ravpreet.se...@oicr.on.ca> wrote:
>>
>>>  Some tools (tophat is one) are failing to run because they cannot be
>>> found. I have noticed that after launching a new instance with the latest
>>> AMI, the "//default" sym-links under /mnt/galaxy/tools
>>> point to a directory in /mnt/galaxyTools, which does not exist since this
>>> new AMI merged galaxyTools and galaxyData.
>>>
>>>  Additionally, even after manually fixing the symlink and the path in
>>> the env.sh file (it also references galaxyTools), running tophat would
>>> fail, although now, at least, it can find the program.
>>>
>>>  This document explains how the default symlink is used by Galaxy:
>>> http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies
>>>
>>>  Thanks for any suggestions.
>>>
>>>
>>>
>>>   From: Enis Afgan 
>>> Date: Sun, 30 Jun 2013 07:37:46 +0200
>>> To: Galaxy-dev 
>>> Subject: [galaxy-dev] Galaxy CloudMan release
>>>
>>>  *Last night, we released an update to Galaxy CloudMan.* CloudMan offers
>>> an easy way to get a personal and completely functional instance of Galaxy
>>> in the cloud in just a few minutes, without any manual configuration.
>>>
>>> *IMPORTANT - please read*
>>> Any new cluster will automatically start using this version of CloudMan.
>>> Existing clusters will be given an option to do an automatic update once
>>> the main interface page is refreshed. Note that this upgrade is a major
>>> version upgrade and thus the migration is rather complicated. The migration
>>> process has been automated but will take a little while to complete. If you
>>> have made customizations to your cluster in terms of adding file systems,
>>> upgrading the database, or similar, we do not recommend you perform the
>>> upgrade. Note that this upgrade comes with (and requires) a new AMI
>>> (ami-118bfc78), which will be automatically used if starting an instance
>>> via CloudLaunch <http://usegalaxy.org/cloudlaunch>.
>>>
>>>  *This update brings a large number of updates and new features, the
>>> most prominent ones being:*
>>>  - Unification of *galaxyTools* and *galaxyData* file systems into a
>>> single *galaxy* filesystem. This change makes it possible to utilize
>>> the Galaxy Tool Shed when installing tools into Galaxy.
>>> - Added initial support for Hadoop-type workloads

Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work

[Enis Afgan]

Next week, we'll update the underlying snapshot to correct those symlinks
and get Tophat working. Sorry for the trouble.


On Fri, Jul 12, 2013 at 9:23 PM, Ravpreet Setia
wrote:

>  I see you are experiencing the same problem as I am. The reason these
> programs cannot be found is because the "default" symlink is broken. The
> following page describes how the symlink is used by Galaxy:
>
>  http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies
>
>  Suppose you wish to fix Tophat, then you will need to go to
> /mnt/galaxy/tools/tophat. Type 'ls –l' and you will notice that the
> 'default' symlink points to a directory in "/mnt/galaxyTools". Recall that
> this update merged galaxyTools and galaxyData into a single volume – but
> the symlink was not modified to account for this. Therefore, the symlink
> should instead point to /mnt/galaxy/tools/tophat/.
>
>  Then, go into the directory of the version you specified and modify the
> env.sh file so it also has the proper path.
>
>  Let me know if Tophat works for you, even after doing this it fails to
> run properly for me. However, at least now Galaxy can find the programs.
>
>
>   From: Mohammad Heydarian 
> Date: Fri, 12 Jul 2013 14:21:23 -0400
> To: Microsoft Office User 
> Cc: Enis Afgan , Galaxy-dev 
> Subject: Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work
>
>  Cufflinks, Cuffcompare, and Cuffdiff are also failing to run because
> they can not be found. I am using the newly released version of Cloudman
> 2.0 (ami-118bfc78).
>
>  Any help would be appreciated.
>
>  Cheers,
> Mo Heydarian
>
>
>  On Mon, Jul 8, 2013 at 5:02 PM, Ravpreet Setia  > wrote:
>
>>  Some tools (tophat is one) are failing to run because they cannot be
>> found. I have noticed that after launching a new instance with the latest
>> AMI, the "//default" sym-links under /mnt/galaxy/tools
>> point to a directory in /mnt/galaxyTools, which does not exist since this
>> new AMI merged galaxyTools and galaxyData.
>>
>>  Additionally, even after manually fixing the symlink and the path in
>> the env.sh file (it also references galaxyTools), running tophat would
>> fail, although now, at least, it can find the program.
>>
>>  This document explains how the default symlink is used by Galaxy:
>> http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies
>>
>>  Thanks for any suggestions.
>>
>>
>>
>>   From: Enis Afgan 
>> Date: Sun, 30 Jun 2013 07:37:46 +0200
>> To: Galaxy-dev 
>> Subject: [galaxy-dev] Galaxy CloudMan release
>>
>>  *Last night, we released an update to Galaxy CloudMan.* CloudMan offers
>> an easy way to get a personal and completely functional instance of Galaxy
>> in the cloud in just a few minutes, without any manual configuration.
>>
>> *IMPORTANT - please read*
>> Any new cluster will automatically start using this version of CloudMan.
>> Existing clusters will be given an option to do an automatic update once
>> the main interface page is refreshed. Note that this upgrade is a major
>> version upgrade and thus the migration is rather complicated. The migration
>> process has been automated but will take a little while to complete. If you
>> have made customizations to your cluster in terms of adding file systems,
>> upgrading the database, or similar, we do not recommend you perform the
>> upgrade. Note that this upgrade comes with (and requires) a new AMI
>> (ami-118bfc78), which will be automatically used if starting an instance
>> via CloudLaunch <http://usegalaxy.org/cloudlaunch>.
>>
>>  *This update brings a large number of updates and new features, the
>> most prominent ones being:*
>>  - Unification of *galaxyTools* and *galaxyData* file systems into a
>> single *galaxy* filesystem. This change makes it possible to utilize the
>> Galaxy Tool Shed when installing tools into Galaxy.
>> - Added initial support for Hadoop-type workloads
>> - Added initial support for cluster federation via HTCondor
>> - Added a new file system service for instance's transient storage,
>> allowing it to be used across the cluster over NFS
>> - Added a service for Galaxy Reports webapp
>> - Added optional Loggly (loggly.com) based off-site logging support
>>  - Added tags to all resources utilized by CloudMan
>>
>>  For more details on the new features, see the the 
>> CHANGELOG<https://bitbucket.org/galaxy/cloudman/src/tip/CHANGELOG.md?at=default>and
>>  for even more details see, all of 291
>> commit 
>> messages<https://bitbucket.org/gal

Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work

[Ravpreet Setia]

I see you are experiencing the same problem as I am. The reason these programs 
cannot be found is because the "default" symlink is broken. The following page 
describes how the symlink is used by Galaxy:

http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies

Suppose you wish to fix Tophat, then you will need to go to 
/mnt/galaxy/tools/tophat. Type 'ls –l' and you will notice that the 'default' 
symlink points to a directory in "/mnt/galaxyTools". Recall that this update 
merged galaxyTools and galaxyData into a single volume – but the symlink was 
not modified to account for this. Therefore, the symlink should instead point 
to /mnt/galaxy/tools/tophat/.

Then, go into the directory of the version you specified and modify the env.sh 
file so it also has the proper path.

Let me know if Tophat works for you, even after doing this it fails to run 
properly for me. However, at least now Galaxy can find the programs.


From: Mohammad Heydarian mailto:mheyd...@jhmi.edu>>
Date: Fri, 12 Jul 2013 14:21:23 -0400
To: Microsoft Office User 
mailto:ravpreet.se...@oicr.on.ca>>
Cc: Enis Afgan mailto:afg...@gmail.com>>, Galaxy-dev 
mailto:galaxy-...@bx.psu.edu>>
Subject: Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work

Cufflinks, Cuffcompare, and Cuffdiff are also failing to run because they can 
not be found. I am using the newly released version of Cloudman 2.0 
(ami-118bfc78).

Any help would be appreciated.

Cheers,
Mo Heydarian


On Mon, Jul 8, 2013 at 5:02 PM, Ravpreet Setia 
mailto:ravpreet.se...@oicr.on.ca>> wrote:
Some tools (tophat is one) are failing to run because they cannot be found. I 
have noticed that after launching a new instance with the latest AMI, the 
"//default" sym-links under /mnt/galaxy/tools point to a 
directory in /mnt/galaxyTools, which does not exist since this new AMI merged 
galaxyTools and galaxyData.

Additionally, even after manually fixing the symlink and the path in the env.sh 
file (it also references galaxyTools), running tophat would fail, although now, 
at least, it can find the program.

This document explains how the default symlink is used by Galaxy:
http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies

Thanks for any suggestions.



From: Enis Afgan mailto:afg...@gmail.com>>
Date: Sun, 30 Jun 2013 07:37:46 +0200
To: Galaxy-dev mailto:galaxy-...@bx.psu.edu>>
Subject: [galaxy-dev] Galaxy CloudMan release

Last night, we released an update to Galaxy CloudMan. CloudMan offers an easy 
way to get a personal and completely functional instance of Galaxy in the cloud 
in just a few minutes, without any manual configuration.

IMPORTANT - please read
Any new cluster will automatically start using this version of CloudMan. 
Existing clusters will be given an option to do an automatic update once the 
main interface page is refreshed. Note that this upgrade is a major version 
upgrade and thus the migration is rather complicated. The migration process has 
been automated but will take a little while to complete. If you have made 
customizations to your cluster in terms of adding file systems, upgrading the 
database, or similar, we do not recommend you perform the upgrade. Note that 
this upgrade comes with (and requires) a new AMI (ami-118bfc78), which will be 
automatically used if starting an instance via 
CloudLaunch<http://usegalaxy.org/cloudlaunch>.

This update brings a large number of updates and new features, the most 
prominent ones being:
- Unification of galaxyTools and galaxyData file systems into a single galaxy 
filesystem. This change makes it possible to utilize the Galaxy Tool Shed when 
installing tools into Galaxy.
- Added initial support for Hadoop-type workloads
- Added initial support for cluster federation via HTCondor
- Added a new file system service for instance's transient storage, allowing it 
to be used across the cluster over NFS
- Added a service for Galaxy Reports webapp
- Added optional Loggly (loggly.com<http://loggly.com>) based off-site logging 
support
- Added tags to all resources utilized by CloudMan

For more details on the new features, see the the 
CHANGELOG<https://bitbucket.org/galaxy/cloudman/src/tip/CHANGELOG.md?at=default>
 and for even more details see, all of 291 commit 
messages<https://bitbucket.org/galaxy/cloudman/commits/all?search=35baec1%3A8bbae3f>
 from 7 contributors.

Enjoy and please let us know what you think,
Enis


P.S.
We also now have a logo for CloudMan
[Inline image 2]

___ 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 CloudMan release - Tophat does not work

[Mohammad Heydarian]

Cufflinks, Cuffcompare, and Cuffdiff are also failing to run because they
can not be found. I am using the newly released version of Cloudman 2.0 (
ami-118bfc78).

Any help would be appreciated.

Cheers,
Mo Heydarian


On Mon, Jul 8, 2013 at 5:02 PM, Ravpreet Setia wrote:

>  Some tools (tophat is one) are failing to run because they cannot be
> found. I have noticed that after launching a new instance with the latest
> AMI, the "//default" sym-links under /mnt/galaxy/tools
> point to a directory in /mnt/galaxyTools, which does not exist since this
> new AMI merged galaxyTools and galaxyData.
>
>  Additionally, even after manually fixing the symlink and the path in the
> env.sh file (it also references galaxyTools), running tophat would fail,
> although now, at least, it can find the program.
>
>  This document explains how the default symlink is used by Galaxy:
> http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies
>
>  Thanks for any suggestions.
>
>
>
>   From: Enis Afgan 
> Date: Sun, 30 Jun 2013 07:37:46 +0200
> To: Galaxy-dev 
> Subject: [galaxy-dev] Galaxy CloudMan release
>
>  *Last night, we released an update to Galaxy CloudMan.* CloudMan offers
> an easy way to get a personal and completely functional instance of Galaxy
> in the cloud in just a few minutes, without any manual configuration.
>
> *IMPORTANT - please read*
> Any new cluster will automatically start using this version of CloudMan.
> Existing clusters will be given an option to do an automatic update once
> the main interface page is refreshed. Note that this upgrade is a major
> version upgrade and thus the migration is rather complicated. The migration
> process has been automated but will take a little while to complete. If you
> have made customizations to your cluster in terms of adding file systems,
> upgrading the database, or similar, we do not recommend you perform the
> upgrade. Note that this upgrade comes with (and requires) a new AMI
> (ami-118bfc78), which will be automatically used if starting an instance
> via CloudLaunch <http://usegalaxy.org/cloudlaunch>.
>
>  *This update brings a large number of updates and new features, the most
> prominent ones being:*
>  - Unification of *galaxyTools* and *galaxyData* file systems into a
> single *galaxy* filesystem. This change makes it possible to utilize the
> Galaxy Tool Shed when installing tools into Galaxy.
> - Added initial support for Hadoop-type workloads
> - Added initial support for cluster federation via HTCondor
> - Added a new file system service for instance's transient storage,
> allowing it to be used across the cluster over NFS
> - Added a service for Galaxy Reports webapp
> - Added optional Loggly (loggly.com) based off-site logging support
>  - Added tags to all resources utilized by CloudMan
>
>  For more details on the new features, see the the 
> CHANGELOG<https://bitbucket.org/galaxy/cloudman/src/tip/CHANGELOG.md?at=default>and
>  for even more details see, all of 291
> commit 
> messages<https://bitbucket.org/galaxy/cloudman/commits/all?search=35baec1%3A8bbae3f>
>  from
> 7 contributors.
>
>  Enjoy and please let us know what you think,
>  Enis
>
>
>  P.S.
> We also now have a logo for CloudMan
> [image: Inline image 2]
>
>  ___ 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/

[galaxy-dev] Galaxy CloudMan release

[Enis Afgan]

*Last night, we released an update to Galaxy CloudMan.* CloudMan offers an
easy way to get a personal and completely functional instance of Galaxy in
the cloud in just a few minutes, without any manual configuration.

*IMPORTANT - please read*
Any new cluster will automatically start using this version of CloudMan.
Existing clusters will be given an option to do an automatic update once
the main interface page is refreshed. Note that this upgrade is a major
version upgrade and thus the migration is rather complicated. The migration
process has been automated but will take a little while to complete. If you
have made customizations to your cluster in terms of adding file systems,
upgrading the database, or similar, we do not recommend you perform the
upgrade. Note that this upgrade comes with (and requires) a new AMI
(ami-118bfc78), which will be automatically used if starting an instance
via CloudLaunch .

*This update brings a large number of updates and new features, the most
prominent ones being:*
- Unification of *galaxyTools* and *galaxyData* file systems into a single *
galaxy* filesystem. This change makes it possible to utilize the Galaxy
Tool Shed when installing tools into Galaxy.
- Added initial support for Hadoop-type workloads
- Added initial support for cluster federation via HTCondor
- Added a new file system service for instance's transient storage,
allowing it to be used across the cluster over NFS
- Added a service for Galaxy Reports webapp
- Added optional Loggly (loggly.com) based off-site logging support
- Added tags to all resources utilized by CloudMan

For more details on the new features, see the the
CHANGELOGand
for even more details see, all of 291
commit 
messages
from
7 contributors.

Enjoy and please let us know what you think,
Enis


P.S.
We also now have a logo for CloudMan
[image: Inline image 2]
<>___
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, CloudMan & nginx 1.4.0

[John Chilton]

I wanted to update CloudMan to use nginx 1.4.0 for web socket proxy
support, but I hit a problem. nginx-upload-module does not work with
nginx 1.4.0 and the author has no intention of continuing work on the
module.

https://github.com/vkholodkov/nginx-upload-module/issues/41

There is a patch that based on the comments in the above thread doesn't work:
http://paste.davromaniak.eu/index.php?show=110

And there are some related projects but I don't understand enough
about how Galaxy is interacting with nginx upload to know if they are
a promising replacement.

https://github.com/pgaertig/nginx-big-upload
https://github.com/agentzh/lua-resty-upload

It also kind of seems like nginx might provide some support for
handling uploads directly without that module, here is the example
from that thread:

location /upload {
  limit_except POST  { deny all; }

  client_body_temp_path  /tmp/;
  client_body_in_file_only   on;
  client_body_buffer_size128K;
  client_max_body_size   50M;
  proxy_pass_request_headers on;
  proxy_set_body $request_body_file;
  proxy_pass http://upstream; # will receive
file_name only
  proxy_redirect off;
}

Can the galaxy solution be adapted for this client_body_xxx style?

If not, has anyone looked at something like nginx-big-upload and
gotten it to work? I suppose this is not likely since nginx 1.4 just
came out, but it is worth asking.

If someone does figure it out someday, let me know and I can test and
update the CloudBioLinux/CloudMan stuff for whatever you figure out.

Thanks,
-John
___
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/cloudman failure handling

[Dannon Baker]

On Nov 12, 2012, at 10:23 AM, Jorrit Boekel  wrote:
> I was therefore looking for fault tolerance mechanisms in the galaxy project, 
> which I seem to remember existed. Somehow I can't find anything about it 
> right now though.
> 
> I've tested a little bit, and it seems that as soon as one reboots instances 
> or manually kills a job or task, the whole job is deleted and set to error 
> state. I am not that knowledgeable in cluster computing, so I don't really 
> know what handles what here, but this would be an ideal starting point to 
> learn something about SGE and queue handling. Is there any mechanism in place 
> that deals with node failure, network problems, etc? If not, would it be hard 
> to implement?

You're correct in that currently jobs will be set to error and need to be 
automatically rerun by the Galaxy user.  There isn't anything in place for 
automatic retry after spot instance failure, but this is definitely something 
we plan to implement in the near term - a generalized retry and resume 
mechanism will be useful for both cloud and local instances.

-Dannon
___
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] galaxy/cloudman failure handling

[Jorrit Boekel]

Dear list,

I would like to start using Amazon's spot pricing model for my
Galaxy/Cloudman instances (e.g. an on demand master node with spot instance
worker nodes). However, this means that Amazon at times of spot prices
higher than my set price limit will shutdown my instances without notion.

I was therefore looking for fault tolerance mechanisms in the galaxy
project, which I seem to remember existed. Somehow I can't find anything
about it right now though.

I've tested a little bit, and it seems that as soon as one reboots
instances or manually kills a job or task, the whole job is deleted and set
to error state. I am not that knowledgeable in cluster computing, so I
don't really know what handles what here, but this would be an ideal
starting point to learn something about SGE and queue handling. Is there
any mechanism in place that deals with node failure, network problems, etc?
If not, would it be hard to implement?

cheers,
jorrit boekel
___
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] galaxy cloudMan failed

[jiesh...@bioteam.net]

Hi, all
I just tried installing galaxy in amazon cloud following the instruction 
here:http://wiki.g2.bx.psu.edu/CloudMan.
Using this ami-da58aab3, I do not have http service after the instance 
is started. I logined into the instance and confirmed it. How should I 
troubleshoot it?


Could your guys ask Amazon to remove  
ami-561bc93f, 072133624695/galaxy-cloudman-2012-02-26 ? If it is not 
from galaxy, it is risky to have it. If user selects it, user most 
likely will give access key and secret key at launch time as is in 
instruction.  I used this one before I went to section 5 to find out I 
am not supposed to use it.



thanks

--
jason zhang
The BioTeam, Inc.
ja...@bioteam.net


___
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 Cloudman - How to analyse > 1TB data ?

[Wetzels, Yves [JRDBE Extern]]

Hi Enis

 

1.   I first created the LVM on 2 new volumes.

2.   Mounted the LVM

3.   I stopped all services (SGE, PostgreSQL, Galaxy).

4.   Copied all data on filesystem /mnt/galaxyData to the LVM

5.   Umounted /mnt/galaxyData

6.   Mounted LVM to /mnt/galaxyData

7.   Started all services

 

As I mentioned in my previous posts all seems to be ok but I received a 

 

WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with
extension 'coverage', using datatype from /mnt/galaxyData/tmp/tmpGx9fsi.

 

while running the "Groom" tool.

I didn`t know what to do at that time and started "messing" around
removing tmp files, restarting SGE etc.

I later received the same error on a newly created Galaxy Cloudman
instance with normal (<1TB size) galaxyData filesystem.

Greg Von Kuster replied to me I had to remove a duplicate value in the
datatypes.conf.xml file.

 

Hello Yves,

 

You have one or more entries in your datatypes_conf.xml file for a
datatype named "coverage"  These should be eliminated from your
datatypes.conf.xml file because they are not valid datatypes (unless you
have added proprietary datatypes to your Galaxy instance with this
extension).  They were originally in the datatypes.conf.xml.sample file
for datatype indexers\, but datatype indexers have been eliminated from
the Galaxy framework because datatype converters do the same thing.

 

Greg Von Kuster

 

Currently I am running multiple Galaxy Cloudman instances to circumvent
the 1 TB limit.

If I find some time I will redo the exercise with the LVM.

 

Kind Regards
Yves

 

From: Enis Afgan [mailto:eaf...@emory.edu] 
Sent: Sunday, 19 February 2012 23:50
To: Wetzels, Yves [JRDBE Extern]
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] Galaxy Cloudman - How to analyse > 1TB data ?

 

Hi Yves, 

When you create the LVM file system - are you composing it from the
volume that already contains the data (i.e., directory structure++
created by CloudMan) and then adding another volume into the LVM or
starting with 2 new, clean volumes? 

Maybe trying again and not messing with SGE at all would at least
resolve the SGE issue. Namely, SGE is on the root file system so it
should be fine as is. I'd suggest stopping Galaxy and PostgreSQL
services (from the CloudMan Admin), from the CLI, unmount galaxyData
file system and proceed to create the LVM. Mount the file system and
ensure the directories and the data that were there are still there. The
start back PostgreSQL and Galaxy services. See if it all comes up fine
and try adding a worker node if it does. 

 

Currently, CloudMan does not support composition of a file system from
multiple volumes but I would think that as long as you did not restart
the cluster and created the file system manually, things would work
fine. I've been thinking about why you're seeing the described behavior
and am not really sure so please let me know how the above process works
out.

 

 

 

On Thu, Feb 16, 2012 at 7:37 PM, Wetzels, Yves [JRDBE Extern]
 wrote:

Hi Brad

I did not restart the master CloudMan node.
I only restarted the services (Galaxy, PostgreSQL and SGE).
I do not have these problems without  creating the logical volume.

Kind Regards
Yves



Yves;
I'm hoping Enis can jump in here since he is more familiar with the
internals of CloudMan and may be able to offer better advice. I can tell
you what I see from your error messages.

> I used LVM2 to create the logical volume.

Does this involve stopping and restarting the master CloudMan node? The
error messages you are seeing look like SGE is missing or not properly
configured on the master node:

> 02/15/2012 11:22:08|  main|domU-12-31-39-0A-62-12|E|error opening file
> "/opt/sge/default/common/./sched_configuration" for reading: No such
> file or directory
[...]
> DeniedByDrmException: code 17: error: no suitable queues

which is causing the job submission to fail since it can't find the SGE
cluster environment to submit to. The strange thing is that SGE is
present in /opt on the main EBS store, so I wouldn't expect your
modified /mnt/galaxyData volume to influence this.

Since starting worker nodes appears to be fine, I'd focus on the main
instance manipulations you are doing. Perhaps some of the setup causes
the problem without creating the logical volume? This could help narrow
down the issue and hopefully get you running again.

Hope this helps,
Brad


___
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/

Re: [galaxy-dev] Galaxy Cloudman - How to analyse > 1TB data ?

[Enis Afgan]

Hi Yves,
When you create the LVM file system - are you composing it from the volume
that already contains the data (i.e., directory structure++ created by
CloudMan) and then adding another volume into the LVM or starting with 2
new, clean volumes?
Maybe trying again and not messing with SGE at all would at least resolve
the SGE issue. Namely, SGE is on the root file system so it should be fine
as is. I'd suggest stopping Galaxy and PostgreSQL services (from the
CloudMan Admin), from the CLI, unmount galaxyData file system and proceed
to create the LVM. Mount the file system and ensure the directories and the
data that were there are still there. The start back PostgreSQL and Galaxy
services. See if it all comes up fine and try adding a worker node if it
does.

Currently, CloudMan does not support composition of a file system from
multiple volumes but I would think that as long as you did not restart the
cluster and created the file system manually, things would work fine. I've
been thinking about why you're seeing the described behavior and am not
really sure so please let me know how the above process works out.



On Thu, Feb 16, 2012 at 7:37 PM, Wetzels, Yves [JRDBE Extern] <
ywet...@its.jnj.com> wrote:

> Hi Brad
>
> I did not restart the master CloudMan node.
> I only restarted the services (Galaxy, PostgreSQL and SGE).
> I do not have these problems without  creating the logical volume.
>
> Kind Regards
> Yves
>
>
> Yves;
> I'm hoping Enis can jump in here since he is more familiar with the
> internals of CloudMan and may be able to offer better advice. I can tell
> you what I see from your error messages.
>
> > I used LVM2 to create the logical volume.
>
> Does this involve stopping and restarting the master CloudMan node? The
> error messages you are seeing look like SGE is missing or not properly
> configured on the master node:
>
> > 02/15/2012 11:22:08|  main|domU-12-31-39-0A-62-12|E|error opening file
> > "/opt/sge/default/common/./sched_configuration" for reading: No such
> > file or directory
> [...]
> > DeniedByDrmException: code 17: error: no suitable queues
>
> which is causing the job submission to fail since it can't find the SGE
> cluster environment to submit to. The strange thing is that SGE is
> present in /opt on the main EBS store, so I wouldn't expect your
> modified /mnt/galaxyData volume to influence this.
>
> Since starting worker nodes appears to be fine, I'd focus on the main
> instance manipulations you are doing. Perhaps some of the setup causes
> the problem without creating the logical volume? This could help narrow
> down the issue and hopefully get you running again.
>
> Hope this helps,
> Brad
>
>
> ___
> 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/

Re: [galaxy-dev] Galaxy Cloudman - How to analyse > 1TB data ?

[Wetzels, Yves [JRDBE Extern]]

Hi Brad

I did not restart the master CloudMan node.
I only restarted the services (Galaxy, PostgreSQL and SGE).
I do not have these problems without  creating the logical volume.

Kind Regards
Yves


Yves;
I'm hoping Enis can jump in here since he is more familiar with the
internals of CloudMan and may be able to offer better advice. I can tell
you what I see from your error messages.

> I used LVM2 to create the logical volume.

Does this involve stopping and restarting the master CloudMan node? The
error messages you are seeing look like SGE is missing or not properly
configured on the master node:

> 02/15/2012 11:22:08|  main|domU-12-31-39-0A-62-12|E|error opening file
> "/opt/sge/default/common/./sched_configuration" for reading: No such
> file or directory
[...]
> DeniedByDrmException: code 17: error: no suitable queues

which is causing the job submission to fail since it can't find the SGE
cluster environment to submit to. The strange thing is that SGE is
present in /opt on the main EBS store, so I wouldn't expect your
modified /mnt/galaxyData volume to influence this.

Since starting worker nodes appears to be fine, I'd focus on the main
instance manipulations you are doing. Perhaps some of the setup causes
the problem without creating the logical volume? This could help narrow
down the issue and hopefully get you running again.

Hope this helps,
Brad


___
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 Cloudman - How to analyse > 1TB data ?

[Brad Chapman]

Yves;
I'm hoping Enis can jump in here since he is more familiar with the
internals of CloudMan and may be able to offer better advice. I can tell
you what I see from your error messages.

> I used LVM2 to create the logical volume.

Does this involve stopping and restarting the master CloudMan node? The
error messages you are seeing look like SGE is missing or not properly
configured on the master node:

> 02/15/2012 11:22:08|  main|domU-12-31-39-0A-62-12|E|error opening file
> "/opt/sge/default/common/./sched_configuration" for reading: No such
> file or directory
[...]
> DeniedByDrmException: code 17: error: no suitable queues

which is causing the job submission to fail since it can't find the SGE
cluster environment to submit to. The strange thing is that SGE is
present in /opt on the main EBS store, so I wouldn't expect your
modified /mnt/galaxyData volume to influence this.

Since starting worker nodes appears to be fine, I'd focus on the main
instance manipulations you are doing. Perhaps some of the setup causes
the problem without creating the logical volume? This could help narrow
down the issue and hopefully get you running again.

Hope this helps,
Brad
___
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 Cloudman - How to analyse > 1TB data ?

[Brad Chapman]

Yves;

> I am currently investigating if Galaxy Cloudman can help us in analyzing
> large NGS datasets.
> 
> I was first impressed by the simple setup, the autoscaling and
> useability of Galaxy Cloudman but soon ran into the EBS limit of 1 TB L
> 
> I thought to be clever and umounted the /mnt/galaxyData EBS volume,
> created a logical volume of 2 TB and remounted this volume to
> /mnt/galaxyData.

How did you create this volume? I know there are some tricks to get
around the 1Tb limit:

http://alestic.com/2009/06/ec2-ebs-raid

In the screenshot you sent it looks like Cloudman is a bit confused
about the disk size. The Disk Status lists 1.2Tb out of 668Gb, which
might be the source of your problems.

> All is green as you can see from the picture below but running a tool is
> not possible since Galaxy is not configured to work with logical volume
> I assume.

Can you describe what errors you are seeing?

> It is truly a waste having this fine setup (autoscaling) but this is not
> useable if there is not enough storage ?
> 
> Does anybody has experience with this ? Tips, tricks ...

The more general answer is that folks do not normally use EBS this way
since having large permanent EBS filesystems is expensive. S3 stores larger
data, up to 50Tb, at a more reasonable price. S3 files are then copied to a
transient EBS store, processed, and uploaded back to S3. This isn't as
automated since it will be highly dependent on your workflow and what
files you want to save, but might be worth exploring in general when
using EC2.

Hope this helps,
Brad
___
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/