On 03/29/2010 10:29 AM, Bryan Kearney wrote:
> On 03/29/2010 10:00 AM, Justin Harris wrote:
>
>> ----- "Bryan Kearney"<bkearney(a)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(a)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(a)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(a)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.
I have this on the backlog to design out. Part of it will ber versioning
vs. auditing.
-- bk