1168096 - set up "stage" Yum repo(s)

Status: RESOLVED FIXED

(Socorro :: Infra, task)

Description

[Daniel Maher [:phrawzty]]

We are now functionally building distinct Prod and Stage socorro RPM packages; however, we make no particular distinction between the two in our repository.  A "tagged" release is considered production-ready (read: stable) and any other push to master is meant for stage only (read: unstable).  In this model, the only way to know what is stable is to look at all of the packages and pick the oldest most recent tagged release, which is not exactly intuitive.

Consider the following list of (theoretical) packages sitting in our Yum repo:

socorro-100.1432217670-1.x86_64.rpm
socorro-100.1432218437-1.x86_64.rpm
socorro-101.1432248990-1.x86_64.rpm
socorro-101.1432256690-1.x86_64.rpm
socorro-101.1432290222-1.x86_64.rpm

Which is stable?  The answer is socorro-101.1432248990-1.x86_64.rpm, but I challenge somebody from outside of our little group to figure that out on their own.

Furthermore, anybody running a "yum install socorro" with our repo enabled will end up getting whatever happens to be the most recent package, whether it's stable or not (without any warning) - this isn't very good from a community stewardship perspective.

Yet Another Repository which contains our stage packages only (such as socorro-public-stage and, eventually, socorro-public-noarch-stage), much like how some distros make the distinction.  That way we can test things from staging as we like without polluting the repo with potentially bad builds.

Comment 1

[Daniel Maher [:phrawzty]]

JP sez:
> Sure, I think that makes sense.  We can have the prod step copy that particular repo from
> the stage repo to the prod repo.  That way, we don't have to build the rpm during the prod push.

Comment 2

[Daniel Maher [:phrawzty]]

I've updated the manage_repo.sh script such that it has awareness of multiple environments.

Next step is to set up a Yum config and package it (like socorro-public-repo.rpm) so that it's automatable. From there we can work on integrating the stage/prod repo division into our workflow.

Comment 3

[Robert Helmer [:rhelmer]]

What's the status on this? Does it need to block AWS production?

Comment 4

[JP Schneider [:jp]]

IMHO, it doesn't block prod, but it is a 'would be nice to have' type of thing.

Comment 5

[Daniel Maher [:phrawzty]]

As I was on vacation this bug has not progressed from comment #2.

It's not a blocker; adjusting.

Comment 6

[Daniel Maher [:phrawzty]]

(In reply to Daniel Maher [:phrawzty] from comment #2)
> Next step is to set up a Yum config and package it (like
> socorro-public-repo.rpm) so that it's automatable. From there we can work on
> integrating the stage/prod repo division into our workflow.

This package (and associated SRPM) are now available in the (prod) repo.