On Wed, 12 Mar 2014, John Spray wrote: > OK, in chatting about this I've been convinced that it's legitimately > separate, because the CRUSH ruleset is mutable during the lifetime of > a pool but the EC settings are not. I suppose the way we could > explain the logical separation for users is to say that the CRUSH > ruleset is mainly about location selection, whereas the EC settings > tell you about encoding within those locations. > > Can we call this something more descriptive like "EC profile" to avoid > confusion? "properties" is very generic. Yeah, I like 'ec profile' better than 'properties'. sage > > Cheers, > John > > > > On Wed, Mar 12, 2014 at 1:10 PM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > > On 12/03/2014 13:39, 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 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. > > Here are the default parameters > > > > OPTION(osd_pool_default_erasure_code_properties, > > OPT_STR, > > "erasure-code-plugin=jerasure " > > "erasure-code-technique=reed_sol_van " > > "erasure-code-k=4 " > > "erasure-code-m=2 " > > ) // default properties of osd pool create > > > > The k and m parameters have a clear relationship with the pool size. And they also define the minimum number of items the crush ruleset must be able to provide. The other parameters relate to the code/decode functions and are better understood in the context of the OSD than crush. This is the reason why I don't see these properties as being exclusively linked to the crush ruleset or the OSD. By introducing a new set of properties associated to the erasure code feature there is no need to chose. > > > > Does that make sense ? > >> > >> 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 > >>> > > > > > > -- > > Loïc Dachary, Artisan Logiciel Libre > > > > > -- > 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 > >
