I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality. Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move all übercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality. Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move all übercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 11-09-09 10:29 AM, Michael Stead wrote:
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality. Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move all übercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
I was thinking about adding a new resource - something like: /owner/:id/uebercert with POST and GET. The logic is roughly:
- create a special Product "ueber_product" - create content "ueber_content" - add content to product - create subscription for "ueber_product" - refresh pools - create consumer that will be used to consume the entitlement - "ueber_consumer" - and, finally, consume the entitlement and return the certificate
I'm thinking that on a subsequent POST the entitlement cert can be re-generated.
-d
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
On 11-09-09 10:29 AM, Michael Stead wrote:
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality. Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move all übercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
I was thinking about adding a new resource - something like: /owner/:id/uebercert with POST and GET. The logic is roughly:
- create a special Product "ueber_product"
- create content "ueber_content"
- add content to product
- create subscription for "ueber_product"
- refresh pools
- create consumer that will be used to consume the entitlement -
"ueber_consumer"
- and, finally, consume the entitlement and return the certificate
I'm thinking that on a subsequent POST the entitlement cert can be re-generated.
-d
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
This content prefix stuff is on the owner, and its pretty deep down in the candlepin code. I'm fine with doing it in candlepin, then. the idea of a specific url for it as you suggested also looks good. My only concern is this is a developement only thing, right? so we'd want to have an option toggle for it or something (plugin?)
-James
On 09/12/2011 09:06 AM, James Bowes wrote:
On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
On 11-09-09 10:29 AM, Michael Stead wrote:
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality. Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move all übercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
I was thinking about adding a new resource - something like: /owner/:id/uebercert with POST and GET. The logic is roughly:
- create a special Product "ueber_product"
- create content "ueber_content"
- add content to product
- create subscription for "ueber_product"
- refresh pools
- create consumer that will be used to consume the entitlement -
"ueber_consumer"
- and, finally, consume the entitlement and return the certificate
I'm thinking that on a subsequent POST the entitlement cert can be re-generated.
-d
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
This content prefix stuff is on the owner, and its pretty deep down in the candlepin code. I'm fine with doing it in candlepin, then. the idea of a specific url for it as you suggested also looks good. My only concern is this is a developement only thing, right? so we'd want to have an option toggle for it or something (plugin?)
-James
No.. this is production. Help customers create debug certs which they can hand out internally.
-- bk
On 11-09-12 10:06 AM, James Bowes wrote:
On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
On 11-09-09 10:29 AM, Michael Stead wrote:
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality. Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move all übercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
I was thinking about adding a new resource - something like: /owner/:id/uebercert with POST and GET. The logic is roughly:
- create a special Product "ueber_product"
- create content "ueber_content"
- add content to product
- create subscription for "ueber_product"
- refresh pools
- create consumer that will be used to consume the entitlement -
"ueber_consumer"
- and, finally, consume the entitlement and return the certificate
I'm thinking that on a subsequent POST the entitlement cert can be re-generated.
-d
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
This content prefix stuff is on the owner, and its pretty deep down in the candlepin code. I'm fine with doing it in candlepin, then. the idea of a specific url for it as you suggested also looks good. My only concern is this is a developement only thing, right? so we'd want to have an option toggle for it or something (plugin?)
Nope, this isn't a development-only thing - uebercert is going to be used by image factory. Hence my preference for resource approach.
-d
-James
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 09/12/2011 09:14 AM, Dmitri Dolguikh wrote:
On 11-09-12 10:06 AM, James Bowes wrote:
On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
On 11-09-09 10:29 AM, Michael Stead wrote:
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality.Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move allübercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
I was thinking about adding a new resource - something like: /owner/:id/uebercert with POST and GET. The logic is roughly:
- create a special Product "ueber_product"
- create content "ueber_content"
- add content to product
- create subscription for "ueber_product"
- refresh pools
- create consumer that will be used to consume the entitlement -
"ueber_consumer"
- and, finally, consume the entitlement and return the certificate
I'm thinking that on a subsequent POST the entitlement cert can be re-generated.
-d
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
This content prefix stuff is on the owner, and its pretty deep down in the candlepin code. I'm fine with doing it in candlepin, then. the idea of a specific url for it as you suggested also looks good. My only concern is this is a developement only thing, right? so we'd want to have an option toggle for it or something (plugin?)
Nope, this isn't a development-only thing - uebercert is going to be used by image factory. Hence my preference for resource approach.
-d
-James
What stories should I put on the candlepin backlog for next sprint?
-- bk
On 11-09-12 10:36 AM, Bryan Kearney wrote:
On 09/12/2011 09:14 AM, Dmitri Dolguikh wrote:
On 11-09-12 10:06 AM, James Bowes wrote:
On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
On 11-09-09 10:29 AM, Michael Stead wrote:
On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
I ran into an issue with how content path is being created in entitlement certificates generated by candlepin when working on übercert functionality.Übercert is an entitlement certificate that has a single piece of content with the url of "/owner_name_goes_here" (this would grant access to all urls below the one specified).
During entitlement certificate generation candlepin prefixes all content urls with owner-specific prefix (/owner_name/$env in general case). One way to handle this situation would be to move allübercert-related logic to candlepin (internal candlepin api allows to bypass prefix addition during cert generation). This would also have a benefit (imo) of bypassing async cert regeneration, since in this particular case it would be a bit of an overkill.
I like this approach better. It seems a lot cleaner to me than just adding a somewhat buried notion of "if startswith // than do this". Would this be done as a new resource, or just bolted onto an existing? What sort of 'übercert-related logic' are we talking about here?
I was thinking about adding a new resource - something like: /owner/:id/uebercert with POST and GET. The logic is roughly:
- create a special Product "ueber_product"
- create content "ueber_content"
- add content to product
- create subscription for "ueber_product"
- refresh pools
- create consumer that will be used to consume the entitlement -
"ueber_consumer"
- and, finally, consume the entitlement and return the certificate
I'm thinking that on a subsequent POST the entitlement cert can be re-generated.
-d
Another approach would be for katello to create content with url in some specific form (one suggestion was to use '//' at the start of the url, e.g. "//ACME_Corporation"), and bypass prefix addition for such urls on candlepin side.
I'm not a big fan of #2. Thoughts/opinions?
Cheers, -d
This content prefix stuff is on the owner, and its pretty deep down in the candlepin code. I'm fine with doing it in candlepin, then. the idea of a specific url for it as you suggested also looks good. My only concern is this is a developement only thing, right? so we'd want to have an option toggle for it or something (plugin?)
Nope, this isn't a development-only thing - uebercert is going to be used by image factory. Hence my preference for resource approach.
-d
-James
What stories should I put on the candlepin backlog for next sprint?
-- bk
Something like: - as an Image Factory user I'd like to create an uebercert (an entitlement certficate granting access to all content for a given organization) - as an Image Factory user I'd like to be able to download an existing uebercert - as an Image Factory user I'd like to be able to re-generate uebercert (this one can be rolled-in into creation however)
-d
candlepin@lists.fedorahosted.org
-
Bryan Kearney -
Dmitri Dolguikh -
James Bowes -
Michael Stead