Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

osd_df and cluster_df methods #32

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

osd_df and cluster_df methods #32

wants to merge 5 commits into from

Conversation

oms4suse
Copy link
Owner

@oms4suse oms4suse commented Sep 5, 2016

We want osd_df and cluster_df methods to allow us to check if the cluster is empty when removing osd's

We need a place for storing the output of 'ceph osd df'

Signed-off-by: Owen Synge <osynge@suse.com>
User output of 'ceph osd df'

Signed-off-by: Owen Synge <osynge@suse.com>
Present sanitised output of 'ceph osd df' to model

Signed-off-by: Owen Synge <osynge@suse.com>
Present sanitised output of 'ceph osd df' to user

Signed-off-by: Owen Synge <osynge@suse.com>
Present sanitised output of 'ceph osd df' to user

Signed-off-by: Owen Synge <osynge@suse.com>
@oms4suse oms4suse mentioned this pull request Sep 7, 2016
osd_pgs = node.get("pgs")
osd_utilization = node.get("utilization")
return {
"id" : osd_id,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do the temporary variables make sense? You could either directly construct it in the return statement ("id" : node.get("id")) or iterate over a set of keywords and build it up like that? Or use a list comprehension maybe? http://stackoverflow.com/questions/1747817/create-a-dictionary-with-list-comprehension-in-python

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Temporary variables provide little advantage without error checking for None. The only real advantage is code clarity.

As for list comprehension, This would make sense if the input and output fields where identical.

I felt that particularly "crush_weight" was more ceph implementation specific, and "weight_crush" being presented to the user (and stored in the model) was easier to understand since it would (in default representation of json by python it is sorted alphabetically) be next to "crush_weight".

Which would you prefer?

I add a comment explaining the rational, or move to list comprehension?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd think that sticking to the ceph naming would probably be easier to understand, even if it is not the naming I'd have chosen (because then we're consistent with how ceph calls things and users don't have to remember multiple naming schemes).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agree, either directly construct in return statement or list comprehension/dict comprehension if keys stay the same. Direct construction would make key change obvious enough I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants