11:30 a.m.
Take a look:
http://bill.burkecentral.com/2010/03/25/modeling-operations-in-rest/
-- bk
11:46 a.m.
On Thu, Mar 25, 2010 at 12:30 PM, Bryan Kearney <bkearney(a)redhat.com> wrote:
Since JSON has no link mechanism, I found this which seemed to be a
reasonable way of adding links to our model output:
http://wiki.sproutcore.com/FieldNotes-REST-B-JSON
jesus
7:37 a.m.
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:
> Take a look:
>
> http://bill.burkecentral.com/2010/03/25/modeling-operations-in-rest/
Since JSON has no link mechanism, I found this which seemed to be a
reasonable way of adding links to our model output:
http://wiki.sproutcore.com/FieldNotes-REST-B-JSON
jesus
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
I like the first one. Do you
think the atom stuff would serialize close
to that?
-- bk
7:52 a.m.
----- "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:
>> Take a look:
>>
>>
http://bill.burkecentral.com/2010/03/25/modeling-operations-in-rest/
>
> Since JSON has no link mechanism, I found this which seemed to be a
> reasonable way of adding links to our model output:
>
> http://wiki.sproutcore.com/FieldNotes-REST-B-JSON
>
> jesus
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
I like the first one. Do you think the atom stuff would serialize
close
to that?
Along those lines, have we considered atom as a use case for interacting with Candlepin?
I know it is
xml based which gets no love, but I have actually heard good things. Google is pushing it
pretty hard, and
I tend to blindly follow whatever they do...
- Justin
-- bk
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
8:14 a.m.
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:
>> Take a look:
>>
>> http://bill.burkecentral.com/2010/03/25/modeling-operations-in-rest/
>
> Since JSON has no link mechanism, I found this which seemed to be a
> reasonable way of adding links to our model output:
>
> http://wiki.sproutcore.com/FieldNotes-REST-B-JSON
>
> jesus
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.
Cheers,
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
10:42 a.m.
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?
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 |
+---------------------------------------------+
10:49 a.m.
----- "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
9:26 p.m.
On 03/26/2010 11:49 AM, Justin Harris wrote:
----- "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.
Delete of the relationship should be a delete. Even if we hold on to
the Data of Hysterical Raisins.
BTW, when we un entitle a consumer, we shouldn't necessarily delete the
entitlement, should we? From what I saw in the slide show today, the
entitlement itself may be reused, just bound to a different consumer.
ISn't this why we have two tables: cp_entitlement and
cp_consumer_entitlements.
BTW, we should either make all of the the tables singular or all of them
plural. and be consistant on the column nameing as well. In Pool we have
productid
sourceentitlement_id
I'm thinking these should be
product_id
source_entitlement_id
> 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
>
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
7:29 a.m.
On Fri, Mar 26, 2010 at 11:26 PM, Adam Young <ayoung(a)redhat.com> wrote:
Delete of the relationship should be a delete. Even if we hold on to
the Data of Hysterical Raisins.
BTW, when we un entitle a consumer, we shouldn't necessarily delete the
entitlement, should we? From what I saw in the slide show today, the
entitlement itself may be reused, just bound to a different consumer.
ISn't this why we have two tables: cp_entitlement and
cp_consumer_entitlements.
Not really, pools are created and no entitlements exist for that pool
at the time. The entitlement only exists when a bind happens, when
unbound the entitlement is deleted and in theory, returned to the
pool. If someone else were to make use of it, a new entitlement (in
terms of a new database row) would be created. I can't remember why I
did join table vs just a join column with consumer, probably something
misguided. :)
Cheers,
Devan
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
7:33 a.m.
On 03/27/2010 08:29 AM, Devan Goodwin wrote:
On Fri, Mar 26, 2010 at 11:26 PM, Adam Young<ayoung(a)redhat.com>
wrote:
>
> Delete of the relationship should be a delete. Even if we hold on to
> the Data of Hysterical Raisins.
>
> BTW, when we un entitle a consumer, we shouldn't necessarily delete the
> entitlement, should we? From what I saw in the slide show today, the
> entitlement itself may be reused, just bound to a different consumer.
> ISn't this why we have two tables: cp_entitlement and
> cp_consumer_entitlements.
Not really, pools are created and no entitlements exist for that pool
at the time. The entitlement only exists when a bind happens, when
unbound the entitlement is deleted and in theory, returned to the
pool. If someone else were to make use of it, a new entitlement (in
terms of a new database row) would be created. I can't remember why I
did join table vs just a join column with consumer, probably something
misguided. :)
You had a thought of having an entitlement span two consumers.
-- bk
7:37 a.m.
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
Any other items?
-- bk
9 a.m.
----- "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
Any other items?
-- bk
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
9:29 a.m.
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
9:30 a.m.
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.
7:20 a.m.
On 03/29/2010 10:30 AM, Adam Young wrote:
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.
I have this on the backlog to design out. Part of it will ber versioning
vs. auditing.
-- bk
5201
days inactive
5207
days old
candlepin@lists.fedorahosted.org
14 comments
6 participants
participants (6)
-
Adam Young -
Bryan Kearney -
Devan Goodwin -
Jesus M. Rodriguez -
jesus rodriguez -
Justin Harris