[katello-devel] Renaming of environments: summary

Tue Aug 14 12:41:46 UTC 2012

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
>
> 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?

I believe (and someone please correct me if I'm wrong)  that the only 
thing that can contain non-ascii characters is the name.  The url & Id 
(ACME_Corporation_zoo_zoorepo in the above example) has to be ascii as 
well.  The name itself can contain any crazy kind of letter you want.   
I'm basing this on recent discussion with pulp, but someone please 
correct me if I'm wrong, as I could have misunderstood that discussion.

-Justin

>>
>>
>> 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
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel