[katello-devel] Renaming of environments: summary

Tue Aug 14 13:58:06 UTC 2012

On 08/14/2012 09:26 AM, Dmitri Dolguikh wrote:
> On 14/08/12 02:07 PM, Bryan Kearney wrote:
>> 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.
>
> Hmm. how about automatically generate labels in spirit of
> http://world.std.com/~reinhold/diceware.html
> <http://world.std.com/%7Ereinhold/diceware.html>? The trick would be
> guarantee uniqueness, I'll have to think about that...

That's clever, but is it really necessary? I'm not opposed to using it as a 
way to generate labels. But you'll still want to allow a user to enter 
their own label at creation time. They may not want the autogenerated one.

jesus

-- 
jesus m. rodriguez          | jesusr at redhat.com
principal software engineer | irc: zeus
red hat systems management  | 919.754.4413 (w)
rhce # 805008586930012      | 919.623.0080 (c)
+---------------------------------------------+
|   "Those who cannot remember the past       |
|    are condemned to repeat it."             |
|                        -- George Santayana  |
+---------------------------------------------+