[katello-devel] Renaming of environments: summary

Tue Aug 14 14:13:37 UTC 2012

On 14/08/12 02:58 PM, jesus m. rodriguez wrote:
> 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.
>
we are back to discussing discrimination against users not using 
ascii-based character sets. Another point of contention - the resource 
id has to be unique, so something like this works and stays valid after 
w/e changes users make to the resource: 
http://blah.org/environments/<some id here>/

In our case url of the resource is also its uri, and I'll put emphasis 
on unique here. No human can generate random enough information, and 
repeatedly asking the user to re-enter a bit of information is bad ui 
too. Much easier is to generate the bit automatically, leads to a better 
user interaction too.

-d
> jesus
>
>