allowing debug ssh access to jenkins slaves for developers

Eyal Edri eedri at redhat.com
Sun Mar 16 08:25:08 UTC 2014



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: eedri at redhat.com, asegurap at redhat.com
> Cc: "Vered Volansky" <vered at redhat.com>, "Michal Skrivanek" <mskrivan at redhat.com>, "Barak Azulay"
> <bazulay at redhat.com>, "infra" <infra at ovirt.org>
> Sent: Saturday, March 15, 2014 4:29:10 PM
> Subject: Re: allowing debug ssh access to jenkins slaves for developers
> 
> On Tue, Mar 11, 2014 at 05:59:16AM -0400, Vered Volansky wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Michal Skrivanek" <mskrivan at redhat.com>
> > > To: "Eyal Edri" <eedri at redhat.com>
> > > Cc: "David Caro" <dcaroest at redhat.com>, "Vered Volansky"
> > > <vered at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> > > "Barak Azulay" <bazulay at redhat.com>, "infra" <infra at ovirt.org>
> > > Sent: Tuesday, March 11, 2014 11:52:39 AM
> > > Subject: Re: allowing debug ssh access to jenkins slaves for developers
> > > 
> > > 
> > > On 11 Mar 2014, at 11:46, Eyal Edri wrote:
> > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > >> From: "David Caro" <dcaroest at redhat.com>
> > > >> To: "Allon Mureinik" <amureini at redhat.com>
> > > >> Cc: "Eyal Edri" <eedri at redhat.com>, "Barak Azulay"
> > > >> <bazulay at redhat.com>,
> > > >> "infra" <infra at ovirt.org>, "Michal
> > > >> Skrivanek" <mskrivan at redhat.com>
> > > >> Sent: Tuesday, March 11, 2014 11:44:19 AM
> > > >> Subject: Re: allowing debug ssh access to jenkins slaves for
> > > >> developers
> > > >> 
> > > >> On Tue 11 Mar 2014 09:55:08 AM CET, Allon Mureinik wrote:
> > > >>> 
> > > >>> 
> > > >>> ----- Original Message -----
> > > >>>> On Mon 10 Mar 2014 09:15:12 AM CET, Eyal Edri wrote:
> > > >>>>> Hi,
> > > >>>>> 
> > > >>>>> Recently I've been approached by several developers who are working
> > > >>>>> on
> > > >>>>> enabling
> > > >>>>> vdsm functional tests on jenkins.ovirt.org, and they need access to
> > > >>>>> the
> > > >>>>> slaves running those tests,
> > > >>>>> otherwise its almost impossible to debug and fix those tests
> > > >>>>> (errors
> > > >>>>> doesn't reproduce on their test env).
> > > >>>>> 
> > > >>>>> What i propose is giving "power user" access to jenkins slaves,
> > > >>>>> similar
> > > >>>>> to
> > > >>>>> what we do on jenkins master,
> > > >>>>> maybe at 1st w/o sudo access, and later on adding specific commands
> > > >>>>> to
> > > >>>>> sudo
> > > >>>>> if it's needed.
> > > >>>>> 
> > > >>>>> procedure should be documented in ovirt.org and request should be
> > > >>>>> sent
> > > >>>>> to
> > > >>>>> infra at ovirt.org,
> > > >>>>> explaining the need to access the slaves + public key of the
> > > >>>>> requester.
> > > >>>>> 
> > > >>>>> I think it's important to allow this access if we want our infra to
> > > >>>>> scale,
> > > >>>>> having more
> > > >>>>> people that can fix and solve problems on their specific
> > > >>>>> jobs/projects.
> > > >>>>> 
> > > >>>>> thoughts/suggestions?
> > > >>>>> 
> > > >>>>> Eyal.
> > > >>>>> 
> > > >>>>> _______________________________________________
> > > >>>>> Infra mailing list
> > > >>>>> Infra at ovirt.org
> > > >>>>> http://lists.ovirt.org/mailman/listinfo/infra
> > > >>>> 
> > > >>>> IMO each allowed developer must have it's own user/ssh key to log
> > > >>>> into
> > > >>>> the slaves.
> > > >>>> 
> > > >>>> Also some of the slaves are not reachable from outside (minidells)
> > > >>>> or
> > > >>>> only reachable from jenkins master or vpn (rackspace). That needs to
> > > >>>> be
> > > >>>> sorted out also.
> > > >>> Another "parallel" feature would be the ability to pin a job to a
> > > >>> slave
> > > >>> (not sure if this is achievable currently), so you could run a job,
> > > >>> login
> > > >>> to the slave, fix something, re-run, repeat.
> > > >> 
> > > >> Mmm, well, if you can configure the job you can pin it to a slave,
> > > >> just
> > > >> click 'restrict where this job can be run' and write there the name of
> > > >> the slave. Is that what you want?
> > > >> 
> > > >> That should only be done on jobs that are in development, as it will
> > > >> greatly affect other runs.
> > > > 
> > > > +1 in general for allowing power users ssh access to slaves (no sudo
> > > > access
> > > > at first).
> > > > but i would like to ask the relevant vdsm funtional tests which info
> > > > are
> > > > they seeking in the slave,
> > > > and if those logs can be collected and archived via the job (like other
> > > > jobs are doing already).
> > > > 
> > > > can the vdsm fuctional test owner can provide more info?
> > > 
> > > not sure if we can find out all pieces. Would sudo to less on everything
> > > in
> > > /var/log/ really hurt?
> > > maybe something like logcollector…but they tend to be huge
> > +1
> > Plus download time after each run will become unreasonable.
> 
> the logcollector would not be huge if it's taken after each job, and
> collected on job failures. Having vdsm.log on supervdsm.log ready for
> failed jobs is highly useful.
> 
> In any case, please grant me and Toni power user ssh access (please take
> the public keys from gerrit).
> 

dan,
please send official request to infra list (each one in separate email)
specifying which jobs you need to debug and what sudo access you need.
attached you public key to the mail as well.

once approved on the list, it will be added to the relevant puppet class.

as for attaching logs - feel free to add this functionality to the vdsm functional job,
if you need assistance, you can contact infra, but mainly these jobs are owned by vdsm power users.

eyal.

> 



More information about the Infra mailing list