July 2012 - Devel - oVirt List Archives

[Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks
by Mike Kolesnik 08 Jul '12

08 Jul '12

--=_4ee2f20c-97ca-4df5-82e5-22b48c2bc7b8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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. 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 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 --=_4ee2f20c-97ca-4df5-82e5-22b48c2bc7b8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= ><div style=3D"color:#000;font-weight:normal;font-style:normal;text-decorat= ion:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><style></s= tyle><div style=3D"font-family: Times New Roman; font-size: 12pt; color: #0= 00000">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 "l= ogical 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://engi= ne/api/cluster/xxx/networks The network itself is defined per DC lev= el, so for each DC you would have at least one logical network for mana= gement, which has some properties such as STP, MTU, etc.. The top lev= el collection is used to create/delete such network entities. The su= b-collection in the context of a Cluster is used to attach/detach a net= work from the DC of that cluster. The network in the context of a cluste= r has some additional information, let's say for example 'status' of the= network:     If a network is defined on all hosts in the clus= ter then it's status is     'Operational'.   &nb= sp; If a network is not defined on some of the hosts in the cluster then it= 's     status is 'Not Operational'[1]. -- Pro= blem -- The problem is that details which are only relevant in context o= f a cluster, are still displayed in the root context as well (e.g: 'stat= us'). This can, in certain cases, cause unexpected behaviour. For example,= let's consider this topology:   Data Center A   &nbsp= ;     |         |= \____ Network 'red'         |\____ Cluster A1<b= r>        |      &nb= sp;       \______ Network 'red' attached &= nbsp;       \____ Cluster A2    &nbsp= ;            &n= bsp;      \______ 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).<= br>If, however, the status is not the same (ie. on A1 the network is 'Op= erational' and on A2 it is 'Non Operational') then the top-level collec= tion will show two elements for the network, where all network details a= re the same and only the 'status' field is different. This is proble= matic IMHO for several reasons:   1. Showing one network in certain= states, and multiple copies of this       netw= ork in other states is not optimal, to say the least.   2. In the t= op-level collection there is no indicator of the cluster for which &nbsp= ;     the network is displayed, so there is no way to d= ifferentiate between the       two 'red' networ= k elements (they will have same id, name, etc.).   3. There is a ce= rtain asymmetry between the remove action[2] and the    =    result in that you would expect: you either remove a network b= ut in the       result you would see several el= ements removed. -- Proposed Solutions -- Personally I can thi= nk of several solutions to this problem:   1. Declare the top-level= collection as a collection of all networks that are    &= nbsp;  either attached to cluster or not, and if they are indeed attac= hed then       show the details for each cluste= r, including a link to the cluster.   2. Declare the top-level coll= ection as a collection of all networks that are     =   defined in data-centers, but they will not contain any cluster speci= fic       data, and thus each entry is unique.<= br> Solution #2 is breaking the API backwards-compatibility, since it in= cludes removing certain fields that have appeared today (namely 'status'= and 'display') but IMO would give a better experience since the top-lev= el collection is actually used for managing networks, and not their atta= chment to clusters which should be done in the context of each cluster.<= br> 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 simplicit= y I didn't      specify the new behaviour. [2] Cu= rrently you can't update the network if it's attached to any cluster, &n= bsp;    but perhaps in the future this would be possible.<br= > <div>Regards, Mike </div> </div></d= iv> </div></body></html> --=_4ee2f20c-97ca-4df5-82e5-22b48c2bc7b8--

12 36

[Engine-devel] Search option for finding disks for templates / vms
by Asaf Shakarchi 05 Jul '12

05 Jul '12

Hey, https://bugzilla.redhat.com/show_bug.cgi?id=828089 I would like add a search option for searching disks of a VM or Template, Please suggest a name for the search option, In the 'view' level we call it 'entity_type', but maybe 'type' is nicer ? (or not too specific?) Thanks, Regards, Asaf

6 7

[Engine-devel] Separating engine-setup from ovirt-engine
by Ofer Schreiber 05 Jul '12

05 Jul '12

In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine. I've started to think about separating it into another git (similar to ovirt-iso-uploader), so we will be able to build this rpm separately. This change is really easy to implement (actually, I have already done it locally), and sounds to me like it's the right thing to do. Thought? Ofer.

5 10

[Engine-devel] oVirt UI Plugins feature: Ready for review
by Vojtech Szocs 04 Jul '12

04 Jul '12

Hi guys, I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application: http://www.ovirt.org/wiki/Features/UIPlugins Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel. Cheers, Vojtech

4 10

[Engine-devel] oVirt 3.1 - New beta RPMs available
by Ofer Schreiber 04 Jul '12

04 Jul '12

New set of VDSM & oVirt Engine RPMs (Fedora 17 based) has been uploaded to ovirt.org [1] As those RPMs contains critical bug fixes, the oVirt team will appreciate any kind input and bug verification [2]. Thanks, Ofer Schreiber oVirt Release Manager [1] www.ovirt.org/releases/beta/fedora/17/ [2] Specifically, We would like to verify the following BZs: https://bugzilla.redhat.com/buglist.cgi?quicksearch=831998%20832577%2083311…

1 0

[Engine-devel] Backend bean validation wiki
by Roy Golan 03 Jul '12

03 Jul '12

Hi All, Here's a how-to for Backend bean validation http://www.ovirt.org/wiki/Backend_Bean_Validation Comments are welcome. Thanks, Roy

1 0

[Engine-devel] JVM version required
by Yaniv Kaul 02 Jul '12

02 Jul '12

1. Do we want to enforce a minimal JDK version required? For example, 1.7? 2. If we do, I assume we'll do it in the packaging requirement, but should we check for it at runtime (read: service startup) ? TIA, Y.

2 1

[Engine-devel] restapi: Storage-Domain creation - Used Luns
by Ori Liel 02 Jul '12

02 Jul '12

We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). We need a way in rest-api to explicitly approve the use of such luns. Does anyone have a suggestion for a good name for such a flag, a name that conveys: "use the given luns even if they are part of a VG?" Thanks, Ori.

6 8