[katello-devel] Renaming of environments: summary

Tue Aug 14 11:17:10 UTC 2012

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

That's not what I meant. I was thinking to use repo name in the section 
heading, but uuid in the url. So, using your example, it's going to be:

[ACME_Corporation_zoo_zoorepo]
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

while url has to stay in ascii, I don't think there's the same 
requirement for yum repo config file?
>
>
> 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
Does my example above resolve the questions you had?
>
>
> Is renaming environments really worth all this effort?  If so, lets 
> not sacrifice our usability at the client level just to support it.
Personally, I'm not convinced that it's worth it, since we could 
replicate renaming with create environment/move system[s] (although we 
need bulk moving). This doesn't resolve the issue with environment names 
in urls however.

-d
>
> Mike
>
>
>
>
>