Foretello - names / labels / ids

Development
1

Katello has the concept of "labels" on some of its models. A label must be unique to an organization and contain just ascii characters. This label is basically a user definable unique ID for the given object. The reason it was introduced initially was that some of the backend services for katello could not handle special characters in names (ie. pulp wanted names to be of a certain format and katello allowed names in any language).

A side benefit of labels was that internal database row number ids were not exposed to the user: The ids used via the command line are "human readable" and sensible.

Another benefit is that an install can be "dumped" and recreated in a new install with all IDs consistent between the two (since internal database IDs are not referenced from a user perspective).

The question is, should we make it a goal for all objects to support labels instead of internal numeric IDs, removing the IDs from user view?

··· -- @thomasmckay

–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School

2

>
> Katello has the concept of "labels" on some of its models. A label must be unique to an organization and contain just ascii characters. This label is basically a user definable unique ID for the given object. The reason it was introduced initially was that some of the backend services for katello could not handle special characters in names (ie. pulp wanted names to be of a certain format and katello allowed names in any language).
>

Are the labels still required by back-end services now?

> A side benefit of labels was that internal database row number ids were not exposed to the user: The ids used via the command line are "human readable" and sensible.
>

I would prefer to show only names in CLI, or optionally DB ids. I am not
sure where is the benefit of hiding them, Tom?

> Another benefit is that an install can be "dumped" and recreated in a new install with all IDs consistent between the two (since internal database IDs are not referenced from a user perspective).
>

I would just ensure that the dump has correct numerical IDs and thath
they are imported again correctly. Or maybe I am missing something.

> The question is, should we make it a goal for all objects to support labels instead of internal numeric IDs, removing the IDs from user view?
>
>

Personally I would remove labels if possible or hide them. The main
reason is that when the resource is renamed the label stays and is
source of confusion. If memorability of numerical IDs is problem, I
would replace them with some memorable string representation (like
Heroku app names).

··· On 24.03.14 14:59, Tom McKay wrote:
3

>
> >
> > Katello has the concept of "labels" on some of its models. A label must be
> > unique to an organization and contain just ascii characters. This label is
> > basically a user definable unique ID for the given object. The reason it
> > was introduced initially was that some of the backend services for katello
> > could not handle special characters in names (ie. pulp wanted names to be
> > of a certain format and katello allowed names in any language).
> >
>
> Are the labels still required by back-end services now?

Yes, and in the case of repos they are visible to the user on the client system so having them in a readable format (versus just a random hash/number) was deemed important.

>
> > A side benefit of labels was that internal database row number ids were not
> > exposed to the user: The ids used via the command line are "human
> > readable" and sensible.
> >
>
> I would prefer to show only names in CLI, or optionally DB ids. I am not
> sure where is the benefit of hiding them, Tom?

The labels are alternatives to the db ids. If the tool filled in the labels w/ a db id style (ie. a unique number) then the user wouldn't know or care about the difference, right?

>
> > Another benefit is that an install can be "dumped" and recreated in a new
> > install with all IDs consistent between the two (since internal database
> > IDs are not referenced from a user perspective).
> >
>
> I would just ensure that the dump has correct numerical IDs and thath
> they are imported again correctly. Or maybe I am missing something.

I don't work with dbs that often so assumed that maintaining numerical ids across two dbs would not be easy.

>
> > The question is, should we make it a goal for all objects to support labels
> > instead of internal numeric IDs, removing the IDs from user view?
> >
> >
>
> Personally I would remove labels if possible or hide them. The main
> reason is that when the resource is renamed the label stays and is
> source of confusion. If memorability of numerical IDs is problem, I
> would replace them with some memorable string representation (like
> Heroku app names).

Labels are the memorable string representations.

Are there benefits to using actual database row numbers as the exposed id versus another representation like label?

··· ----- Original Message ----- > On 24.03.14 14:59, Tom McKay wrote:

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

>
>
>>
>>>
>>> Katello has the concept of "labels" on some of its models. A label must be
>>> unique to an organization and contain just ascii characters. This label is
>>> basically a user definable unique ID for the given object. The reason it
>>> was introduced initially was that some of the backend services for katello
>>> could not handle special characters in names (ie. pulp wanted names to be
>>> of a certain format and katello allowed names in any language).
>>>
>>
>> Are the labels still required by back-end services now?
>
> Yes, and in the case of repos they are visible to the user on the client system so having them in a readable format (versus just a random hash/number) was deemed important.

Just curious, what about using hash/number for the url and add human
readable comment or description to the generated repo file as a comment?
Is it even possible to include the comment/description for the repo? (I
think that could (in some far future) simplify the url/path juggling in
pulp and katello.)

>
>>
>>> A side benefit of labels was that internal database row number ids were not
>>> exposed to the user: The ids used via the command line are "human
>>> readable" and sensible.
>>>
>>
>> I would prefer to show only names in CLI, or optionally DB ids. I am not
>> sure where is the benefit of hiding them, Tom?
>
> The labels are alternatives to the db ids. If the tool filled in the labels w/ a db id style (ie. a unique number) then the user wouldn't know or care about the difference, right?

I am not sure what you mean. I am maybe missing some other angle but for
me from a user perspective labels are like "crippled" names. I would
like to see full names as I've put them in the application not the
stripped down labels. If I need abstract representation I would like ids
not labels. I would guess that most of the CLI users will be sysadmins
so they should be comfortable with numerical ids.

>
>>
>>> Another benefit is that an install can be "dumped" and recreated in a new
>>> install with all IDs consistent between the two (since internal database
>>> IDs are not referenced from a user perspective).
>>>
>>
>> I would just ensure that the dump has correct numerical IDs and thath
>> they are imported again correctly. Or maybe I am missing something.
>
> I don't work with dbs that often so assumed that maintaining numerical ids across two dbs would not be easy.

I am probably missing something, but doesn't master-salve replication do
what you are describing?

>
>>
>>> The question is, should we make it a goal for all objects to support labels
>>> instead of internal numeric IDs, removing the IDs from user view?
>>>
>>>
>>
>> Personally I would remove labels if possible or hide them. The main
>> reason is that when the resource is renamed the label stays and is
>> source of confusion. If memorability of numerical IDs is problem, I
>> would replace them with some memorable string representation (like
>> Heroku app names).
>
> Labels are the memorable string representations.

Yes but they have to be filled in. I was thinking more about creating a
function to be able to generate memorable id from db id and vice-versa.

>
> Are there benefits to using actual database row numbers as the exposed id versus another representation like label?

I think less work and complexity. And possibly less confusing since they
do not have meaning so they cannot get outdated.

··· On 24.03.14 17:28, Tom McKay wrote: > ----- Original Message ----- >> On 24.03.14 14:59, Tom McKay wrote:

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

5

this is the real thing for me… Words are much easier to remember then
numbers.

– b
k

··· On 03/24/2014 12:28 PM, Tom McKay wrote: > > ----- Original Message ----- >> > >> >On 24.03.14 14:59, Tom McKay wrote: >>> > > >>> > >Katello has the concept of "labels" on some of its models. A label must be >>> > >unique to an organization and contain just ascii characters. This label is >>> > >basically a user definable unique ID for the given object. The reason it >>> > >was introduced initially was that some of the backend services for katello >>> > >could not handle special characters in names (ie. pulp wanted names to be >>> > >of a certain format and katello allowed names in any language). >>> > > >> > >> >Are the labels still required by back-end services now? > Yes, and in the case of repos they are visible to the user on the client system so having them in a readable format (versus just a random hash/number) was deemed important. > >> > >>> > >A side benefit of labels was that internal database row number ids were not >>> > >exposed to the user: The ids used via the command line are "human >>> > >readable" and sensible. >>> > > >> > >> >I would prefer to show only names in CLI, or optionally DB ids. I am not >> >sure where is the benefit of hiding them, Tom? > The labels are alternatives to the db ids. If the tool filled in the labels w/ a db id style (ie. a unique number) then the user wouldn't know or care about the difference, right? >
6

>
>
>>
>>
>>
>>>
>>>
>>>>
>>>>
>>>> Katello has the concept of "labels" on some of its models. A label must
>>>> be
>>>> unique to an organization and contain just ascii characters. This label
>>>> is
>>>> basically a user definable unique ID for the given object. The reason it
>>>> was introduced initially was that some of the backend services for
>>>> katello
>>>> could not handle special characters in names (ie. pulp wanted names to
>>>> be
>>>> of a certain format and katello allowed names in any language).
>>>>
>>>
>>> Are the labels still required by back-end services now?
>>
>>
>> Yes, and in the case of repos they are visible to the user on the client
>> system so having them in a readable format (versus just a random
>> hash/number) was deemed important.
>
>
> Just curious, what about using hash/number for the url and add human
> readable comment or description to the generated repo file as a comment? Is
> it even possible to include the comment/description for the repo? (I think
> that could (in some far future) simplify the url/path juggling in pulp and
> katello.)
>
>>
>>>
>>>> A side benefit of labels was that internal database row number ids were
>>>> not
>>>> exposed to the user: The ids used via the command line are "human
>>>> readable" and sensible.
>>>>
>>>
>>> I would prefer to show only names in CLI, or optionally DB ids. I am not
>>> sure where is the benefit of hiding them, Tom?
>>
>>
>> The labels are alternatives to the db ids. If the tool filled in the
>> labels w/ a db id style (ie. a unique number) then the user wouldn't know or
>> care about the difference, right?
>
>
> I am not sure what you mean. I am maybe missing some other angle but for me
> from a user perspective labels are like "crippled" names. I would like to
> see full names as I've put them in the application not the stripped down
> labels. If I need abstract representation I would like ids not labels. I
> would guess that most of the CLI users will be sysadmins so they should be
> comfortable with numerical ids.
>
>>
>>>
>>>> Another benefit is that an install can be "dumped" and recreated in a
>>>> new
>>>> install with all IDs consistent between the two (since internal database
>>>> IDs are not referenced from a user perspective).
>>>>
>>>
>>> I would just ensure that the dump has correct numerical IDs and thath
>>> they are imported again correctly. Or maybe I am missing something.
>>
>>
>> I don't work with dbs that often so assumed that maintaining numerical ids
>> across two dbs would not be easy.
>
>
> I am probably missing something, but doesn't master-salve replication do
> what you are describing?
>
>>
>>>
>>>> The question is, should we make it a goal for all objects to support
>>>> labels
>>>> instead of internal numeric IDs, removing the IDs from user view?
>>>>
>>>>
>>>
>>> Personally I would remove labels if possible or hide them. The main
>>> reason is that when the resource is renamed the label stays and is
>>> source of confusion. If memorability of numerical IDs is problem, I
>>> would replace them with some memorable string representation (like
>>> Heroku app names).
>>
>>
>> Labels are the memorable string representations.
>
>
> Yes but they have to be filled in. I was thinking more about creating a
> function to be able to generate memorable id from db id and vice-versa.
>
>>
>> Are there benefits to using actual database row numbers as the exposed id
>> versus another representation like label?
>
>
> I think less work and complexity. And possibly less confusing since they do
> not have meaning so they cannot get outdated.

I agree with Petr's points. User-generated/readable ids are way too
much work. It's pretty easy to replace db ids with uuids if there are
concerns related to resource id uniqueness in a distributed
environment.

-d

··· On Tue, Mar 25, 2014 at 12:57 PM, Petr Chalupa wrote: > On 24.03.14 17:28, Tom McKay wrote: >> ----- Original Message ----- >>> On 24.03.14 14:59, Tom McKay wrote:

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

7

