<html><body><p> In multiple occasions in the past, we have had to use version of some software that's not available yet<br>in the upstream image for bug fixes or new features (Kubernetes, Docker, Flannel,...). Eventually the upstream <br>image would catch up, but having the tool to customize let us push forward with development, and gate tests<br>if it makes sense.<br><br>Ton Ngo,<br><br><br><img width="16" height="16" src="cid:1__=07BBF516DFE1D85D8f9e8a93df938690918c07B@" border="0" alt="Inactive hide details for Yolanda Robla Mota ---03/29/2016 01:35:48 PM---So the advantages I can see with diskimage-builder are"><font color="#424282">Yolanda Robla Mota ---03/29/2016 01:35:48 PM---So the advantages I can see with diskimage-builder are: - we reuse the same tooling that is present</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Yolanda Robla Mota <yolanda.robla-mota@hpe.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2"><openstack-dev@lists.openstack.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/29/2016 01:35 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>So the advantages I can see with diskimage-builder are:<br>- we reuse the same tooling that is present in other openstack projects <br>to generate images, rather than relying on an external image<br>- it improves the control we have on the contents of the image, instead <br>of seeing that as a black box. At the moment we can rely on the default <br>tree for fedora 23, but this can be updated per magnum needs<br>- reusability: we have atomic 23 now, but why not create magnum images <br>with dib, for ubuntu, or any other distros ? Relying on <br>diskimage-builder makes it easy and flexible, because it's a matter of <br>adding the right elements.<br><br>Best<br>Yolanda<br><br>El 29/03/16 a las 21:54, Steven Dake (stdake) escribió:<br>> Adrian,<br>><br>> Makes sense. Do the images have to be built to be mirrored though? Can't<br>> they just be put on the mirror sites fro upstream?<br>><br>> Thanks<br>> -steve<br>><br>> On 3/29/16, 11:02 AM, "Adrian Otto" <adrian.otto@rackspace.com> wrote:<br>><br>>> Steve,<br>>><br>>> I¹m very interested in having an image locally cached in glance in each<br>>> of the clouds used by OpenStack infra. The local caching of the glance<br>>> images will produce much faster gate testing times. I don¹t care about<br>>> how the images are built, but we really do care about the performance<br>>> outcome.<br>>><br>>> Adrian<br>>><br>>>> On Mar 29, 2016, at 10:38 AM, Steven Dake (stdake) <stdake@cisco.com><br>>>> wrote:<br>>>><br>>>> Yolanda,<br>>>><br>>>> That is a fantastic objective. Matthieu asked why build our own images<br>>>> if<br>>>> the upstream images work and need no further customization?<br>>>><br>>>> Regards<br>>>> -steve<br>>>><br>>>> On 3/29/16, 1:57 AM, "Yolanda Robla Mota" <yolanda.robla-mota@hpe.com><br>>>> wrote:<br>>>><br>>>>> Hi<br>>>>> The idea is to build own images using diskimage-builder, rather than<br>>>>> downloading the image from external sources. By that way, the image can<br>>>>> live in our mirrors, and is built using the same pattern as other<br>>>>> images<br>>>>> used in OpenStack.<br>>>>> It also opens the door to customize the images, using custom trees, if<br>>>>> there is a need for it. Actually we rely on official tree for Fedora 23<br>>>>> Atomic (</tt><tt><a href="https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/">https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/</a></tt><tt>) as<br>>>>> default.<br>>>>><br>>>>> Best,<br>>>>> Yolanda<br>>>>><br>>>>> El 29/03/16 a las 10:17, Mathieu Velten escribió:<br>>>>>> Hi,<br>>>>>><br>>>>>> We are using the official Fedora Atomic 23 images here (on Mitaka M1<br>>>>>> however) and it seems to work fine with at least Kubernetes and Docker<br>>>>>> Swarm.<br>>>>>> Any reason to continue building specific Magnum image ?<br>>>>>><br>>>>>> Regards,<br>>>>>><br>>>>>> Mathieu<br>>>>>><br>>>>>> Le mercredi 23 mars 2016 à 12:09 +0100, Yolanda Robla Mota a écrit :<br>>>>>>> Hi<br>>>>>>> I wanted to start a discussion on how Fedora Atomic images are being<br>>>>>>> built. Currently the process for generating the atomic images used<br>>>>>>> on<br>>>>>>> Magnum is described here:<br>>>>>>> </tt><tt><a href="http://docs.openstack.org/developer/magnum/dev/build-atomic-image.htm">http://docs.openstack.org/developer/magnum/dev/build-atomic-image.htm</a></tt><tt><br>>>>>>> l.<br>>>>>>> The image needs to be built manually, uploaded to fedorapeople, and<br>>>>>>> then<br>>>>>>> consumed from there in the magnum tests.<br>>>>>>> I have been working on a feature to allow diskimage-builder to<br>>>>>>> generate<br>>>>>>> these images. The code that makes it possible is here:<br>>>>>>> </tt><tt><a href="https://review.openstack.org/287167">https://review.openstack.org/287167</a></tt><tt><br>>>>>>> This will allow that magnum images are generated on infra, using<br>>>>>>> diskimage-builder element. This element also has the ability to<br>>>>>>> consume<br>>>>>>> any tree we need, so images can be customized on demand. I generated<br>>>>>>> one<br>>>>>>> image using this element, and uploaded to fedora people. The image<br>>>>>>> has<br>>>>>>> passed tests, and has been validated by several people.<br>>>>>>><br>>>>>>> So i'm raising that topic to decide what should be the next steps.<br>>>>>>> This<br>>>>>>> change to generate fedora-atomic images has not already landed into<br>>>>>>> diskimage-builder. But we have two options here:<br>>>>>>> - add this element to generic diskimage-builder elements, as i'm<br>>>>>>> doing now<br>>>>>>> - generate this element internally on magnum. So we can have a<br>>>>>>> directory<br>>>>>>> in magnum project, called "elements", and have the fedora-atomic<br>>>>>>> element<br>>>>>>> here. This will give us more control on the element behaviour, and<br>>>>>>> will<br>>>>>>> allow to update the element without waiting for external reviews.<br>>>>>>><br>>>>>>> Once the code for diskimage-builder has landed, another step can be<br>>>>>>> to<br>>>>>>> periodically generate images using a magnum job, and upload these<br>>>>>>> images<br>>>>>>> to OpenStack Infra mirrors. Currently the image is based on Fedora<br>>>>>>> F23,<br>>>>>>> docker-host tree. But different images can be generated if we need a<br>>>>>>> better option.<br>>>>>>><br>>>>>>> As soon as the images are available on internal infra mirrors, the<br>>>>>>> tests<br>>>>>>> can be changed, to consume these internals images. By this way the<br>>>>>>> tests<br>>>>>>> can be a bit faster (i know that the bottleneck is on the functional<br>>>>>>> testing, but if we reduce the download time it can help), and tests<br>>>>>>> can<br>>>>>>> be more reilable, because we will be removing an external dependency.<br>>>>>>><br>>>>>>> So i'd like to get more feedback on this topic, options and next<br>>>>>>> steps<br>>>>>>> to achieve the goals. Best<br>>>>>>><br>>>>>><br>>>>>> _______________________________________________________________________<br>>>>>> __<br>>>>>> _<br>>>>>> OpenStack Development Mailing List (not for usage questions)<br>>>>>> Unsubscribe:<br>>>>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>>>>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>>>>> -- <br>>>>> Yolanda Robla Mota<br>>>>> Cloud Automation and Distribution Engineer<br>>>>> +34 605641639<br>>>>> yolanda.robla-mota@hpe.com<br>>>>><br>>>>><br>>>>><br>>>>> ________________________________________________________________________<br>>>>> __<br>>>>> OpenStack Development Mailing List (not for usage questions)<br>>>>> Unsubscribe:<br>>>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>>>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>>>><br>>>><br>>>> _________________________________________________________________________<br>>>> _<br>>>> OpenStack Development Mailing List (not for usage questions)<br>>>> Unsubscribe:<br>>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br><br>-- <br>Yolanda Robla Mota<br>Cloud Automation and Distribution Engineer<br>+34 605641639<br>yolanda.robla-mota@hpe.com<br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br><br></tt><br><br><BR>
</body></html>