Adrian, Makes sense. Do the images have to be built to be mirrored though? Can't they just be put on the mirror sites fro upstream?
Thanks -steve On 3/29/16, 11:02 AM, "Adrian Otto" <adrian.o...@rackspace.com> wrote: >Steve, > >I¹m very interested in having an image locally cached in glance in each >of the clouds used by OpenStack infra. The local caching of the glance >images will produce much faster gate testing times. I don¹t care about >how the images are built, but we really do care about the performance >outcome. > >Adrian > >> On Mar 29, 2016, at 10:38 AM, Steven Dake (stdake) <std...@cisco.com> >>wrote: >> >> 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 > > >__________________________________________________________________________ >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