Add Reconnect and Revert Idle Action#90
Conversation
- Added idle action to vSphereCloudSlave and vSphereCloudProvisionedSlave for Reconnect and Revert. - When selected, the VM will reconnect it's computer to Jenkins when it's disconnected. When a snapshot is specified, it will be reverted to at startup (default functionality in the plugin).
|
Hi, e.g. How does "Reconnect and Revert" differ from "Revert and Reset"? What's the point of one if we've got the other? Lastly, are you quite sure this code achieves what is claimed in the help text? It's not obvious (at least, it isn't obvious to me) how calling "slaveComputer.connect(false)" results in the revert happening. |
|
Hi, I agree "littering" the plugin with different ways of achieving the same result is bad, but in this case I don't want to mess up someone else's workflow if they depend on any of these other idle actions or perhaps simply don't want the slave reconnected. If you think it'd be preferable to merely update the existing option for "Revert" to do a Reconnect and then Revert, I could do that. But again, I don't want to change functionality when a user may depend on it. I'm completely confident the code achieves what is claimed, I'm using it right now. Look at the link above, which shows the snapshot revert being done in |
|
Hmm, that's interesting - we also want a "fresh environment for every job" but in our setup that's done by destroying the VM once it's been used and spinning up a fresh one (and hence waiting for it to boot up) each time. ...and on the subject of "time", I don't have much of it right now, so I can't easily do a merge and release at present. |
|
Hi Peter,
I had some other things I wanted to discuss, but figured they were better
outside of the PR. First and foremost, I wanted to say thank you for being
a maintainer of a public repo and using scrutiny when receiving PRs. I've
worked with enough Jenkins plugins that didn't have maintainers that did
this, and it always ended badly (bugs, NPE's....).
I wanted to ask you a little about your setup, if you don't mind.
Originally I did what you're talking about, where we'd use VM templates in
the cloud configuration. How do you destroy your VMs, do you just set a
low idle termination timeout? In this case you get fresh VMs pretty often
but not for every job? Also, how do you let the nodes get provisioned this
way? Do you just let the NodeProvisioner do its thing where when a job
comes in against a label that you've defined in a slave template, then you
wait for it to get provisioned? I have done this with the EC2 Plugin with
Jenkins before and it worked great, but I found in this plugin it takes
forever for nodes to be provisioned for me. One last question, what do you
use for your storage array in VMware? Is it running flash/ssd drives?
We're running 15K SAS drives in a RAID (10?) array, and they are dog slow
when I have around 25 VMs running. Specifically the operating systems
coming up and going down were killing my performance, so I had to get
creative and realized that reverting to snapshots (and having live running
snapshots) was much more performant. If you have SSD's, I'm willing to bet
the OS spinning up isn't a problem. It appears Travis CI does this and it
works quite well for them. If you don't mind explaining a little more how
you use the plugin exactly, I'd truly appreciate it. I can do the same for
you if you'd like.
Cheers,
-Ray
…On Tue, Mar 13, 2018 at 11:22 AM, Peter Darton ***@***.***> wrote:
Hmm, that's interesting - we also want a "fresh environment for every job"
but in our setup that's done by destroying the VM once it's been used and
spinning up a fresh one (and hence waiting for it to boot up) each time.
Sounds like your solution achieves much the same aims, but faster - I'll
have to write myself a TODO item to take a look at this when I have time ;-)
...and on the subject of "time", I don't have much of it right now, so I
can't easily do a merge and release at present.
i.e. I *will* merge this, but I can't commit to a "when" at present.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOG0RvXsWsfv6J9170uGO9NwhGVQuKdks5teA5mgaJpZM4Sn3qI>
.
|
|
I should also indicate, and sorry for the additional email. I work on CI
for teams that create desktop applications. Specifically macOS and Windows
applications. There is no cloud provider for macOS, and the best solution
is MacStadium (which is IaaS). It's basically mac hardware hosted for you
and running vmware's hypervisors on it. In this case, I'm not able to run
containers for my tests and builds, so I need to ensure it's a fresh new VM
every job.
On Tue, Mar 13, 2018 at 11:43 AM, Ray Sennewald <ray.sennewald@gmail.com>
wrote:
… Hi Peter,
I had some other things I wanted to discuss, but figured they were better
outside of the PR. First and foremost, I wanted to say thank you for being
a maintainer of a public repo and using scrutiny when receiving PRs. I've
worked with enough Jenkins plugins that didn't have maintainers that did
this, and it always ended badly (bugs, NPE's....).
I wanted to ask you a little about your setup, if you don't mind.
Originally I did what you're talking about, where we'd use VM templates in
the cloud configuration. How do you destroy your VMs, do you just set a
low idle termination timeout? In this case you get fresh VMs pretty often
but not for every job? Also, how do you let the nodes get provisioned this
way? Do you just let the NodeProvisioner do its thing where when a job
comes in against a label that you've defined in a slave template, then you
wait for it to get provisioned? I have done this with the EC2 Plugin with
Jenkins before and it worked great, but I found in this plugin it takes
forever for nodes to be provisioned for me. One last question, what do you
use for your storage array in VMware? Is it running flash/ssd drives?
We're running 15K SAS drives in a RAID (10?) array, and they are dog slow
when I have around 25 VMs running. Specifically the operating systems
coming up and going down were killing my performance, so I had to get
creative and realized that reverting to snapshots (and having live running
snapshots) was much more performant. If you have SSD's, I'm willing to bet
the OS spinning up isn't a problem. It appears Travis CI does this and it
works quite well for them. If you don't mind explaining a little more how
you use the plugin exactly, I'd truly appreciate it. I can do the same for
you if you'd like.
Cheers,
-Ray
On Tue, Mar 13, 2018 at 11:22 AM, Peter Darton ***@***.***>
wrote:
> Hmm, that's interesting - we also want a "fresh environment for every
> job" but in our setup that's done by destroying the VM once it's been used
> and spinning up a fresh one (and hence waiting for it to boot up) each time.
> Sounds like your solution achieves much the same aims, but faster - I'll
> have to write myself a TODO item to take a look at this when I have time ;-)
>
> ...and on the subject of "time", I don't have much of it right now, so I
> can't easily do a merge and release at present.
> i.e. I *will* merge this, but I can't commit to a "when" at present.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#90 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAOG0RvXsWsfv6J9170uGO9NwhGVQuKdks5teA5mgaJpZM4Sn3qI>
> .
>
|
|
@rsennewald FYI release 2.18 was uploaded a few minutes ago; it should get indexed in the next 12 hours or so and thus appear as an available update in your Jenkins server(s) within 48 hours. |
2 participants
vSphereCloudProvisionedSlave for Reconnect and Revert.
to Jenkins when it's disconnected. When a snapshot
is specified, it will be reverted to at startup
(default functionality in the plugin).