feature suggestion: initial generation of management network

[Livnat Peer]

On 05/08/2013 04:35 PM, Dan Kenigsberg wrote:
> On Tue, May 07, 2013 at 09:31:47AM -0400, Moti Asayag wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>>> To: "Moti Asayag" <masayag at redhat.com>
>>> Cc: "arch" <arch at ovirt.org>, "Alon Bar-Lev" <abarlev at redhat.com>
>>> Sent: Tuesday, May 7, 2013 4:11:05 PM
>>> Subject: Re: feature suggestion: initial generation of management network
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: "arch" <arch at ovirt.org>
>>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
>>>> Sent: Tuesday, May 7, 2013 2:22:19 PM
>>>> Subject: Re: feature suggestion: initial generation of management network
>>>>
>>>> I stumbled upon few issues with the current design while implementing it:
>>>>
>>>> There seems to be a requirement to reboot the host after the installation
>>>> is completed in order to assure the host is recoverable.
>>>>
>>>> Therefore, the building blocks of the installation process of 3.3 are:
>>>> 1. host deploy which installs the host expect configuring its management
>>>> network.
>>>> 2. SetupNetwork (and CommitNetworkChanges) - for creating the management
>>>> network
>>>> on the host and persisting the network configuration.
>>>> 3. Reboot the host - This is a missing piece. (engine has FenceVds command,
>>>> but it
>>>> requires the power management to be configured prior to the installation
>>>> and
>>>> might
>>>> be irrelevant for hosts without PM.)
>>>>
>>>> So, there are couple of issues here:
>>>> 1. How to reboot the host?
>>>> 1.1. By exposing new RebootNode verb in VDSM and invoking it from the
>>>> engine
>>>> 1.2. By opening ssh dialog to the host in order to execute the reboot
>>>>
>>>
>>> why not send a reboot flag to the CommitNetworkChanges which is sent anyway,
>>> one less call (or connection if you choose ssh) and easier to do.
>>>
>>
>> Adding a reboot parameter to the CommitNetworkChanges (setSafeNetworkConfig on vdsm side) 
>> exceeds its logical scope which is persisting the network changes.
>>
>> Needless to say if such functionally will be required elsewhere, it couldn't be
>> properly reused if implemented as part of that command.
>>
>> Adding Dan to comment on this as well.
> 
> Yeah, a "reboot-after-me" flag defies my sense of cleanliness.
> If reboot-after-initial-net-config is crucial, we would need to add a
> special verb for that (or use the fenceNode verb if available).
> 

+1

> 
> However, I am not sure that this reboot is unavoidable.
> Originally the reboot had two important goal:
> - make sure that the updated kernel is running
> - make sure that the network, which we tweak during bootstrap, is
>   accessible after boot
> 
> Nowadays, the kernels does not change THAT often, for all ovirt can
> matter. running an oldish kernel is not the end of the world.
> 
> And with Moti's feature implemented, we no longer tweak net config
> blindly during boot. We use a well-define setupNetwork API, with a
> well-tested rollback mechanism.
> 
> The bottom line is, that in my opinion, reboot-after-install can be
> skipped these days.
> 

Adding Barak to the thread as I think he had some concern about removing
the reboot after install.


>>
>>>> 2. When to perform the reboot?
>>>> 2.1. After host deploy, by utilizing the host deploy to perform the reboot.
>>>> It requires to configure the network by the monitor when the host is
>>>> detected
>>>> by the engine,
>>>> detached from the installation flow. However it is a step toward the
>>>> non-persistent network feature
>>>> yet to be defined.
>>>> 2.2. After setupNetwork is done and network was configured and persisted on
>>>> the host.
>>>> There is no special advantage from recoverable aspect, as setupNetwork is
>>>> constantly
>>>> used to persist the network configuration (by the complementary
>>>> CommitNetworkChanges command).
>>>> In case and network configuration fails, VDSM will revert to the last well
>>>> known configuration
>>>> - so connectivity with engine should be restored. Design wise, it fits to
>>>> configure the management
>>>>  network as part of the installation sequence.
>>>> If the network configuration fails in this context, the host status will be
>>>> set to "InstallFailed" rather than "NonOperational",
>>>> as might occur as a result of a failed setupNetwork command.
>>>>
>>>>
>>>> Your inputs are welcome.
>>>>
>>>> Thanks,
>>>> Moti
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>