[rdo-dev] [Octavia] Providing service VM images in RDO

[Javier Pena]

----- Original Message -----
> On 10 January 2018 at 14:41, Assaf Muller <assaf at redhat.com> wrote:
> > On Wed, Jan 10, 2018 at 8:10 AM, Alan Pevec <apevec at redhat.com> wrote:
> >> Hi Bernard,
> >>
> >> I've added this as a topic for the
> >> https://etherpad.openstack.org/p/RDO-Meeting today,
> >> with some initial questions to explore.
> Thanks, I will be there in #rdo
> >>
> >> On Wed, Jan 10, 2018 at 1:50 PM, Bernard Cafarelli <bcafarel at redhat.com>
> >> wrote:
> >>> * easier install/maintenance for the user, tripleo can consume the
> >>> image directly (from a package)
> >>
> >> How do you plan to distribute the image, wrapped inside RPM?
> If possible, that is my initial idea yes (easier to fetch, and allows
> tracking available updates with yum)

If we want to deliver via RPM and build on each Octavia change, we could try to add it to the octavia spec and build it using DLRN. Does the script require many external resources besides diskimage-builder?

I'm not sure if that would work on CBS though, if we need to have network connectivity during the build process.

Regards,
Javier

> >>
> >>> * ensuring up-to-date amphora images (to match the controller version,
> >>> for security updates, …)
> >>
> >> That's the most critical part of the process to figure out, how to
> >> automate image updates,
> >> just run it daily, trigger when included packages change...
> >
> > On Octavia patches (because the agent in the image might change), but
> > it's worth pointing out that other elements in the image may need
> > updating - Say, on a kernel CVE fix, haproxy update, etc. Maybe on
> > Octavia changes + on a nightly basis?
> A side-effect here would be that the user will see a new image
> available, while there are maybe no real changes. But determining if
> an image has real changes may not be easy (thinking out loud,
> comparing the installed packages versions?)
> 
> >
> >>
> >>> * allow to test and confirm the amphora works properly with latest
> >>> changes, including enforcing SELinux (CentOS upstream gate runs in
> >>> permissive)
> >>
> >> And that's the second part, which CI job would test it properly?
> A bit outside of the RDO pipeline, tripleo CI would use it to test
> Octavia deployments (I will check here with relevant folks)
> In the pipeline yes it would be nice to test to confirm that Octavia
> parts work fine with this repository version
> >>
> >>> * use this image in tripleo CI (instead of having to build it there)
> >>
> >> Related to the up-to-date issue: how to ensure it's latest for CI?
> >>
> >>> * (future) extend this system for other system VM images
> >>
> >> Which ones?
> Currently off the top of my head, Sahara and Trove? Though I did not
> study it further if it is possible/worth it for  these projects
> 
> Projects like tacker also have service VMs, but these are probably too
> specific/customizable
> >>
> >> Cheers,
> >> Alan
> >> _______________________________________________
> >> dev mailing list
> >> dev at lists.rdoproject.org
> >> http://lists.rdoproject.org/mailman/listinfo/dev
> >>
> >> To unsubscribe: dev-unsubscribe at lists.rdoproject.org
> _______________________________________________
> dev mailing list
> dev at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
> 
> To unsubscribe: dev-unsubscribe at lists.rdoproject.org
>