On 07/05/2012 01:43 PM, Mike Kolesnik wrote: > ----- Original Message ----- >> On 05/07/12 13:23, Mike Kolesnik wrote: >>>> On 07/05/2012 12:19 PM, Livnat Peer wrote: >>>>>> I'll give you one scenario and I'm sure there are lot more: >>>>>>> delete all unused networks .... >>>>>>> >>>>> not strong enough use case in my opinion >>>> >>>> i do see sense in this, and based on my experience of >>>> closing ~5 bugs on this for SD and explaining like >>>> ~10 times on ML to users why /api/storagedomains/xxx >>>> doesn't have <status>, I'm sure it should be done this way >>>> as it creates clear differentiation between root-resource >>>> and cluster-resource (shared) status. >>>> >>>>> to add this yet another confusing property. >>>> >>>> you not adding another property, you fix existent >>>> (which was incorrectly used/implemented). >>>> >>>>> >>>>> BTW - If a requirement will get from the field to add properties >>>>> we >>>>> can >>>>> do them later why add something we think is not needed. >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >>>> >>> >>> I think we got a little bit off the topic here, so if you don't >>> mind I would like to see if everyone agrees on this: >>> >>> We have at the api/networks collection these properties and their >>> possible values: >>> status - OPERATIONAL, NON_OPERATIONAL >>> display - true, false >>> >>> We (as far as I understood) agreed that these fields causea problem >>> in this context since they can be different for a given network, >>> and current representation will return the network element >>> multiple times with only difference in either one of these fields. >>> Also I understood we agreed that this is bad behaviour (even a bug) >>> and we don't want to support this anymore. >>> >>> This gives 2 choices IMHO: >>> 1. Fix the behaviour but keep the fields with some default >>> values. >>> 2. Fix the behaviour and remove these field as well, which isn't >>> really breaking an API since the behaviour was broken to begin >>> with. >>> >> >> So a summary of the thread so far: >> >> Simon, Miki Ori and me voted +1 for option #2 >> >> Michael wants to change the value of the status field to >> attach/detach >> >> Anyone else wants to vote in on this? > > I vote for fix #2. > > I think not only is leaving these fields with some defaults a mistake, but > also changing their possible values is breaking the API either way, so if we > already breaking the API I think removing the fields entirely is cleaner, and > in future if we have request to add fields then we can model them correctly.
+1 for #2 (but only for <display> and new 3.1 props), -2 for removing <status> (based on told above) > >> >> >>> Please comment what option seems valid (I though we were going to >>> the direction of fix #2). >>> >>> Thanks, >>> Mike >>> >> >> >> -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
