mgr/dashboard_v2: Pool controller

[rjfd]

This PR implements the pool controller that can be used to retrive OSD pools info.

Two endpoints are enabled by this controller: /api/pool and /api/pool/<pool_name>

The endpoints support two parameters:

• attrs: comma separated list of pool info attributes (to filter which attributes should be returned)
• stats: boolean (to include pools stats in the response)

Example:

curl -H "Content-Type: application/json" -X GET  http://localhost:43216/api/pool/cephfs_metadata_a\?stats\=true\&attrs\=type,stats | jq

{
  "stats": {
    "quota_objects": {
      "series": [
        [
          1520614275.325569,
          0
        ]
      ],
      "rate": 0,
      "latest": 0
    },
    "bytes_used": {
      "series": [
        [
          1520614275.325569,
          2246
        ]
      ],
      "rate": 0,
      "latest": 2246
    },
    "max_avail": {
      "series": [
        [
          1520614275.325569,
          9554860032
        ]
      ],
      "rate": 0,
      "latest": 9554860032
    },
    # ...
  },
  "type": "replicated",
  "pool_name": "cephfs_metadata_a"
}

Signed-off-by: Ricardo Dias rdias@suse.com

[rjfd]

dashboard QA suite ran successfully:
http://pulpito.ceph.com/kchai-2018-03-12_09:20:19-rados-wip-rdias-testing-distro-basic-mira/

[sebastian-philipp]

This is quite incomplete. We're missing info that we right now display in oA

[rjfd]

@sebastian-philipp could you be more specific?

I don't know what missing information you are talking about, but the current information returned is enough for what dashboard is showing in the frontend, and addresses the requirements for the RBD management feature.
If future frontend features require information that is missing from this controller, then they just need to add it.

[sebastian-philipp]

I don't know what missing information you are talking about

When looking at http://demo.openattic.org/openattic/ we're missing

• erasure_code_profile
• application_metadata
• pg_num
• size
• type
• crush_ruleset
• compression_mode

the current information returned is enough for what dashboard is showing in the frontend, and will require for the RBD management feature.

Exactly. But not for replacing the Pool view.

If future frontend features require information that is missing from this controller, then they just need to
add it.

+1

[LenzGr]

I think it's fine to get this initial implementation ready for merging, so the basic infrastructure and code path is in place. Afterwards, let's look into adding the missing information that gets us in par with the functionality provided by openATTIC.

[ricardoasmarques]

I agree with @LenzGr.

This PR provides the necessary information to implement the RBD form, Pool form will be done latter.

[rjfd]

@sebastian-philipp

we're missing erasure_code_profile

Actually the information returned in this implementation also returns the erasure_code_profile:

Example of output for an erasure-code pool:

$ curl -H "Content-Type: application/json" -X GET  http://localhost:43247/api/pool/rbd_ec | jq
{
  "cache_target_full_ratio_micro": 800000,
  "fast_read": false,
  "stripe_width": 8192,
  "flags_names": "hashpspool,ec_overwrites",
  "tier_of": -1,
  "hit_set_grade_decay_rate": 0,
  "pg_placement_num": 10,
  "use_gmt_hitset": true,
  "last_force_op_resend_preluminous": "0",
  "quota_max_bytes": 0,
  "erasure_code_profile": "default",
  "expected_num_objects": 0,
  "size": 3,
  "snap_seq": 0,
  "auid": 0,
  "cache_min_flush_age": 0,
  "hit_set_period": 0,
  "min_read_recency_for_promote": 0,
  "target_max_objects": 0,
  "pg_num": 10,
  "type": 3,
  "grade_table": [],
  "pool_name": "rbd_ec",
  "cache_min_evict_age": 0,
  "snap_mode": "selfmanaged",
  "cache_mode": "none",
  "min_size": 3,
  "cache_target_dirty_high_ratio_micro": 600000,
  "object_hash": 2,
  "application_metadata": {
    "rbd": {}
  },
  "write_tier": -1,
  "cache_target_dirty_ratio_micro": 400000,
  "pool": 14,
  "removed_snaps": "[]",
  "crush_rule": 1,
  "tiers": [],
  "hit_set_params": {
    "type": "none"
  },
  "last_force_op_resend": "0",
  "pool_snaps": [],
  "quota_max_objects": 0,
  "options": {},
  "hit_set_count": 0,
  "flags": 5,
  "target_max_bytes": 0,
  "snap_epoch": 0,
  "hit_set_search_last_n": 0,
  "last_change": "72",
  "min_write_recency_for_promote": 0,
  "read_tier": -1
}

Exactly. But not for replacing the Pool view.

The purpose of this PR is not a replacement of the oA Pool view, but rather to add the infrastructure for dashboard future features.

[ricardoasmarques]

This PR is working well when integrated with the RBD form that I'm working on.

[sebastian-philipp]

Either s/PoolController/Pool/ or we should add the Controller postfix to all controllers.

[sebastian-philipp]

@staticmethod? You don't use cls here.

[rjfd]

@sebastian-philipp addressed your comments.