Re: Introducing Flight Deck: Infrastructure-as-Code for Debian Go Team Repositories
Hi Arthur, Ananthu and others,
>> I don't think another layer of terraform complexicity is any helpful
>> for us. Keeping things simple is better. I am generally all for modern
I shared the same concern initially as Ananthu expressed above about
complexity. Doing config updates is much "simpler" with a script like
the one I did in
https://salsa.debian.org/go-team/infra/pkg-go-tools/-/tree/master/scripts.
However, after looking more into what Arthur has built, I realize that
a simple script like the one above is hard to extend, it has little
error management, can't be integrated into a devops workflow etc. So I
think that the additional complexity of Terraform is actually
justified. Also, Terraform is used by the Salsa Admins to maintain
other Salsa stuff, so even though it is a bit complex, there are some
synergies that we have more DDs that use it and know about it.
And the people who want to create/enroll repositories don't need to
know much about Terraform/OpenTofu. Requesting a new repo to be
created or existing one to enrolled is fairly simple as the example in
https://salsa.debian.org/go-team/flight-deck/-/merge_requests/19
shows.
I am sure if we test this our and give Arthur feedback on what is
relevant and what is not, we can all help him strike a good balance
between right enough amount of functionality without having
unneceassary complexity.
>> tooling and all that, but this dev-ops-ification basically feels like
>> a completely unnecessary addition of complexicity and abstraction
>> layer on top of everything else we already have. On top of the supposed
>> benefits here, with how terraform state management and whatnot works,
>> it is just as easy to completely destroy resources with a single
>> mistake as well. It is not like office work where few infra people manage
>
>
> I make sure to have those guardrails in place to make the flight-deck not be able to be
> destructive so you never might be able to delete repos for example only stop tracking/updating it.
Based on what Arthur explained earlier, this Flight Deck already has
code that prevents it from deleting any repository, so it can't be
used to accidentally delete Go team pacakges.
>> everything and others wait for their check and approval to get
>> anything done at all (and even then people mess up a lot).
>
>
> The approval from others is not required for doing actions,
> the idea of open merge request is for the pipeline to run and
> show you the plan of changes before you merge.
I think Ananthu was concerned here that there would be a bottle-neck
of a small group of admins. That is not the case here - how this works
is that as soon as some change is merged on 'main', the CI runner will
apply the changes. So we can have new contributors requesting a new
repository to be made for a new package they want to work on, and then
anyone in the Go team who has membership Developer or higher can merge
it, and the repository will be created and have the correct settings.
Arthur: Please improve the README as Nilesh and Andrea suggested, they
had very good points. I am concerned a good idea here is not getting
traction because it isn't explained well enough. If this is done well,
I think Flight Deck could even be used across all of Salsa since many
teams have the same need to be able to manage GitLab project configs,
and editing and reviewing and merging config files is much better than
having people or random scripts poke around the configs.
Reply to: