[Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks

[Avi Tal]

Comments inline

----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, July 2, 2012 5:35:52 PM
> Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of	logical networks
> 
> 
> 
> 
> 
> Hi All,
> 
> I would like to hear opinions about a behaviour that I think is
> problematic in
> REST API handling of logical networks.
> 
> -- Intro --
> Today in the REST API we are exposing two collections for "logical
> network" related entities.
> 
> First is a top level collection which is out of any context at the
> address
> http://engine/api/networks.
> Second is a sub-collection in the context of a cluster:
> http://engine/api/cluster/xxx/networks
> 
> The network itself is defined per DC level, so for each DC you would
> have
> at least one logical network for management, which has some
> properties such
> as STP, MTU, etc..
> The top level collection is used to create/delete such network
> entities.
> 
> The sub-collection in the context of a Cluster is used to
> attach/detach a
> network from the DC of that cluster.

Edit as well. you can update cluster network and change the "Display" property.

> The network in the context of a cluster has some additional
> information, let's
> say for example 'status' of the network:
> If a network is defined on all hosts in the cluster then it's status
> is
> 'Operational'.
> If a network is not defined on some of the hosts in the cluster then
> it's
> status is 'Not Operational'[1].
> 
> 
> -- Problem --
> The problem is that details which are only relevant in context of a
> cluster, are still displayed in the root context as well (e.g:
> 'status').
> This can, in certain cases, cause unexpected behaviour.
> 

+1 no need to display cluster properties in datacenter context. (https://bugzilla.redhat.com/show_bug.cgi?id=815268)

> For example, let's consider this topology:
> Data Center A
> | 
> |\____ Network 'red'
> |\____ Cluster A1
> | \______ Network 'red' attached
> \____ Cluster A2
> \______ Network 'red' attached
> 
> If the 'status' is the same on all the clusters that the network is
> attached to
> (A1, A2) then there will be one element in the top level collection,
> with the
> network details and the 'status' field representing the state (which
> is same
> for all networks in the cluster contexts of the cluster).
> If, however, the status is not the same (ie. on A1 the network is
> 'Operational' and on A2 it is 'Non Operational') then the top-level
> collection will show two elements for the network, where all network
> details are the same and only the 'status' field is different.
> 
> This is problematic IMHO for several reasons:
> 1. Showing one network in certain states, and multiple copies of this
> network in other states is not optimal, to say the least.
> 2. In the top-level collection there is no indicator of the cluster
> for which
> the network is displayed, so there is no way to differentiate between
> the
> two 'red' network elements (they will have same id, name, etc.).
> 3. There is a certain asymmetry between the remove action[2] and the
> result in that you would expect: you either remove a network but in
> the
> result you would see several elements removed.
> 
> 
> -- Proposed Solutions --
> Personally I can think of several solutions to this problem:
> 1. Declare the top-level collection as a collection of all networks
> that are
> either attached to cluster or not, and if they are indeed attached
> then
> show the details for each cluster, including a link to the cluster.
> 2. Declare the top-level collection as a collection of all networks
> that are
> defined in data-centers, but they will not contain any cluster
> specific
> data, and thus each entry is unique.
> 

Why do we keep holding this Top level collection instead of having each network related under his datacenter (/api/datacenter/id/networks)???

https://bugzilla.redhat.com/show_bug.cgi?id=741111

One solution which is must is to move the top level network (/api/networks) under each Datacenter!

1. having top level networks path isn't symmetric to our entire REST API implementation! 
   all other network collections (cluster, hosts, VMs, Templates) placed under their related component.
2. as a REST API user, having sub collection networks under each datacenter is better to handle than parsing a top level collection
   and comparing DC id in order to get all DC related networks.
3. as for breaking api/ backward compatibility, we can still hold the top level network collection ad deprecated and start exposing the sub collections
   under each datacenter.




> Solution #2 is breaking the API backwards-compatibility, since it
> includes
> removing certain fields that have appeared today (namely 'status' and
> 'display') but IMO would give a better experience since the top-level
> collection is actually used for managing networks, and not their
> attachment
> to clusters which should be done in the context of each cluster.
> 
> I would like to hear what suggestions you have to solve this problem
> or if
> you prefer either of the above solutions.
> 
> 
> -- Footnotes --
> [1] In 3.1 this is slightly different, but for the sake of simplicity
> I didn't
> specify the new behaviour.
> [2] Currently you can't update the network if it's attached to any
> cluster,
> but perhaps in the future this would be possible.
> 
> 
> Regards,
> Mike
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>