We are working to get bodhi calling pungi instead of mash to create repos. One problem with this is that the structure of the directories is different between pungi and mash. We essentially need to resolve how we want this to look in the future.
Here is what bodhi looks like today:
$topdir/f26-updates -> symlink to latest run $topdir/f26-updates-170804.1348/f26-updates/aarch64/ $topdir/f26-updates-170804.1348/f26-updates/x86_64/
Here is what we get when we run bodhi + pungi together:
$topdir/f26-updates -> symlink to latest bodhi run $topdir/f26-updates-170803.0245/Fedora-Atomic-26-20170803.0/latest-Fedora-Atomic-26 -> symlink to latest pungi run $topdir/f26-updates-170803.0245/Fedora-Atomic-26-20170803.0/compose/Everything/x86_64/os/ $topdir/f26-updates-170803.0245/Fedora-Atomic-26-20170803.0/compose/Everything/aarch64/os/
I had to manually work around some assumptions about the file hierarchy in bodhi in order to fake it out and get the compose to complete. Mainly this meant running the following after the compose had started:
cd $topdir/f26-updates-170803.0245/ sudo mkdir f26-updates cd f26-updates sudo ln -s ../Fedora-Atomic-26-20170803.0/compose/Everything/x86_64/os/ ./x86_64 sudo chown -R apache:apache ./f26-updates/
We need to figure out what we want this to look like in the future. Should I have bodhi simulate the file structure that it expects to see by using symlinks in the code?
in the releng meeting today we decided that we would accept the pungi file hierarchy as is and would make updates to mirrormanager to handle the issues.
We will continue to make toplevel symlinks as was done in the past. After a single bodhi run we'll have something like this:
$topdir/f26-updates -> ./f26-updates-170803.0245 $topdir/f26-updates-170803.0245/Fedora-Atomic-26-20170803.0 $topdir/f26-updates-170803.0245/latest-Fedora-Atomic-26 -> ./Fedora-Atomic-26-20170803.0
After a 2nd bodhi run we would have something like:
$topdir/f26-updates -> ./f26-updates-170804.0245 $topdir/f26-updates-170804.0245/Fedora-Atomic-26-20170804.0 $topdir/f26-updates-170804.0245/latest-Fedora-Atomic-26 -> ./Fedora-Atomic-26-20170804.0 $topdir/f26-updates-170803.0245/Fedora-Atomic-26-20170803.0 $topdir/f26-updates-170803.0245/latest-Fedora-Atomic-26 -> ./Fedora-Atomic-26-20170803.0
one thing I didn't think about before is if we take the pungi repos as-is then we will end up mirroring all artifacts (qcows, isos , etc) from the pungi compose. Previously I had planned to sym link to only the repos and that way nothing else would get mirrored. I think this is something we should consider.
its simple enough to mirror the bits we want.
OK. So from that I won't worry about including content that we don't want to mirror. Are those details for mirrormanager?
opened a ticket here for mirrormanager: https://github.com/fedora-infra/mirrormanager2/issues/215
After talking with @adrian he thinks it would make sense for us to temporarily support both the old file structure and the new file structure in order to not have any issues while the mirrors transition to the new file structure. How hard do we think this would be to do? How much should we worry about the transition period and the user experience during that period?
given the shart change window and how mm works, I do not think we needs to do anything special, we just need to make sure we update the pointers to where the content now goes when we update the locations.
We are going to resolve this on the sync script side of things, so we should be good here.
Metadata Update from @puiterwijk: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.