Answers: <p>Generic answer yes, it is possible with a lot of work...</p>
  
  <p>Is it something wise to do? In my opinion no, you should convert your bare metal nodes to hypervisors with low maintenance and use common tooling to start slaves Virtual Machines on those hypervisors. </p>
  
Answers: CC BY-SA 3.0
Answers: 2018-02-26T00:15:10.817Z
Answers: Thanks for the honest answer... I like that idea.  I'm worried about certain things, but I think my best approach is to have a way to manually control the up/down of the blade IF it is needed.  from there I will put CoreOs on them using the PXE service on my host as well.  then jenkins can deploy docker on them and the state will belong to the docker image.
Answers: scott
Answers: CC BY-SA 3.0
Answers: 2018-01-25T21:31:15.683Z
Answers: 2018-01-25T21:31:15.683Z
Answers: Tensibai
Answers: <p>Jenkins is but a scheduler.
  It is oriented to respond to code changes, and do whatever you want.</p>
  
  <p>About IPMI, if you cannot follow @Tensibai's advice,
  I would suggest to wrap the operations at IPMI with something like ansible  (Depending on what you actually need to do there).</p>
  
  <p>Usually ipmi environment is used to TEST baremetal operations, in which case you have no other choice but use things like <code>ipmi_boot</code> or <code>ipmi_power</code> ansible modules, or actually write shell based ipmitool invocations to match incompatible hardware special saltos you need to do.
  Or even to use other "older generatino" things (chef, puppet, even cfengine etc.)</p>
  
  <p>You still may find some consolation in Foreman/Satellite to control BMs via ipmi using PXE boot, and all the other "oldies" technologies.</p>
  
  <p>All that of course, if you cannot actually wrap your BMs somehow to make them either k8s cluster with flexible slave-pods OR VMs, or something ... more "up-to-date" (Sometimes you can't I know).</p>
  
  <p>I believe if you don't have network/io constraints you should go with Kubernetes (a.k.a. k8s), and not with Docker.</p>
  
  <p>With both you can work with locally created images, but Kuberenets will allow you much more convenient housekeeping of containers, groups of containers, and even better - a "service", "operator" and other cool entities.</p>
  
  <p>Besides you can version control your deployments with Helm charts and many many many other nice toys.</p>
  
  <p>Good luck!</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-12T16:01:11.073Z
Answers: 2018-08-12T16:01:11.073Z
Answers: mvk_il
Body: <p>I have a setup with a bunch of blades that pxe boot into coreos using terraform/matchbox setup.  I currently control them all manually using ipmitool from my desktop.</p>
  
  <p>Is there a way to let jenkins control this?  </p>
  
  <p>an example use case would be if a bunch of different builds are being run and a new one is kicked off jenkins will know to use one of the slaves not running a build so it will power reset the machine and wait for it to come up and then run my docker stuff and the build.</p>
  
Tags: <jenkins><jenkins-plugins><terraform>
Title: Can jenkins control baremetal with ipmi
UserDisplayName: scott
ThreadText: # Can jenkins control baremetal with ipmi
  
  (Asked by: username_0 on 2018-01-25)
  
  I have a setup with a bunch of blades that pxe boot into coreos using terraform/matchbox setup. I currently control them all manually using ipmitool from my desktop.
  
  Is there a way to let jenkins control this?
  
  an example use case would be if a bunch of different builds are being run and a new one is kicked off jenkins will know to use one of the slaves not running a build so it will power reset the machine and wait for it to come up and then run my docker stuff and the build.
  
  **Tags:** jenkins, jenkins-plugins, terraform
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-01-25. Score: 3
  
  Generic answer yes, it is possible with a lot of work...
  
  Is it something wise to do? In my opinion no, you should convert your bare metal nodes to hypervisors with low maintenance and use common tooling to start slaves Virtual Machines on those hypervisors.
  
  > **Comments:**
  > **username_0**: Thanks for the honest answer... I like that idea.  I'm worried about certain things, but I think my best approach is to have a way to manually control the up/down of the blade IF it is needed.  from there I will put CoreOs on them using the PXE service on my host as well.  then jenkins can deploy docker on them and the state will belong to the docker image.  
  
  ---
  
  ### Answer by username_2 on 2018-08-12. Score: 0
  
  Jenkins is but a scheduler.
  It is oriented to respond to code changes, and do whatever you want.
  
  About IPMI, if you cannot follow @username_1's advice,
  I would suggest to wrap the operations at IPMI with something like ansible (Depending on what you actually need to do there).
  
  Usually ipmi environment is used to TEST baremetal operations, in which case you have no other choice but use things like `ipmi_boot` or `ipmi_power` ansible modules, or actually write shell based ipmitool invocations to match incompatible hardware special saltos you need to do.
  Or even to use other "older generatino" things (chef, puppet, even cfengine etc.)
  
  You still may find some consolation in Foreman/Satellite to control BMs via ipmi using PXE boot, and all the other "oldies" technologies.
  
  All that of course, if you cannot actually wrap your BMs somehow to make them either k8s cluster with flexible slave-pods OR VMs, or something ... more "up-to-date" (Sometimes you can't I know).
  
  I believe if you don't have network/io constraints you should go with Kubernetes (a.k.a. k8s), and not with Docker.
  
  With both you can work with locally created images, but Kuberenets will allow you much more convenient housekeeping of containers, groups of containers, and even better - a "service", "operator" and other cool entities.
  
  Besides you can version control your deployments with Helm charts and many many many other nice toys.
  
  Good luck!
  
  
  ---
  
  