hotsos/core: add name aliasing support #929
Conversation
xmkg
force-pushed
the
feature/alias
branch
2 times, most recently
from
af813d6
to
403c38c
Compare
xmkg
force-pushed
the
feature/alias
branch
3 times, most recently
from
c4a9496
to
ddc4d2a
Compare
There was a problem hiding this comment.
The aliasing naming seems a bit odd to me. For example, juju.base, kernel.calltrace, ceph.daemon.all-osds and so on give the impression it's a package/class hierarchy when they are just a given name.
Given we could mix with the original way of writing/accessing the properties, the use of dots seems a little misleading.
Perhaps we can drop the dot (A.B) in aliases and use a single word name such as jujuBase/jujubase/juju_base or something like that?
| @@ -63,6 +65,7 @@ def path(self): | |||
| return os.path.join(HotSOSConfig.data_root, 'proc/vmstat') | |||
|
|
|||
| @property | |||
| @alias("kernel.vmstat.compaction_failures_pct") | |||
There was a problem hiding this comment.
I think this isn't needed since the class is aliased. Can be directly used as kernel.vmstat.compaction_failures_percent.
There was a problem hiding this comment.
nice catch, I'll remove it
The dot separation represents a hierarchy, where the first part is the plugin name, then the optional subsections, and finally the property name. I made it this way so if we write a YAML schema(*another important QOL improvement that will make it easier to write scenarios) for the scenarios for IDE/editor assistance in the future, it would be convenient for tab completion. As for the possible confusion, we can easily distinguish an alias from the full path as the package names always have to start with |
Now you say that, it makes sense. But it's not obvious otherwise. Also nothing prevents anyone from giving arbitrary names. So might be useful to have a section ("Alias naming") in documentation on the naming convention. |
xmkg
force-pushed
the
feature/alias
branch
2 times, most recently
from
43cb969
to
f5221a8
Compare
Added a check for preventing an alias from starting with "hotsos.", added the "Alias naming" section to the docs, and also added some unit tests to verify all that. |
at the moment, scenarios are using the long import paths in order to reference to a Python property. this feature allows assigning an alias to a Python class or variable in order to make using plugin property interfaces easier. Added aliases to the plugins. Updated existing scenarios to use aliases. Added unit tests for the aliasing code. Updated the docs. Fixes canonical#912 Signed-off-by: Mustafa Kemal Gilor <[email protected]>
at the moment, scenarios are using the long import paths in order to reference to a Python property. this feature allows assigning an alias to a Python class or variable in order to make using plugin property interfaces easier.
Added aliases to the plugins.
Updated existing scenarios to use aliases.
Fixes #912