[katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments)

[Dmitri Dolguikh]

On 09/08/12 05:37 PM, Cliff Perry wrote:
> On 08/09/2012 04:51 PM, Dmitri Dolguikh wrote:
>> Since uuids got no love, let's replace uuids with immutable
>> human-readable labels.
>> -d
>
> Hmm... random thoughts here.
>
> How often will rename of an environment actually happen?
>  - Continue to do not allow rename of an environment. If you really do 
> not want to continue using an environment, I would think that:
>   - Would it be easier to allow customers to 'clone' an environment 
> into a new Environment, then move systems from one environment to 
> another.
>   - They would then retire (or delete) the old environment, when no 
> longer used/needed.
That would work, considering we now have support for moving of systems 
between environments.
>
> If you do wish to allow to rename an Environment.
>  - How will any proposed solution be impacted by upgrades? Can what 
> you propose be implemented sanely to allow a current katello 1.0 user 
> to consume/upgrade smoothly to this new model.
Could be very disruptive, as repository ids will have to change, 
resulting in need to regenerate all entitlement certificates that have 
content. Could be handled by an upgrade script though.
> - I would vote for a unique immutable human-readable (assuming you 
> have a latin based/derived alphabet) label. Or a numberic ID.
>   - I agree with Justin, that there was almost zero negative feedback 
> in Satellite for customers wanting to change the label, as long as 
> they could modify the description/name of the object.
>
> I know this could be its own thread... but IMHO using/feeding 
> environment name/label into a yum URL is a bit limiting, if we have to 
> restrict it and would propose that Environment name/label is not used 
> but an arbitrary numeric ID, thus allowing Japanese, etc languages to 
> be used in creation of an Environment name. (unless I am mistaken on 
> how this works today).
Something I haven't considered at all. Any human-readable id will have 
to be limited to ascii, as URL-encoding a non-ascii human readable label 
will turn it into human-unreadable. Back to uuids.


Very good points. Should we choose to go with editing of environment 
names (which seems inevitable), I think we could migrate environments to 
new ones by cloning environment name as the id, and use uuid for all 
newly created environments. This would eliminate the need for 
regeneration of repository urls and entitlement certificates for all 
systems involved.

Alternatively, moving of systems provides a graceful way to change 
environments (although we'll need bulk system moving for this to be a 
functional equivalent).

-d
>
> If something else pops into my head, I'll reply again :)
>
> Cliff
>
>>
>> On 09/08/12 12:34 PM, Dmitri Dolguikh wrote:
>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for
>>> description of an issue with environment renaming.
>>>
>>> The immediate problems around environments: using of environment names
>>> and environment ids for identification of environments
>>> interchangeably. Using db ids for environment identification when not
>>> using environment names.
>>>
>>> To resolve these:
>>> - introduce environment uuids
>>> - update katello/katello cli to use uuids for environment 
>>> identification
>>> - update repository naming to use environment uuids
>>> - update candlepin (this will include updates to schema, and resource
>>> controller)
>>>
>>>
>>> The larger problem: Katello and Candlepin modelling of
>>> products/product content/environments lost coherency.
>>>
>>> Candlepin's view of the above trifecta (use of a monospaced font is
>>> encouraged for the content below):
>>> +-------------+ +--------------------+
>>> | Environment | 1 <--- * | EnvironmentContent |
>>> +-------------+ +--------------------+
>>> ^
>>> | *
>>> | 1
>>> +---------+ +----------------+
>>> | Product | 1 ---> * | ProductContent |
>>> +---------+ +----------------+
>>>
>>>
>>> same thing in Katello (with added pulp repositories):
>>>
>>> +-------------+
>>> | Pulp::Repos |<-----------------------+
>>> +-------------+ |
>>> ^ |
>>> | uses |
>>> +----------------------------------+ | +-------------+
>>> | Candlepin::Product | | | Environment |
>>> | (uses Candlepin::ProductContent) | | +-------------+
>>> +----------------------------------+ | ^
>>> | ^ | | 1
>>> |uses | uses | |
>>> | | | | *
>>> +---------+ +--------------------+
>>> | Product | 1 ---------------> * | EnvironmentProduct |
>>> +---------+ +--------------------+
>>> | |1
>>> | |*
>>> | V
>>> | uses +------------+
>>> +------| Repository |
>>> +------------+
>>>
>>>
>>> I propose:
>>> - Rename EnvironmentProduct to ProductContent
>>> - make it use Candlepin::ProductContent
>>> - remove use of Pulp::Repos from Product
>>> - delegate responsibility of generation of environment uuids to
>>> Candlepin (should cp folks agree on this)
>>>
>>> resulting in:
>>>
>>> +-------------+
>>> | Environment |
>>> +-------------+
>>> ^
>>> | 1
>>> | *
>>> +---------+ +----------------+
>>> | Product | 1 ---> * | ProductContent |
>>> +---------+ +----------------+
>>> |1 | uses
>>> | | +---------------------------+
>>> |1 +-> | Candlepin::ProductContent |
>>> V +---------------------------+
>>> +-------------+ uses +------------+
>>> | Pulp::Repos |<-----| Repository |
>>> +-------------+ +------------+
>>>
>>> I don't think many-1 relation is required on
>>> Repository-ProductContent, it's 1-1?
>>>
>>>
>>> Thoughts, concerns, opinions?
>>> -d
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>>
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>