3:15 a.m.
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.
3:56 a.m.
On 10 Mar 2014, at 10:15, 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?
I think it will be great when more people can get issues resolved and get the tests
stable. IMHO this is really a high priority to have a solid foundation (100% working basic
tests) before we add higher level integration tests and flows
Thanks,
michal
Eyal.
10:55 a.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--119DnkStMdBKg9UCIfVcDv8IqRekTkXRN
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
do=
esn'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 sca=
le,
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=20
the slaves.
Also some of the slaves are not reachable from outside (minidells) or=20
only reachable from jenkins master or vpn (rackspace). That needs to be=20
sorted out also.
--
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
--119DnkStMdBKg9UCIfVcDv8IqRekTkXRN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJTHeBaAAoJEEBxx+HSYmnD2hAH/16TWh56yNN9FCZ5JkjwB+GD
QkWOimCvC6UzqMVtkulPJ5rac9Jm3xYMiKMdmGGCl1QxAg3ZhyRq2EcxlXTXGt5D
5hbl4zzb+KewQ0Qvuc5PUKcTr1Rtv88VZKEnH1BraqeHJjb8GN/dVNQmFeO99wyc
yWmbYKLDZUCRl5FimY9IDm4bmBCDQsWmaQ05Rwa/ohIjXRU3klJuwbEog7iuJ/vO
8MpJtUy0zOrgTG/hkrkU7UWhOSBZxtY6d3g5IR13b6KtDE5x5kIbRJncugKi0rM8
f4euTHp6g/Wdixuv0fNzUohMvsiAY5yUzqtEjNzVzatRcyPHlOV15uBGElwK9uM=
=HtKA
-----END PGP SIGNATURE-----
--119DnkStMdBKg9UCIfVcDv8IqRekTkXRN--
3:55 a.m.
----- 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.
--
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
4:44 a.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gDVuifhQiPSBA5FRXKxtwuqsdGu3P0cAf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 o=
n
>> enabling
>> vdsm functional tests on jenkins.ovirt.org, and they need access to t=
he
>> 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, simil=
ar to
>> what we do on jenkins master,
>> maybe at 1st w/o sudo access, and later on adding specific commands t=
o
sudo
>> if it's needed.
>>
>> procedure should be documented in ovirt.org and request should be sen=
t
to
>> infra(a)ovirt.org,
>> explaining the need to access the slaves + public key of the requeste=
r.
>>
>> I think it's important to allow this access if we want our infra to s=
cale,
>> having more
>> people that can fix and solve problems on their specific jobs/project=
s.
>>
>> 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 b=
e
> 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, logi=
n to the slave, fix something, re-run, repeat.
Mmm, well, if you can configure the job you can pin it to a slave, just=20
click 'restrict where this job can be run' and write there the name of=20
the slave. Is that what you want?
That should only be done on jobs that are in development, as it will=20
greatly affect other runs.
>
> --
> 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
--gDVuifhQiPSBA5FRXKxtwuqsdGu3P0cAf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJTHtrzAAoJEEBxx+HSYmnD9IAH/05EJd2OCiWzw/rTAEib9Nj7
zRVIi80aZjXU8xLNJ1nDP3TRjw8zkjXt0m+awwas+/vtVn3XZ633ALZxP2epMfwb
/HilMqNDGkyyJKhUr2ZY2r3Bemnq6EGrOcEXO+lDJCtJFGYeN1ZcupiqmVDibBYo
2MlhkSmj0vUDnBfxmEwbNFDwndoo9QZFRqGdeihGmF5JU3UZm8ibfT4ChXPrKgXi
y9XJJTfwavOdGZZJgaQhR2C42jI8Kh9TDteYypTZwnHtU+orDYNF3F3O5SLKOAZG
wXM0iJgQmvPAn4wl+tTBtfnV3LUhzgs0vRQ5dHxsjmi5Z4F5xeRmTn1j9kWhmBY=
=hYXY
-----END PGP SIGNATURE-----
--gDVuifhQiPSBA5FRXKxtwuqsdGu3P0cAf--
4:45 a.m.
----- Original Message -----
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?
Doh!
Yes, that should do it.
Thanks!
That should only be done on jobs that are in development, as it will
greatly affect other runs.
>
>>
>> --
>> 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
4:46 a.m.
----- 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?
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
4:52 a.m.
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
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
>
>
4:59 a.m.
----- Original Message -----
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
>>
>>
9:29 a.m.
On Tue, Mar 11, 2014 at 05:59:16AM -0400, Vered Volansky wrote:
----- Original Message -----
> 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.
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).
3:25 a.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: eedri(a)redhat.com, asegurap(a)redhat.com
Cc: "Vered Volansky" <vered(a)redhat.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>, "Barak Azulay"
<bazulay(a)redhat.com>, "infra" <infra(a)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(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.
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.
6:24 p.m.
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.
I hereby send an official request to add my
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCrl6PvqVX2qKHnJTiGZ7ILpoThdHWYvFatiW9ZxZ9EF7+aZpy79ij3tnUEAWaMpYrwf7kO/odaoh22P/cvkjfphFz9D0BvDEjH+X7h6Kr/YU+3R7PxcIldmclSnCwzjbQBstnjGZj2Yj1WAWPuE4YppadpYMMxgWsrhclGry3V28zXcxdGkG6pmL3oTrXMp3dCqDqL1cpdgmsWdhFKD+Gyb4HSZ7p37szscLhrLVSLn32T2ZJ/WobK9E1kjYgJRik+IPwcmp9LOVMTxpi1ZnYFvysP7HZorQAcW8bKvLJ7eBxuvkt+lzK/IFlbaRHr++wkO+WSGYu7EjVjvpeGyOlv
danken
key to the Jenkins slaves.
At the moment I need
sudo su - vdsm -s /bin/bash
but I may nag for more in the future.
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.
>
4:19 p.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Eyal Edri" <eedri(a)redhat.com>
Cc: asegurap(a)redhat.com, "Vered Volansky" <vered(a)redhat.com>,
"Michal Skrivanek" <mskrivan(a)redhat.com>, "Barak
Azulay" <bazulay(a)redhat.com>, "infra" <infra(a)ovirt.org>
Sent: Monday, March 17, 2014 1:24:02 AM
Subject: Re: allowing debug ssh access to jenkins slaves for developers
> 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.
I hereby send an official request to add my
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCrl6PvqVX2qKHnJTiGZ7ILpoThdHWYvFatiW9ZxZ9EF7+aZpy79ij3tnUEAWaMpYrwf7kO/odaoh22P/cvkjfphFz9D0BvDEjH+X7h6Kr/YU+3R7PxcIldmclSnCwzjbQBstnjGZj2Yj1WAWPuE4YppadpYMMxgWsrhclGry3V28zXcxdGkG6pmL3oTrXMp3dCqDqL1cpdgmsWdhFKD+Gyb4HSZ7p37szscLhrLVSLn32T2ZJ/WobK9E1kjYgJRik+IPwcmp9LOVMTxpi1ZnYFvysP7HZorQAcW8bKvLJ7eBxuvkt+lzK/IFlbaRHr++wkO+WSGYu7EjVjvpeGyOlv
danken
key to the Jenkins slaves.
At the moment I need
sudo su - vdsm -s /bin/bash
but I may nag for more in the future.
please specify the job that you need to debug and the relevant slave (we're going to
add it manually for now, until a proper puppet
class can be written to support it).
>
> 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.
>
> >
3700
days inactive
3709
days old
12 comments
6 participants
participants (6)
-
Allon Mureinik -
Dan Kenigsberg -
David Caro -
Eyal Edri -
Michal Skrivanek -
Vered Volansky