----- 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. > > > > Please comment what option seems valid (I though we were going to > > the direction of fix #2). > > > > Thanks, > > Mike > > > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
