[katello-devel] Activation keys requirements

[Devan Goodwin]

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 Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca