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
Attachment:
signature.asc
Description: OpenPGP digital signature
