[Gluster-devel] [gluster-devel] Reviewing Rackspace Use

[Niels de Vos]

On Wed, May 18, 2016 at 03:20:30PM +0200, Michael Scherer wrote:
> Le mercredi 18 mai 2016 à 12:13 +0200, Niels de Vos a écrit :
> > On Wed, May 18, 2016 at 11:37:43AM +0200, Michael Scherer wrote:
> > > Le mercredi 18 mai 2016 à 09:53 +0200, Niels de Vos a écrit :
> > > > On Wed, May 18, 2016 at 12:28:25PM +0530, Kaushal M wrote:
> > > > > On Tue, May 17, 2016 at 7:50 PM, Amye Scavarda <amye at redhat.com> wrote:
> > > > > > Over the last year or so, the Rackspace use seems to have gone up pretty
> > > > > > steadily. While Rackspace is being awesome and supporting us as an open
> > > > > > source project, this usage has been growing in ways that we can't always
> > > > > > plan for.
> > > > > >
> > > > > > I think(?) that what's on Rackspace is mostly CI, but I would love some
> > > > > > guidance on what we might be able to make on-demand instead of constant
> > > > > > lying in wait.
> > > > > 
> > > > > All the CI machines could be made on-demand. All are based on ready
> > > > > images, so we should be able to spin up a VM on demand.
> > > > 
> > > > Or, even by only starting the VMs when needed, and shutting down when
> > > > done. Either way, we need a plugin for creating or starting the VMs on
> > > > demand. This is something we looked into before, but never had enough
> > > > time to test and finish it:
> > > > 
> > > >   http://thread.gmane.org/gmane.comp.file-systems.gluster.infra/156
> > > >   https://github.com/gluster/jenkins-ssh-slaves-plugin/tree/Before-connect-script-for-gluster-jenkins
> > > 
> > > I did ask to a friend for the jclouds plugin and he was saying that the
> > > stable version is buggy as hell, so we would need a devel snapshot. It
> > > didn't inspire a huge confidence.
> > > 
> > > But now that the automated install is working well (after the last few
> > > bugs fixes around, like the xfsprogs issue found by ndevos, the python
> > > dir issue finally fixed, etc), that's the next step.
> > 
> > That could work too, but new slave installations need to get added to
> > the Jenkins master. 
> 
> My biggest concern is that jenkins is kinda getting too much CVE theses
> days for me to be confortable with giving rackspace credentials to it,
> and i would rather make sure we have hardened the server as much as
> possible before it start to be leaked and that we are losing a ton of
> money if someone started 500 bitcoins miners VM due to that.
> 
> > Booting and poweroff prevents that step. But.
> > whatever works :-)
> 
> Mhh in fact, i do not really understand the plugin you pointed, can you
> explain a bit more ?

The plugin (well, patches for the existing ssh-slaves-plugin) add the
possibility to execute a shell script before a job gets started on a
slave, and after a job has finished (or the slave is idle?). These
scripts can boot/poweroff an existing VM in a similar way that the
https://build.gluster.org/job/reboot-vm/ job does.

This keeps the number of slaves completely in our control, while not
running any slave VMs when not needed. From my understanding, that
should save quite a bit of online-hours, and VMs in shutdown state are
much cheaper.

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160518/52179ec7/attachment.sig>