>
>
> >
> >
> >>
> >>>
> >>> Katello has the concept of "labels" on some of its models. A label must
> >>> be
> >>> unique to an organization and contain just ascii characters. This label
> >>> is
> >>> basically a user definable unique ID for the given object. The reason it
> >>> was introduced initially was that some of the backend services for
> >>> katello
> >>> could not handle special characters in names (ie. pulp wanted names to be
> >>> of a certain format and katello allowed names in any language).
> >>>
> >>
> >> Are the labels still required by back-end services now?
> >
> > Yes, and in the case of repos they are visible to the user on the client
> > system so having them in a readable format (versus just a random
> > hash/number) was deemed important.
>
> Just curious, what about using hash/number for the url and add human
> readable comment or description to the generated repo file as a comment?
> Is it even possible to include the comment/description for the repo? (I
> think that could (in some far future) simplify the url/path juggling in
> pulp and katello.)
>
> >
> >>
> >>> A side benefit of labels was that internal database row number ids were
> >>> not
> >>> exposed to the user: The ids used via the command line are "human
> >>> readable" and sensible.
> >>>
> >>
> >> I would prefer to show only names in CLI, or optionally DB ids. I am not
> >> sure where is the benefit of hiding them, Tom?
> >
> > The labels are alternatives to the db ids. If the tool filled in the labels
> > w/ a db id style (ie. a unique number) then the user wouldn't know or care
> > about the difference, right?
>
> I am not sure what you mean. I am maybe missing some other angle but for
> me from a user perspective labels are like "crippled" names. I would
> like to see full names as I've put them in the application not the
> stripped down labels. If I need abstract representation I would like ids
> not labels. I would guess that most of the CLI users will be sysadmins
> so they should be comfortable with numerical ids.
>
> >
> >>
> >>> Another benefit is that an install can be "dumped" and recreated in a new
> >>> install with all IDs consistent between the two (since internal database
> >>> IDs are not referenced from a user perspective).
> >>>
> >>
> >> I would just ensure that the dump has correct numerical IDs and thath
> >> they are imported again correctly. Or maybe I am missing something.
> >
> > I don't work with dbs that often so assumed that maintaining numerical ids
> > across two dbs would not be easy.
>
> I am probably missing something, but doesn't master-salve replication do
> what you are describing?
>
> >
> >>
> >>> The question is, should we make it a goal for all objects to support
> >>> labels
> >>> instead of internal numeric IDs, removing the IDs from user view?
> >>>
> >>>
> >>
> >> Personally I would remove labels if possible or hide them. The main
> >> reason is that when the resource is renamed the label stays and is
> >> source of confusion. If memorability of numerical IDs is problem, I
> >> would replace them with some memorable string representation (like
> >> Heroku app names).
> >
> > Labels are the memorable string representations.
>
> Yes but they have to be filled in. I was thinking more about creating a
> function to be able to generate memorable id from db id and vice-versa.

Labels are auto-suggested in the UI as the object names are typed so most times there is no need for user to override the suggested unless they have a specific desire. Languages with a different character set (Japanese, Chinese, etc.) get a number label suggested.

··· ----- Original Message ----- > On 24.03.14 17:28, Tom McKay wrote: > > ----- Original Message ----- > >> On 24.03.14 14:59, Tom McKay wrote:

Are there benefits to using actual database row numbers as the exposed id
versus another representation like label?

I think less work and complexity. And possibly less confusing since they
do not have meaning so they cannot get outdated.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

8

>>
>>
>>>
>>> >
>>>>
>>>> > >
>>>> > >Katello has the concept of "labels" on some of its models. A label
>>>> > > must be
>>>> > >unique to an organization and contain just ascii characters. This
>>>> > > label is
>>>> > >basically a user definable unique ID for the given object. The reason
>>>> > > it
>>>> > >was introduced initially was that some of the backend services for
>>>> > > katello
>>>> > >could not handle special characters in names (ie. pulp wanted names
>>>> > > to be
>>>> > >of a certain format and katello allowed names in any language).
>>>> > >
>>>
>>> >
>>> >Are the labels still required by back-end services now?
>>
>> Yes, and in the case of repos they are visible to the user on the client
>> system so having them in a readable format (versus just a random
>> hash/number) was deemed important.
>>
>>> >
>>>>
>>>> > >A side benefit of labels was that internal database row number ids
>>>> > > were not
>>>> > >exposed to the user: The ids used via the command line are "human
>>>> > >readable" and sensible.
>>>> > >
>>>
>>> >
>>> >I would prefer to show only names in CLI, or optionally DB ids. I am not
>>> >sure where is the benefit of hiding them, Tom?
>>
>> The labels are alternatives to the db ids. If the tool filled in the
>> labels w/ a db id style (ie. a unique number) then the user wouldn't know or
>> care about the difference, right?
>>
>
>
> this is the real thing for me… Words are much easier to remember then
> numbers.
>
> – b

I don't think it has to be a hard choice, but rather a change in
semantics: human readable ids (labels, names, etc) could be used in
operations with search semantics, and db ids (uuids) for "get"
semantics. This has a potential of getting rid duplicate information
(such as labels), clean up API, deal with stuff like labels getting
out of sync with resource names (or handling of renames), etc, etc.

-d

··· On Tue, Mar 25, 2014 at 7:06 PM, Bryan Kearney wrote: > On 03/24/2014 12:28 PM, Tom McKay wrote: >> ----- Original Message ----- >>> >On 24.03.14 14:59, Tom McKay wrote:

k

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

9

>>>
>>>>>
>>>>>>> Katello has the concept of "labels" on some of its models. A label
>>>>>>> must be
>>>>>>> unique to an organization and contain just ascii characters. This
>>>>>>> label is
>>>>>>> basically a user definable unique ID for the given object. The reason
>>>>>>> it
>>>>>>> was introduced initially was that some of the backend services for
>>>>>>> katello
>>>>>>> could not handle special characters in names (ie. pulp wanted names
>>>>>>> to be
>>>>>>> of a certain format and katello allowed names in any language).
>>>>>>>
>>>>> Are the labels still required by back-end services now?
>>> Yes, and in the case of repos they are visible to the user on the client
>>> system so having them in a readable format (versus just a random
>>> hash/number) was deemed important.
>>>
>>>>>
>>>>>>> A side benefit of labels was that internal database row number ids
>>>>>>> were not
>>>>>>> exposed to the user: The ids used via the command line are "human
>>>>>>> readable" and sensible.
>>>>>>>
>>>>> I would prefer to show only names in CLI, or optionally DB ids. I am not
>>>>> sure where is the benefit of hiding them, Tom?
>>> The labels are alternatives to the db ids. If the tool filled in the
>>> labels w/ a db id style (ie. a unique number) then the user wouldn't know or
>>> care about the difference, right?
>>>
>>
>> this is the real thing for me… Words are much easier to remember then
>> numbers.
>>
>> – b
> I don't think it has to be a hard choice, but rather a change in
> semantics: human readable ids (labels, names, etc) could be used in
> operations with search semantics, and db ids (uuids) for "get"
> semantics. This has a potential of getting rid duplicate information
> (such as labels), clean up API, deal with stuff like labels getting
> out of sync with resource names (or handling of renames), etc, etc.
>
> -d
>
I think most are aware, but if not, the labels in katello follow some
pretty basic rules:

  1. The user may enter a label when creating an object (e.g
    org/env/product/repo/content view…etc),
    if they desire. When doing so, the label must consist of
    alphanumerics, '_' or '-'.
    (e.g. label="My_Org")

  2. If the user chooses not to provide a label, one is auto-generated as
    part of object creation.
    2a. If the name is ascii and can be translated using the rule from
    1, it will be human readable
    (e.g. name="My Org" becomes label="My_Org")
    2b. If the name cannot be directly translated to a label (e.g.
    multi-byte), then a UUID is assigned.
    (e.g. name="Funções" becomes label="
    650a8400-c89b-41d4-a716-446655440000")

So, from a user's point of view, they aren't too inconvenienced by
having to assign labels,
unless they fall in the category of a multi-byte user and they want
readability in the label.
At that point, it is their choice.

thanks,
Brad

··· On 03/25/2014 03:40 PM, Dmitri Dolguikh wrote: > On Tue, Mar 25, 2014 at 7:06 PM, Bryan Kearney wrote: >> On 03/24/2014 12:28 PM, Tom McKay wrote: >>> ----- Original Message ----- >>>>> On 24.03.14 14:59, Tom McKay wrote: >> k >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout.