On 11 Mar 2014, at 11:46, Eyal Edri wrote: > > > ----- Original Message ----- >> From: "David Caro" <[email protected]> >> To: "Allon Mureinik" <[email protected]> >> Cc: "Eyal Edri" <[email protected]>, "Barak Azulay" <[email protected]>, >> "infra" <[email protected]>, "Michal >> Skrivanek" <[email protected]> >> 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 >>>>> [email protected], >>>>> 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 >>>>> [email protected] >>>>> 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: [email protected] >>>> Web: www.redhat.com >>>> RHT Global #: 82-62605 >>>> >>>> >>>> _______________________________________________ >>>> Infra mailing list >>>> [email protected] >>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >> >> >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Email: [email protected] >> Web: www.redhat.com >> RHT Global #: 82-62605 >> >> _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
