[openstack-dev] [magnum] Generate atomic images using diskimage-builder
ton at us.ibm.com
Wed Mar 23 17:10:26 UTC 2016
Thank you for making a huge improvement from the manual process of
building the Fedora Atomic image.
Although Atomic does publish a public OpenStack image that is being
considered in this patch:
in the past we have come to many situations where we need an image with
specific version of certain software
for features or bug fixes (Kubernetes, Docker, Flannel, ...). So the
automated and customizable build process
will be very helpful.
With respect to where to land the patch, I think diskimage-builder is a
If it does not land there, Magnum does currently have 2 sets of
diskimage-builder elements for Mesos image
and Ironic image, so it is also reasonable to submit the patch to Magnum.
With the new push to reorganize
into drivers for COE and distro, the elements would be a natural fit for
As for periodic image build, it's a good idea to stay current with the
distro, but we should avoid the situation
where something new in the image breaks a COE and we are stuck for awhile
until a fix is made. So instead of
an automated periodic build, we might want to stage the new image to make
sure it's good before switching.
One question: I notice the image built by DIB is 871MB, similar to the
manually built image, while the
public image from Atomic is 486MB. It might be worthwhile to understand
From: Yolanda Robla Mota <yolanda.robla-mota at hpe.com>
To: <openstack-dev at lists.openstack.org>
Date: 03/23/2016 04:12 AM
Subject: [openstack-dev] [magnum] Generate atomic images using
I wanted to start a discussion on how Fedora Atomic images are being
built. Currently the process for generating the atomic images used on
Magnum is described here:
The image needs to be built manually, uploaded to fedorapeople, and then
consumed from there in the magnum tests.
I have been working on a feature to allow diskimage-builder to generate
these images. The code that makes it possible is here:
This will allow that magnum images are generated on infra, using
diskimage-builder element. This element also has the ability to consume
any tree we need, so images can be customized on demand. I generated one
image using this element, and uploaded to fedora people. The image has
passed tests, and has been validated by several people.
So i'm raising that topic to decide what should be the next steps. This
change to generate fedora-atomic images has not already landed into
diskimage-builder. But we have two options here:
- add this element to generic diskimage-builder elements, as i'm doing now
- generate this element internally on magnum. So we can have a directory
in magnum project, called "elements", and have the fedora-atomic element
here. This will give us more control on the element behaviour, and will
allow to update the element without waiting for external reviews.
Once the code for diskimage-builder has landed, another step can be to
periodically generate images using a magnum job, and upload these images
to OpenStack Infra mirrors. Currently the image is based on Fedora F23,
docker-host tree. But different images can be generated if we need a
As soon as the images are available on internal infra mirrors, the tests
can be changed, to consume these internals images. By this way the tests
can be a bit faster (i know that the bottleneck is on the functional
testing, but if we reduce the download time it can help), and tests can
be more reilable, because we will be removing an external dependency.
So i'd like to get more feedback on this topic, options and next steps
to achieve the goals. Best
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
yolanda.robla-mota at hpe.com
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 105 bytes
Desc: not available
More information about the OpenStack-dev