Edit Provisioned Network Feature

Einav Cohen ecohen at redhat.com
Wed Nov 27 12:10:34 UTC 2013 

Hi Moti, many thanks for the explanation. I was sure that up until now, we simply 
blocked editing logical networks that were already attached to Hosts, and only 
with this feature we would allow it, but this is not the case. 

IMO - it is important to show this information in the Hosts main tab (or at least 
in the Networks sub-tab of the Hosts main tab), but as you mentioned - it is not 
directly related to this feature in particular, as out-of-sync networks can 
already exist today, and this feature is not "making things any worse" in that 
sense or anything like that. 
I also was not aware that we have the 'sync' indication/method available via the 
'Setup Host Networks' dialog, so that's good as well. 

----
Regards,
Einav

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "arch" <arch at ovirt.org>
> Sent: Wednesday, November 27, 2013 2:42:39 AM
> Subject: Re: Edit Provisioned Network Feature
> 
> 
> 
> ----- 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