Open Stack

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.otto at 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) <stdake at 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-mota at 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-request at 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-mota at hpe.com
>>> 
>>> 
>>> 
>>>________________________________________________________________________
>>>__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>>OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev