|
||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
This fix does not resolve the following use cases
1. Multiple jenkins servers running in the same VPC using the same ami - needed when 1 jenkins cannot manage that many jobs and/or each team wants their own jenkins server
2. Multple labels using same ami
2.1 - Different instance sizes for different build jobs/labels (eg use 5 T2Medium and 4 Large of same ami)
2.2 - Different subnets used for different labels - all sorts of reasons to use multiple subnets (access control just being one of them)
2.3 - Different instance counts for different labels/builds - so can manage costs differently (eg 2 for nightly builds and 5 for release and 10 for CI) - this allows bunch of CI builds to not block a release build for instance, or for the long running nightly build to not interfere with a CI build.
Proposed solution - extend current fix of a tag to indicate this is a jenkins instance, to indicate it's a jenkins instance for a specific label - add labels to the EC2Tag.TAG_NAME_JENKINS_SLAVE_TYPE when instance started and match the label requested in isEc2ProvisionedSlave
Solves both 1 and 2.