On 03/26/2010 11:49 AM, Justin Harris wrote:
----- "Jesus Rodriguez"<jesusr(a)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(a)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(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/candlepin
>
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin