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

[Michael Pasternak]

On 07/02/2012 05:35 PM, Mike Kolesnik wrote:
> 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.
> 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 is 2.2 bug, behaviour has to be the same as in /api/storagedomains
and /api/datacenters/xxx/storagedomains - 'status' should be addressed indeed.

(only use-case for status in /api/networks is when network yet not attached
to any cluster)

> This can, in certain cases, cause unexpected behaviour.
> 
> 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.

this is not correct, remove from /api/networks is not considered as *detach* from
clusters as well, but only as remove from /api/networks which is deletes network
from the DC, so it can't be 1:N,

if network still attached to cluster/s, backend should block this operation by CDA,
this is not api prerogative anyway.

> 
> 
> -- 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.
> 
> 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 vote for #2, that's the right way to go forward (but only if leaving properties
in /api/networks creates logical collisions as in 'status' case)

as for now it's only: 'status', 'display', right?

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


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D