Yolanda, That is a fantastic objective. Matthieu asked why build our own images if the upstream images work and need no further customization?
Regards -steve On 3/29/16, 1:57 AM, "Yolanda Robla Mota" <yolanda.robla-m...@hpe.com> wrote: >Hi >The idea is to build own images using diskimage-builder, rather than >downloading the image from external sources. By that way, the image can >live in our mirrors, and is built using the same pattern as other images >used in OpenStack. >It also opens the door to customize the images, using custom trees, if >there is a need for it. Actually we rely on official tree for Fedora 23 >Atomic (https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/) as >default. > >Best, >Yolanda > >El 29/03/16 a las 10:17, Mathieu Velten escribió: >> 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 >>> >> >>_________________________________________________________________________ >>_ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >-- >Yolanda Robla Mota >Cloud Automation and Distribution Engineer >+34 605641639 >yolanda.robla-m...@hpe.com > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev