[Pulp-list] Consumer History

[Jason Dobies]

-----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-----