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

[Justin Sherrill]

On 08/09/2012 07:59 PM, Bryan Kearney wrote:
> On 08/09/2012 09:11 AM, Justin Sherrill wrote:
>> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote:
>>> On 09/08/12 01:49 PM, Justin Sherrill 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.
>>>>>
>>>>> 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
>>>>>
>>>> I would agree with you, except for the fact that in Satellite many
>>>> different objects used the idea of a mutable name and an immutable
>>>> label (especially for repos).   I don't know that I once heard a
>>>> complaint from a customer that they couldn't rename a label or that
>>>> it was stale.
>>>>
>>> I just don't think it's possible to communicate the intent using a
>>> short (for the benefit of usability) label, so that the label would
>>> stay constant while environment name kept changing.
>>>
>>> Perhaps renaming of environments is overrated?
>>> -d
>>
>> I don't think its overrated, and regardless i feel that we need to be
>> able to rename repositories as well (where you'd hit the same issue). It
>> does seem odd, but it worked really well in satellite :)
>>
>> -Justin
>
> Did folks on the client ever see the repos? If I remember, they were 
> always server side.
>
> We could move to a model where the name and id are readable, but the 
> url is not:
>
> [Dev-Evironment-Wiked-Product-Kick-Arse-Repo]
> name= Dev Evironment Wiked Product Kick Arse Repo
> url= /content/919/555/1212/
>
> -- bk

You would see them when interacting with yum (yum repolist, etc..)  
There was no file that contained the list though.  I think the above 
would be fine, as in satellite you couldn't ever really see the url in 
any way.   I think the priority is to make the yum repo ID and name 
human readable.  I don't think its important at all for the url to be 
human readable.

-Justin

>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel