<div dir="ltr">Andrew is right about our ability to upgrade packages on a system using "yum update" or "apt-get upgrade" because IBP installs standalone OS (unlike cloud case). Even more, we'll build Ubuntu images on a master node by 6.1 and of course we'll be able to use actual repo for that.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Tue, Jan 27, 2015 at 1:23 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Guys, <div><br></div><div>First, we are not talking about deliberate disabling preseed based approach just because we so crazy. The question is "What is the best way to achieve our 6.1 goals?" We definitely need to be able to install two versions of Ubuntu 12.04 and 14.04. Those versions have different sets of packages (for example ntp related ones) and we install some of those packages during provisioning (we point out which packages we need with their versions). To make this working with preseed based approach we need either to insert some "IF release==6.1" conditional lines into preseed (not very beautiful, isn't it?) or to create different Distros and Profiles for different releases. Second is not a problem for Cobbler but it is for nailgun/astute because we do not deal with that stuff and it looks that we cannot implement this easily.</div><div><br></div><div>IMO, the only options we have are to insert "IFs" into preseed (I would say it is not more reliable than IBP) or to refuse preseed approach for ONLY NEW UPCOMING releases. You can call "crazy" but for me having a set "IFs" together with pmanager.py which are absolutely difficult to maintain is crazy. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Tue, Jan 27, 2015 at 3:03 AM, 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"><span>On Mon, Jan 26, 2015 at 10:47 AM, Sergii Golovatiuk<br>
<<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">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 these<br>
> fixed packages, I would leave backward compatibility with normal provision.<br>
> ... Just in case.<br>
<br>
</span>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>
<div><div>><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" target="_blank">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 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 <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">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" target="_blank">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" target="_blank">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 different<br>
>>> >> OS<br>
>>> >> versions also means having different sets of packages and some of 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 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 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 to<br>
>>> >> completely avoid using kickstart/preseed based way of OS 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>
>>> > 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>
>>> 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>
>> 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>
</div></div><span><font color="#888888">--<br>
Andrew<br>
Mirantis<br>
Ceph community<br>
</font></span><div><div><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></div></div>
</blockquote></div><br></div>