[openstack-dev] [Fuel] Image based provisioning
Alexander Gordeev
agordeev at mirantis.com
Mon Jan 12 13:08:30 UTC 2015
Hello,
Andrew, thank you for pointing out all the issues. I left more
detailed comments inlined
On Tue, Jan 6, 2015 at 3:51 AM, Andrew Woodward <xarses at gmail.com> wrote:
> Here is a list of the issues I ran into using IBP before the 23rd. 5
> appears to not be merged yet and must be resolved prior to making IBP
> the default as you can't restart a provisioned node.
>
> 1. a full cobbler template is generated for the IBP node, if you
> wanted to re-prov the node, you would have to erase the cobbler
> profile, bootstrap and call the node provision api. If you forced it
> back to netboot (which can be done with installer methods) it loads
> the installer instead of the bootstrap image
>
Sounds like we have a bug here.
> 2. We need to be careful when considering removing cobbler from fuel,
> its still being used in IBP to manage dnsmasq (dhcp lease for
> fuelweb_admin iface) and bootp/PXE loading profiles
>
Yes, indeed. We're going to implement our own dnsmasq driven service
for managing all what cobbler performed earlier for us.
> 3. After a time all DNS names for nodes expire (ssh node-1 -> Could
> not resolve hostname) even though they are still in cobbler (cobbler
> system list)
>
Definitely a bug.
> 4. fuel-agent log is not in logs UI
>
Again, it's a bug.
> 5. image based nodes won't set up network after first boot
> https://bugs.launchpad.net/fuel/+bug/1398207
>
The fix is available on the review board. I hope it'll be merged soon
> 6 image based nodes are basically impossible to read network settings
> on unless you know everything about cloud-init
>
Sorry, i didn't get you. What did you mean?
For image based, only the interface looking to "admin network" will be
set up by cloud-init. All other network configuration will be done
later and without cloud-init.
>
> On Wed, Dec 17, 2014 at 3:08 AM, Vladimir Kozhukalov
> <vkozhukalov at mirantis.com> wrote:
>> In case of image based we need either to update image or run "yum
>> update/apt-get upgrade" right after first boot (second option partly
>> devalues advantages of image based scheme). Besides, we are planning to
>> re-implement image build script so as to be able to build images on a master
>> node (but unfortunately 6.1 is not a real estimate for that).
>>
>> Vladimir Kozhukalov
>>
>> On Wed, Dec 17, 2014 at 5:03 AM, Mike Scherbakov <mscherbakov at mirantis.com>
>> wrote:
>>>
>>> Dmitry,
>>> as part of 6.1 roadmap, we are going to work on patching feature.
>>> There are two types of workflow to consider:
>>> - patch existing environment (already deployed nodes, aka "target" nodes)
>>> - ensure that new nodes, added to the existing and already patched envs,
>>> will install updated packages too.
>>>
>>> In case of anakonda/preseed install, we can simply update repo on master
>>> node and run createrepo/etc. What do we do in case of image? Will we need a
>>> separate repo alongside with main one, "updates" repo - and do
>>> post-provisioning "yum update" to fetch all patched packages?
>>>
>>> On Tue, Dec 16, 2014 at 11:09 PM, Andrey Danin <adanin at mirantis.com>
>>> wrote:
>>>>
>>>> Adding Mellanox team explicitly.
>>>>
>>>> Gil, Nurit, Aviram, can you confirm that you tested that feature? It can
>>>> be enabled on every fresh ISO. You just need to enable the Experimental mode
>>>> (please, see the documentation for instructions).
>>>>
>>>> On Tuesday, December 16, 2014, Dmitry Pyzhov <dpyzhov at mirantis.com>
>>>> wrote:
>>>>>
>>>>> Guys,
>>>>>
>>>>> we are about to enable image based provisioning in our master by
>>>>> default. I'm trying to figure out requirement for this change. As far as I
>>>>> know, it was not tested on scale lab. Is it true? Have we ever run full
>>>>> system tests cycle with this option?
>>>>>
>>>>> Do we have any other pre-requirements?
>>>>
>>>>
>>>>
>>>> --
>>>> Andrey Danin
>>>> adanin at mirantis.com
>>>> skype: gcon.monolake
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> --
>>> Mike Scherbakov
>>> #mihgen
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Andrew
> Mirantis
> Ceph community
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list