Open Stack

Hi,

We are using the official Fedora Atomic 23 images here (on Mitaka M1
however) and it seems to work fine with at least Kubernetes and Docker
Swarm.
Any reason to continue building specific Magnum image ?

Regards,

Mathieu

Le mercredi 23 mars 2016 à 12:09 +0100, Yolanda Robla Mota a écrit :
> Hi
> 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: 
> http://docs.openstack.org/developer/magnum/dev/build-atomic-image.htm
> l.
> 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: 
> https://review.openstack.org/287167
> 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 
> better option.
> 
> 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
>