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

0 vote

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.

0 vote

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 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?

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?

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
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,341 views 0 5
Read article

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