<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
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:<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/296719/">https://review.openstack.org/#/c/296719/</a><br>
<br>
About diskimage-size, I'll dig a bit more on it. It can be for two
causes:<br>
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.<br>
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 <a class="moz-txt-link-freetext" href="https://review.openstack.org/290944">https://review.openstack.org/290944</a> . Is
worth investigating a bit more as well.<br>
<br>
Best<br>
Yolanda<br>
<br>
<div class="moz-cite-prefix">El 23/03/16 a las 18:10, Ton Ngo
escribió:<br>
</div>
<blockquote
cite="mid:201603231710.u2NHASfS000840@d03av04.boulder.ibm.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p>Hi Yolanda,<br>
Thank you for making a huge improvement from the manual process
of building the Fedora Atomic image. <br>
Although Atomic does publish a public OpenStack image that is
being considered in this patch:<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/276232/">https://review.openstack.org/#/c/276232/</a><br>
in the past we have come to many situations where we need an
image with specific version of certain software<br>
for features or bug fixes (Kubernetes, Docker, Flannel, ...). So
the automated and customizable build process <br>
will be very helpful. <br>
<br>
With respect to where to land the patch, I think
diskimage-builder is a reasonable target. <br>
If it does not land there, Magnum does currently have 2 sets of
diskimage-builder elements for Mesos image <br>
and Ironic image, so it is also reasonable to submit the patch
to Magnum. With the new push to reorganize<br>
into drivers for COE and distro, the elements would be a natural
fit for Fedora Atomic. <br>
<br>
As for periodic image build, it's a good idea to stay current
with the distro, but we should avoid the situation <br>
where something new in the image breaks a COE and we are stuck
for awhile until a fix is made. So instead of<br>
an automated periodic build, we might want to stage the new
image to make sure it's good before switching.<br>
<br>
One question: I notice the image built by DIB is 871MB, similar
to the manually built image, while the<br>
public image from Atomic is 486MB. It might be worthwhile to
understand the difference. <br>
<br>
Ton Ngo,<br>
<br>
<img src="cid:part2.02020803.07040900@hpe.com" alt="Inactive
hide details for Yolanda Robla Mota ---03/23/2016 04:12:54
AM---Hi I wanted to start a discussion on how Fedora Atomic"
border="0" height="16" width="16"><font color="#424282">Yolanda
Robla Mota ---03/23/2016 04:12:54 AM---Hi I wanted to start a
discussion on how Fedora Atomic images are being</font><br>
<br>
<font color="#5F5F5F" size="2">From: </font><font size="2">Yolanda
Robla Mota <a class="moz-txt-link-rfc2396E" href="mailto:yolanda.robla-mota@hpe.com"><yolanda.robla-mota@hpe.com></a></font><br>
<font color="#5F5F5F" size="2">To: </font><font size="2"><a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a></font><br>
<font color="#5F5F5F" size="2">Date: </font><font size="2">03/23/2016
04:12 AM</font><br>
<font color="#5F5F5F" size="2">Subject: </font><font size="2">[openstack-dev]
[magnum] Generate atomic images using diskimage-builder</font><br>
</p>
<hr style="color:#8091A5; " align="left" size="2"
noshade="noshade" width="100%"><br>
<br>
<br>
<tt>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 on <br>
Magnum is described here: <br>
</tt><tt><a moz-do-not-send="true"
href="http://docs.openstack.org/developer/magnum/dev/build-atomic-image.html">http://docs.openstack.org/developer/magnum/dev/build-atomic-image.html</a></tt><tt>.<br>
The image needs to be built manually, uploaded to fedorapeople,
and then <br>
consumed from there in the magnum tests.<br>
I have been working on a feature to allow diskimage-builder to
generate <br>
these images. The code that makes it possible is here: <br>
</tt><tt><a moz-do-not-send="true"
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
consume <br>
any tree we need, so images can be customized on demand. I
generated one <br>
image using this element, and uploaded to fedora people. The
image 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. 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
doing now<br>
- generate this element internally on magnum. So we can have a
directory <br>
in magnum project, called "elements", and have the fedora-atomic
element <br>
here. This will give us more control on the element behaviour,
and 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 to <br>
periodically generate images using a magnum job, and upload
these images <br>
to OpenStack Infra mirrors. Currently the image is based on
Fedora 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 tests <br>
can be changed, to consume these internals images. By this way
the 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 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
steps <br>
to achieve the goals. Best<br>
<br>
-- <br>
Yolanda Robla Mota<br>
Cloud Automation and Distribution Engineer<br>
+34 605641639<br>
<a class="moz-txt-link-abbreviated" href="mailto:yolanda.robla-mota@hpe.com">yolanda.robla-mota@hpe.com</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</tt><tt><a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
<a class="moz-txt-link-abbreviated" href="mailto:yolanda.robla-mota@hpe.com">yolanda.robla-mota@hpe.com</a></pre>
</body>
</html>