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

Openstack Cloud Plugin does not wait until the user data script completes

      I created a script in "Openstack User Data" section in Jenkins Management that is supposed to load some files to the new node before any jenkins job can be launched.
      it's a shell script that calls a python script at the end.

      I see that sometimes the jenkins job is started on the new node BEFORE the init script completes, which is not acceptable.

      are there any examples available on how to make sure "Openstack User Data" script completes before any jobs are started on that node?

          [JENKINS-30183] Openstack Cloud Plugin does not wait until the user data script completes

          Donald Morton added a comment -

          How do you control when cloud-init creates a user?

          Donald Morton added a comment - How do you control when cloud-init creates a user?

          d1morto Here's how we do it in our various environments.

          We pass a user-data script that does what is explained in the README in the following location.

          https://github.com/zephyrproject-rtos/ci-management/tree/master/jenkins-scripts

          I'll note we do this for several different Jenkins systems that we support

          Andrew Grimberg added a comment - d1morto Here's how we do it in our various environments. We pass a user-data script that does what is explained in the README in the following location. https://github.com/zephyrproject-rtos/ci-management/tree/master/jenkins-scripts I'll note we do this for several different Jenkins systems that we support

          Joshua Harlow added a comment -

          Ya, that idea is similar to what I'm doing at godaddy as well.

          Its not ideal, but basically using a shell script to add the user (and making sure adding the user last) will at least ensure jenkins can't login until the rest of the user script is finished...

          Best I've seen so far (though IMHO far from the best it could be).

          Joshua Harlow added a comment - Ya, that idea is similar to what I'm doing at godaddy as well. Its not ideal, but basically using a shell script to add the user (and making sure adding the user last ) will at least ensure jenkins can't login until the rest of the user script is finished... Best I've seen so far (though IMHO far from the best it could be).

          harlowja, No good news from cloud-init land?

          Oliver Gondža added a comment - harlowja , No good news from cloud-init land?

          harlowja it works pretty well actually. The one I linked is one of our simpler setups. Our most complex one is at:

          https://github.com/opendaylight/releng-builder/tree/master/jenkins-scripts

          Though I think the README is a little outdated since we're using the jenkins-init-script.sh pattern that was mentioned in the previous one I linked.

          It gives us some extra flexibility in our instance management so we don't have have to be regularly respinning packer builds for small configuration tweaks.

          Andrew Grimberg added a comment - harlowja it works pretty well actually. The one I linked is one of our simpler setups. Our most complex one is at: https://github.com/opendaylight/releng-builder/tree/master/jenkins-scripts Though I think the README is a little outdated since we're using the jenkins-init-script.sh pattern that was mentioned in the previous one I linked. It gives us some extra flexibility in our instance management so we don't have have to be regularly respinning packer builds for small configuration tweaks.

          Oliver Gondža added a comment - - edited

          Here is an idea how to implement it in a way that is easy to integrate with the plugin and is portable to all flavors of user-data including the situation when there is none. Openstack plugin will define one more macro that would be a file path inside remoteFs directory. The author of the user data script will write there a value depending on progress (running/completed/failed?) and openstack cloud plugin would wait for it to say completed before it starts launching. The plugin can tell if there is some setup logic to wait for by detecting the variable in user data (no matter what language it uses) and checking the file content in OS independent way should not be such a problem either (though, it would require to intercept ssh-slaves launching logic a bit). This will work even when nodes can not reach the master (easily) due to network restrictions or SSL verification.

          Oliver Gondža added a comment - - edited Here is an idea how to implement it in a way that is easy to integrate with the plugin and is portable to all flavors of user-data including the situation when there is none. Openstack plugin will define one more macro that would be a file path inside remoteFs directory. The author of the user data script will write there a value depending on progress (running/completed/failed?) and openstack cloud plugin would wait for it to say completed before it starts launching. The plugin can tell if there is some setup logic to wait for by detecting the variable in user data (no matter what language it uses) and checking the file content in OS independent way should not be such a problem either (though, it would require to intercept ssh-slaves launching logic a bit). This will work even when nodes can not reach the master (easily) due to network restrictions or SSL verification.

          olivergondza That sounds like folks would have to modify their current scripts (if they have anything even currently working). The phone home bit that was suggested would seem like a binary toggle (default false) that someone would set as an option to the template configuration.

          IIRC the JClouds plugin itself implements this pattern now. Doing so for the OpenStack plugin would put enabling it at the discretion of the admin configuring the instance template.

          If you do add in something like what you're proposing I would hope that's it's a toggle to enable the feature.

          Andrew Grimberg added a comment - olivergondza That sounds like folks would have to modify their current scripts (if they have anything even currently working). The phone home bit that was suggested would seem like a binary toggle (default false) that someone would set as an option to the template configuration. IIRC the JClouds plugin itself implements this pattern now. Doing so for the OpenStack plugin would put enabling it at the discretion of the admin configuring the instance template. If you do add in something like what you're proposing I would hope that's it's a toggle to enable the feature.

          I do not quite see how would you toggle any of the two features from plugin. As I understand, the plugin would need to manipulate the cloud-init scripts on the fly with something like https://cloudinit.readthedocs.io/en/latest/topics/examples.html#call-a-url-when-finished? jclouds plugin does not seem to do it so users are required to toggle that on modifying their cloud-init scripts anyway. Do I miss something, tykeal?

          I still have a mild preference of marker file over ping url. The latter would be more familiar to users, though...

          Oliver Gondža added a comment - I do not quite see how would you toggle any of the two features from plugin. As I understand, the plugin would need to manipulate the cloud-init scripts on the fly with something like https://cloudinit.readthedocs.io/en/latest/topics/examples.html#call-a-url-when-finished? jclouds plugin does not seem to do it so users are required to toggle that on modifying their cloud-init scripts anyway. Do I miss something, tykeal ? I still have a mild preference of marker file over ping url. The latter would be more familiar to users, though...

          I would have to setup a test system with JClouds installed again, but IIRC the toggle was on a per template basis and enabling it would cause that particular template to not attempt to do an connection to the instance until it had received the call back to a "phone home" URL. How that phone home gets triggered is left up to the admin creating the actual image being launched, not the the Jenkins system.

          Here's the info from the JClouds plugin: https://wiki.jenkins-ci.org/display/JENKINS/JClouds+Plugin#JCloudsPlugin-Usingthenewphone-homefeature

          You'll notice that they aren't saying that they're manipulating your cloud-init, they're stating that they delay the connection setup until the POST is received.

          Here's the webhook code for it https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/src/main/java/jenkins/plugins/jclouds/internal/PhoneHomeWebHook.java

          As to the latter being more familiar to users. I'm not so certain on that. Since most folks are likely using cloud-init to work with, the phone_home feature has been in there for a fairly long time now it's just a matter of things being written to take advantage of it.

          Andrew Grimberg added a comment - I would have to setup a test system with JClouds installed again, but IIRC the toggle was on a per template basis and enabling it would cause that particular template to not attempt to do an connection to the instance until it had received the call back to a "phone home" URL. How that phone home gets triggered is left up to the admin creating the actual image being launched, not the the Jenkins system. Here's the info from the JClouds plugin: https://wiki.jenkins-ci.org/display/JENKINS/JClouds+Plugin#JCloudsPlugin-Usingthenewphone-homefeature You'll notice that they aren't saying that they're manipulating your cloud-init, they're stating that they delay the connection setup until the POST is received. Here's the webhook code for it https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/src/main/java/jenkins/plugins/jclouds/internal/PhoneHomeWebHook.java As to the latter being more familiar to users. I'm not so certain on that. Since most folks are likely using cloud-init to work with, the phone_home feature has been in there for a fairly long time now it's just a matter of things being written to take advantage of it.

          I though so after reading the code. The thing is the machine needs to initiate the ping and there is no way for the plugin to get that arranged on its own. You need to change your cloud-init scripts or images.

          As to the latter being more familiar to users. I'm not so certain on that. Since most folks are likely using cloud-init to work with, the phone_home feature has been in there for a fairly long time now it's just a matter of things being written to take advantage of it.

          So we seem to be on the same page here.

          Oliver Gondža added a comment - I though so after reading the code. The thing is the machine needs to initiate the ping and there is no way for the plugin to get that arranged on its own. You need to change your cloud-init scripts or images. As to the latter being more familiar to users. I'm not so certain on that. Since most folks are likely using cloud-init to work with, the phone_home feature has been in there for a fairly long time now it's just a matter of things being written to take advantage of it. So we seem to be on the same page here.

            olivergondza Oliver Gondža
            alskor Alex Java
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: