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

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?

> Please comment what option seems valid (I though we were going to > the direction of fix #2). > > Thanks, > Mike >