I am sure all of that will work, but it doesn't explain why these properties must be stored and named separately to crush rulesets. To flesh this out one also needs "get" and "list" operations for the sets of properties, which feels like overkill if there is an existing place we could be storing these things. The reason I'm taking such an interest in what may seem something minor is that once this has been added, we will be stuck with it for some time once external tools start depending on the interface. The ruleset-based approach doesn't have to be more complicated for CLI users, we would essentially replace any "myproperties" above with a ruleset name instead. osd pool create mypool <pgnum> <pgpnum> <ruleset> osd set ruleset-properties <ruleset> <key>=<val> [<key>=<val>...] The simple default cases of "pool create mypool <pgnum> <pgpnum> erasure" could be handled by making sure there exist default rulesets called "erasure" and "replicated" rather than having these be magic words to the commands that cause ruleset creation. Rulesets currently just have numbers instead of names, but it would be simpler to add names to rulesets than to introduce a whole new type of object to the interface. John On Tue, Mar 11, 2014 at 2:03 PM, Loic Dachary <loic.dachary@xxxxxxxxxxxxx> wrote: > On 11/03/2014 13:21, John Spray wrote: >> From a high level view, what is the logical difference between the >> crush ruleset and the properties object? I'm thinking about how this >> is exposed to users and tools, and it seems like both would be defined >> as "the settings about data placement and encoding". I certainly >> understand the separation internally, I am just concerned about making >> the interface we expose upwards more complicated by adding a new type >> of object. >> >> Is there really a need for a new type of properties object, instead of >> storing these properties under the existing ruleset ID? > These properties are used to configure the new feature that was introduced in Firefly : erasure coded pools. From a user point of view the simplest would be to > > ceph osd pool create mypool erasure > > and rely on the fact that a default ruleset will be created using the default erasure code plugin with the default parameters. > > If the sysadmin wants to tweak the K+M factors (s)he could: > > ceph osd set properties myproperties k=10 m=4 > > and then > > ceph osd pool create mypool erasure myproperties > > which would implicitly ask the default erasure code plugin to create a ruleset named "mypool-ruleset" after configuring it with myproperties. > > If the sysadmin wants to share rulesets between pools instead of relying on their implicit creation, (s)he could > > ceph osd create-serasure myruleset myproperties > > and then ceph osd set crush_ruleset as per usual. And if (s)he really wants fine tuning, manually adding the ruleset is also possible. > > I feel confortable explaining this but I'm probably much too familiar with the subject to be a good judge of what makes sense to someone new or not ;-) > > Cheers > >> >> John >> >> >> On Sun, Mar 9, 2014 at 12:13 PM, Loic Dachary >> <loic.dachary@xxxxxxxxxxxxx> wrote: >>> Hi Sage & Sam, >>> >>> I quickly sketched the replacement of the pg_pool_t::properties map with a OSDMap::properties list of maps at https://github.com/dachary/ceph/commit/fe3819a62eb139fc3f0fa4282b4d22aecd8cd398 and explained how I see it at http://tracker.ceph.com/issues/7662#note-2 >>> >>> It indeed makes things simpler, more consistent and easier to explain. I can provide an implementation this week if this seems reasonable to you. >>> >>> Cheers >>> >>> -- >>> Loďc Dachary, Senior Developer >>> >>> -- >>> 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 > > > -- > Loïc Dachary, Senior Developer > -- 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
