----- Original Message -----
> From: "David Caro" <dcaroest(a)redhat.com>
> To: "Allon Mureinik" <amureini(a)redhat.com>
> Cc: "Eyal Edri" <eedri(a)redhat.com>, "Barak Azulay"
<bazulay(a)redhat.com>, "infra" <infra(a)ovirt.org>, "Michal
> Skrivanek" <mskrivan(a)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(a)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(a)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
eyal
>
>>
>>>
>>> --
>>> David Caro
>>>
>>> Red Hat S.L.
>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>>
>>> Email: dcaro(a)redhat.com
>>> Web:
www.redhat.com
>>> RHT Global #: 82-62605
>>>
>>>
>>> _______________________________________________
>>> Infra mailing list
>>> Infra(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/infra
>>>
>
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Email: dcaro(a)redhat.com
> Web:
www.redhat.com
> RHT Global #: 82-62605
>
>