nikolay, i forgot to mention that it does work across a reboot. it took me awhile but i finally figured it out with some help from a java guru (thanks jason) to get it to work. i really like this one because it works on demand and within a discrete step within the build process.
xterm-one On Wed, Aug 7, 2013 at 10:43 AM, Phil Soliz <[email protected]> wrote: > Hello Nikolay, > > i think that i might have a plugin to do what you want. i tried to add > this plugin awhile back but didnt get a positive reply for its addition. > > the plugin name is vmware-esx-plugin and i built this so that i could > revert the vm to a specific state, before or after the build, so that i > could do repetitive testing. i would still like to add this plugin to the > jenkins repo but i havent really pushed it. > > my username is xterm-one and its location is xterm-one/vmware-esx-plugin. > > i also had a bank of hardware machines that i used it on to revert to a > specific state using a bootable cd (such as hiren) to revert to a specific > state using ghost. > > xterm-one > > > On Wed, Aug 7, 2013 at 10:17 AM, James Nord (jnord) <[email protected]>wrote: > >> Hi Nickolay,**** >> >> ** ** >> >> For virtual you can somewhat accomplish this with the Cloudbees auto >> scaling plugin.**** >> >> ** ** >> >> You create a pool of virtual machines, and then assign one to your build >> which you can access via SSH. You can do whatever you want to to this VM >> as this VM is not the slave VM – although there are no additional states >> available.**** >> >> If you feel like coding then you could probably do something similar with >> the vSphere cloud plugin, or the labmanager plugin.**** >> >> ** ** >> >> I have a plan to do something similar for physical machines – have a pool >> – be able to obtain one (or more), control the OS to revert to a snapshot >> etc.. but have some other things I need to accomplish first, and the extra >> snapshots will require UCS hardware and some SAN – yet to be determined.* >> *** >> >> ** ** >> >> /James**** >> >> ** ** >> >> **** >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Jason Swager >> *Sent:* 07 August 2013 15:34 >> *To:* [email protected] >> *Subject:* Re: Persistent slave**** >> >> ** ** >> >> As far as I know, this isn't possible. The basic slave architecture >> requires a constant, unbroken connection to the slave. If the connection >> is broken, the build is considered a failure. There might be ways to >> handle this in the slave classes, but if there is, I'm not aware of them. >> **** >> >> ** ** >> >> See this Stackoverflow >> Question<http://stackoverflow.com/questions/5543413/reconfigure-and-reboot-a-hudson-jenkins-slave-as-part-of-a-build>that >> deals with the same issue. There are workarounds, but none quite as >> elegant as a rebootable slave. >> >> On Wednesday, August 7, 2013 7:18:17 AM UTC-7, Nickolay Rumyantsev wrote: >> **** >> >> Hi!**** >> >> ** ** >> >> I am looking for a way to create a new kind of a slave (or a channel or >> smth) for defining a set of testing machines (virtual and real) in my >> jenkins. It must meet the following requirements:**** >> >> 1. It should provide additional states like: rebooting, broken, >> available (and probably some others). The logic of selecting the current >> state exists already and is related to tha testing process.**** >> 2. The job that is being executed on such kind of the slave should be >> tolerant to slave reboot (until the specified timeout is exceeded) so the >> build will proceed after reboot normally.**** >> >> I had a look a the exiting plugins and it looks for me that there is no >> similar plugin for now.**** >> >> ** ** >> >> Can you please tell me if is it possible and if it is so suggest what >> plugin can I take as a base or which extension points should I look at to >> start development?**** >> >> ** ** >> >> Thanks,**** >> >> Nickolay**** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> **** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
