Bug 1194022

Alfredo, master of usability, what say you?

This is how the output looks for Ceph version 0.80.9 (minus logging which I have no idea why I was getting it):

$ sudo ceph osd crush show-tunables
{ "choose_local_tries": 0,
  "choose_local_fallback_tries": 0,
  "choose_total_tries": 50,
  "chooseleaf_descend_once": 1,
  "chooseleaf_vary_r": 0,
  "straw_calc_version": 1,
  "profile": "unknown",
  "optimal_tunables": 0,
  "legacy_tunables": 0,
  "require_feature_tunables": 1,
  "require_feature_tunables2": 1,
  "require_feature_tunables3": 0,
  "has_v2_rules": 0,
  "has_v3_rules": 0}

------------------

It looks like unformatted JSON output which is OK for machine consumption but not for readability.

A nice tabular representation with the profile as the title with Tupper's recommendation would be much better.

Since we would be returning a text representation of the JSON output, we would also be able to add more prose if needed that would be difficult (or just not possible) with JSON output.
That output is *beyond* confusing. We should get rid of all those log messages that do not belong in the output of for the command.

I'm not clear on what it would take to fix this bug. It sounds like we need some doc improvements, and some "ceph osd crush show-tunables" output improvements?

Interpreting icolle's set of release flag to "+" mean "+" for devel ack

Nevermind... I see what happened. Resetting.

Will this bug be fixed via code change or doc change or both? Please clarify. Also, please share the expected output if the fix is going to be in code.

Please refer to my comment 7 and provide the details requested there so i can ACK this bug.

I wasn't aware this bug was assigned to me until today.  I have no plans or design.

Reviewing the code that creates the lists briefly, it's not as simple as all that; the tunables are both individually settable (either by tunable
keywords in the crush map source or with an osd crush tunables command)
and settable as a lump (osd crush tunables only).  The output indicates whether the tunables exactly match the ones set by the 'group' name.  As I understand it, the main source of confusion is that multiple tests can match the set tunables, but only the first match is output as 'profile'.

I guess I would personally prefer to have "profile" multivalued, outputting all matching profiles rather than, apparently, just the first one tested.  If we did that, we could potentially roll up the idea of 'optimal' and 'legacy' into that same list.  It's still a bit opaque, as the question of "what exactly does optimal mean" isn't queryable either.

Separately, the JSON output, and its lack of sorting, is common to many Ceph commands, so I don't think it should change.  We could address this with a non-JSON form of the command, specified by "ceph osd crush show-tunables --format=plain" (since we can't change the default 'output JSON' form of the existing command without breaking backward compatibility).

What say you, BZ universe?

Hi Dan,

Will this be fixed in 1.3.1?

Can you please provide the steps and expected cli output to test this fix?

Regards,
Harish

Dan,

Can you please change the Target Release for this defect if it's not going to be fixed in 1.3.1?

Regards,
Harish

(In reply to Harish NV Rao from comment #12)
> Can you please change the Target Release for this defect if it's not going
> to be fixed in 1.3.1?

Changed :)

Dan's listed two code improvements here (comment #10):

    1. Make "profile" multivalued
    2. Introduce a "--format=plain" option

Tupper, will these suggestions work for you?

Dan can you please file bug(s) upstream at tracker.ceph.com to track these features, if they are not already implemented for Jewel?

I haven't made anything like a plan to do this; I've gotten no feedback at all from Tupper, so am considering this stalled until I get any kind of answer...

A long time with no update; I'm assuming this is no longer desired.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days