----- "Jesus Rodriguez" <jesusr(a)redhat.com> wrote:
On Fri, Mar 26, 2010 at 10:14:40AM -0300, Devan Goodwin wrote:
> I've got concerns about the end result assuming we solve this
problem.
> The purpose of this whole issue has been described to me as
> warehousing the data about what consumers we knew about instead of
> just deleting them.
>
> The first thing that comes to mind is that this is probably not
> specific to consumers, arguably even more importantly we're going
to
> want to maintain info about what entitlements were bound to those
> consumers, perhaps with some info about when and by whom. (which is
> totally new)
>
> The second big issue is that given this is motivated by auditing
like
> concerns, I can't understand why we'd want the choice between "mark
> inactive/terminated" and "actually delete" available to callers of
the
> API, not even management applications should be able to circumvent
it.
> Auditing seems like it should be handled internally and
transparently.
> IMO delete should remain delete, that resource no longer exists at
> that location. Internally Candlepin would store whatever
> auditing/state information we need about the deleted resource, and
> perhaps this info would be accessible over an API call to a
management
> application, but it's a new resource, not the old one.
>
> If we just flag resources as inactive in their original location
then
> we need to be vigilant about filtering out where inactive = true
> throughout the application. No doubt we can do this, it's just
> unplesant to consider a slew of inactive consumers and possibly
> entitlements living together for an unknown period of time, and
quite
> likely a recipe for a lot of bugs down the road.
>
> 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.
This does bring up the real problem, the reason we don't want to use
delete is for historical data. And yes I think you are right that
auditing
is probably the right way to solve the problem.
In a cube conversation (yay for open environments) [1], we talked
about
Approach 4, DELETING the relationship. The relationship that would
need
to be removed when terminating a consumer is the entitlement.
When Justin suggested we delete the entitlement the feedback was then
we'd lose the history. So as Devan stated above, why don't we
log what happened with the entitlement 'deleted by foo on 2010/04/01
for
unknown reasons', then delete the entitlement.
It would certainly make the API cleaner and solve the problem. So
this
take care of terminating a consumer's entitlement, then again, as
Devan
asked what else do we need to audit? Is there a list of historical
data we'd like to maintain?
+1 for doing the deletion, and making auditing a first class requirement, if it really
is.
I don't like all this wishy-washy leaves stuff around just in case. No one is
actually using
this yet (at least I hope not) so if we need to add in auditing later then it
shouldn't be a problem, IMO.
jesus
--
jesus m. rodriguez | jesusr(a)redhat.com
principal software engineer | irc: zeus
red hat systems management | 919.754.4413 (w)
rhce # 805008586930012 | 919.623.0080 (c)
+---------------------------------------------+
| "Those who cannot remember the past |
| are condemned to repeat it." |
| -- George Santayana |
+---------------------------------------------+
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin