[katello-devel] BZ 823890 - importing multiple manifests does not clear previous

Garik Khachikyan gkhachik at redhat.com
Tue May 22 13:39:52 UTC 2012


On 22/05/12 15:28, Tom McKay wrote:
>
> ----- Original Message -----
>> From: "Garik Khachikyan"<gkhachik at redhat.com>
>> To: katello-devel at redhat.com
>> Sent: Tuesday, May 22, 2012 9:19:03 AM
>> Subject: Re: [katello-devel] BZ 823890 - importing multiple manifests does not clear previous
>>
>> On 22/05/12 15:05, Tom McKay wrote:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=823890
>>>
>>> I could use some help on this one: Importing a second manifest from
>>> the same distributor stacks the subscriptions rather than replaces
>>> them. Candlepin handles everything correctly, but the katello DB
>>> duplicates keeps the entries around. What is the technique for
>>> properly handling the removal of the previous ones flushing things
>>> out?
>>>
>>> A second point I noted in the BZ is that both the marketing
>>> products as well as the engineering products are listed. This does
>>> not match the UI, though listing marketing products is useful.
>>> Opinions on this aspect?
>>>
>>> This is a high priority BZ, help greatly appreciated!
>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>> And are you sure it is the "right logic" replacing the previous
>> manifest
>> content.
>>
>> In real life it could happen that some org requests some amount of
>> subscriptions; then consumes it fully and requests the second
>> portion.
>>
>> So I'm really not sure that we should remove (or replace) the old
>> subscriptions (as client already paid for it) but rather to add them
>> into existing ones.
>>
>> Or maybe I'm missing the point?
> The "right" thing for katello to do is not try to override what candlepin is doing. What candlepin says is the right answer.
>
> To adjust subscription amounts, the user goes to the customer portal and adjusts the amounts in their distributor (adding, removing, etc.), then they download a new manifest. This new manifest contains everything the katello org should have.
>
> The wrinkle, of course, is custom providers. Importing a new Red Hat manifest should not touch the custom provider products.
>
>> Garik.
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
huh!

Saying that it means: the recent/current importing manifest *always* 
illustrates ALL subscriptions that the customer has (so altogether with 
previous requests) - so it does not go as "incremental" ?

So it seems to be different from the "old" subscription model (that our 
clients might be used to use before)

thanks for highlighting that.
Garik.




More information about the katello-devel mailing list