-
Notifications
You must be signed in to change notification settings - Fork 540
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
[collect] Handle custom node and inherited configs with collections #3852
base: main
Are you sure you want to change the base?
[collect] Handle custom node and inherited configs with collections #3852
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. |
d8a835a
to
8641897
Compare
Signed-off-by: Trevor Benson <[email protected]>
Signed-off-by: Trevor Benson <[email protected]>
8641897
to
d6bc604
Compare
Signed-off-by: Trevor Benson <[email protected]>
24cdb35
to
4b56b74
Compare
I've restarted the 2 failed jobs, not sure why they are failing, and it's not the first time, I'll take that away as a separate issue |
Signed-off-by: Trevor Benson <[email protected]>
sos/collector/__init__.py
Outdated
collect_grp.add_argument('--inherit-config-file', type=str, | ||
default=None, | ||
help='Path to a local config file to' | ||
' copy to the remote node and use with' | ||
' sos report') |
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.
My initial thought was that this would be a toggle, whereby if True
we implicitly take the config-file used locally, so sos.conf
by default or whatever gets set.
Is there a use case you have where a user would have config_file_A locally that is used for the collect
and local report
collections, but would have config_file_B also local to the system that is running collect but should be used only for remote node collections?
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 suspect any difference is mostly my misinterpretation of the discussion
- A new --inherit-config-file (or whatever) option causes collect to transfer the supplied config file to remote nodes and implicitly sets the per-node sos command to use that transferred config file
Not intentional change to your thoughts on implementation.
Is there a use case you have where [...]
Possibly, but not one of my requirements. I plan to use the same config for the collector and the local/remote nodes.
I'll attempt to layout the resulting behavior from this change.
Overview
Three arguments
- --config-file: str
- --node-config-file: str
- --inherit-config-file: bool
Logic
--inherit-config-file
isFalse
--config-file
&--node-config-file
unset- Current behavior for both collector and report.
--config-file
set to/etc/sos/custom1.conf
- collector uses
custom1.conf
- report uses
sos.conf
- collector uses
--node-config
set to/etc/sos/custom2.conf
- collector uses default
/etc/sos/sos.conf
- report uses (pre-existing)
/etc/sos/custom2.conf
for the local and remote nodes .
- collector uses default
--inherit-config-file
isTrue
--config-file
&--node-config-file
unset- collector uses
/etc/sos/sos.conf
/etc/sos/sos.conf
is copied to all nodes in a temp path.- report uses
/tmp/sos.XXXXX.conf
(local could use default path)
- collector uses
--config-file
set to/etc/sos/custom3.conf
- collector uses
/etc/sos/custom3.conf
/etc/sos/custom3.conf
is copied to all nodes in a temp path.- report uses
/tmp/sos.XXXXX.conf
(local ...)
- collector uses
--node-config-file
& --inherit-config-file
are an incompatible argument pair. Potentially also --config-file
& --node-config-file
.
Does this correctly describe what you were thinking?
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've got this logic and additional comments worked out. I will add the new commit for review, but can be dropped/reverted if this wasn't what you were thinking of.
sos/collector/sosnode.py
Outdated
self.run_command(f"rm {remote_config} ; rmdir {self.tmpdir}", | ||
use_shell=True, | ||
need_root=True) |
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.
Yeah, same here. Very much not a fan of doing rm
s like this - the local sos installation on the remote node should take care of any cleanup. If we place the inherited config files in /tmp
, then they would be both out of the way and cleaned up separately by long-standing behavior.
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'll presume you mean leaving the inherited conf in the tmp directory and letting systemd-tmpfiles-clean.timer
RHEL, or tmpfiles.d
for Ubuntu, handle the cleanup on schedule?
It works for my use case, as long as we are comfortable that the file remains might (although probably uncommon) store plugin_options
in the file for things like mysql.dbpass
, postgresql.password
, skydive.password
?
Inherit-config-file as toggle No changes will be made Long-standing cleanup behavior Signed-off-by: Trevor Benson <[email protected]>
I've started building some packages for testing [1], so will do the testing soon [1] https://launchpad.net/~arif-ali/+archive/ubuntu/sos-pr-3852 |
@TrevorBenson did you test the oc transport already? I'm asking because I'm setting up an environment to test some other stuff and I can use it to test this PR as well. |
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.
tested both the of the new config options, and works as expected from the juju
perspective. Thanks for your work on this
EDIT: don't forget to squash your commits, as ideally it is preferred to have one commit per PR
if ret: | ||
return True | ||
self.log_info(f"File copy attempt {attempts} failed") | ||
self.log_info("File copy failed after 5 attempts") |
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.
while attempts < 3
vs. failed after 5 attempts
:)
self.sos_cmd = ( | ||
f"{self.sos_cmd} {config_file_arg}" | ||
if config_file_arg else self.sos_cmd) |
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.
Isn't it easier just to have
if config_file_arg:
self.sos_cmd = f"{self.sos_cmd} {config_file_arg}"
? But I am ok with the current code.
Just the 3 / 5 retry attempts are worth to fix, otherwise ACK. |
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.
Looks good to me overall. Just two super minor nits, and Pavel's comment on the 3 vs 5 attempts. FWIW, I think 3 attempts is sufficient.
cmd = (f"/usr/bin/scp -oControlPath={self.control_path} " | ||
f"{fname} {self.opts.ssh_user}@{self.address}:{dest}") | ||
res = sos_get_command_output(cmd, | ||
timeout=10) |
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.
Nit: this can fit on one line
model_option = f"-m {model}" if model else "" | ||
cmd = f"juju scp {model_option} -- {fname} {unit}:{dest}" | ||
res = sos_get_command_output(cmd, | ||
timeout=15) |
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.
Nit: same here
@@ -41,6 +41,9 @@ def _retrieve_file(self, fname, dest): | |||
def _format_cmd_for_exec(self, cmd): | |||
return cmd | |||
|
|||
def _copy_file_to_remote(self, fname, dest): | |||
pass |
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.
Hmm. I was initially going to say this should return True
, but that might not track given that we may not be writing the the same location (and in this first implementation we already aren't).
This might need some attention later on depending on how much use this functionality sees, but for now I think it's fine.
Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines