Edit Provisioned Network Feature

[Moti Asayag]

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