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

Adam Young ayoung at redhat.com
Mon Mar 29 14:30:15 UTC 2010


On 03/29/2010 10:29 AM, Bryan Kearney wrote:
> On 03/29/2010 10:00 AM, Justin Harris wrote:
>    
>> ----- "Bryan Kearney"<bkearney at redhat.com>   wrote:
>>
>>      
>>> On 03/26/2010 09:14 AM, Devan Goodwin wrote:
>>>        
>>>> 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:
>>> <SNIP
>>>        
>>>> 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.
>>>>          
>>> OK.. thinking out loud. I think we will want to audit:
>>>
>>> 1) The satcerts which are assigned to an owner.
>>> 2) The owner itself.
>>> 3) The consumers for the owner, and the collection of facts.
>>> 4) The entitlements which a consumer had.
>>> 5) The subscription pools which a consumer had
>>>        
>>
>> Forgive the silly question, but it seems like auditing would be event-based, as opposed to just figuring out what data to pull.  Is it that we want to audit any action that affects these entities?
>>
>>    - Justin
>>      
>
> Yeah..I am confusing audting with versioning.. /me needs to noodle on that.
>
> -- bk
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>    
My gut says:  create a file (not a DB dbtable) that just gets a running 
stream of events.  From inside Candlepin, anything we need to audit 
should just get thrown in a JMS Queue.  This Queue starts off as a 
simple file, and can later be anything we want to replace it.






More information about the candlepin mailing list