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

[Javier Pena]

----- Original Message -----
> Bumping the thead, upstream patches are merged now [0]
> 
> With current upstream code, I can generate an image from master packages
> with:
> $ wget
> https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1801-01.qcow2
> $ virt-customize -a CentOS-7-x86_64-GenericCloud-1801-01.qcow2
> --selinux-relabel --run-command 'yum-config-manager --add-repo
> http://trunk.rdoproject.org/centos7/delorean-deps.repo'
> $ virt-customize -a CentOS-7-x86_64-GenericCloud-1801-01.qcow2
> --selinux-relabel --run-command 'yum-config-manager --add-repo
> https://trunk.rdoproject.org/centos7/current-passed-ci/delorean.repo'
> $ DIB_LOCAL_IMAGE=/home/stack/CentOS-7-x86_64-GenericCloud-1801-01.qcow2
>  /opt/stack/octavia/diskimage-create/diskimage-create.sh -p -i centos
> -o amphora-x64-haproxy-centos.qcow2
> 
> This is with devstack, but will be mostly the same when RDO packages
> are updated (just the script location that then comes from
> openstack-octavia-diskimage-create package)
> 

I have run a quick test with the latest openstack-octavia-diskimage-create package from RDO Trunk, and it works like a charm.

> So what are the next steps here? missing information, place to track
> this, item for next meeting, action items, … ?
> 

Let's add it as an item for the next meeting, so we define a plan. My proposal would be a daily build using a periodic job, storing images in a new path under images.rdoproject.org.

Regards,
Javier


> 
> [0] https://review.openstack.org/#/c/522626/
> 
> On 12 January 2018 at 13:05, Bernard Cafarelli <bcafarel at redhat.com> wrote:
> > On 11 January 2018 at 11:53, Javier Pena <jpena at redhat.com> wrote:
> >> ----- Original Message -----
> >>> On Wed, Jan 10, 2018 at 7:50 PM, Javier Pena <jpena at redhat.com> wrote:
> >>> > 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.
> > I looked a bit initially into building the image directly in spec, one
> > problem was how to pass the needed RDO packages properly to
> > diskimage-builder (as a repo so that yum pulls them in).
> > Apart from some configuration tweaks, most of the steps sum up to yum
> > calls (system update - install haproxy, keepalived, … - install
> > openstack-octavia-amphora-agent), these need network access, or at
> > least local mirrors.
> >>>
> >>> I would be concerned with the storage required, also we need to
> >>> trigger not only on Octavia distgit or upstream changes, all included
> >>> RPMs need to be checked checked for updates.
> >>> This could be simulated with dummy commits in distgit to force e.g.
> >>> nightly refresh but due to storage requirements, I'd keep image builds
> >>> outside trunk repos.
> >>>
> >>
> >> I have been doing some tests, and it looks like running diskimage-builder
> >> from a chroot is not the best idea (it tries to mount some tmpfs and
> >> fails), so even if we solved the storage issue it wouldn't work.
> >> I think our best chance is to create a periodic job to rebuild the images
> >> (daily) then upload them to images.rdoproject.org. This would be a
> >> similar approach to what we are currently doing with containers.
> > That would work for "keeping other packages up to date" too
> >
> >> The only drawback of this alternative is that we would be distributing the
> >> qcow2 images instead of an RPM package, but we could still apply
> >> retention policies, and add some CI jobs to test them if needed.
> > On disk usage and retention polices, the images I build locally (with
> > CentOS) are 500-500 MB qcow2 files
> >
> > --
> > Bernard
> 
> 
> 
> --
> Bernard Cafarelli
> _______________________________________________
> dev mailing list
> dev at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
> 
> To unsubscribe: dev-unsubscribe at lists.rdoproject.org
>