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

[Ewoud Kohl van Wijngaarden]

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.