#21 Fedora infrastructure local development environment
Closed 8 months ago by amoloney. Opened 2 years ago by lrossett.

New initiative: fedora infrastructure development environment

What is this initiative about?

There is no easy/straightforward way to test our infrastructure code locally without some hacks or code gimmicks which leads to an unproductive development workflow process when contributing to our infrastructure code (i.e. fedora-infra/ansible).

The initiative is about enabling a lightweight local development environment to run and test our infrastructure code, not only this would allow a faster development workflow but also enable us to run those tests on CI jobs.

Why this initiative?

  • Allow fedora-infra contributors to test their code changes locally;
  • Enable fedora-infra end-to-end tests in CI jobs;

Definition of success

This should be implemented in bits with incremental changes instead of a "big release".

I think this could start as an ARC project to identify which components/services could be added in this scheme and which cannot, come up with a minimal infrastructure scheme and how it could be used locally.

It would be great if we could use podman and docker-compose together with the podman ansible connection plugin.

The main idea is to have a reproducible way to bootstrap a local infra env. to then run our ansible playbook locally targeting that infrastructure.

Area/community impacted

  • Fedora contributors
  • Fedora development workflow and quality of code
  • It could definitely be extended to CentOS

Dependencies

  • Containers
  • Ansible
  • Devops
  • Basic network knowledge

Deadline

No deadlines.


What is this initiative about?

There is no easy/straightforward way to test our infrastructure code locally without some hacks or code gimmicks which leads to an unproductive development workflow process when contributing to our infrastructure code (i.e. fedora-infra/ansible).

The initiative is about enabling a lightweight local development environment to run and test our infrastructure code, not only this would allow a faster development workflow but also enable us to run those tests on CI jobs.

Considering the size and diversity of the Fedora Infrastructure, we will need to
have a clear definition of what you mean here, for examples:
- Do you want to include signing RPMs (sigul,robotsignatory...)?
- Do you want to include shipping RPMs to mirrors (mirrormanager & co)?
- Do you want to includes the websites ran for end-users?

All this to say, I think it's a good idea, but I don't think it's feasible to do
the "entire" infrastructure, especially not in the first pass and thus I suggest
defining the part of the infrastructure you'd like to focus on first.

PS: Ryan already did quite a bit of work when working on noggin, so the auth
piece is potentially already there and something that can be leveraged here

Issue tagged with: Accepted

2 years ago

I agree that we don't need all of the infrastructure (I don't think a local koji env. makes much sense for example) but I was thinking in grouping some "environments".

Groups go from rabbitmq + openshift, or pagure + lookaside cache, and so on.

Those groups could also be "merged" together if there is a need for them to do so.

@lrossett Im doing some 'spring cleaning' and wanted to check if this is still an active request? If yes, happy to schedule some time in to get a little more detail from you but if you no longer need this I will close.

Thanks!
Aoife

Dropping this initiative as tiny-stage replicates most of the fedora infra environment needed for testing. Expanding on tiny-stage functionality to include CI could be an option, if demand is there. A new ticket will need to be filed though if this is something folks want. Closing this one as dropped for now.

Metadata Update from @amoloney:
- Issue status updated to: Closed (was: Open)

8 months ago

Metadata Update from @amoloney:
- Issue untagged with: Accepted
- Issue tagged with: Dropped

8 months ago

Login to comment on this ticket.

Metadata