Bamboo refuses to do builds, despite knowing it should spin up a new agent.

We have a big issue where suddenly our Bamboo based CI has stopped working at all, and our research shows that this is due to Bamboo itself mistakenly detecting our AWS based EC2 instances deployed in our different environments in AWS and thinking they are build agents when that is not the case, even though the bamboo system itself claims they are NOT build agents and seems to know the difference.

This is a BIG defect in bamboo that is currently blocking all of our build and CI efforts, and has our entire software development process blocked as we depend on TDD and the CI and Bamboo is now activly refusing to spawn a build agent to handle our builds.

Let me repeat this: Bamboo detects these 2 EC2 instances are not affiliated with our Atlassian Bamboo based CI, but still refuses to load an agent becouse it still counts them against our limit of agents. So its smart enough to detect this, but too dumb to ignore them?

Log:

Feb 14, 2014 2:31:31 PM No instances will be started: there are 2 unknown instances running on your account, 1 is allowed by your configuration. Please adjust the configuration or terminate the instances.

These 2 detected EC2 instances are dev/test related deployments of our software and are not affiliated with Atlassian in any way. The error even shows that Bamboo knows this, yet despite the fact that it knows this, it still counts them as related even though they are using different images and have no affiliation with Atlassian in any way. Why?

Due to this defect in Atlassian Bsamboo we are currently unable to do a single build, and all CI efforts are blocked, becouse Atlassian Bamboo is refusing to spin up a new agent to handle them.

Atlassian Bamboo is finding our current EC2 based environments for our product - deployed as part of AWS Elastic Beanstalk in this case - and mistakenly thinks these booted images for our dev environment are build agents from Bamboo, but they are not, and as they are not even the correct AMI to support such a thing this makes no sense at all.

Of course if all we wanted to use AWS for was bamboo build agents we could simply un-deploy our production and development AWS applications but that is not an option. You can't expect us to not have a production environment in order to use this CI product, as the very REASON you have CI is to have something to deploy to production.


Given that we are paying customers, this is a very big issue.

Please help!

5 answers

This widget could not be displayed.

We are looking into making the detection smarter in the next release (for OnDemand, it means it should be available within a month or so).

For now, the only option is to set the unknown instance limit to the amount of prod instances you have running on your account.

Why don't you at least tell people to do this? This is not documented anywhere we could find.

Or even better, make the default not care about the number of non-bamboo instances? It should not care how many non-bamboo instances I have deployed, as they are not related to my bamboo usage.

This widget could not be displayed.

Or even better, make the default not care about the number of non-bamboo instances? It should not care how many non-bamboo instances I have deployed, as they are not related to my bamboo usage.

So the problem is that AWS does not let people tag the instance as "Mine" when you're starting it. You can only do it after the instance has started. Additionally, AWS does not guarantee that Spot instance requests will not be resent multiple times due to network errors . That's why the setting is in place. We've come up with a way to avoid all that, but it's not yet in place.

This widget could not be displayed.

This in my humble opinion seems to be an artifact of your of your licening model of arbitraging AWS owned resources, not a direct AWS issue itself.

Also, We are not even using "spot" instances; we are only using elastic instances. So your answer doesnt make a lot of sense to me unless you are making the statement that elastic instances are just "spot" instances under the hood. Is that the case?

Also, We are not even using "spot" instances; we are only using elastic instances.

Tagging (related to all resources) and request non-idempotency (related to spot instances and EBS volumes) are two separate issues.

This in my humble opinion seems to be an artifact of your of your licening model of arbitraging AWS owned resources, not a direct AWS issue itself.

I assume this opinion is backed by AWS documentation showing that you can start an instance and tag it in a single step?

This widget could not be displayed.

Since you have already formally admitted this is an issue, I am closing this thread as we have a work around.

That stated, I ask that you create a action item and document both this issue and the fix somewhere public so that others may not be blocked as we were.

When I load that page, I am not authorized to vote.

As you can clearly see from the fact my name shows up and my picture is displayed, I am in fact logged in to my account. In addition, this account is merged with the support account I *had* so per your site, I have to use it for both.

Are you logged in?

This widget could not be displayed.

Per my earlier comments this is still an issue and you have not fixed anything yet.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

140 views 1 3
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you