nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Roy Penn

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!

Accepted answers

All comments

Przemek Bruski

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.

Roy Penn

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.

Przemek Bruski

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.

Duane King

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?

Przemek Bruski

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?

Duane King

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.

Przemek Bruski

Please vote here: https://jira.atlassian.com/browse/BAM-14354

Duane King

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

Duane King

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.

Duane King

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bamboo

aws