BioCloudCentral - First Launch Not Working
Hi guys, For the past two days when I try to launch my CloudMan instance using http://biocloudcentral.herokuapp.com the first time I see an instance get up and running, but it doesn't mount my galaxyData volume and I can't get to the webpage <public DNS>/cloud. The webpage just says "Unable to connect. Firefox can't establish a connection to the server at ...". If I terminate the instance and relaunch through BioCloudCentral it seems to then start up fine. Any ideas? Is there any more information I can provide to help? Thanks, Greg
Hi Greg, This sounds like the availability zone issue. I am assuming you are restarting the same cluster (i.e., using the same name) and the instance that gets created may be created in a zone different from the one that the volume from the previous instantiation of the cluster was in. biocloudcentral does not know which zone your cluster was created in previously so it cannot request an instance in that zone. Obviously, this is a limitation of service and, thus far, we are mostly recommending it be used to start a cluster only the very first time. After the cluster creation, we recommend using the AWS console (which is easier to get going now because all the security group/key pair issues have been resolved). The underlying reason for not having this functionality built into biocloudcentral is because we did not want to keep user information in a database over time because it is somewhat sensitive data... Enis On Tue, Jan 24, 2012 at 2:39 PM, mailing list <margeemail@gmail.com> wrote:
Hi guys,
For the past two days when I try to launch my CloudMan instance using http://biocloudcentral.herokuapp.com the first time I see an instance get up and running, but it doesn't mount my galaxyData volume and I can't get to the webpage <public DNS>/cloud. The webpage just says "Unable to connect. Firefox can't establish a connection to the server at ...".
If I terminate the instance and relaunch through BioCloudCentral it seems to then start up fine.
Any ideas? Is there any more information I can provide to help?
Thanks,
Greg ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:
http://lists.bx.psu.edu/listinfo/galaxy-dev
To manage your subscriptions to this and other Galaxy lists, please use the interface at:
Thanks Enis. You are correct, that I'm restarting a cluster. Would it be possible for the user to enter their zone on the form? Or could CloudMan detect a problem, shutdown and try a different zone? (probably infeasible). Thanks again, Greg On Tue, Jan 24, 2012 at 9:08 AM, Enis Afgan <afgane@gmail.com> wrote:
Hi Greg, This sounds like the availability zone issue. I am assuming you are restarting the same cluster (i.e., using the same name) and the instance that gets created may be created in a zone different from the one that the volume from the previous instantiation of the cluster was in. biocloudcentral does not know which zone your cluster was created in previously so it cannot request an instance in that zone. Obviously, this is a limitation of service and, thus far, we are mostly recommending it be used to start a cluster only the very first time. After the cluster creation, we recommend using the AWS console (which is easier to get going now because all the security group/key pair issues have been resolved).
The underlying reason for not having this functionality built into biocloudcentral is because we did not want to keep user information in a database over time because it is somewhat sensitive data...
Enis
On Tue, Jan 24, 2012 at 2:39 PM, mailing list <margeemail@gmail.com> wrote:
Hi guys,
For the past two days when I try to launch my CloudMan instance using http://biocloudcentral.herokuapp.com the first time I see an instance get up and running, but it doesn't mount my galaxyData volume and I can't get to the webpage <public DNS>/cloud. The webpage just says "Unable to connect. Firefox can't establish a connection to the server at ...".
If I terminate the instance and relaunch through BioCloudCentral it seems to then start up fine.
Any ideas? Is there any more information I can provide to help?
Thanks,
Greg ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:
http://lists.bx.psu.edu/listinfo/galaxy-dev
To manage your subscriptions to this and other Galaxy lists, please use the interface at:
Both are feasible (and on the todo list) so lets just hope they get done sooner rather than later... Your comments help push it higher up on the list. On Tue, Jan 24, 2012 at 3:29 PM, mailing list <margeemail@gmail.com> wrote:
Thanks Enis.
You are correct, that I'm restarting a cluster.
Would it be possible for the user to enter their zone on the form? Or could CloudMan detect a problem, shutdown and try a different zone? (probably infeasible).
Thanks again,
Greg
Hi Greg, This sounds like the availability zone issue. I am assuming you are restarting the same cluster (i.e., using the same name) and the instance that gets created may be created in a zone different from the one that
volume from the previous instantiation of the cluster was in. biocloudcentral does not know which zone your cluster was created in previously so it cannot request an instance in that zone. Obviously,
On Tue, Jan 24, 2012 at 9:08 AM, Enis Afgan <afgane@gmail.com> wrote: the this is
a limitation of service and, thus far, we are mostly recommending it be used to start a cluster only the very first time. After the cluster creation, we recommend using the AWS console (which is easier to get going now because all the security group/key pair issues have been resolved).
The underlying reason for not having this functionality built into biocloudcentral is because we did not want to keep user information in a database over time because it is somewhat sensitive data...
Enis
On Tue, Jan 24, 2012 at 2:39 PM, mailing list <margeemail@gmail.com> wrote:
Hi guys,
For the past two days when I try to launch my CloudMan instance using http://biocloudcentral.herokuapp.com the first time I see an instance get up and running, but it doesn't mount my galaxyData volume and I can't get to the webpage <public DNS>/cloud. The webpage just says "Unable to connect. Firefox can't establish a connection to the server at ...".
If I terminate the instance and relaunch through BioCloudCentral it seems to then start up fine.
Any ideas? Is there any more information I can provide to help?
Thanks,
Greg ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:
http://lists.bx.psu.edu/listinfo/galaxy-dev
To manage your subscriptions to this and other Galaxy lists, please use the interface at:
Enis and Greg;
This sounds like the availability zone issue. I am assuming you are restarting the same cluster (i.e., using the same name) and the instance that gets created may be created in a zone different from the one that the volume from the previous instantiation of the cluster was in.
You are correct, that I'm restarting a cluster.
BioCloudCentral does try to consistently start in the same availability zone to avoid this issue. I added some fixes at the end of December that try to handle it. Can you describe the process you initially used to create the cluster before re-starting it with BioCloudCentral? I can think of a couple of ways this could be a problem: - If you start the initial instance of 'cluster name' via the Console or some other method, then subsequently start it up via BioCloudCentral. - If you start the initial instance of 'cluster name' via BioCloudCentral as one image type (saw micro), then subsequently restart it as a different image type (say large). The availability zone issue is a bit tricky, since not all image types are available in all availability zones. Additionally this differs between users. Greg, if you're consistently starting the same instance type via BioCloudCentral maybe something else is wrong and we can dig into it more to try and figure this out. We'd definitely like to make it as work as smoothly as possible. Thanks for the feedback, Brad
Hi Brad, I'm almost positive I originally started the instance via BioCloudCentral, and I always use Large. I've been exclusively using BioCloudCentral for a few weeks now. I hadn't noticed this issue until yesterday. I can definitely do whatever you need if you want to dig into the issue more. By the way, one weird thing I also noticed yesterday (maybe not related) is that my "security groups" screen is empty on the Amazon EC2 console even though my running instance says "Security Groups: CloudMan". So I guess the security group still exists but Amazon doesn't want to show it to me? (Just thought I'd mention that in case it's related). -Greg On Tue, Jan 24, 2012 at 9:53 AM, Brad Chapman <chapmanb@50mail.com> wrote:
Enis and Greg;
This sounds like the availability zone issue. I am assuming you are restarting the same cluster (i.e., using the same name) and the instance that gets created may be created in a zone different from the one that the volume from the previous instantiation of the cluster was in.
You are correct, that I'm restarting a cluster.
BioCloudCentral does try to consistently start in the same availability zone to avoid this issue. I added some fixes at the end of December that try to handle it. Can you describe the process you initially used to create the cluster before re-starting it with BioCloudCentral? I can think of a couple of ways this could be a problem:
- If you start the initial instance of 'cluster name' via the Console or some other method, then subsequently start it up via BioCloudCentral.
- If you start the initial instance of 'cluster name' via BioCloudCentral as one image type (saw micro), then subsequently restart it as a different image type (say large).
The availability zone issue is a bit tricky, since not all image types are available in all availability zones. Additionally this differs between users.
Greg, if you're consistently starting the same instance type via BioCloudCentral maybe something else is wrong and we can dig into it more to try and figure this out. We'd definitely like to make it as work as smoothly as possible.
Thanks for the feedback, Brad
Greg;
I'm almost positive I originally started the instance via BioCloudCentral, and I always use Large. I've been exclusively using BioCloudCentral for a few weeks now.
I hadn't noticed this issue until yesterday. I can definitely do whatever you need if you want to dig into the issue more.
Ah, so it was working okay for restarting clusters until recently? Do you know what the previous availability zone was, and what it is starting up now? It's possible that things could change at AWS over time in terms of availability of instances per zone, which might be causing this. Enis has some good ideas to work around these issues, but it would take a bit of work so I don't have a fix right now.
By the way, one weird thing I also noticed yesterday (maybe not related) is that my "security groups" screen is empty on the Amazon EC2 console even though my running instance says "Security Groups: CloudMan". So I guess the security group still exists but Amazon doesn't want to show it to me? (Just thought I'd mention that in case it's related).
So your security group is no longer present? This could definitely cause issues as well, although I don't believe it's related to the availability zone issue. I also don't know of any reason you wouldn't be able to see it in the console. If deleted, you'll need to restart/re-create it which should happen on a fresh start via BioCloudCentral. Thanks again for the feedback, Brad
Hi Brad, On Tue, Jan 24, 2012 at 9:22 PM, Brad Chapman <chapmanb@50mail.com> wrote:
Greg;
I'm almost positive I originally started the instance via BioCloudCentral, and I always use Large. I've been exclusively using BioCloudCentral for a few weeks now.
I hadn't noticed this issue until yesterday. I can definitely do whatever you need if you want to dig into the issue more.
Ah, so it was working okay for restarting clusters until recently? Do you know what the previous availability zone was, and what it is starting up now?
I didn't look at the availability zones. I think I'm normally in US east? I'll pay attention to that from now on.
By the way, one weird thing I also noticed yesterday (maybe not related) is that my "security groups" screen is empty on the Amazon EC2 console even though my running instance says "Security Groups: CloudMan". So I guess the security group still exists but Amazon doesn't want to show it to me? (Just thought I'd mention that in case it's related).
So your security group is no longer present? This could definitely cause issues as well, although I don't believe it's related to the availability zone issue. I also don't know of any reason you wouldn't be able to see it in the console.
If deleted, you'll need to restart/re-create it which should happen on a fresh start via BioCloudCentral.
It just doesn't show the security group, but when I start instances, it does say it's using the cloudman security group. I don't know how CloudMan could be working if I truly don't have a security group, right? I'm assuming it's an issue with Amazon's interface. -Greg
participants (4)
-
Brad Chapman -
Enis Afgan -
Enis Afgan -
mailing list