<div dir="ltr">Gentlemen,<div><br></div><div>I have one small question about IBP, and I'm not sure if this is the right place to ask, but still: how do you plan to build the images for the image-based provisioning? Will you leverage <a href="https://github.com/openstack/diskimage-builder">diskimage-builder</a> or some other tool?</div><div><br></div><div>Thanks,</div><div><br></div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div><div>Mirantis Labs</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 10:55 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't see this as crazy, it's not a feature of the cloud, its a<br>
mechanism to get us there. It's not even something that most of the<br>
time anyone sees. Continuing to waste time supporting something we are<br>
ready to replace, and have been testing for a release already is<br>
crazy. It adds to the technical debt around provisioning that is<br>
broken a chlot of the time. We spend around 11% of all commits of<br>
fuel-library to cobbler, templates, pmanager etc<br>
<br>
It's also not removing it, it will continue to be present to support<br>
prior releases, so it's even still available if we cant make IBP work<br>
the way we need to.<br>
<div><div class="h5"><br>
On Tue, Jan 27, 2015 at 2:23 AM, Vladimir Kozhukalov<br>
<<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
> Guys,<br>
><br>
> First, we are not talking about deliberate disabling preseed based approach<br>
> just because we so crazy. The question is "What is the best way to achieve<br>
> our 6.1 goals?" We definitely need to be able to install two versions of<br>
> Ubuntu 12.04 and 14.04. Those versions have different sets of packages (for<br>
> example ntp related ones) and we install some of those packages during<br>
> provisioning (we point out which packages we need with their versions). To<br>
> make this working with preseed based approach we need either to insert some<br>
> "IF release==6.1" conditional lines into preseed (not very beautiful, isn't<br>
> it?) or to create different Distros and Profiles for different releases.<br>
> Second is not a problem for Cobbler but it is for nailgun/astute because we<br>
> do not deal with that stuff and it looks that we cannot implement this<br>
> easily.<br>
><br>
> IMO, the only options we have are to insert "IFs" into preseed (I would say<br>
> it is not more reliable than IBP) or to refuse preseed approach for ONLY NEW<br>
> UPCOMING releases. You can call "crazy" but for me having a set "IFs"<br>
> together with pmanager.py which are absolutely difficult to maintain is<br>
> crazy.<br>
><br>
><br>
><br>
> Vladimir Kozhukalov<br>
><br>
> On Tue, Jan 27, 2015 at 3:03 AM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Jan 26, 2015 at 10:47 AM, Sergii Golovatiuk<br>
>> <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>> wrote:<br>
>> > Until we are sure IBP solves operation phase where we need to deliver<br>
>> > updated packages so client will be able to provision new machines with<br>
>> > these<br>
>> > fixed packages, I would leave backward compatibility with normal<br>
>> > provision.<br>
>> > ... Just in case.<br>
>><br>
>> doesn't running 'apt-get upgrade' or 'yum update' after laying out the<br>
>> FS image resolve the gap until we can rebuild the images on the fly?<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Best regards,<br>
>> > Sergii Golovatiuk,<br>
>> > Skype #golserge<br>
>> > IRC #holser<br>
>> ><br>
>> > On Mon, Jan 26, 2015 at 4:56 PM, Vladimir Kozhukalov<br>
>> > <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>> >><br>
>> >> My suggestion is to make IBP the only option available for all upcoming<br>
>> >> OpenStack releases which are defined in openstack.yaml. It is to be<br>
>> >> possible<br>
>> >> to install OS using kickstart for all currently available OpenStack<br>
>> >> releases.<br>
>> >><br>
>> >> Vladimir Kozhukalov<br>
>> >><br>
>> >> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky<br>
>> >> <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Just want to be sure I understand you correctly: do you propose to<br>
>> >>> FORBID kickstart/preseed installation way in upcoming release at all?<br>
>> >>><br>
>> >>> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov<br>
>> >>> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>> >>> > Subject is changed.<br>
>> >>> ><br>
>> >>> > Vladimir Kozhukalov<br>
>> >>> ><br>
>> >>> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov<br>
>> >>> > <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>> >>> >><br>
>> >>> >> Dear Fuelers,<br>
>> >>> >><br>
>> >>> >> As you might know we need it to be possible to install several<br>
>> >>> >> versions of<br>
>> >>> >> a particular OS (Ubuntu and Centos) by 6.1  As far as having<br>
>> >>> >> different<br>
>> >>> >> OS<br>
>> >>> >> versions also means having different sets of packages and some of<br>
>> >>> >> the<br>
>> >>> >> packages are installed and configured during provisioning stage, we<br>
>> >>> >> need to<br>
>> >>> >> have a kind of kickstart/preseed version mechanism.<br>
>> >>> >><br>
>> >>> >> Cobbler is exactly such a mechanism. It allows us to have several<br>
>> >>> >> Distros<br>
>> >>> >> (installer images) and profiles (kickstart/preseed files). But<br>
>> >>> >> unfortunately, for some reasons we have not been using those<br>
>> >>> >> Cobbler's<br>
>> >>> >> capabilities since the beginning of Fuel and it doesn't seem to be<br>
>> >>> >> easily<br>
>> >>> >> introduced into Nailgun to deal with the whole Cobbler life cycle.<br>
>> >>> >><br>
>> >>> >> Anyway, we are moving towards IBP (image based provisioning) and we<br>
>> >>> >> already have different images connected to different OpenStack<br>
>> >>> >> releases<br>
>> >>> >> (openstack.yaml) and everything else which is necessary for initial<br>
>> >>> >> node<br>
>> >>> >> configuration is serialized inside provision data (including<br>
>> >>> >> profile<br>
>> >>> >> name<br>
>> >>> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose<br>
>> >>> >> cloud-init<br>
>> >>> >> template by this profile name.<br>
>> >>> >><br>
>> >>> >> And taking into account what it is written above, the suggestion is<br>
>> >>> >> to<br>
>> >>> >> completely avoid using kickstart/preseed based way of OS<br>
>> >>> >> provisioning<br>
>> >>> >> by 6.1<br>
>> >>> >> for all new releases allowing ONLY old ones to use this way.<br>
>> >>> >><br>
>> >>> >> Any opinions about that stuff are welcome.<br>
>> >>> >><br>
>> >>> >> Vladimir Kozhukalov<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > __________________________________________________________________________<br>
>> >>> > OpenStack Development Mailing List (not for usage questions)<br>
>> >>> > Unsubscribe:<br>
>> >>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>> ><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> __________________________________________________________________________<br>
>> >>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>> Unsubscribe:<br>
>> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Andrew<br>
>> Mirantis<br>
>> Ceph community<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Andrew<br>
Mirantis<br>
</div></div>Fuel community ambassador<br>
<div class="HOEnZb"><div class="h5">Ceph community<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>