On 03/29/2010 10:29 AM, Bryan Kearney wrote:
On 03/29/2010 10:00 AM, Justin Harris wrote:
----- "Bryan Kearney"bkearney@redhat.com wrote:
On 03/26/2010 09:14 AM, Devan Goodwin wrote:
On Fri, Mar 26, 2010 at 9:37 AM, Bryan Kearneybkearney@redhat.com
wrote:
On 03/25/2010 12:46 PM, Jesus M. Rodriguez wrote:
On Thu, Mar 25, 2010 at 12:30 PM, Bryan
Kearneybkearney@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:
- The satcerts which are assigned to an owner.
- The owner itself.
- The consumers for the owner, and the collection of facts.
- The entitlements which a consumer had.
- 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@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.