set up "stage" Yum repo(s)

RESOLVED FIXED

Status

Socorro
Infra
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: phrawzty, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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.
(Reporter)

Comment 2

2 years ago
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.
What's the status on this? Does it need to block AWS production?
Flags: needinfo?(dmaher)

Comment 4

2 years ago
IMHO, it doesn't block prod, but it is a 'would be nice to have' type of thing.
No longer blocks: 1118288
(Reporter)

Comment 5

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

It's not a blocker; adjusting.
Blocks: 1097891
Flags: needinfo?(dmaher)
(Reporter)

Comment 6

2 years ago
(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.

Updated

a year ago
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.