[infra][qe][nova] Would it be possible to host a custom cirros image somewhere for the nova-next job?
lyarwood at redhat.com
Wed Mar 3 22:31:22 UTC 2021
On Wed, 3 Mar 2021 at 19:33, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2021-03-03 17:33:59 +0000 (+0000), Lee Yarwood wrote:
> > On Wed, 3 Mar 2021 at 13:45, Jeremy Stanley <fungi at yuggoth.org> wrote:
> > > https://opendev.org/openstack/project-config/src/branch/master/nodepool/elements/cache-devstack/source-repository-images
> > >
> > > If you look in the build logs of a DevStack-based job, you'll see it
> > > check, e.g., /opt/stack/devstack/files/cirros-0.4.0-x86_64-disk.img
> > > and then not wget that image over the network because it exists on
> > > the filesystem.
> > Thanks both,
> > So this final option looks like the most promising. It would not
> > however involve any independent build steps in nodepool or zuul. If
> > infra are okay with this I can host the dev build I have with my
> > change applied and post a change to cache it alongside the official
> > images.
> Yeah, I don't see that being much different from hitting
> download.cirros-cloud.net during out image builds. If you're forking
> or otherwise making unofficial builds of Cirros though, you might
> want to name the files something which makes that clear so people
> seeing it in job build logs know it's not an official Cirros
> provided version. I believe our Nodepool builders also cache such
> downloads locally, so you'll probably see them downloaded once each
> from handful of builders and, not again until the next time you
> update the filename in that DIB element.
Okay I've pushed the following for this:
Add custom cirros image with ahci module enabled to cache
I've gone for cirros-0.5.1-dev-ahci-x86_64-disk.img as the image name
but we can hash that out in the review.
Many thanks again!
More information about the openstack-discuss