Hi all, in Katello we currently can't create two custom products (each in different Org) with the same name. There's uniqueness constraint on product names in candlepin that doesn't allow it.
My question is: Would it be possible to remove the constraint?
There are still unique product ids so from my point of view it seems safe to remove the constraint from names. But my candlepin knowledge is not very deep. Are there any objections or better solutions you can see?
Prefixing the product name with org name wouldn't work here as the name is displayed in subscription manager. Also sharing one candlepin product with more katello products is no a good idea because they can have different content.
Thanks for opinions and ideas Tomas
This part of Candlepin is coming from initially designing for hosted products which are global in nature and that's likely why we added this uniqueness constraint.
I don't see any real problem with removing it on the product name, aside from the fact that an org could make two products with the same name and in a lot of UI locations, would be unable to tell the difference. (unless Katello enforces product name uniqueness per org, which I guess it probably should)
A much larger possible solution is getting Candlepin's products per-org, but this is likely a very big rats nest on our part, so we're hoping this solution works, and Katello can do the needful in terms of tracking orgs and their custom products.
I would file a bug and harass us/BK if it's an urgent change.
Cheers,
Devan
On Wed, Feb 8, 2012 at 11:47 AM, Tomas Strachota tstrachota@redhat.com wrote:
Hi all, in Katello we currently can't create two custom products (each in different Org) with the same name. There's uniqueness constraint on product names in candlepin that doesn't allow it.
My question is: Would it be possible to remove the constraint?
There are still unique product ids so from my point of view it seems safe to remove the constraint from names. But my candlepin knowledge is not very deep. Are there any objections or better solutions you can see?
Prefixing the product name with org name wouldn't work here as the name is displayed in subscription manager. Also sharing one candlepin product with more katello products is no a good idea because they can have different content.
Thanks for opinions and ideas Tomas
katello-devel mailing list katello-devel@redhat.com https://www.redhat.com/mailman/listinfo/katello-devel
On 02/08/2012 11:39 AM, Devan Goodwin wrote:
This part of Candlepin is coming from initially designing for hosted products which are global in nature and that's likely why we added this uniqueness constraint.
I don't see any real problem with removing it on the product name, aside from the fact that an org could make two products with the same name and in a lot of UI locations, would be unable to tell the difference. (unless Katello enforces product name uniqueness per org, which I guess it probably should)
Does name == id for this object?
A much larger possible solution is getting Candlepin's products per-org, but this is likely a very big rats nest on our part, so we're hoping this solution works, and Katello can do the needful in terms of tracking orgs and their custom products.
I would file a bug and harass us/BK if it's an urgent change.
lemme know how urgent.
-- bk
On Wed, Feb 8, 2012 at 1:37 PM, Bryan Kearney bkearney@redhat.com wrote:
On 02/08/2012 11:39 AM, Devan Goodwin wrote:
This part of Candlepin is coming from initially designing for hosted products which are global in nature and that's likely why we added this uniqueness constraint.
I don't see any real problem with removing it on the product name, aside from the fact that an org could make two products with the same name and in a lot of UI locations, would be unable to tell the difference. (unless Katello enforces product name uniqueness per org, which I guess it probably should)
Does name == id for this object?
No, products have their own id which is unique. I was against this change since it means you can create duplicates with the same name which just seems wrong, but compared to the alternative which seems more complicated it's a quick solution for now.
jesus
candlepin@lists.fedorahosted.org