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

Tue Aug 14 10:53:32 UTC 2012

On 14/08/12 11:35 AM, Lukas Zapletal wrote:
> What Jesus describes here was already discussed some time ago on the
> list. In short: "Why not to introduce invariant labels and independent
> resource names". Like, for environment the HTML form would look like:
>
> New Environment
>
> Name: My Own Label I Can Change
> Label: my-own-label-i-can-change *
> Description: _____________
>
> * - prefilled with javascript, lowercased, not changeable in future
>
> So users can change their "Name" but not "Label".
>
> But I am big fan of ID-whatever-you-want approach. Instead of using
> label, we would use simple numeric ID (there is no point of using UUIDs
> in Katello). Then we could use it everywhere:
>
> /environments/1234-my-environment/edit
> /api/environments/1234-my-environment/
> /repos/9876-acme-corporation/1234-my-environment/packages/xyz.rpm
>
> There are few cases we need to use UUIDs directly (e.g. when we proxy to
> Candlepin), but these are rare.
UUID as in globally-unique-identifier. I assume that at some point more 
than one instance of Katello is going to be executed in parallel in a 
single environment? UUID's are much simpler and faster than state 
synchronization across multiple instances.

-d

>
> LZ
>
> On Thu, Aug 09, 2012 at 10:37:20AM -0400, Jesus Rodriguez wrote:
>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote:
>>> On 09/08/12 01:20 PM, James Bowes wrote:
>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, 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)
>>>>>
>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp
>>>> repo labels. a url like:
>>>>
>>>> https://my-cdn.local/content/dev/rhel-server/i386/
>>>>
>>>> is way more useful than:
>>>>
>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/
>>>>
>>>> not to mention, far more handsome!
>>>>
>>>> I'd rather see either immutable labels, or supporting renaming labels,
>>>> too.
>>> The issue boils down to renaming of environments. If we are to use
>>> environment names for environment identification, we have to provide
>>> resolution for urls that are no longer valid (via 301). Doable, but
>>> additional work.
>> Labels are not necessarily environment names. Nothing says you have
>> to allow changing of the label. The label is just a human readable
>> identifier that is both easy to remember and use.
>>
>> While allowing renaming of labels is nice, I don't think it is
>> necessary. Even if you allow renaming the environment (the one shown
>> on the page).
>>
>> Think of the trac wiki url. If I create a new page I can call it
>> DesignLabelsEnvironments. But change the title on the page to be
>> 'Design of Labels for Environments'. Later I change the title to be:
>> 'Environment Label Design'. I don't have to change the page name. If
>> I want to I just create a new one. So if you want to allow label
>> renaming, then make it easy to create Environments.
>>
>>
>>> The idea of labels is interesting, but I don't think it would work out
>>> in the long-term: it would become stale after a rename or two
>> The labels is what we used for RHN Satellite for Channels. It works
>> and a lot easier to remember. I can guarantee if you go with UUID
>> you *WILL* get someone asking why can't they pass in a name. And
>> using the actual name is bad because they will have spaces and might
>> have to be translated. Labels are again human readable.
>>
>>> With uuid's we won't need to support url redirection, they won't go
>>> stale. For user-friendliness we should provide querying by name with
>>> environment resource, smt. like:
>> Nothing says you have to offer redirection with labels. If you make
>> them static and force users to create a new environment to get a new
>> label.
>>
>> So let's walk through the label rename then. You let a user change
>> the label of an environment. So now instead of being 'int-dev' it
>> becomes 'devel'. You could simply return 404 for anyone still using
>> 'int-dev' just like they were if they used the wrong uuid.
>>
>> If you *MUST* offer 301 'moved permanently' for the label then
>> you'll have to keep a list of labels. But I think that's going to be
>> more of a user issue. Because I know people will want to reuse label
>> names later. So I think most of them will be ok if you have a 404
>> for a non existent label.
>>
>> IMO I don't think you need to offer label renames. Just allow
>> renaming of the environment for displaying on the UI. That way your
>> urls are easier to use, cli will be easier to use, and you'll get
>> less complaints.
>>
>>> GET
>>> http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper
>>>
>>> Less convenient, but easier to implement and maintain (from both user
>>> and developer perspective).
>> I don't understand what your example is about. name should never be
>> used, it should be label:
>>
>> ../ACME_Corporation/environments?label=super-duper
>>
>> jesus
>>
>> -- 
>> jesus m. rodriguez          | jesusr at redhat.com
>> principal software engineer | irc: zeus
>> red hat systems management  | 919.754.4413 (w)
>> rhce # 805008586930012      | 919.623.0080 (c)
>> +---------------------------------------------+
>> |   "Those who cannot remember the past       |
>> |    are condemned to repeat it."             |
>> |                        -- George Santayana  |
>> +---------------------------------------------+
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel