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