releng

#6971 pungi->bodhi - where should pungi configs be stored?
Closed Opened by dustymabe.

Closed
Reopen Issue

I had assumed that we would just do a git clone of the pungi-fedora git repo, but @bowlofeggs pointed out that this has implications on other users of bodhi outside of Fedora. I'll try to point out some of the options and some of the arguments for or against those options:

Options:

Store the pungi configs in pungi-fedora git repo and git clone them from within bodhi

  • postive: all configs files live in the same repo. Easy to make changes to nightly pungi config files and bodhi pungi config files.
  • positive: we don't have to copy around the pungi configs or the variants.xml file
  • positive: as soon as you commit a change to the git repo it will take effect
  • negative: bodhi needs to learn about another place where config is stored and git clone a repo to grab the config
  • negative: possible bad experience for sysadmins managing bodhi machines

Store pungi config for bodhi in infra ansible - place them on bodhi backend machines using ansible

  • positive: more configuration for bodhi lives in the ansible git repo
  • positive: maybe sys-admins will like this better?
  • negative: we manage pungi configs in separate places (pungi-fedora and infra ansible repo)
  • negative: we have to make a copy of the variants file from pungi-fedora in infra ansible repo

Store pungi config in pungi-fedora repo - place them on bodhi backend machines using ansible

  • positive: other users of bodhi (not Fedora) can still place their pungi configs manually on the machine using whatever mechanism they like. They are not forced to have a git repo for the configs.
  • negative: config still doesn't live in ansible (sys-admins might not like this)
  • negative: when you commit to the pungi-fedora git repo you also need to get someone to run an ansible playbook to apply the change

Metadata Update from @mohanboddu:
- Issue tagged with: meeting

The first option has an additional negative in that it makes Bodhi more complicated to deploy. It's important to keep in mind that Fedora is not the only user of Bodhi (I know of at least 3 other deployments), and so we shouldn't hard code behaviors into it because Fedora wants configuration to be a particular way. Like any other service, it should expect to find the config files it needs inside /etc/, and the concerns for managing those configs should be separate from the concerns of Bodhi. There are many ways to do config management, and we shouldn't make Bodhi be opinionated about how configs are managed. I'm pretty strongly opposed to the first option for these reasons.

I think second option (storing the configs in the infra Ansible repo) is the most sensible. We shouldn't let the fact that Pungi and Bodhi are separate programs confuse us. The Pungi config makes sense to think of as being a Bodhi config, since we think of Bodhi as being the thing that creates the update repos. It happens to do it via Pungi, but that's an implementation detail and so the configuration for making update repos should live with the rest of Bodhi's configuration. Bodhi's mash configs are stored in the infra ansible repo today, and it makes the most sense to keep them in there because that's the place where we configure Bodhi.

For an analogous relationship between programs, consider libvirt and qemu. It wouldn't be sensible for libvirt to git clone qemu configs. Qemu configs are managed alongside it (and even by it, if so chosen, which is analogous to Martin's Bodhi PR that has Bodhi dynamically creating Pungi configs for module "mashing"), because in the end libvirt users don't care that qemu is how the VMs are made - they think of libvirt as doing it.

P.S. It might make sense to move this ticket to the infra repository, since Bodhi mash configs are managed in the infra repo today.

My vote is for option 2.

  • The pungi configs (for bodhi) are analogous to the mash configs (for bodhi), which are stored in the ansible repo.
  • The pungi configs for bodhi likely won't share enough in common with the pungi configs for GA to make keeping them in the same repo super useful.

We can close this issue and consider #2 to be the accepted solution.

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

meeting

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.