8 Replies Latest reply on Jan 25, 2014 5:52 AM by Steffen Kreis

    Aborting Provisioning Job from Preinstall Script

      Hello,

       

      I've got a use case I'm trying to figure out the best possible solution to.  During our provisioning, I am checking are series of items on the hardware to make sure it is ok to provision.  If any one of those criteria's are not OK, I want to cancel the provisioning job.

       

      I've got a pre-install script that is working well in "pausing" the provisioning job, but I'd like to take it a step forward.  RIght now, when I exit, it's exiting BMI on the preboot image (it's a linux preboot).  My pre-boot environment then sleeps for 2 minutes and starts BMI back up.  It then tries to run the script again, fails, and loops in this until the job times out.

       

      Is it possible, from a pre-install script, to abort the provisioning job if it exits?  In doing so, I'd like to return a useful message in the log.

       

      Thanks!

        • 1. Re: Aborting Provisioning Job from Preinstall Script
          Steffen Kreis

          Hi,

           

          i believe that when your Pre-Install script exits with anything other than 0, than the provisioning job will be aborted.

          At least this is the behavior in our WinPE based Provisioning environment.

          But you say, yours is just restarting the script ?

           

          Also the items that you log out with your script, will be in the Job-Run Log so you can send back a meaningful message.

           

          Steffen

          • 2. Re: Aborting Provisioning Job from Preinstall Script

            That may be the case with Windows, but it doesn't appear to be the case on the Unix BMI.  When I exit with a non-zero return code, it exits BMI on the host, but the job continues running on the app server.  As soon as BMI starts up again, it runs the pre-install script again, and continues on in that loop.

             

            I haven't tried it with a Windows Pre-Boot- but I could.  Unfortunately, WinPE isn't really an option for us to use as our pre-boot environment.

            • 3. Re: Aborting Provisioning Job from Preinstall Script
              Steffen Kreis

              This is weird,

               

              but when the script exits with 0 then this step is treated as successful by the Provisioning-Job ?

              Any other Returncode isn't recognized by the Job and it will stay in that step forever ?

               

              Steffen

              • 4. Re: Aborting Provisioning Job from Preinstall Script

                It's weird.  It doesn't treat it as a success or failure.  It honestly just treats it like it didn't even run.  Here is the log output

                 

                Participant,Type,Date,Message

                "Run at Jan 24, 2014 11:02:38 AM",Info,"Jan 24, 2014 11:02:39 AM",Started running the job 'RHEL_6.2' with priority 'NORMAL' on application server 'bsa403'(2)

                testing123,Info,"Jan 24, 2014 11:02:39 AM",Running provisioning job with data store: Lab-Linux

                testing123,Info,"Jan 24, 2014 11:02:39 AM",pxe image file: Boot_Images\preboot\preboot.cpio.gz

                "Run at Jan 24, 2014 11:02:38 AM",Info,"Jan 24, 2014 11:02:40 AM",Executing work item Provision Job:PollForProvisionedWorkItem;  on application server: bsa403

                testing123,Info,"Jan 24, 2014 11:02:42 AM",+ echo 'Switch Boot Image Done'

                Switch Boot Image Done

                 

                "Run at Jan 24, 2014 11:02:38 AM",Info,"Jan 24, 2014 11:02:42 AM",Starting Switch Boot Image

                testing123,Info,"Jan 24, 2014 11:03:19 AM",+ exit 10

                 

                testing123,Info,"Jan 24, 2014 11:04:59 AM",+ exit 10

                 

                My preboot script is simply "Exit 10" to recreate the issue.

                 

                Sounds like this may be a bug?  I'll open a ticket if so.  I was just hoping that it was something I wasn't doing correctly.

                • 5. Re: Aborting Provisioning Job from Preinstall Script

                  Forgot to mention, on the preboot side, we call BMI.  If BMI exits, we sleep for 2 minutes and then restart it.

                  • 6. Re: Aborting Provisioning Job from Preinstall Script
                    Steffen Kreis

                    Hang on... If your script loops around bmi, then it actually never finishes ??

                     

                    So your loop script finishes fine when your real script exits with 0. But when your real script fails your outer loop script just keeps on trying and actually never finishes, so that step never completes in BSA.

                     

                    Is this maybe what's happening here ??

                    • 7. Re: Aborting Provisioning Job from Preinstall Script

                      I dont think so.  Anything outside of BMI the application server is completely oblivious to.  Inside of the pre-install script there are no loops.

                       

                      BMI starts up and sits in a waiting state until a provision job starts.  Once a provision job starts for the given mac address, BMI starts communicating with the application server on what it's next steps are.

                       

                      In my case, it's executing a pre-install command that is simply Exit 10.  When it hits this, the pre-install script is complete and BMI sends back a return code of 10 to the application server.  At that point, I would expect the provisioning job to fail because it received a none 0 return code.  However, it job continues to run.  It appears that if a pre-install script is

                       

                      Eventually, BMI restarts from the exit code and it attempts to execute that same exit 10 pre-install script since the job has neither passed that step successfully or failed due to a non-zero.

                      • 8. Re: Aborting Provisioning Job from Preinstall Script
                        Steffen Kreis

                        Okay, i see.....

                         

                        Still sounds really strange, so a Ticket with Support might be the best way to go forward.

                         

                        Steffen