-
Notifications
You must be signed in to change notification settings - Fork 12
osd_df and cluster_df methods #32
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
base: master
Are you sure you want to change the base?
Changes from all commits
6a71648
69fd270
4b7b68e
a1b66e5
a8b1f0c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,6 +3,16 @@ | |
| log = logging.getLogger(__name__) | ||
|
|
||
|
|
||
| class Error(Exception): | ||
| """ | ||
| Error | ||
| """ | ||
|
|
||
| def __str__(self): | ||
| doc = self.__doc__.strip() | ||
| return ': '.join([doc] + [str(a) for a in self.args]) | ||
|
|
||
|
|
||
| class mdl_presentor(): | ||
| """ | ||
| Since presentation should be clean to the end user | ||
|
|
@@ -349,3 +359,29 @@ def ceph_version(self): | |
|
|
||
| def cephfs_list(self): | ||
| return self.model.cephfs_list | ||
|
|
||
|
|
||
| def df_osd(self, osd_number): | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This function is called in exactly one place, and besides the error checking has exactly two lines of data mangling. Does it make sense to fold into the calling place? (Also, osd_df calling df_osd is slightly confusing naming scheme ...)
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Main rational is I wanted to put all functions presenting to the user the model data structures in one place. Since I had already mangled the ceph output this operation became trivial. The only reason for this code is consistency. |
||
| if self.model.cluster_df is None: | ||
| msg = "Programming error : self.model.cluster_df is None" | ||
| log.error(msg) | ||
| raise(msg) | ||
| osd_details = self.model.cluster_df.get("osd") | ||
| if osd_details is None: | ||
| msg = "Programming error : self.model.cluster_df[osd] is None" | ||
| log.error(msg) | ||
| raise(msg) | ||
| details = osd_details.get(osd_number) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this get the stats for all OSDs? Is that costly for a single lookup?
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes it does stats for all OSD's. I am not sure how expensive it it. I had not really thought about cost here as I wanted to focus on functionality. It might be better to use another call for osd fullness in osd removal. I can list PG by OSD for a less costly operation. For admin though I see utility in providing a call to do this for inspection. |
||
| if details is None: | ||
| msg = "Osd '{number}' not found".format(number=osd_number) | ||
| log.error(msg) | ||
| raise(msg) | ||
| return details | ||
|
|
||
|
|
||
| def df(self): | ||
| if self.model.cluster_df is None: | ||
| msg = "Programming error : self.model.cluster_df is None" | ||
| log.error(msg) | ||
| raise(msg) | ||
| return self.model.cluster_df | ||
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.