Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-7960

EC2 Nodes which share an AMI ID get the wrong labels

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Minor
    • Resolution: Fixed
    • ec2-plugin
    • None

    Description

      We have two separate projects which we build with Hudson. We would like to use the same AMI to build both projects. We would:

      1. Create Setting1 which uses AMI1, with label "project1", and a custom init script appropriate for project 1.
      2. Create Setting2, which ALSO uses AMI1, with label "project2", and a custom init script appropriate for project 2.

      The user interface allows us to do this. However, when we start up an instance of "project2", the label(s) from "project1" are erroneously applied to it instead.

      We currently work around this by using a separate AMI for setting2, but that's a bit kludge and doesn't scale well.

      Attachments

        Activity

          Code changed in jenkins
          User: Kevin P. Fleming
          Path:
          src/main/java/hudson/plugins/ec2/EC2Cloud.java
          src/main/resources/hudson/plugins/ec2/EC2Cloud/computerSet.jelly
          src/main/resources/hudson/plugins/ec2/SlaveTemplate/config.jelly
          src/test/java/hudson/plugins/ec2/SlaveTemplateTest.java
          http://jenkins-ci.org/commit/ec2-plugin/803dfea25551d92453e99fd39e7e366d41007592
          Log:
          Change primary template identification to be its name, not its AMI.

          Many useful configurations will have multiple slave templates that use
          the same AMI (but differ in other aspects). This patch changes various
          parts of the code to properly identify templates by their names (in the
          'description' field) instead of their AMI. As an example, the manual slave
          provisioning button, before this patch, would allow the user to select a
          template from a drop-down list, but then launched the slave using the
          template's AMI, which could have resulted in the wrong template being
          used for the launch. This patch also changes the global config page so
          that the 'description' field is the first field in each template
          definition, to emphasize its importance.

          Addresses JENKINS-7960 and JENKINS-15158.

          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kevin P. Fleming Path: src/main/java/hudson/plugins/ec2/EC2Cloud.java src/main/resources/hudson/plugins/ec2/EC2Cloud/computerSet.jelly src/main/resources/hudson/plugins/ec2/SlaveTemplate/config.jelly src/test/java/hudson/plugins/ec2/SlaveTemplateTest.java http://jenkins-ci.org/commit/ec2-plugin/803dfea25551d92453e99fd39e7e366d41007592 Log: Change primary template identification to be its name, not its AMI. Many useful configurations will have multiple slave templates that use the same AMI (but differ in other aspects). This patch changes various parts of the code to properly identify templates by their names (in the 'description' field) instead of their AMI. As an example, the manual slave provisioning button, before this patch, would allow the user to select a template from a drop-down list, but then launched the slave using the template's AMI, which could have resulted in the wrong template being used for the launch. This patch also changes the global config page so that the 'description' field is the first field in each template definition, to emphasize its importance. Addresses JENKINS-7960 and JENKINS-15158 .
          francisu Francis Upton added a comment -

          Fixed by patch from Kevin Fleming

          francisu Francis Upton added a comment - Fixed by patch from Kevin Fleming
          sit Emil Sit added a comment -

          This does not work properly still with instance caps: instance caps are calculated solely based on AMI (see EC2Cloud#addProvisionedSlave), not based on template. So, if you have two types of slaves based on a common AMI but intended for different purpose, if the instance cap is low on one type, it may never get provisioned if the other type has many outstanding instances.

          I'm not sure an easy way around this particular issue; perhaps the template information could be stored on a provisioned instance as a tag?

          sit Emil Sit added a comment - This does not work properly still with instance caps: instance caps are calculated solely based on AMI (see EC2Cloud#addProvisionedSlave), not based on template. So, if you have two types of slaves based on a common AMI but intended for different purpose, if the instance cap is low on one type, it may never get provisioned if the other type has many outstanding instances. I'm not sure an easy way around this particular issue; perhaps the template information could be stored on a provisioned instance as a tag?

          People

            francisu Francis Upton
            codyc Codyc
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: