-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Salt-based supportconfig #49480
Salt-based supportconfig #49480
Conversation
@gtmanfred @terminalmage @cachedout @rallytime Here. You have it. 😉 |
This has earned the much-coveted I'm really happy about this feature, @isbm. I think it's absolutely fantastic! Great work here. |
@isbm Can you start by addressing the lint errors? https://jenkinsci.saltstack.com/job/pr-lint/job/PR-49480/1/warnings52Result/new/ |
@cachedout I am exactly doing that right now! 😉 |
@cachedout hopefully this cleans it up. |
@cachedout lints are now fixed. There is a case where I had to just mute W8470 (use |
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.
This looks really nice. Well done, @isbm.
@cachedout @rallytime any updates here? |
Bah, sorry I meant to request a review from someone and I accidentally asked @cachedout to review again. My mistake! |
@cachedout @terminalmage @rallytime any updates here? |
@isbm I think there will be a delay in reviews here because of SaltConf. In the mean time, I will restart the tests. The last run looks suspicious to me. :) |
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 really like this feature @isbm!
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.
Found some minor issue here. Apart from that, we need to add salt-support
script reference inside setup.py
in order to get it installed while building the package.
41d2de3
to
c333366
Compare
return env.get_template(os.path.basename(path)).render(salt=caller, runners=runner).strip() | ||
|
||
|
||
def get_profile(profile, caller, runner): |
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.
This function is a little hard to read. Might be a good target to either break apart or add additional documentation about what's happening here.
self.__arch.close() | ||
self.__arch = None | ||
|
||
def _flush_content(self): |
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.
Here's another function that CodeClimate has marked as being difficult to read. Can we break this up into something easier to understand?
|
||
return conf | ||
|
||
def _get_runner(self, conf): |
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.
Can we refactor to DRY between _get_runner
and _get_caller
?
|
||
return ret | ||
|
||
def run(self): |
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.
Can we factor what's in here to call some smaller functions that are easier to understand?
…port salt.ext.six as six'
3f0b2b9
to
870b382
Compare
Salt-based supportconfig. Re-implementation of Support Config Tool in Salt.
Salt-based supportconfig. Re-implementation of Support Config Tool in Salt.
What does this PR do?
Re-implementation of Support Config Tool in Salt.
What is this?
Over many years SUSE is using Support Config Tool [to collect system information] (https://www.suse.com/documentation/sled11/book_sle_admin/data/sec_admsupport_supportconfig.html) in order to provide detailed information of a running system to technical support. However, given on its age and therefore design, this tool has a number of limitations that would be nice to do not have.
Imagine, you want to know why one of your supported applications on some machine doesn't work. But you already have Salt running there. Would it be cool to run your crafted (or standard) state-like YAML scenario and then get all the needed precise data about broken component and ask exactly only what you need? No more poking "please try run this and that". Simply make your own YAML-based scenario what you would like to fetch, and say "run this scenario, send us the resulting archive". That's it.
It also works on whatever OS you run Salt.
Support Scenarios vs States
Support Scenario very much looks like orchestration. However, it is not an orchestration on its own. Salt state files (SLS) gets parsed when Salt is already running. That said, Salt is parsing, compiling, injecting required variables etc and then running them. Support Scenario, however, needs to be parsed and compiled beforehand Salt is even running. Additionally, Support Scenario runs a mix of runners and modules.
Overview
Salt Support is implemented on top of Salt as a platform and thus comes with its own CLI command, called
salt-support
. Once installed, you will find it along withsalt
,salt-key
,salt-minion
orsalt-master
etc commands. Naturally, it inherits most of the Salt typical features: debugging interface-l <level>
and other that you already know:Typical Usage
By default,
salt-support
is acting as it being a Minion. So the usage is following:Login to your broken machine:
ssh yourmachine
In case you want other profile than default, list available profiles:
salt-support -P
Run it:
salt-support
In case you running a custom scenario:
salt-support -p /path/to/your/own/profile.yml
At this point it will collect all the data of the machine, such as system info, its health, disks status, network layout, users, system logs, actual minion configuration, pillars, highstate etc and it will put into an archive in
/tmp/yourhost-support.tar.bz2
file. Now you can send this archive to your technical support. 😎What happens if I run it?
Essentially, Support Profile will just call any module or useful runner or useful utility in your battery-included Salt in any combination you want and record that data for you. Your support desk won't need to ask anymore "How looks output from the following command: .....?" It will do that for you and you will get a corresponding file inside the archive.
What is inside the archive?
It is a tree of directories: a date-time when the snapshot has been taken and full path to copied file tree, if you wanted so. Snapshot will contain many self-descriptive text files, such as
systeminfo
,system-health
,network
,packages
etc. You can look into them and get an idea what is going on with the affected machine.Jinja in Support Profile!?
Yes. Each profile is essentially a YAML Jinja2 template, just like SLS. However, difference is that it should be compiled beforehand. Currently there is only one way to call other modules within the template:
{{ salt('cmd.run', 'uname') }}
for example. If module returns a list or any structure, you can just iterate over it, just the same way as you would do in normal Jinja2.Limitations
Current limitations of this implementation as of today (subject to change):
Tests written?
Yes