|
||||||||||||||
|
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 jenkinsci-issues+unsubscr...@googlegroups.com.
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.