The idea is to keep history, and we should have it configurable on how much we want to keep back (ideally i would keep everything at least few months back, if we have the space),
unlike nighties which are rotated frequently, we expect these repos will be used to verify ovirt bugs over a period of a few weeks/month so we should allow some level of history.

In time we'll do adjustments and we'll optimize the retention policy to the best usage of dev+qa consumption.

Yea, we need to keep an update link to latest repo + link to latest release rpm.

> Issue is that as the build flow is right now once the repo is created (ovirt-4.0_alpha1) a new ovirt-release rpm has to be created pointing to it (ovirt-release-4.0.0-0.2.alpha1) and added to the repo. Such repo will be referenced within the appliance, node image and live image so it should be something like a "final" repo, not a staging one.

One of the points of the task is:

Question is if that repo that is created weekly, is just the same each time (removed and regenerated) or should it keep a certain amount of them and rolling them out?
The release rpm can be created along with the repo itself in case you need it for each, or we can keep a 'latest' link to the newer repo and point the release rpm there, or anything in between.

> to know what will be the directory structure of the repositories, right now there's some ovirt-4.0_prealpha1/2 and prealpha_latest. It would be helpful if the names maintained the version order when alphabetically sorted, if not, things get a bit more weird.

we're starting with alpha1 today so from now on, it will be alphabetically sorted being alpha < beta < rc

> The created snapshot repo sholud be just 'ovirt_4.0.0_snap1' or should it create one each week? (like incremental numbers or something)
If the above, then how many to keep?

Issue is that as the build flow is right now once the repo is created (ovirt-4.0_alpha1) a new ovirt-release rpm has to be created pointing to it (ovirt-release-4.0.0-0.2.alpha1) and added to the repo. Such repo will be referenced within the appliance, node image and live image so it should be something like a "final" repo, not a staging one.

> the repos allowed when running the repo closure (or a script or similar).
all allowed repos are in ovirt-release40 rpm

Also, why are you collecting artifacts in the 'partial' flow patch?

I need a couple things (asking you as release manager):

• to know what will be the directory structure of the repositories, right now there's some ovirt-4.0_prealpha1/2 and prealpha_latest. It would be helpful if the names maintained the version order when alphabetically sorted, if not, things get a bit more weird.

• The created snapshot repo sholud be just 'ovirt_4.0.0_snap1' or should it create one each week? (like incremental numbers or something)

• If the above, then how many to keep?

• the repos allowed when running the repo closure (or a script or similar).

Last update on needed steps:

Current status:
"Stage 1" (first snapshot repo without images)

• a. oVirt nightlies are being published as usual

• b. A snapshot was created manually using repoman command, as described in [1]

• c ** missing **

• d. new release rpm for 4.0 was created manually [2]

• e ** missing **

• f. new softlink was created for latest pre-alpha releases [3]
  "Stage 2" (final repo with images)

• a. new jobs [4] building node + appliance created using the rpm from [3]

Missing steps:
"Stage 1" (first snapshot repo without images)

• new jenkins job that will run the whole flow starting from 1b, work has started here [5] (@sandro, please correct if i'm wrong)

• new step for checking repoclosure needs to be added as step 'c', code can be taken from [6].

• automate the step of building the release rpm pointing to a specific release dir.

• create new release rpm that will always point to latest snapshot link [3]

• add sanity for first repo using lago, similar to [7], just using the new release rpm to run on the new snapshot (step 1e)

"Stage 2" (repo including images)

• run the job(s) to build appliance, node & ovirt-live using the rpm from [2]. (job for ovirt-live might needs fixing to use release rpm)

• push the new images to the new repo, using TBD job

• run repoclosure to make sure images are install-able, similar to [6]

• run lago sanity tests on whatever is possible (node/appliance/he)

• update softlink [3] to point to new repo with images

• make repo readonly

• move bugs to ON_QA [8]

• send email on release with links + changelog

[1] https://ovirt-jira.atlassian.net/browse/OVIRT-422
[2] http://resources.ovirt.org/pub/ovirt-4.0_prealpha2/rpm/el7/noarch/ovirt-release40.rpm
[3] http://resources.ovirt.org/pub/ovirt-4.0_prealpha-latest/
[4] - can you share the links to the jobs?
[5] https://gerrit.ovirt.org/#/c/54626/
[6] http://jenkins.ovirt.org/job/repos_master_check-closure_merged/
[7] http://jenkins.ovirt.org/job/ovirt_master_system-tests/
[8] as first step we'll use the logic of extracting bugs from the commits msg for a list of projects (do we need approval from each maintainer?)

I believe you made some progress for this flow, including adjusting the rhevh and appliance jobs plus adding links + release rpm.

Can you add some info & links so we'll be able to plan the remaining items to finish the automation of the flow?

do you know if anyone from the infra team can handle it?