A good summary from Bill Burke on his take for state transitions
Adam Young
ayoung at redhat.com
Sat Mar 27 02:26:41 UTC 2010
On 03/26/2010 11:49 AM, Justin Harris wrote:
> ----- "Jesus Rodriguez"<jesusr at redhat.com> wrote:
>
>
>> On Fri, Mar 26, 2010 at 10:14:40AM -0300, Devan Goodwin wrote:
>>
>>> 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.
>>>
>> This does bring up the real problem, the reason we don't want to use
>> delete is for historical data. And yes I think you are right that
>> auditing
>> is probably the right way to solve the problem.
>>
>> In a cube conversation (yay for open environments) [1], we talked
>> about
>> Approach 4, DELETING the relationship. The relationship that would
>> need
>> to be removed when terminating a consumer is the entitlement.
>> When Justin suggested we delete the entitlement the feedback was then
>> we'd lose the history. So as Devan stated above, why don't we
>> log what happened with the entitlement 'deleted by foo on 2010/04/01
>> for
>> unknown reasons', then delete the entitlement.
>>
>> It would certainly make the API cleaner and solve the problem. So
>> this
>> take care of terminating a consumer's entitlement, then again, as
>> Devan
>> asked what else do we need to audit? Is there a list of historical
>> data we'd like to maintain?
>>
> +1 for doing the deletion, and making auditing a first class requirement, if it really is.
> I don't like all this wishy-washy leaves stuff around just in case. No one is actually using
> this yet (at least I hope not) so if we need to add in auditing later then it shouldn't be a problem, IMO.
>
Delete of the relationship should be a delete. Even if we hold on to
the Data of Hysterical Raisins.
BTW, when we un entitle a consumer, we shouldn't necessarily delete the
entitlement, should we? From what I saw in the slide show today, the
entitlement itself may be reused, just bound to a different consumer.
ISn't this why we have two tables: cp_entitlement and
cp_consumer_entitlements.
BTW, we should either make all of the the tables singular or all of them
plural. and be consistant on the column nameing as well. In Pool we have
productid
sourceentitlement_id
I'm thinking these should be
product_id
source_entitlement_id
>
>> jesus
>>
>> --
>> jesus m. rodriguez | jesusr at redhat.com
>> principal software engineer | irc: zeus
>> red hat systems management | 919.754.4413 (w)
>> rhce # 805008586930012 | 919.623.0080 (c)
>> +---------------------------------------------+
>> | "Those who cannot remember the past |
>> | are condemned to repeat it." |
>> | -- George Santayana |
>> +---------------------------------------------+
>>
>> _______________________________________________
>> candlepin mailing list
>> candlepin at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>
More information about the candlepin
mailing list