Edit Provisioned Network Feature

Tue Nov 26 18:45:06 UTC 2013

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? 

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). 

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
> 