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

Dmitri Dolguikh dmitri at redhat.com
Thu Aug 9 15:37:32 UTC 2012


On 09/08/12 03:37 PM, jesus m. 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:
Querying could be done on any field, really, it's a query after all. A 
uri, on the other hand should include resource id, in your case the label:

http://localhost/katello/api/environments/super-duper

-d
>
>
> ../ACME_Corporation/environments?label=super-duper
>
> jesus
>





More information about the katello-devel mailing list