[katello-devel] Renaming of environments: summary

[Mike McCune]

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


now as a user you have no idea what env+repo you are really looking at. 
  You know it is the zoorepo in the locker for ACME_Corporation but you 
would have to know what IDs the environments have to even begin to 
figure out what content you are pointing at.

we are taking something readable and turning it into a generated 
configuration value that our sysadmins will *really* hate.  I think the 
changes outlined above while clear are a definite step backwards in 
functionality for Katello.  The price to pay to support Env renaming is 
*not* worth it if we implement it as such.  Lets not take this decision 
likely because one of the primary touch points at the client is the 
redhat.repo file that lists the content you are pulling down.

I'd much rather do the following to ensure our yum config values on the 
clients are readable and sacrifice i18n in order to do so:

1) use an ASCII label for reops if we are going to really implement repo 
renaming
2) force Org (possibly), Env and Repo names to be ASCII
3) Any existing utf-8 data for these values is left alone and users are 
warned we do not support this, or we encode it in some way such that it 
works

Is renaming environments really worth all this effort?  If so, lets not 
sacrifice our usability at the client level just to support it.

Mike