feature suggestion: initial generation of management network

Sun May 12 20:29:20 UTC 2013

On May 12, 2013, at 21:59, Alon Bar-Lev <alonbl at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Barak Azulay" <bazulay at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Dan Kenigsberg" <danken at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Sunday, May 12, 2013 9:40:41 PM
>> Subject: Re: feature suggestion: initial generation of management network
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>
>>> Sent: Sunday, May 12, 2013 3:58:53 PM
>>> Subject: Re: feature suggestion: initial generation of management network
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>>> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "arch" <arch at ovirt.org>
>>>> Sent: Sunday, May 12, 2013 3:39:54 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>> 
>>>> On Thu, May 09, 2013 at 10:57:16AM -0400, Antoni Segura Puimedon wrote:
>>>>>> 
>>>>>> The risk of a deployed system (without bridge) to be unresponsive
>>>>>> after
>>>>>> reboot is minimum.
>>>>>> 
>>>>>> 1. iptables rules are already active.
>>>>>> 2. udev rules are active.
>>>>>> 3. vdsm is up.
>>>>>> 
>>>>>> The major risk is basically if some dependency package was UPDATED
>>>>>> during
>>>>>> the
>>>>>> installation of vdsm, while its service/consumer is already running,
>>>>>> then
>>>>>> we
>>>>>> are running a host with the old software and there is a chance that
>>>>>> after
>>>>>> reboot with the new software the host will fail.
>>>>>> 
>>>>>> I think that the decision to reboot host should be delegated to
>>>>>> administrator, adding vdsm verb to reboot is usable. This way admin
>>>>>> will
>>>>>> be
>>>>>> able to take a host to maintenance mode and reboot, and we can add
>>>>>> checkbox
>>>>>> to the add host dialog '[x] reboot', rebooting the host at the end of
>>>>>> the
>>>>>> sequence. I think the default should be off.
>>>>> 
>>>>> I'm also in agreement with the addition of a reboot verb. It could be a
>>>>> nice
>>>>> addition regardless of this specific use case.
>>>> 
>>>> A "reboot" verb is nice, but I am not yet sure that it is actually
>>>> needed. Above, Alon give one argument for it - to make sure that vdsm
>>>> (and its dependencies, and other updated packages) works smoothely after
>>>> boot. That's a good argument - but it may be acheived by post-deploy
>>>> boot as done today - without an additional frighteningly-named verb.
>>>> 
>>>> Note that vdsm, or any other package, may be upgraded by yum
>>>> asynchronous to Engine's operation, so we may face a surprise
>>>> cannot-start-after-boot later in the host life cycle. Not only
>>>> post-install.
>>>> 
>>>> As I said in my first comment to this thread - I do not think that
>>>> reboot-after-install is desperately needed, and find that it does not
>>>> deserve the Engine-side complexity of calling a new verb.
>>>> 
>>>> Dan.
>>> 
>>> What we are trying to say, product wise, is that the requirement to
>>> remotely
>>> reboot a host
>> 
>> No it is not a requirement - it is here because in the past it proved to be a
>> necessity (on the early days),
>> i don't think it's a must today.
>> 
>>> (cooperate reboot) may be available regardless of the
>>> host-deploy sequence. Administrator may decide to reboot a host right after
>>> host-deploy or once a week.
>> 
>> Correct, and the right way to do it is first move to maintenance mode.
>> 
>>> 
>>> Adding the ability to perform reboot is different independent discussion.
>>> 
>>> The only reason we discuss it here is because we currently force reboot
>>> after
>>> host-deploy (although in the API it is optional).
>>> 
>>> Having the bridge created by the engine is, in my opinion, far more
>>> important
>>> than keeping the reboot feature. We can discuss if remote reboot feature
>>> should and to which version, regardless.
>> 
>> 
>> I agree with you that the creation of the bridge engine is more important
>> from the reboot,
>> However when discussing new reboot API for VDSM, I prefer to not do reboot at
>> all on host-deploy, and do the bridge config by engine.
>> 
>> The reboot API suggested is a general purpose API which in this discussion is
>> focused around a specific use case (host-deploy),
>> If we had a way to enforce call for the reboot API only in the deployment
>> scenario, I would have been o.k. with it,

>> But the weird thing about APIs is that people end up using them ... and not
>> always as we intended,
>> and we might end up finding ourselves in tough situations due to a stray
>> reboot call from X ???
> 
> I must reply that, cannot help it... :)))

I know you can't ;-)

> What if the admin just login to the server and just rebooted?
> What if there is power failure?
> What if there is provisioning infrastructure that manages the servers in parallel of ovirt and it decides to reboot?
> We should deal with that in any case...
> And doing this via VDSM has only advantages, as VDSM is aware of the reboot request and can take safety measures to complete it successfully without losing information nor state.

As I said above, if we could limit the reboot API call for host deploy I was o.k with it.
Since we can't than it is likely that it will be used in some other flow, which might cause a mess.

It is one thing when an admin is doing it manually (and is aware he is loosing all the running VMs), and between having the engine call it in some other corner case flow (just because the API was there and it looked like he right thing when reviewed), and all running VMs die (just like case we have had with the lib virt crash .... Fencing race)

Eventually general purpose APIs are being used, And here you are arguing about the most destructive API in the context of a distant corner case.

I find it hard to believe such a patch will pass vdsm code review ... 

> 
>> This is the reason I have suggested reboot over SSH which is different.
> 
> Right, but we can do about 40% (I think closer to 80%) of VDSM functionality via SSH, right?

35 ? ;-)

> 
>> And I would argue that host deploy is here to stay hence the dependency in
>> SSH is here to stay.
> 
> There are talks to move to standard provisioning framework such as puppet or even foreman... not sure what the future is.

And who will install and provision those systems ? .... I assume Otopi ... Using SSH

> 
>> 
>> Thanks
>> Barak Azulay
>> 
>> 
>> 
>> 
>>> 
>>> Regards,
>>> Alon
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>> 
>>> 
>>> 
>> 