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

Tue Aug 14 10:35:50 UTC 2012

What Jesus describes here was already discussed some time ago on the
list. In short: "Why not to introduce invariant labels and independent
resource names". Like, for environment the HTML form would look like:

New Environment

Name: My Own Label I Can Change
Label: my-own-label-i-can-change *
Description: _____________

* - prefilled with javascript, lowercased, not changeable in future

So users can change their "Name" but not "Label".

But I am big fan of ID-whatever-you-want approach. Instead of using
label, we would use simple numeric ID (there is no point of using UUIDs
in Katello). Then we could use it everywhere:

/environments/1234-my-environment/edit
/api/environments/1234-my-environment/
/repos/9876-acme-corporation/1234-my-environment/packages/xyz.rpm

There are few cases we need to use UUIDs directly (e.g. when we proxy to
Candlepin), but these are rare.

LZ

On Thu, Aug 09, 2012 at 10:37:20AM -0400, Jesus Rodriguez 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.
> 
> Labels are not necessarily environment names. Nothing says you have
> to allow changing of the label. The label is just a human readable
> identifier that is both easy to remember and use.
> 
> While allowing renaming of labels is nice, I don't think it is
> necessary. Even if you allow renaming the environment (the one shown
> on the page).
> 
> Think of the trac wiki url. If I create a new page I can call it
> DesignLabelsEnvironments. But change the title on the page to be
> 'Design of Labels for Environments'. Later I change the title to be:
> 'Environment Label Design'. I don't have to change the page name. If
> I want to I just create a new one. So if you want to allow label
> renaming, then make it easy to create Environments.
> 
> 
> >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
> 
> The labels is what we used for RHN Satellite for Channels. It works
> and a lot easier to remember. I can guarantee if you go with UUID
> you *WILL* get someone asking why can't they pass in a name. And
> using the actual name is bad because they will have spaces and might
> have to be translated. Labels are again human readable.
> 
> >
> >With uuid's we won't need to support url redirection, they won't go
> >stale. For user-friendliness we should provide querying by name with
> >environment resource, smt. like:
> 
> Nothing says you have to offer redirection with labels. If you make
> them static and force users to create a new environment to get a new
> label.
> 
> So let's walk through the label rename then. You let a user change
> the label of an environment. So now instead of being 'int-dev' it
> becomes 'devel'. You could simply return 404 for anyone still using
> 'int-dev' just like they were if they used the wrong uuid.
> 
> If you *MUST* offer 301 'moved permanently' for the label then
> you'll have to keep a list of labels. But I think that's going to be
> more of a user issue. Because I know people will want to reuse label
> names later. So I think most of them will be ok if you have a 404
> for a non existent label.
> 
> IMO I don't think you need to offer label renames. Just allow
> renaming of the environment for displaying on the UI. That way your
> urls are easier to use, cli will be easier to use, and you'll get
> less complaints.
> 
> >
> >GET
> >http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper
> >
> >Less convenient, but easier to implement and maintain (from both user
> >and developer perspective).
> 
> I don't understand what your example is about. name should never be
> used, it should be label:
> 
> ../ACME_Corporation/environments?label=super-duper
> 
> 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  |
> +---------------------------------------------+
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine