-
Notifications
You must be signed in to change notification settings - Fork 12
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
base: master
Are you sure you want to change the base?
Conversation
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>
osd_pgs = node.get("pgs") | ||
osd_utilization = node.get("utilization") | ||
return { | ||
"id" : osd_id, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
We want osd_df and cluster_df methods to allow us to check if the cluster is empty when removing osd's