On 07/05/2012 10:51 AM, Livnat Peer wrote:
Actually the API has the same concept as you suggest for storage
>>> domains. >>> At the top level you don't have a status field, but under data >>> center level, where it's valid then you get the status property. >>> >>> Same should go for networks. >>> The status property should be added only where it's valid, in >>> this >>> case the cluster level sub-collection > > so sounds like we want to declare these properties deprecated to be > able > to remove them in a future version?
I guess so, The question is, are there other location where the status property (or any other property) exists at an irrelevant level. Unless we want to go into the effort of mapping them all now we probably need to define a concept and anything not complying to that is a bug that is allowed to be fixed without considering it as breaking the API.
Thoughts?
+1 I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. This is too major to just fix this one, and wait until we bump into another one... Mike i see there a general consensus that this is a bug and the top level entity should be a DC network.
i disagree that <status> should be completely removed, instead as bug fix it should contain different members: ATTACHED|UNATTACHED (same concept we using in /api/storagedomains/xxx)
Can you please open a bug / update the existing bug to reflect that.
Thanks, Livnat
-- Michael Pasternak RedHat, ENG-Virtualization R&D