[katello-devel] Renaming of environments: summary

[Bryan Kearney]

On 08/14/2012 09:04 AM, Dmitri Dolguikh wrote:
> On 14/08/12 02:01 PM, Bryan Kearney wrote:
>> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote:
>>> On 13/08/12 11:13 PM, Mike McCune wrote:
>>>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote:
>>>>> On 13/08/12 03:57 PM, Justin Sherrill wrote:
>>>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote:
>>>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote:
>>>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote:
>>>>>>>>> This is a summary of the thread started at
>>>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for
>>>>>>>>> details of the issue with environment renaming.
>>>>>>>>>
>>>>>>>>> Quite a few folks suggested using of an immutable label instead of
>>>>>>>>> environment name, but at the end the idea was defeated by a
>>>>>>>>> comment
>>>>>>>>> from Cliff Perry about users from locales using non-ascii-based
>>>>>>>>> character sets.
>>>>>>>>> Another issue that was discovered was the migration of already
>>>>>>>>> established environments from current version of Katello to the
>>>>>>>>> version containing the fix. My current thinking is to use
>>>>>>>>> environment name value as uuid for "legacy" environments. This
>>>>>>>>> would significantly simply upgrade, as there will be no need to
>>>>>>>>> regenerate entitlement certificates, etc.
>>>>>>>>>
>>>>>>>>> Katello:
>>>>>>>>>   - introduce environment uuids (update db schema, model, etc)
>>>>>>>>>   - update candlepin (this will include updates to schema, and
>>>>>>>>> resource controller)
>>>>>>>>>   - update katello/katello cli to use uuids for environment
>>>>>>>>> identification
>>>>>>>>>   - update repository-related functionality to use environment
>>>>>>>>> uuids
>>>>>>>>>   - figure out/create migration from 1.0 to current
>>>>>>>>>
>>>>>>>>> Bryan, everything minus the migration bit is probably a couple
>>>>>>>>> days
>>>>>>>>> worth of work. Should I create a new story, or I can start on this
>>>>>>>>> right away?
>>>>>>>>>
>>>>>>>>> -d
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> katello-devel mailing list
>>>>>>>>> katello-devel at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>>>>> Any idea what the redhat.repo file will look like with numerical
>>>>>>>> ids?  Or yum repolist ?
>>>>>>> Same as now, but with environment uuids instead on environment
>>>>>>> names.
>>>>>>> -d
>>>>>>
>>>>> Apologies, I didn't understand the question. The latter.
>>>>> -d
>>>>>> So
>>>>>>
>>>>>> [123456]
>>>>>> name=123456
>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/
>>>>>>
>>>>>> or
>>>>>>
>>>>>> [123456]
>>>>>> name=Red Hat Enterprise Linux Server 6 RPMS
>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/
>>>>>>
>>>>>>
>>>>>> ?
>>>>>>
>>>>
>>>>
>>>> and this really blows for our users, IMHO.  You go from a relatively
>>>> readable and clear yum configuration file that a sysadmin can look at
>>>> quickly and understand:
>>>>
>>>> [ACME_Corporation_zoo_zoorepo]
>>>> name = zoorepo
>>>> baseurl =
>>>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo
>>>>
>>>>
>>>> enabled = 1
>>>> gpgcheck = 1
>>>> sslverify = 1
>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem
>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem
>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem
>>>>
>>>> to:
>>>>
>>>> [313024c0-c7bd-012f-d852-1803734d16c4]
>>>> name = zoorepo
>>>> baseurl =
>>>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4
>>>>
>>>>
>>>> enabled = 1
>>>> gpgcheck = 1
>>>> sslverify = 1
>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem
>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem
>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem
>>
>> So, this pains me.. especially since tools like packagekit need to
>> enable and disable repos. If there is a solution where the name and
>> the id are Human Readable and "As close to locale as possible" then I
>> am fine. Image how ugly this screen would look with UUIDS.
> My understanding is that the name does not have any constraints on what
> characters can be used. We could generate repository label (or w/e is
> used in the repo url using Product name, etc?)
>
> -d

I would prefer the URl to be friendly, but I see how UUIDS will make it 
easier. So, give me a path where the IDs and names are as human readable 
as possible and I will be relent.

-- bk