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

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; Sent: Tuesday, July 3, 2012 10:06:37 PM Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks On 03/07/12 21:28, Itamar Heim wrote: > On 07/03/2012 10:30 AM, Livnat Peer wrote: >> On 02/07/12 17:35, 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 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. >>> >> >> That sounds like a bug to me. >> I think that top collection should include only DC level >> properties and >> not cluster level properties, status should not be there (same as >> display required etc.) >> >> >>> 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. >>> >>> 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 really don't think top collections should include cluster >> networks it >> is not user-friendly to say the least. > > how is that different from top collections including VMs and > templates? > (or logical networks becoming main tab in the UI going forward) > I think you missed the point of cluster network entity vs. DC network entity. we should have in the top collection a DC network, I think we should not display the network per cluster in top network collection (that can be viewed under the cluster context).

>> >> I vote for the second option, I don't think that having a bug in >> previous versions should drive this decision. >> >> >>> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel