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.