Hi all,
Suppose there is a LAVA user, and to avoid taxing my imagination let's call him Alexandros. He wants to have some jobs submitted automatically from ci.linaro.org to lava that deposit results in a bundle stream that only members of linaro can see, which all seems reasonable enough.
Currently though, the story for tokens around this is a bit horrible. To be able to submit to the a /private/team/linaro/... bundle, you have to submit the job as a member of the linaro group in v.l.o.
I can think of a few ways of doing this, but I don't really like any of them:
1) jenkins on ci.linaro.org could use one of alf's tokens, but that seems a little tied to him (what if he leaves linaro, etc)
2) Another way is to create a user that does not correspond to a user on LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
3) A third way is to create a fake user on LP and add it to the ~linaro team there. This also seems a bit horrible.
There is a fourth way that is actually happening but doesn't help -- create a user on LP and do _not_ add it ~linaro: https://launchpad.net/~ciadmin [1].
I don't really have a suggestion for what would be better here. It feels a bit like the model we have for access and handling tokens is perhaps a bit too simple currently. What do you guys think?
Cheers, mwh
[1] this is why ci.linaro.org lost the job-submitting permission -- I didn't realize ciadmin on v.l.o corresponded to a user on LP!
On 7 May 2012 08:08, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Hi all,
Suppose there is a LAVA user, and to avoid taxing my imagination let's call him Alexandros. He wants to have some jobs submitted automatically from ci.linaro.org to lava that deposit results in a bundle stream that only members of linaro can see, which all seems reasonable enough.
Currently though, the story for tokens around this is a bit horrible. To be able to submit to the a /private/team/linaro/... bundle, you have to submit the job as a member of the linaro group in v.l.o.
I can think of a few ways of doing this, but I don't really like any of them:
- jenkins on ci.linaro.org could use one of alf's tokens, but that
seems a little tied to him (what if he leaves linaro, etc)
We have a process for leavers. If we choose this option, we should add an action to disable/remove those accounts.
- Another way is to create a user that does not correspond to a user on
LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
- A third way is to create a fake user on LP and add it to the ~linaro
team there. This also seems a bit horrible.
There is a fourth way that is actually happening but doesn't help -- create a user on LP and do _not_ add it ~linaro: https://launchpad.net/~ciadmin [1].
This option isn't 'self service' either. A CI admin should add the credential on Jenkins and a v.l.o admin should create the user.
I don't really have a suggestion for what would be better here. It feels a bit like the model we have for access and handling tokens is perhaps a bit too simple currently. What do you guys think?
I don't have better to propose but the issue to resolve isn't for Validation only imo. It should involve Infrastructure to get a really safe [2] self service system and a better story for the end user.
Cheers, mwh
[1] this is why ci.linaro.org lost the job-submitting permission -- I didn't realize ciadmin on v.l.o corresponded to a user on LP!
[2] avoid leaking lava user/token
On Mon, May 7, 2012 at 8:20 AM, Fathi Boudra fathi.boudra@linaro.org wrote:
On 7 May 2012 08:08, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Hi all,
Suppose there is a LAVA user, and to avoid taxing my imagination let's call him Alexandros. He wants to have some jobs submitted automatically from ci.linaro.org to lava that deposit results in a bundle stream that only members of linaro can see, which all seems reasonable enough.
Currently though, the story for tokens around this is a bit horrible. To be able to submit to the a /private/team/linaro/... bundle, you have to submit the job as a member of the linaro group in v.l.o.
I can think of a few ways of doing this, but I don't really like any of them:
- jenkins on ci.linaro.org could use one of alf's tokens, but that
seems a little tied to him (what if he leaves linaro, etc)
We have a process for leavers. If we choose this option, we should add an action to disable/remove those accounts.
- Another way is to create a user that does not correspond to a user on
LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
- A third way is to create a fake user on LP and add it to the ~linaro
team there. This also seems a bit horrible.
There is a fourth way that is actually happening but doesn't help -- create a user on LP and do _not_ add it ~linaro: https://launchpad.net/~ciadmin [1].
This option isn't 'self service' either. A CI admin should add the credential on Jenkins and a v.l.o admin should create the user.
I don't really have a suggestion for what would be better here. It feels a bit like the model we have for access and handling tokens is perhaps a bit too simple currently. What do you guys think?
I don't have better to propose but the issue to resolve isn't for Validation only imo. It should involve Infrastructure to get a really safe [2] self service system and a better story for the end user.
I anticipated that setting up jobs (recurring and one off jobs) would be done as a service by the infrastructure team. They could ensure that the users etc. are all ok etc. I believe option 2 should be fine. We would need just one special user that is shared by all jobs that submit to @linaro.org protected bundlestreams.
Is that a problem?
On Mon, May 07, 2012, Michael Hudson wrote:
- Another way is to create a user that does not correspond to a user on LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
This seems fine to me; creating a machine-to-machine account/setup seems like a one-off action which doesn't need to involve LP. We could share a single set of LAVA credentials for all jobs coming from ci.linaro.org.
If this isn't automated enough, we could have a way to create new LAVA credentials for anyone in a specific Launchpad team?
On Mon, May 7, 2012 at 12:19 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, May 07, 2012, Michael Hudson wrote:
- Another way is to create a user that does not correspond to a user on
LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
This seems fine to me; creating a machine-to-machine account/setup seems like a one-off action which doesn't need to involve LP. We could share a single set of LAVA credentials for all jobs coming from ci.linaro.org.
If this isn't automated enough, we could have a way to create new LAVA credentials for anyone in a specific Launchpad team?
Yes, machine to machine is the way to go...
But, I don't think we need specific users like gfx-... we just need _one_ user shared by all @linaro.org protected jobs. This should be configured on the backend side for all @linaro.org transparently so the user (alf) does not need to bother about it...
That should be simple to setup and shouldn't require lot's of maintenance nor any further sophistication.
On Mon, 7 May 2012 12:26:00 +0200, Alexander Sack asac@linaro.org wrote:
On Mon, May 7, 2012 at 12:19 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, May 07, 2012, Michael Hudson wrote:
- Another way is to create a user that does not correspond to a user on
LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
This seems fine to me; creating a machine-to-machine account/setup seems like a one-off action which doesn't need to involve LP. We could share a single set of LAVA credentials for all jobs coming from ci.linaro.org.
If this isn't automated enough, we could have a way to create new LAVA credentials for anyone in a specific Launchpad team?
Yes, machine to machine is the way to go...
But, I don't think we need specific users like gfx-... we just need _one_ user shared by all @linaro.org protected jobs. This should be configured on the backend side for all @linaro.org transparently so the user (alf) does not need to bother about it...
That should be simple to setup and shouldn't require lot's of maintenance nor any further sophistication.
I think that makes sense. The necessity of the infrastructure team sharing the password of this user still doesn't seem like a great thing, but maybe that's OK for now.
(In the medium term, maybe we should be able to associate tokens with groups, and any member of the group can manage tokens associated with the group?)
Cheers, mwh
On Tue, May 8, 2012 at 3:21 AM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
On Mon, 7 May 2012 12:26:00 +0200, Alexander Sack asac@linaro.org wrote:
On Mon, May 7, 2012 at 12:19 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, May 07, 2012, Michael Hudson wrote:
- Another way is to create a user that does not correspond to a user on
LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
This seems fine to me; creating a machine-to-machine account/setup seems like a one-off action which doesn't need to involve LP. We could share a single set of LAVA credentials for all jobs coming from ci.linaro.org.
If this isn't automated enough, we could have a way to create new LAVA credentials for anyone in a specific Launchpad team?
Yes, machine to machine is the way to go...
But, I don't think we need specific users like gfx-... we just need _one_ user shared by all @linaro.org protected jobs. This should be configured on the backend side for all @linaro.org transparently so the user (alf) does not need to bother about it...
That should be simple to setup and shouldn't require lot's of maintenance nor any further sophistication.
I think that makes sense. The necessity of the infrastructure team sharing the password of this user still doesn't seem like a great thing, but maybe that's OK for now.
(In the medium term, maybe we should be able to associate tokens with groups, and any member of the group can manage tokens associated with the group?)
Why does the infrastructure team need to share the password? I anticipate them to setup the job for alf and ensure that the proper password is seeded on the build host that submits the tests.
On Tue, 8 May 2012 10:48:06 +0200, Alexander Sack asac@linaro.org wrote:
On Tue, May 8, 2012 at 3:21 AM, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
On Mon, 7 May 2012 12:26:00 +0200, Alexander Sack asac@linaro.org wrote:
On Mon, May 7, 2012 at 12:19 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, May 07, 2012, Michael Hudson wrote:
- Another way is to create a user that does not correspond to a user on
LP (gfx-daily-job-submitter or somethign) and add it to the linaro group on v.l.o. This feels a bit better, but it's not very 'self service' -- the only way to create such a user is via the admin panel afaik.
This seems fine to me; creating a machine-to-machine account/setup seems like a one-off action which doesn't need to involve LP. We could share a single set of LAVA credentials for all jobs coming from ci.linaro.org.
If this isn't automated enough, we could have a way to create new LAVA credentials for anyone in a specific Launchpad team?
Yes, machine to machine is the way to go...
But, I don't think we need specific users like gfx-... we just need _one_ user shared by all @linaro.org protected jobs. This should be configured on the backend side for all @linaro.org transparently so the user (alf) does not need to bother about it...
That should be simple to setup and shouldn't require lot's of maintenance nor any further sophistication.
I think that makes sense. The necessity of the infrastructure team sharing the password of this user still doesn't seem like a great thing, but maybe that's OK for now.
(In the medium term, maybe we should be able to associate tokens with groups, and any member of the group can manage tokens associated with the group?)
Why does the infrastructure team need to share the password? I anticipate them to setup the job for alf and ensure that the proper password is seeded on the build host that submits the tests.
They would need to log on to v.l.o as the "_one_ user shared by all @linaro.org protected jobs" to generate/manage the tokens used.
Cheers, mwh
linaro-validation@lists.linaro.org
-
Alexander Sack -
Fathi Boudra -
Loïc Minier -
Michael Hudson-Doyle