A good summary from Bill Burke on his take for state transitions

Devan Goodwin dgoodwin at rm-rf.ca
Fri Mar 26 13:14:40 UTC 2010


On Fri, Mar 26, 2010 at 9:37 AM, Bryan Kearney <bkearney at redhat.com> wrote:
> On 03/25/2010 12:46 PM, Jesus M. Rodriguez wrote:
>> On Thu, Mar 25, 2010 at 12:30 PM, Bryan Kearney<bkearney at redhat.com>  wrote:
>>> Take a look:
>>>
>>> http://bill.burkecentral.com/2010/03/25/modeling-operations-in-rest/
>>
>> Since JSON has no link mechanism, I found this which seemed to be a
>> reasonable way of adding links to our model output:
>>
>> http://wiki.sproutcore.com/FieldNotes-REST-B-JSON
>>
>> jesus

I've got concerns about the end result assuming we solve this problem.
The purpose of this whole issue has been described to me as
warehousing the data about what consumers we knew about instead of
just deleting them.

The first thing that comes to mind is that this is probably not
specific to consumers, arguably even more importantly we're going to
want to maintain info about what entitlements were bound to those
consumers, perhaps with some info about when and by whom. (which is
totally new)

The second big issue is that given this is motivated by auditing like
concerns, I can't understand why we'd want the choice between "mark
inactive/terminated" and "actually delete" available to callers of the
API, not even management applications should be able to circumvent it.
Auditing seems like it should be handled internally and transparently.
IMO delete should remain delete, that resource no longer exists at
that location. Internally Candlepin would store whatever
auditing/state information we need about the deleted resource, and
perhaps this info would be accessible over an API call to a management
application, but it's a new resource, not the old one.

If we just flag resources as inactive in their original location then
we need to be vigilant about filtering out where inactive = true
throughout the application. No doubt we can do this, it's just
unplesant to consider a slew of inactive consumers and possibly
entitlements living together for an unknown period of time, and quite
likely a recipe for a lot of bugs down the road.

To me I think we should bite the bullet and ask ourselves the hard
questions about what data we need to audit. We should solve this
internally and transparently to the API, and we're then free to keep
the API resource oriented and delete's meaning is clear.

Cheers,

Devan



-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca



More information about the candlepin mailing list