On Fri, Jan 12, 2018 at 3:56 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Fri, 12 Jan 2018, Gregory Farnum wrote: >> The rest looks good, but I don't understand this thing about "RO" >> values at all. Based on what's here, it represents options that aren't >> live yet, but will be on reboot? > > These are options that can't change at runtime, so they need a daemon > restart. (Or, in some cases, they only matter at osd or cluster creation > time.) In reality, we have an enum of (cluster_create, daemon_create, > startup, runtime) for each option for when it can take effect. > Generally the question for the user, though, is "can i set this value > now and have it take effect". If it's flagged as RO, then they can set it > via the mon, but then 'config show' will then show 'mon' under IGNORES > because it's something we can't change at runtime. It would be nice to throw Error during set command, because it would let admin/user know it didn't work, A silent return in my view is still confusing and not many would understand to rerun show and check mon.a advanced ms_type simple * > >> On Thu, Jan 11, 2018 at 1:21 PM, Sage Weil <sage@xxxxxxxxxx> wrote: >> > gnit:build (wip-config) 02:48 PM $ bin/ceph config show mon.a >> > NAME VALUE SOURCE OVERRIDES IGNORES > ... >> > ms_type async+posix default mon > ... >> > >> > (sorry for the wide table) >> > >> > A few things to note: SOURCE can be any of default, file, mon, env, >> > cmdline, or override. You'll notice that ms_type SOURCE is 'default' and >> > IGNORES is 'mon', because the daemon is ignoring the mon value--this >> > option can only be set during startup. >> >> I also don't get how one mon having a different setting means that all >> mons are marked as ignoring it. > > This is saying that 'mon.a' (who we just 'show'ed) is ignoring the > mon-managed config. If mon.b was restarted and we did a show it would... > well it would also say the same thing since mon's don't fetch the > mon-stored config before startup. (Not sure if we should implement that > or not.) > > Is that what you're asking? > >> Putting them right next to each other also makes it clear in my mind >> that people are going to be confused about "config get" versus "config >> show". Perhaps it should be "get_stored" and "show_running" or >> something? I don't like those names, but they need to be clearer. > > I don't really like 'show' either. 'show-running'? 'running'? I like > 'get' though. > >> And now I've got a new feature request: a command that outputs the >> difference between those two. Or perhaps that goes through *all* the >> configs and dumps any daemons whose running config differs from their >> stored ones. > > 'show' already shows you this information via the OVERRIDES and IGNORES > columns. > > Oh, you mean that shows *only* the mismatch for the daemon or > cluster... > > sage > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
