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

Tom Barron tbarron at redhat.com
Wed Jan 10 15:24:48 UTC 2018


On 10/01/18 15:48 +0100, Bernard Cafarelli wrote:
>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)
>>>
>>>> * 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

For completeness, upstream manila has service VMs, currently 
downloadable from http://tarballs.openstack.org/manila-image-elements

We've considered potentially asking to carry them in RDO and further 
downstream but are not currently doing so.

-- Tom Barron

>>>
>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20180110/19d82e09/attachment.sig>


More information about the dev mailing list