MRE cards for pinot

[Lucas Kanashiro]

Hey,

On Thu, Jul 20, 2023 at 4:16 PM Bryce Harrington <
bryce.harrington at canonical.com> wrote:

> 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.
>

Sorry for the confusion. This topic just came up to me when I read this
email.


> 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.
>

That would be awesome, thanks for letting me know. No hurry at all from my
side.


>
> > 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.
>

Thanks. Ideally, I want to update the container stack every month (if there
are new upstream releases available), my ongoing work is the foundation to
allow me to do that. Right now, it is kind of impossible to do it so often
due to breakages in the archive. Hopefully, next cycle things will be
better.


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

It does help, thanks again for your work!

Lucas Kanashiro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20230720/85693089/attachment-0001.html>