On 05/07/12 11:31, Michael Pasternak wrote: > 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)
first you agree we should remove the status as it is today as it does not indicate anything to the user. second you suggest that we'll add attached unattached status, I don't see value in it unless you specify the clusters it is attached to as a sub - collection, I don't see us getting to this anytime soon. we can always add it later and it does not change the fact that the API changes. > >> Can you please open a bug / update the existing bug to reflect that. >> >> Thanks, Livnat >> >> >> > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
