From: "Michal Skrivanek" <mskrivan(a)redhat.com>
To: "Eyal Edri" <eedri(a)redhat.com>
Cc: "David Caro" <dcaroest(a)redhat.com>, "Vered Volansky"
<vered(a)redhat.com>, "Allon Mureinik" <amureini(a)redhat.com>,
"Barak Azulay" <bazulay(a)redhat.com>, "infra"
<infra(a)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(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
+1
Plus download time after each run will become unreasonable.
>
> 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
>>
>>