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