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

Dmitri Dolguikh dmitri at redhat.com
Thu Aug 9 15:32:49 UTC 2012


On 09/08/12 04:18 PM, Ewoud Kohl van Wijngaarden wrote:
> On Thu, Aug 09, 2012 at 10:52:31AM -0400, 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.
>>
>> 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.
>> But I do know that most curl users will remember 'devel' as their
>> environment name vs '550e8400e29b41d4a716446655440000'.
> I certainly agree that labels are easier to read, but how hard is it to
> maintain both and symlink the label to the UUID? Here the UUID would be
> stable and label unstable. Then when you rename the environment you
> should warn the user that label urls will disappear, but I doubt that
> happens very often. In cases where it does change often they can switch
> to using UUIDs.
A published url *must* remain accessible, since you don't know where and 
how it is being used. The only appropriate way to deal with this 
situation is to provide a 301 redirect, which requires work (including 
support on the client side).

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





More information about the katello-devel mailing list