Re: Resignation as cloud team delegate
Hi Jonathan,
On Fri, Jun 24, 2022 at 04:47:23PM +0200, Jonathan Carter wrote:
> Hi Ross and cloud team
>
> On 2022/06/19 07:35, Ross Vandegrift wrote:
> > Okay great. We've never written anything down, but I've been meaning to do it
> > for a while. This is from my memory, so it's possible I left something out:
> > https://wiki.debian.org/Teams/Cloud/Rules
>
> I changed "should" to "may" to make it a bit more explicit, does that sound
> ok?
Yes, thanks!
> Here's a draft delegation update (view only, email me off-list if you'd like
> an editable link):
>
> https://storm.debian.net/shared/K6HxKOLn4xg_83EhOIsmV5yye_l51lIOE9E4UuiWVOK
>
> I've made a bunch of changes to simplify/fix language and clarify the
> purpose of having accounts with providers.
Great, most of that seems like a clear improvement. But there's one change I'm
not sure about:
--- original 2022-07-01 21:40:33.826069834 -0700
+++ draft 2022-07-01 21:40:45.778221446 -0700
@@ -1,3 +1,3 @@
- With the Debian Project Leader and under the auspices of the
Trusted Organizations, establish Debian accounts with cloud
- providers, negotiating terms and conditions where necessary.
+ providers for the purpose of managing cloud images
Are you thinking the delegation needs to enumerate responsibilities more
specifically? If so, we have other projects unrelated to VM images:
- provider-specific mirror infrastructure.
- build systems for docker images on docker.io and public.ecr.aws.
A bigger consequence would be that other teams could establish official
provider accounts for Debian. I'm not sure what I think of that. There are
some downsides:
- those accounts would be entirely separate, which can always lead to folks
confusing them. It also duplicates config for auth, auditing, logging, etc.
- other teams will need to work with TOs and their lawyers. Those resoures are
usually in short supply, so duplicating e.g. contract negotiation work will
be unwelcome.
- it also might duplicate work for providers, who sometimes need to do
specialized setup for our accounts (e.g. to enable trademark clearance,
permission to access geographic regions, or provide free services).
On the flip side, there are advantages:
- the account setup process can be hard, and I'm sure we've been a bottleneck.
- our bus factor and bandwidth are small.
- separate teams would be free to implemenet different policies than us.
I'm not sure what I think of these tradeoffs. But I do think we should
consider them. What do you and other team members think?
> It also links to the team rules
> page, for which we might need better policy in the future to maintain that,
> but as long as it doesn't get abused, I think it's fine for now.
Agreed - if becomes an issue, we'll do something else.
Ross
Reply to: