g_conf.id, g_conf.name, g_conf.type and friends

g_conf.id, g_conf.name, g_conf.type and friends

[Colin Patrick McCabe]

So I'm trying to reorganize the common_init code a little bit, in
preparation for tackling issue #815.
I noticed there is a little bit of confusion about g_conf.id,
g_conf.name, g_conf.type, and g_conf.entity_name.
Here is my take on it.

*** g_conf.id: this is a username or a daemon name, depending on the program.
It defaults to "admin" for our various command-line tools, but can be
changed by the -i command-line argument.
For an MDS, this would be "a" or "b", or similar.

*** g_conf.type: nobody seems to know what this is.
It seems like at one point, g_conf.type was intended to be one of
"auth", "mon", "osd", "mds", or "client".

However, over time, the code has drifted away from this, and
g_conf.type usually ends up being the program name.
There are also some code paths that could lead to it being an empty string.

A quick search for "g_conf.type" in the code reveals only two uses:
1. variable expansion of $type in ceph_config
2. used to calculate logfile symlink names

*** g_conf.name: created out of g_conf.type and g_conf.id

*** g_conf.entity_name: seems to be sort of a parsed version of the
preceding variables. g_conf.entity_name actually gets used and seems
to be correct.

Questions:
* Do we even need g_conf.name any more? We could just call
g_conf.entity_name.to_str() and get the same thing. (Actually, a
better thing.)
* Should we rename g_conf.type to g_conf.program_name? Program name is
a clear and unambiguous concept; what we have now is not useful.
* Should $type expand out to ceph_entity_type_name(g_conf.entity_name.type)?
In practice, this would bring us back to $type being "auth", "mon",
"osd", "mds", or "client", etc. again. This seems to be the original
intention of the system.
* Allowing users to set id is great. Allowing them to set the program
type seems wrong. Yet there is some evil code lurking in there that
parses the id parameter and tries to use it to set g_conf.type.

Colin

Re: g_conf.id, g_conf.name, g_conf.type and friends

[Tommi Virtanen]

On Wed, Feb 23, 2011 at 01:58:19PM -0800, Colin Patrick McCabe wrote:
> *** g_conf.id: this is a username or a daemon name, depending on the program.
> It defaults to "admin" for our various command-line tools, but can be
> changed by the -i command-line argument.
> For an MDS, this would be "a" or "b", or similar.

Noob question: why not 0, 1, ..?

> *** g_conf.type: nobody seems to know what this is.
> It seems like at one point, g_conf.type was intended to be one of
> "auth", "mon", "osd", "mds", or "client".

This seems to be tied to cconf's use of "type" as in sections "osd0"
and "osd.0" are both type=osd, id=0. So, it soudns to be like it's
there mostly to get around the fact that config section names are not
predictable.

-- 
:(){ :|:&};:

Re: g_conf.id, g_conf.name, g_conf.type and friends

[Colin Patrick McCabe]

On Wed, Feb 23, 2011 at 2:13 PM, Tommi Virtanen
<tommi.virtanen@dreamhost.com> wrote:
> On Wed, Feb 23, 2011 at 01:58:19PM -0800, Colin Patrick McCabe wrote:
>> *** g_conf.id: this is a username or a daemon name, depending on the program.
>> It defaults to "admin" for our various command-line tools, but can be
>> changed by the -i command-line argument.
>> For an MDS, this would be "a" or "b", or similar.
>
> Noob question: why not 0, 1, ..?

You're not the only one to ask why OSDs are osd.0, osd.1, etc.,
whereas MDSes are mds.a, mds.b, etc. I think the reasons are
historical.

>
>> *** g_conf.type: nobody seems to know what this is.
>> It seems like at one point, g_conf.type was intended to be one of
>> "auth", "mon", "osd", "mds", or "client".
>
> This seems to be tied to cconf's use of "type" as in sections "osd0"
> and "osd.0" are both type=osd, id=0. So, it soudns to be like it's
> there mostly to get around the fact that config section names are not
> predictable.

When filling out a configuration section for the first OSD, you can
use either "osd.0" or "osd0" as the section name.

This is kind of an obscure configuration quirk, though. My point was
that g_conf.type is redundant since we have the same info in a nicely
parsed form in g_conf.entity_name. (There's no reason we can't
continue to support the quirky no-period syntax either.)

Colin

Re: g_conf.id, g_conf.name, g_conf.type and friends

[Tommi Virtanen]

On Wed, Feb 23, 2011 at 02:13:53PM -0800, Tommi Virtanen wrote:
> > *** g_conf.type: nobody seems to know what this is.
> > It seems like at one point, g_conf.type was intended to be one of
> > "auth", "mon", "osd", "mds", or "client".
> 
> This seems to be tied to cconf's use of "type" as in sections "osd0"
> and "osd.0" are both type=osd, id=0. So, it soudns to be like it's
> there mostly to get around the fact that config section names are not
> predictable.

On a related note, this was fairly frustrating to debug:

$ cauthtool --create-keyring --gen-key --name=foo.42 test
creating test
$ cat test
[client.42]
	key = AQCBiWVNuCl4ABAAJjvKiiQvtksfOJtJV8sR9A==
	auid = 18446744073709551615

I hate it when programs silently ignore what I explicitly tell them to
do. cauthtool ignores --name= if it doesn't fit it's expectations.
Why aren't the key names just unique strings?

-- 
:(){ :|:&};:

Re: g_conf.id, g_conf.name, g_conf.type and friends

[Sage Weil]

On Wed, 23 Feb 2011, Colin Patrick McCabe wrote:
> On Wed, Feb 23, 2011 at 2:13 PM, Tommi Virtanen
> <tommi.virtanen@dreamhost.com> wrote:
> > On Wed, Feb 23, 2011 at 01:58:19PM -0800, Colin Patrick McCabe wrote:
> >> *** g_conf.id: this is a username or a daemon name, depending on the program.
> >> It defaults to "admin" for our various command-line tools, but can be
> >> changed by the -i command-line argument.
> >> For an MDS, this would be "a" or "b", or similar.
> >
> > Noob question: why not 0, 1, ..?
> 
> You're not the only one to ask why OSDs are osd.0, osd.1, etc.,
> whereas MDSes are mds.a, mds.b, etc. I think the reasons are
> historical.

The MDS ranks are internally numbered and tracked that way, so that a 
simple int represents who owns what.  However, which rank/role and MDS 
fills is different than the MDS identify (which host/instance of the 
daemon), as any daemon can fill any role.  Hence the alphanumerical names.

Same goes for monitors.

For OSDs, things are a bit different, since a cosd daemon can only fill 
the role for which it actually has the data.  Alphanumeric names might be 
nice for an admin, but that's all they'd accomplish.

> This is kind of an obscure configuration quirk, though. My point was
> that g_conf.type is redundant since we have the same info in a nicely
> parsed form in g_conf.entity_name. (There's no reason we can't
> continue to support the quirky no-period syntax either.)

Yeah, I think can you safely clean that up.  Unless it's needed right now, 
though, let's push it off for the 0.26 branch so that we have plenty of 
time to catch any weird fallout.  (Same goes for anything else that isn't 
needed to get the librados API changes in place and functional.)

sage

Re: g_conf.id, g_conf.name, g_conf.type and friends

[Yehuda Sadeh Weinraub]

On Wed, Feb 23, 2011 at 1:58 PM, Colin Patrick McCabe
<colin.mccabe@dreamhost.com> wrote:
>
> Questions:
> * Do we even need g_conf.name any more? We could just call
> g_conf.entity_name.to_str() and get the same thing. (Actually, a
> better thing.)

Yeah, we can either remove it completely or just set it to be the
result of g_con.entity_name.to_str()

> * Should we rename g_conf.type to g_conf.program_name? Program name is
> a clear and unambiguous concept; what we have now is not useful.
> * Should $type expand out to ceph_entity_type_name(g_conf.entity_name.type)?
> In practice, this would bring us back to $type being "auth", "mon",
> "osd", "mds", or "client", etc. again. This seems to be the original
> intention of the system.

I don't think we need g_conf.type anyway.

> * Allowing users to set id is great. Allowing them to set the program
> type seems wrong. Yet there is some evil code lurking in there that
> parses the id parameter and tries to use it to set g_conf.type.
>

I don't see the point of preventing users from changing the type. It
doesn't solve any security issue, and as long as they don't have a key
to match the program type (when cephx is used) it won't help them
much.

Yehuda