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 <xar...@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
> <vkozhuka...@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 <mscherba...@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 <ada...@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 <dpyz...@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
>>>> ada...@mirantis.com
>>>> skype: gcon.monolake
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> --
>>> Mike Scherbakov
>>> #mihgen
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Andrew
> Mirantis
> Ceph community
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 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

Reply via email to