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