[katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments)

Thu Aug 9 15:34:19 UTC 2012

On 08/09/2012 11:30 AM, Dmitri Dolguikh wrote:
> On 09/08/12 03:52 PM, jesus m. rodriguez wrote:
>> On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote:
>>> On 09/08/12 02:11 PM, Justin Sherrill wrote:
>>>> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote:
>>>>> On 09/08/12 01:49 PM, Justin Sherrill wrote:
>>>>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote:
>>>>>>> On 09/08/12 01:20 PM, James Bowes wrote:
>>>>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote:
>>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for
>>>>>>>>> description of an issue with environment renaming.
>>>>>>>>>
>>>>>>>>> The immediate problems around environments: using of environment
>>>>>>>>> names and environment ids for identification of environments
>>>>>>>>> interchangeably. Using db ids for environment identification when
>>>>>>>>> not using environment names.
>>>>>>>>>
>>>>>>>>> To resolve these:
>>>>>>>>>    - introduce environment uuids
>>>>>>>>>    - update katello/katello cli to use uuids for environment
>>>>>>>>> identification
>>>>>>>>>    - update repository naming to use environment uuids
>>>>>>>>>    - update candlepin (this will include updates to schema, and
>>>>>>>>> resource controller)
>>>>>>>>>
>>>>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp
>>>>>>>> repo labels. a url like:
>>>>>>>>
>>>>>>>> https://my-cdn.local/content/dev/rhel-server/i386/
>>>>>>>>
>>>>>>>> is way more useful than:
>>>>>>>>
>>>>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> not to mention, far more handsome!
>>>>>>>>
>>>>>>>> I'd rather see either immutable labels, or supporting renaming
>>>>>>>> labels,
>>>>>>>> too.
>>>>>>> The issue boils down to renaming of environments. If we are to use
>>>>>>> environment names for environment identification, we have to
>>>>>>> provide resolution for urls that are no longer valid (via 301).
>>>>>>> Doable, but additional work.
>>>>>>>
>>>>>>> The idea of labels is interesting, but I don't think it would work
>>>>>>> out in the long-term: it would become stale after a rename or two
>>>>>>>
>>>>>> I would agree with you, except for the fact that in Satellite many
>>>>>> different objects used the idea of a mutable name and an immutable
>>>>>> label (especially for repos).   I don't know that I once heard a
>>>>>> complaint from a customer that they couldn't rename a label or that
>>>>>> it was stale.
>>>>>>
>>>>> I just don't think it's possible to communicate the intent using a
>>>>> short (for the benefit of usability) label, so that the label would
>>>>> stay constant while environment name kept changing.
>>>>>
>>>>> Perhaps renaming of environments is overrated?
>>>>> -d
>>>>
>>>> I don't think its overrated, and regardless i feel that we need to be
>>>> able to rename repositories as well (where you'd hit the same issue).
>>>> It does seem odd, but it worked really well in satellite :)
>>> I suspect that renaming doesn't happen all that often in the 
>>> lifetime of
>>> a given named resource. While I certainly agree that it's useful and
>>> nice to have human-readable urls, it's not always attainable. The
>>> benefits are further reduced by:
>>>    - realizing that the main consumer of those urls is some piece of 
>>> code.
>>
>> I respectfully disagree. The main consumer will probably be a user 
>> NOT a piece of code. I don't see why label is such a horrible idea. 
>> What is there to convey? You show a page with the Environments 
>> creation. User enters name, you can start to autogenerate the label 
>> for convenience. If the user wants to change it during the creation 
>> step, let them.
> A label, being product of a human being is going to be:
>  - subjective, and fit this persons taxonomy of w/e they happen to be 
> labelling
>  - associated with (in the case of environments) current use of 
> environment
>>
>> Once created they can rename the Environment until their heart's 
>> content. Just not the label. Want a new label? clone the Environment 
>> to a new one give it a new label. Remove the old Environment. Again 
>> labels unique
>> human readable codes they can use to uniquely identify an environment.
>>
>>>    - discoverability (not something we have atm, but something we 
>>> should
>>> be striving for in our REST api) more than compensates for obtuse urls.
>>
>> True but I'm seeing this as overrated. Having done the HATEOAS thing 
>> on candlepin, I don't know how useful it is to a client. Most clients 
>> aren't smart enough to look for ref links and follow them besides a 
>> browser.
> HATEOAS is a big part of it, another is ability to search (we can even 
> provide search links in ther response for each resource).
>> But I do know that most curl users will remember 'devel' as their 
>> environment name vs '550e8400e29b41d4a716446655440000'.
>
> That's one of the issues - devel in this case may be renamed to 
> 'staging', while you'll be stuck with the label 'devel', which has 
> become misleading. As an API implementor I'd much rather annoy 
> everybody equally, than mislead some users.
>
I would normally think along these lines too, however again after years 
on satellite no one ever complained about this that i know of.  Maybe it 
annoyed them just not enough to complain, but it was not anything that 
anyone appeared to care about.  Logically what you say makes sense, but 
from experience in practice it doesn't hold IMHO.

-Justin

> -d
>>
>> jesus
>>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel