-
Notifications
You must be signed in to change notification settings - Fork 543
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
[juju] Add plugin option for Juju state reporting #3803
base: main
Are you sure you want to change the base?
Conversation
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
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.
As well as turboturtle comments, can we also look at the flake/pylint issues as well is any updated PR
A couple of very small comments from me. |
@MichaelThamm remember to squash all the commits into one and sign it |
60d0c0e
to
9d36d66
Compare
@arif-ali or @jcastill I imagine that I need to obfuscate some of the following information which is included in the "lxd": {
"user": "admin",
"recent-server": IP:Port,
"uuid": "ac03821c-361e-4daf-83c9-a712cd56b8d4",
"api-endpoints": [IP:Port],
"ca-cert": "-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----",
}, Is there a need to obfuscate these things or is it just passwords, tokens, keys as mentioned in obfuscate? |
@MichaelThamm The IP addresses and endpoints, not so, as they would be typically handled by In terms of the certs, you can get the example of the sunbeam.py plugin, where we just needs |
When I run:
However, I do not see results in the This method does not have a filename parameter either. Not sure how to continue with this? |
You can just specify |
Signed-off-by: Michael Thamm <[email protected]>
045cef0
to
f389bfa
Compare
I think the PR is almost ready for review, but I noticed we have tests for the Juju plugin. Is there any need to update this since the test for scrubbing seems to be sufficient? I also tested the scrubbing for |
) | ||
if controllers_json["status"] == 0: | ||
desired_controllers = set( | ||
self.get_option("controllers").split(" ") |
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.
We generally have plugins use :
as a delimiter in plugin options that can take a list (as the use of commas gets murky with argparse and how plugin options are....parsed.
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.
The only problem with this is for the Juju model synatx it can be:
- The current controller's model ->
model_a
- Or it can be a specific controller and model ->
controller_x:model_a
For this reason I chose to split via empty space since models and controllers are not allowed to have spaces in their names according to Juju.
i.e. controller one
-> not valid name
Would this be a reasonable exception to the Sos plugin standard?
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.
If it's an expectation that users would pass something like -k juju.controllers="foo:bar"
, then yeah it's totally reasonable to use something else. We should just make note of that, ideally in both the plugin option description (for sos report -l
output) and the docstring for the plugin (as the docstring gets used in sos help
output, e.g. sos help report.plugins.juju
- see the kernel
plugin docstring for a good example).
|
||
# Specific models | ||
if self.get_option("models"): | ||
for model in self.get_option("models").split(" "): |
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.
Ditto, we prefer plugin options to use :
as a delimiter. We may need to add this to the plugin guide, I'll check this shortly.
if self.get_option("models"): | ||
for model in self.get_option("models").split(" "): | ||
command = f"juju status -m {model} --format=json" | ||
self.collect_cmd_output(command, runas=juju_user) |
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.
collect_cmd_output()
is designed to return the output for further processing, if you don't need to do anything with the output, use add_cmd_output()
instead.
f"juju status -m {controller}:{short_name} " | ||
f"--format=json" | ||
) | ||
self.collect_cmd_output(command, runas=juju_user) |
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.
Same here, use add_cmd_output()
if you don't need to do anything further with the output.
if self.get_option("controllers") and self.get_option("models"): | ||
self._log_warn( | ||
"Options: controllers, models are mutually exclusive. " | ||
"Will not collect Juju information." | ||
) | ||
return |
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'm assuming these are mutually exclusive within the Juju stack, but would we not anticipate some (admittedly niche) use case where an sos end user isn't sure if a particular host is using one or the other, and wants to pass e.g. -k juju.controllers=foo,juju.models=bar
to get either without needing to know the specific host configuration? I'm mainly thinking of some sort of automation-driven sos collection here, but I could be way off with that idea.
This change modifies the Juju plugin to optionally capture Juju state (controllers, models, applications, units) information. The capture assumes that
juju
is installed on the machine wheresos
is called, and that the juju user has superuser privilege to the current (or requested) controllers.This option is disabled by default because, while the information can be very useful, the collection acts on the live Juju state.
Use the plugin with the feature:
sos report --only-plugin juju -k juju.juju-state=True
Run with a specific user (who has access to the controllers specified). This defaults to
ubuntu
:-k juju.juju-user=super_admin
If necessary, you can filter by controllers or models with cluster options.
-k juju.controllers="controller_a controller_b"
-k juju.models="controller_a:model_x controller_b:model_y"
If nothing is supplied for either the controllers or models options, the report will include all state information for them respectively.
Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines