Biocloudcentral - First Launch Not Working

Question: Biocloudcentral - First Launch Not Working

6.9 years ago by

mailing list • 840 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

galaxy • 1.0k views

ADD COMMENT • link •

modified 6.9 years ago by Enis Afgan • 690 • written 6.9 years ago by mailing list • 840

6.9 years ago by

mailing list • 840

mailing list • 840 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

ADD COMMENT • link written 6.9 years ago by mailing list • 840

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.

ADD REPLY • link written 6.9 years ago by Enis Afgan • 680

Enis and Greg; 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

ADD REPLY • link written 6.9 years ago by Brad Chapman • 240

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

ADD REPLY • link written 6.9 years ago by mailing list • 840

Greg; 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. 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

ADD REPLY • link written 6.8 years ago by Brad Chapman • 240

Hi Brad, 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. 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

ADD REPLY • link written 6.8 years ago by mailing list • 840

6.9 years ago by

Enis Afgan • 690

United States

Enis Afgan • 690 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

ADD COMMENT • link written 6.9 years ago by Enis Afgan • 690

Please log in to add an answer.

Similar posts • Search »