Gentlemen, 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 diskimage-builder <https://github.com/openstack/diskimage-builder> or some other tool?
Thanks, -- Best regards, Oleg Gelbukh Mirantis Labs On Tue, Jan 27, 2015 at 10:55 PM, Andrew Woodward <xar...@gmail.com> wrote: > I don't see this as crazy, it's not a feature of the cloud, its a > mechanism to get us there. It's not even something that most of the > time anyone sees. Continuing to waste time supporting something we are > ready to replace, and have been testing for a release already is > crazy. It adds to the technical debt around provisioning that is > broken a chlot of the time. We spend around 11% of all commits of > fuel-library to cobbler, templates, pmanager etc > > It's also not removing it, it will continue to be present to support > prior releases, so it's even still available if we cant make IBP work > the way we need to. > > On Tue, Jan 27, 2015 at 2:23 AM, Vladimir Kozhukalov > <vkozhuka...@mirantis.com> wrote: > > Guys, > > > > 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. > > > > 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. > > > > > > > > Vladimir Kozhukalov > > > > On Tue, Jan 27, 2015 at 3:03 AM, Andrew Woodward <xar...@gmail.com> > wrote: > >> > >> On Mon, Jan 26, 2015 at 10:47 AM, Sergii Golovatiuk > >> <sgolovat...@mirantis.com> wrote: > >> > Until we are sure IBP solves operation phase where we need to deliver > >> > updated packages so client will be able to provision new machines with > >> > these > >> > fixed packages, I would leave backward compatibility with normal > >> > provision. > >> > ... Just in case. > >> > >> doesn't running 'apt-get upgrade' or 'yum update' after laying out the > >> FS image resolve the gap until we can rebuild the images on the fly? > >> > > >> > > >> > > >> > -- > >> > Best regards, > >> > Sergii Golovatiuk, > >> > Skype #golserge > >> > IRC #holser > >> > > >> > On Mon, Jan 26, 2015 at 4:56 PM, Vladimir Kozhukalov > >> > <vkozhuka...@mirantis.com> wrote: > >> >> > >> >> My suggestion is to make IBP the only option available for all > upcoming > >> >> OpenStack releases which are defined in openstack.yaml. It is to be > >> >> possible > >> >> to install OS using kickstart for all currently available OpenStack > >> >> releases. > >> >> > >> >> Vladimir Kozhukalov > >> >> > >> >> On Mon, Jan 26, 2015 at 6:22 PM, Igor Kalnitsky > >> >> <ikalnit...@mirantis.com> > >> >> wrote: > >> >>> > >> >>> Just want to be sure I understand you correctly: do you propose to > >> >>> FORBID kickstart/preseed installation way in upcoming release at > all? > >> >>> > >> >>> On Mon, Jan 26, 2015 at 3:59 PM, Vladimir Kozhukalov > >> >>> <vkozhuka...@mirantis.com> wrote: > >> >>> > Subject is changed. > >> >>> > > >> >>> > Vladimir Kozhukalov > >> >>> > > >> >>> > On Mon, Jan 26, 2015 at 4:55 PM, Vladimir Kozhukalov > >> >>> > <vkozhuka...@mirantis.com> wrote: > >> >>> >> > >> >>> >> Dear Fuelers, > >> >>> >> > >> >>> >> As you might know we need it to be possible to install several > >> >>> >> versions of > >> >>> >> a particular OS (Ubuntu and Centos) by 6.1 As far as having > >> >>> >> different > >> >>> >> OS > >> >>> >> versions also means having different sets of packages and some of > >> >>> >> the > >> >>> >> packages are installed and configured during provisioning stage, > we > >> >>> >> need to > >> >>> >> have a kind of kickstart/preseed version mechanism. > >> >>> >> > >> >>> >> Cobbler is exactly such a mechanism. It allows us to have several > >> >>> >> Distros > >> >>> >> (installer images) and profiles (kickstart/preseed files). But > >> >>> >> unfortunately, for some reasons we have not been using those > >> >>> >> Cobbler's > >> >>> >> capabilities since the beginning of Fuel and it doesn't seem to > be > >> >>> >> easily > >> >>> >> introduced into Nailgun to deal with the whole Cobbler life > cycle. > >> >>> >> > >> >>> >> Anyway, we are moving towards IBP (image based provisioning) and > we > >> >>> >> already have different images connected to different OpenStack > >> >>> >> releases > >> >>> >> (openstack.yaml) and everything else which is necessary for > initial > >> >>> >> node > >> >>> >> configuration is serialized inside provision data (including > >> >>> >> profile > >> >>> >> name > >> >>> >> like 'ubuntu_1204' or 'ubuntu_1404') and we are able to choose > >> >>> >> cloud-init > >> >>> >> template by this profile name. > >> >>> >> > >> >>> >> And taking into account what it is written above, the suggestion > is > >> >>> >> to > >> >>> >> completely avoid using kickstart/preseed based way of OS > >> >>> >> provisioning > >> >>> >> by 6.1 > >> >>> >> for all new releases allowing ONLY old ones to use this way. > >> >>> >> > >> >>> >> Any opinions about that stuff are welcome. > >> >>> >> > >> >>> >> Vladimir Kozhukalov > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > __________________________________________________________________________ > >> >>> > OpenStack Development Mailing List (not for usage questions) > >> >>> > Unsubscribe: > >> >>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > >> > >> > >> > >> -- > >> Andrew > >> Mirantis > >> Ceph community > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Andrew > Mirantis > Fuel community ambassador > Ceph community > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev