> 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. 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
