=== 20WAAFCU3 is now known as wallyworld | ||
=== Guest79566 is now known as wallyworld | ||
cjwatson | wgrant: I'm tempted to just disallow LiveFS:requestBuild for private archives for now, as the issue with visibility of dependencies is going to take a while to get right (it can't all be done in requestBuild and dispatch, because the set of people who can see a LiveFSBuild might change later). Does that make sense to you? | 11:44 |
---|---|---|
cjwatson | PES are likely to need it, but not immediately. | 11:45 |
wgrant | cjwatson: Agreed. | 11:50 |
wgrant | The virtualizedness is the bigger problem. | 11:50 |
cjwatson | Haven't got to that yet; working through your review in order ... | 11:50 |
wgrant | Oh | 11:50 |
wgrant | You're in for an unpleasant surprise :) | 11:50 |
cjwatson | Well, it's a problem for opening it up to wider groups such as PES | 11:55 |
cjwatson | It's not particularly a problem with the pretty restricted set of people who can create/edit livefses/livefsbuilds at the moment | 11:56 |
wgrant | That's true, but it might indicate that this model is fatally flawed. | 11:57 |
cjwatson | I want to say that only people who can upload to some devirtualised archive should be able to request livefsbuilds, although most requests will be done by a bot user | 11:57 |
wgrant | Though I guess the consumers are few enough that we can easily change it later. | 11:57 |
wgrant | Right, that might be a sensible rule. | 11:58 |
cjwatson | Sorry, should be able to request livefsbuilds for a devirt archive, I mean | 11:58 |
cjwatson | (actually not a problem for PES, since they basically all have access to devirt archives already) | 11:59 |
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
=== olli_ is now known as olli | ||
cjwatson | wgrant: So a "has any permission on any devirt archive" query is simple enough; what would you think of artificially giving ~ubuntu-cdimage-robot a devirt PPA just so that it passes this test and can run our normal image builds? | 23:47 |
cjwatson | It would keep the code simple at the cost of a bit of deployment WTF | 23:47 |
wgrant | cjwatson: Have you thought about a proper long-term solution for this? I haven't managed to come up with one. | 23:49 |
wgrant | The cross-archive permission query isn't sustainable long-term, so I'm hoping we aren't backing ourselves into a corner here. | 23:49 |
cjwatson | Long-term I'd hope we can do all livefs builds in scalingstack ... | 23:50 |
wgrant | True, but it's similar in many ways to the privacy issue. | 23:50 |
wgrant | But for the immediate term, that workaround sounds reasonable. | 23:51 |
cjwatson | The simplest alternative that comes to mind is to have livefs virtualisation be an admin-settable property of some kind, rather than deriving it. | 23:51 |
wgrant | Yup, but that doesn't solve the privacy issue which is basically the same problem. | 23:51 |
cjwatson | We'd then have to disallow building a given devirt LiveFS against a virt archive. | 23:52 |
cjwatson | Maybe it would simplify things if you were likewise not allowed to build a public LiveFS against a private Archive. | 23:52 |
cjwatson | The same kind of way a public Archive isn't allowed to have a private ArchiveDependency. | 23:53 |
cjwatson | So we could just say that if you're building against a private Archive then the LiveFS owner has to match. | 23:53 |
wgrant | The ArchiveDependency situation is just marginally less bad than what was there before (no restriction). | 23:53 |
wgrant | Right, I'd suggest that owner of the dependent object should have to be able to see the archive. | 23:54 |
wgrant | At build-time. | 23:54 |
wgrant | But for private PPAs that has to be slightly stricter. | 23:54 |
wgrant | Possibly the LiveFS owner must have upload permissions | 23:55 |
cjwatson | Requiring identity would mean that we don't have to worry about what happens if somebody gets added to one side or the other. | 23:55 |
wgrant | Which then also solves the virtness issue, so I've been wondering if we can reasonably make that a normalr estriction. | 23:55 |
cjwatson | For build logs later. | 23:55 |
wgrant | True. | 23:55 |
cjwatson | Any permission rather than just upload permission would be a bit easier logistically. | 23:56 |
cjwatson | But it winds up much the same. | 23:56 |
wgrant | You mean ArchivePermission, I assume | 23:57 |
wgrant | ie. some kind of write access | 23:57 |
cjwatson | Yes | 23:57 |
wgrant | That's what I intended, yeah | 23:58 |
wgrant | But "any permission" could be misconstrued to include ArchiveSubscriber, which is how ArchiveDependencies are now I think. | 23:58 |
wgrant | Maybe? | 23:58 |
wgrant | Anyway. | 23:58 |
cjwatson | It potentially restricts our ability to use new teams for LiveFSes, but maybe that's OK | 23:58 |
cjwatson | I'm just a bit worried about having to add ArchivePermissions for new teams to Ubuntu in order to be able to build livefses | 23:59 |
cjwatson | For non-distro archives, whatever | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!