-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was a discussion yesterday in the chat room about whether or not a failed package install represents a consumer history event. This ultimately boiled down to the question of:
Is consumer history the list of state changes to a consumer? or Is consumer history the list of actions taken against a consumer? It's a subtle but important distinction. The former excludes failed package installations; ultimately nothing has changed on the consumer therefore no history event is logged. The latter is meant to be a log of everything that was done to a specific consumer in a query-able fashion (that's important and will come up later). It ultimately comes down to what this will be used for. I envision it as a way for an admin to know everything that pulp has done to/with/on a consumer, including anything that failed. For instance, consider the following series of events: - - Admin attempts to install package A on consumer X. - - Installation fails because of a missing dependency (newer version, etc.). - - Admin binds repo M to consumer X. - - Admin attempts again to install package A on consumer X. I think tracking all of those events in one location is important. This provides context for why repo M was bound to the consumer; it was a result of the failure and caused the following package install to succeed. A failed package install is arguably more interesting to an admin than a successful one, since it may represent something wrong on the box (incorrect assumptions about what's on it, something nasty was done to the box outside of pulp, solar flares are affecting the data center, etc). One argument was made that failed package installs should only be logged in the audit log rather than in consumer history. After sleeping on it, I disagree with this. One reason is that it splits the full picture of the consumer actions into two places, requiring a manual correlation between them to determine the sequence of events. I'm not sure the audit subsystem can be queried through the API, which would mean not only two places, but two different mechanisms (API and direct DB access/log file parsing). Another is that, to me, auditing is a log of "things done by people to or using pulp". That's a much more generic concept than "things done to a consumer". The notion of what happens to a consumer is an important one and keeping all of it as a first class concept with flexible queries is going to make it easier for an admin to get whatever view is wanted with respect to that consumer. Thoughts? - -- Jason Dobies RHCE# 805008743336126 Freenode: jdob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMnN22AAoJEOMmcTqOSQHCCcYH/1SgTMAPYFwSUW9M3mWnW3kM Kr56fyc7ky/B5bj6A3bep61iD+5tWZKhGgKM85jSQDLCOER3y1LmH9rfLCegiTXv y/4JuLlNZIc+INlaXhZ6bz9WwyuNRFeQ3Q8gwyRKnMYyAakyiOPIccHYpYth/BMf VRkZtwGsM5AjdD6P4qFrDwEdxVkh/fWCqAU3Dp/ppLhAxsiCRqQw1fo/KMNcrEQ/ r2YJPcvGWH4Q8TROrfKvvA31oiNK0X4ujNIZS2qiJ5M2p26AEPWrKplK7oOTwIsJ rchkv8hyLs+6Xk+5evJ7g+f6mx9KuQJDeOOCobmkPXhuE/EXjftW5GSA4OyCNOM= =JIc/ -----END PGP SIGNATURE----- _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
