MRE cards for pinot

[Bryce Harrington]

On Thu, Jul 20, 2023 at 09:24:35AM -0300, Lucas Kanashiro wrote:
> Hi,
> 
> On Wed, Jul 19, 2023 at 8:47 PM Bryce Harrington <
> bryce.harrington at canonical.com> wrote:
> 
> > Following up on the question from this morning regarding the missing
> > cards for the MRE tasks for various packages, here's the config for what
> > we have presently:
> >
> >
> >
> >     software = [
> >         {
> >             'software-name': 'dpdk',
> >             'software-type': 'deb',
> >             'information-type': 'public',
> >             'packages': ['dpdk'],
> >             'update-schedule': ['Mar', 'Jun', 'Sep', 'Dec'],
> >         },
> >         {
> >             'software-name': 'postgresql',
> >             'software-type': 'deb',
> >             'information-type': 'public',
> >             'packages': ['postgresql-10', 'postgresql-12',
> > 'postgresql-13'],
> >             'update-schedule': ['Feb', 'May', 'Aug', 'Nov'],
> >         },
> >         {
> >             'software-name': 'open-vm-tools',
> >             'software-type': 'deb',
> >             'information-type': 'public',
> >             'packages': ['open-vm-tools'],
> >             'update-schedule': ['Apr', 'Oct'],
> >         },
> >         {
> >             'software-name': 'container-stack',
> >             'software-type': 'deb',
> >             'information-type': 'public',
> >             'packages': ['docker.io', 'containerd', 'runc'],
> >             'update-schedule': ['Feb', 'May', 'Aug', 'Nov'],
> >         },
> >
> 
> Regarding the container-stack: I'd like to know if it is possible to track
> upstream instead of Debian when checking for merges Bryce (maybe this is
> another part of your tooling, not this one).

It is, but you're right that that's more a functionality for the merge
tracking side of PDBQ, this is more on the scheduling end and is
agnostic about versions since our process ties MREs to the cycle
timeframe.  This tool is really supposed to be run at the start of a
cycle to put cards on the board for when we might expect to do the MREs,
and that often will be before upstream has made any releases, so is more
predictive and thus agnostic about upstream versions or releases.

As to the merge opportunity tracking for upstream releases, I've got a
couple Jira tickets tracking that work, SD-1085 and SD-340, which I've
chipped away at as time permits each cycle (I've elaborated my plans on
those cards if interested).  Earlier this cycle you may remember I made
progress on improving the collection of upstream and debian versions.
I'm hoping once my more pressing items for this cycle are taken care of,
that I can get that version data into a database that Pinot can use to
generate a package version tabular listing (like the desktop team has,
as Robie pointed out recently), as well as to be able to mark the MRE
cards in our current Pinot web report in some fashion.  So, that'll be a
bit further ahead, but I think will give the functionality you're
imagining for monitoring the container stack upstream state.

> I've made some changes to
> those packages and now we would need the following:
> 
> - docker.io and containerd: check for merges against Debian
> - docker.io-app, containerd-app and runc: check for merges against upstream
> 
> And for the backport for stable releases (not exactly a MRE but that's the
> nomenclature we have been using here), I'd like to track just
> docker.io-app, containerd-app and runc.

Gotcha, so sounds like for purposes of this tool the packages we would
track are docker.io-app, containerd-app and runc.  I'll update the
config to show these three.

> Let me know if the above is possible, thanks for your work on this Bryce!

Thanks, and hope the above helps!
Bryce