On Tue, Apr 24, 2018 at 12:27 AM, Wyllys Ingersoll <wyllys.ingersoll@xxxxxxxxxxxxxx> wrote: > In Luminous the "config help" command (on a monitor socket) displays > about 1400 different config variables along with their descriptions, > defaults, etc. But, the "safe" field which is part of the Option > object for some reason is not included in that output. Mimic appears > to show the "safeness" boolean in the detailed list (I havent tested > it, just looking at the code). Not sure why it was omitted from > earlier releases. The thing that makes this awkward is that the schema can't automatically know how options are really being used in the code. If there is a class somewhere that takes a setting at construction time, and then ignores it, then no matter how safe it is to update at runtime, it will in practice require a service restart. To actually document this stuff requires an expert human to do a pass through all the code where settings are used. The can_update_at_runtime indicator in mimic is not telling you that services will necessarily respect the new value, just that it is possible to set it at runtime (internally, we have a legacy unlocked structure that is accessed unlocked, so runtime updates to strings are unsafe by default). > It would be nice to have a tabular output (or web page) showing *all* > of the options somewhere for reference. The current documentation > only describes a small fraction of them. This part is much easier -- it was one of the intended uses for the new(ish) option schema. It can be included in the docs build pretty easily by building a little helper utility that dumps out the schema, and then calling that from sphinx with a little python extension (it would mean the docs build would depend on a C++ compiler but that's not a big deal in practice). Any volunteers? John > > > > > > > On Mon, Apr 23, 2018 at 5:33 PM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: >> On Mon, Apr 23, 2018 at 7:49 AM, Wyllys Ingersoll >> <wyllys.ingersoll@xxxxxxxxxxxxxx> wrote: >>> Is there a definitive list anywhere of the config variables that are >>> "injectable" for a running service vs those that require a restart? >> >> If there were, we wouldn't have that deliberately-imprecise phrasing >> about "may not" have taken effect. :/ >> Eventually, hopefully, each injectable argument will be marked that >> way and we'll make an explicit flag that needs to be set when you >> create a new config option. But that's not the world today. >> -Greg >> >>> >>> thanks, >>> Wyllys Ingersoll >>> Keeper Technology, LLC >>> -- >>> 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 -- 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
