[katello-devel] Activation keys requirements

Brad Buckingham bbuckingham at redhat.com
Mon Jul 18 15:41:30 UTC 2011


On 07/18/2011 10:22 AM, Devan Goodwin wrote:
> On Mon, Jul 18, 2011 at 11:01 AM, Brad Buckingham
> <bbuckingham at redhat.com>  wrote:
>> On 07/18/2011 09:32 AM, Lukas Zapletal wrote:
>>> Hello,
>>>
>>> let me sum up first phase requirements for activation keys (AK) support in
>>> Katello. AK in Satellite today on few lines:
>>>
>>> - the format is ID + ALPHANUM
>>> - has numeric usage limit
>>> - used for registering to
>>>   - base channel
>>>   - child channels
>>>   - additional entitlements
>>>   - specific packages
>>>   - system groups
>>> - universal AK for systems without AK
>>>
>>> First phase stories are:
>>>
>>> As a cli user, I would like to create activation keys for my org.
>>> As a cli user, I would like to add a default environment to the key.
>>> As a cli user, I would like to assign a template to a key.
>>> As a client, I would like to register with one or more keys and have my
>>> default data set up
>>>
>>> My assumptions are (please comment):
>>>
>>> - new model class ActivationKey
>>> - ActivationKey has column called "value" (32 [A-Za-z_-] characters)
>>> - ActivationKey belongs_to Organization
>>> - ActivationKey has default Environment column (reference to existing)
>>> - ActivationKey has default Template column (reference to existing)
>>> - user can CRUD activation keys using katello CLI
>>> - katello system register --activationkey=key1 registers the systems to
>>> organization, environment and template defined by the AK
>>>
>>> Questions:
>>>
>>> Q0: Are Environment and Template required options? Or could AK live
>>> without one (or both) of them?
>>>
>>> Q1: What should
>>>
>>> # katello system register --activationkey=key1,key2
>>>
>>> do? What organization/environment/template should the system belong to?
>>> Both? Does it make sense?
>>>
>>> Q2: Any objections to the AK format (alphanums)? I guess it needs just to
>>> be unique enough (and hard to guess for crackers).
>>>
>>> Q3: Is there any plan to implement universal AKs?
>>>
>>> Q4: What about AK permissions? Are AKs organization-wide (no explicit
>>> permissions - once you are "in" you can do whatever you want with them)? Or
>>> classical ownership permission (owner = all rights, others = read only,
>>> owner can assign permissions to particular users)?
>>>
>>> Q5: What are Pulp/Candlepin integration plans?
>>>
>>> Any comments&  tips are welcome. Thanks!
>>>
>> Hi Lukas,
>>
>> On the UI, we have actually begun some work for Activation Keys in Katello.
>>   This work is currently being done within the a-keys remote branch.   None
>> of the changes that we have done so far have been merged to master;
>> therefore, you may want to join us in this branch.
>>
>> The following are the stories we are working for the current UI sprint:
>> 1. As a user, I would like to create activation keys for my org.
>> 2. As a user, I would like to add a default environment to the key.
>> 3. As a user, I would like to assign a subscription to a key.
>>
>> The first story is almost completed, pending some additional spec tests.
>>   For this story, we did create an ActivationKey model that contains name and
>> description.  It also has a belongs_to relationship with organization and a
>> has_one relationship with environment (for the default env story).  I
>> anticipate that the environment relationship could change when that story is
>> implemented.
>>
>> The work for the second story is still TBD; however, it should start this
>> week.
>>
>> The third story is in progress.  Shannon is currently working on this one.
>>   Some UI changes have been pushed in the branch; however there will likely
>> be AR changes coming in today to support an ActivationKey to Subscription
>> relationship.
>>
>> thanks,
>> Brad
>>
> I've been working on similar support in Candlepin for activation keys,
> but as I understand it this is just for standalone Candlepin + Headpin
> deployments. In a Katello deployment our activation keys are unused,
> and Katello's will take over. (as they're much richer) and co-ordinate
> whatever needs to be done in Candlepin.
>
> As such I think the only integration we need to get nailed down on our
> end is to make sure Subscription Manager is sending them along during
> registration in a consistent manner. We have this just about complete,
> posting to the normal registration URL like:
>
> POST /consumers?owner=key&activation_keys=key1,key2,key3
>
> Does this look ok?
>
> Cheers,
>
> Devan
>
>
Devan,

The request URI seems reasonable to me.

thanks,
Brad




More information about the katello-devel mailing list