Edit Provisioned Network Feature

Moti Asayag masayag at redhat.com
Wed Nov 27 07:42:39 UTC 2013 


----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Tuesday, November 26, 2013 8:45:06 PM
> Subject: Re: Edit Provisioned Network Feature
> 
> Hi Moti, question:
> 
> what will happen if the 'Apply network change to all hosts' check-box will
> not be checked?
> i.e. the logical network business entity and the networking configuration on
> the Host will
> be out of sync? do we plan to indicate that somewhere in the GUI / allow a
> way to "sync"
> the Hosts' networking configuration with the up-to-date logical network
> business entities?
> 

Yes, it updating the network without sync it with the hosts will result in 
host-network-out-of-sync with the logical network definition. This is the
same behaviour as exist today.

Why would we like to preserve it and not automatically to sync the change with
all hosts ? I think it is up to the administrator to decide whether change should
take effect immediately or to apply it by demand. 

> maybe it is the exact same thing that Mike asked at the end of his e-mail
> (not sure) and
> you mentioned that it is worthy a separate RFE; I am not sure if handling it
> separately
> is such a good idea - question is how important it is to indicate that a Host
> networking
> configuration is not sync'd with the logical network business entities (i.e.
> we can have
> two Hosts, one configured before the provisioned-network change and one
> configured after
> the provisioned-network change, and their networking configuration may seem
> "identical"
> even though it is not really the case).
> 

What you and Mike suggest is exposing already existing functionality in the 'setup networks'
dialog: In the 'setup networks' dialog each network is marked as synced or not, and the user
can select to 'sync' the network with its logical network definition.

So all the building blocks are there:
1. Indication on the network 'sync-ness' on the host
2. Ability to sync a specific network with its logical network definition

The idea of exposing that information in the network main tab as part of its hosts sub-tab
could have been included as part of the 'network main tab' feature which seems more appropriate
and could have been implemented regardless of the the $subject.

In addition, looking from the API perspective - the 'sync' operation is executed via
the 'setup networks' api, and not via the extension to the PUT method of the network.

I agree that those extensions to the network main tab should be added and they have a great value,
but as I see it, it is not tied to this feature.

> we can, at the first stage, decide that the 'Apply network change to all
> hosts' check-box
> is always checked and disabled, so Hosts would never be out of sync, or agree
> upon a
> similar limitation that will allow us to not need the 'sync' action / 'out of
> sync'
> indication immediately.
> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Cc: "arch" <arch at ovirt.org>
> > Sent: Tuesday, November 26, 2013 8:30:40 AM
> > Subject: Re: Edit Provisioned Network Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, November 26, 2013 7:38:43 AM
> > > Subject: Re: Edit Provisioned Network Feature
> > > 
> > > Very nice feature page, and a very good feature!
> > > 
> > > I have a couple of questions:
> > > 
> > > * Is the first part of the update command non-transactive? It's not clear
> > > from
> > > "The 'UpdateNetworkCommand' will be changed to a non-transactive"
> > > I would think the first part is still transactive, and the second one is
> > > not..
> > > 
> > 
> > The scope of the transaction include updating the network in the DB and
> > removing
> > its vnic profiles if network was changed from vm network to non-vm network.
> > The rest of the command (apply changes to host) should run with no
> > transaction.
> > Therefore the command itself will be marked as
> > @NonTransactiveCommandAttribute
> > and specific transaction will be opened to the described scope.
> > 
> > > * How can you apply the non-VM network if VMs/vNICs are down?
> > > I think it makes most sense to block if the network is being used to
> > > avoid
> > > confusion (otherwise say you changed to non-VM and later some VM using
> > > the
> > > network will always fail to launch, not sure it's a good thing).
> > > 
> > 
> > Agree - such change should be blocked.
> > 
> > > * From REST API perspective it looks like apply is a field on the
> > > network?
> > > If it is a field, perhaps worth saving it to DB so that it is used every
> > > time
> > > the network is edited?
> > > i.e. the "edit network" dialog will show this field value and this value
> > > will
> > > also be used later to determine whether to apply on all hosts or not..
> > > 
> > 
> > Since we're using the PUT method, we provide the network entity for the
> > action,
> > and any additional parameter as it sub-element.
> > One can claim that this field which doesn't serve as a network property,
> > rather
> > as an additional action to perform for the given operation. Therefore I
> > find
> > it
> > more suitable to be passed as a parameter.
> > 
> > > * Not sure how you plan to apply on some of the hosts, so not sure it's
> > > worth
> > > mentioning at this point..
> > > 
> > 
> > It should have been marked as p2. I thought as an enhancement to the UI
> > where
> > hierarchical cluster-hosts tree allows specific selection, something like:
> > 
> > (x) Cluster 1
> >     (x) host A
> >     ( ) host B
> > (x) Cluster 2
> >     (x) host C
> >     (X) host D
> > ( ) Cluster 3
> >     ( ) host E
> > 
> > But since it is not planned for p1 we can postpone the discussion of it.
> > 
> > > * You need to take into consideration the "Save network configuration"
> > > behavior
> > > in conjunction with this feature, i.e. the changes should probably be
> > > saved.
> > > 
> > 
> > Indeed, the user should be aware that any non-committed changes applied to
> > the host
> > will be committed once using this feature.
> > 
> > > Also a couple suggestions which are related:
> > > * When standing on a network (in networks tab), you have the Hosts
> > > sub-tab.
> > > 
> > > ** Can we have a column for the sync status?
> > > 
> > > ** Can we have a button to sync to specific host (very useful when
> > > network
> > > got applied only to some of the hosts)?
> > > 
> > 
> > Those are nice improvements and should get their own RFE. Could you open
> > one
> > so we can prioritize and target it properly?
> > 
> > > *** This also answers (IMHO) the capability to apply only to specific
> > > hosts.
> > > 
> > > Regards,
> > > Mike
> > > 
> > > ----- Original Message -----
> > > > Hi,
> > > > 
> > > > Another network feature for 3.4 is "Edit Provisioned Network".
> > > > Please review and add your comments.
> > > > 
> > > > [1] http://www.ovirt.org/Features/EditProvisionedNetwork
> > > > 
> > > > Thanks,
> > > > Moti
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 
>

More information about the Arch mailing list