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

----- 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-180... > $ 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(a)redhat.com&gt; wrote: > > On 11 January 2018 at 11:53, Javier Pena <jpena(a)redhat.com&gt; wrote: > >> ----- Original Message ----- > >>> On Wed, Jan 10, 2018 at 7:50 PM, Javier Pena <jpena(a)redhat.com&gt; 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(a)lists.rdoproject.org > http://lists.rdoproject.org/mailman/listinfo/dev > > To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org >