On Wed, 12 Mar 2014, John Spray wrote: > 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 order would have to switch, like so: osd set ruleset-properties <ruleset> <key>=<val> [<key>=<val>...] osd pool create mypool <pgnum> <pgpnum> <ruleset> because the parameters need to be specified with the pool to determine even basic stuff like the size. The problem with this is that the erasure properties are generally immutable, but it is important to retain the ability to change rules for an existing pool. Would the 'set ruleset' command fail if the properties don't match? Actually, there are some cases where an expert user ought to be able to adjust the properties (swtiching between byte-compatible plugins, for instance), but other values like m and k obviously are fixed. So I think there needs to be an 'expert' or 'force' mode that lets you shoot yourself in the foot, but I don't want that as part of the normal command flow if possible. That said, I can imagine a convenience command that creates a ruleset with the given set of properties in one step (probably matching and reusing an existing set of properties if the exist). It's a more complicated interface, yes, but it still feels like the right set of abstractions. :/ sage > > 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 > >
