@bowlofeggs what is the priority and timelines for this work? will we be able to deliver it in the f28 timeline?

On 03/06/2018 11:54 AM, Dennis Gilmore wrote:

@bowlofeggs what is the priority and timelines for this work? will we b=
e able to deliver it in the f28 timeline?

Hi Dennis!

I'm sorry to say that this is not on the top of my personal priority
list right now, and I can't commit to getting it done for F28. That
doesn't mean it can't happen for F28, but I am concerned about meeting
my other F28 goals as-is at this point and don't want to overcommit.

I also cannot perform this deployment on my own and will need assistance
from a system administrator, so it will also depend on their
availability. I will note that I think a sysadmin could do this without
me if one of them had the time and inclination to take this task on, so
my unavailability should not be a blocker.

We're in freeze, so I don't know exactly where this fits in.

I can take on the redeploy, starting with staging (which wouldn't need a freeze break).

To confirm, all of these (again just stg for now) need to be f27? Or just the first two?

• docker-registry01.stg.phx2.fedoraproject.org
• docker-registry02.stg.phx2.fedoraproject.org
• docker-candidate-registry01.stg.phx2.fedoraproject.org

Is there anyone depending on the stg ones that I need to coordinate with, or can I nuke them and redeploy them at any time?

Hi @codeblock!

I agree that we should not alter production during the freeze. I believe we would want all three of those updated, as I imaging that flatpaks will also be pushed into the candidate registry.

Nobody depends on stg to my knowledge, so I think it's fine to nuke and re-deploy. I would suggest attempting to save their data as practice for when we do this on production, because ideally we would also save production's data in the migration. I believe it is not critical to save the data though, because it should be possible for us to push the containers back into a fresh deployment if necessary. @puiterwijk, do you agree?

It seems to me like the data should be pretty easy to save - just shut down the registry, tar up the root directory of the registry (other otherwise save it) - it should be big but not huge - then untar it on the rebuilt servers.

Okay I've rebuilt the stg boxes as f27 and our newer glusterfs ansible role. Can you play around with it and make sure it works as expected?

Thanks for doing this! I think we'll have to wait until @cverna finishes configuring OSBS to support building Flaptaks for more testing, since the only source of content for the stg registries is OSBS.

@otaylor @cverna @bowlofeggs any update here? We still need to do prod, yes? When is that safe to do?

I think it's pretty safe at any time. But there's no real advantage to doing it before we have Flatpak building working in staging, and once that happens we can do some actual testing of the new functionality.

I do think we should do some testing with stg. Things like asserting we can push container builds into the registry and pull them out still. That said, I agree with @otaylor that it's not that pressing to switch prod since we don't have flatpaks building in Fedora yet.

Okay, then I'm going to close this and bump it out of my queue for the time being. Of course, please re-open it when there's something actionable I can do here :)

I've verified that :

a) OCI images were correctly uploaded to candidate-registry.stg.fedoraproject.org as the result of an OSBS Flatpak build
b) that I can download one of the resulting images, and the Flaptak annotations are correctly preserved

That, to me, completes the testing necessary to move this to production. We're ready to push the flatpak OSBS support to production, so attention to this would be appreciated. Thanks!