Open Stack

Hi
I have also been talking with diskimage-builder cores and they suggested 
we better start with the element on magnum. So I moved the change here:
https://review.openstack.org/#/c/296719/

About diskimage-size, I'll dig a bit more on it. It can be for two causes:
1. To generate the fedora-atomic image, I first install a fedora-minimal 
image, and install ostree packages and the dependencies there. Based on 
that, i execute the ostree commands, and then I update the grub config 
to boot with the new image. But the old contents are still there, so 
this is potentially increasing the size. I will take a look at possible 
cleanup solutions.
2. The way diskimage-builder compresses the image. It can be different 
from the one that Fedora is using, and less effective. I saw discussions 
in diskimage-builder about that, and there have been recent improvements 
as https://review.openstack.org/290944 . Is worth investigating a bit 
more as well.

Best
Yolanda

El 23/03/16 a las 18:10, Ton Ngo escribió:
>
> Hi Yolanda,
> Thank you for making a huge improvement from the manual process of 
> building the Fedora Atomic image.
> Although Atomic does publish a public OpenStack image that is being 
> considered in this patch:
> https://review.openstack.org/#/c/276232/
> in the past we have come to many situations where we need an image 
> with specific version of certain software
> for features or bug fixes (Kubernetes, Docker, Flannel, ...). So the 
> automated and customizable build process
> will be very helpful.
>
> With respect to where to land the patch, I think diskimage-builder is 
> a reasonable target.
> If it does not land there, Magnum does currently have 2 sets of 
> diskimage-builder elements for Mesos image
> and Ironic image, so it is also reasonable to submit the patch to 
> Magnum. With the new push to reorganize
> into drivers for COE and distro, the elements would be a natural fit 
> for Fedora Atomic.
>
> As for periodic image build, it's a good idea to stay current with the 
> distro, but we should avoid the situation
> where something new in the image breaks a COE and we are stuck for 
> awhile until a fix is made. So instead of
> an automated periodic build, we might want to stage the new image to 
> make sure it's good before switching.
>
> One question: I notice the image built by DIB is 871MB, similar to the 
> manually built image, while the
> public image from Atomic is 486MB. It might be worthwhile to 
> understand the difference.
>
> Ton Ngo,
>
> Inactive hide details for Yolanda Robla Mota ---03/23/2016 04:12:54 
> AM---Hi I wanted to start a discussion on how Fedora AtomicYolanda 
> Robla Mota ---03/23/2016 04:12:54 AM---Hi I wanted to start a 
> discussion on how Fedora Atomic images are being
>
> From: Yolanda Robla Mota <yolanda.robla-mota at hpe.com>
> To: <openstack-dev at lists.openstack.org>
> Date: 03/23/2016 04:12 AM
> Subject: [openstack-dev] [magnum] Generate atomic images using 
> diskimage-builder
>
> ------------------------------------------------------------------------
>
>
>
> 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.html.
> 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
>
> -- 
> 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

-- 
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-mota at hpe.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160324/f33969b8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160324/f33969b8/attachment.gif>