Skip to content
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

Merged
merged 145 commits into from
Sep 29, 2018
Merged

Salt-based supportconfig #49480

merged 145 commits into from
Sep 29, 2018

Conversation

isbm
Copy link
Contributor

@isbm isbm commented Sep 1, 2018

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 with salt, salt-key, salt-minion or salt-master etc commands. Naturally, it inherits most of the Salt typical features: debugging interface -l <level> and other that you already know:

$ salt-support --help

Salt Support is a program to collect all support data: logs, system
configuration etc.

Options:
  --version             show program's version number and exit
  -V, --versions-report
                        Show program's dependencies version number and exit.
  -h, --help            show this help message and exit
  -c CONFIG_DIR, --config-dir=CONFIG_DIR
                        Pass in an alternative configuration directory.
                        Default: '/etc/salt'.
  -t TIMEOUT, --timeout=TIMEOUT
                        Change the timeout, if applicable, for the running
                        command (in seconds). Default: 5.
  -P, --show-profiles   Show available profiles
  -p SUPPORT_PROFILE, --profile=SUPPORT_PROFILE
                        Specify support profile or comma-separated profiles,
                        e.g.: "salt,network"
  -a SUPPORT_ARCHIVE, --archive=SUPPORT_ARCHIVE
                        Specify name of the resulting support archive. Default
                        is "/tmp/zeus-support.tar.bz2".
  -u SUPPORT_UNIT, --unit=SUPPORT_UNIT
                        Specify examined unit (default "master").
  -U, --show-units      Show available units
  -f, --force           Force overwrite existing archive, if exists
  -o SUPPORT_OUTPUT_FORMAT, --out=SUPPORT_OUTPUT_FORMAT
                        Set the default output using the specified outputter,
                        unless profile does not overrides this. Default:
                        "yaml".

  Logging Options:
    Logging options which override any settings defined on the
    configuration files.

    -l LOG_LEVEL, --log-level=LOG_LEVEL
                        Console logging log level. One of 'all', 'garbage',
                        'trace', 'debug', 'profile', 'info', 'warning',
                        'error', 'critical', 'quiet'. Default: 'warning'.
    --log-file=LOG_FILE
                        Log file path. Default: '/var/log/salt/master'.
    --log-file-level=LOG_LEVEL_LOGFILE
                        Logfile logging log level. One of 'all', 'garbage',
                        'trace', 'debug', 'profile', 'info', 'warning',
                        'error', 'critical', 'quiet'. Default: 'warning'.

You can find additional help about salt-support issuing "man salt-support" or
on http://docs.saltstack.com

Typical Usage

By default, salt-support is acting as it being a Minion. So the usage is following:

  1. Login to your broken machine:
    ssh yourmachine

  2. In case you want other profile than default, list available profiles:
    salt-support -P

List of available profiles:
  1. default
  2. flt
  3. jobs-active
  4. jobs-last
  5. jobs-trace
  6. network
  7. postgres
  8. salt
  9. users
  1. Run it:
    salt-support

  2. 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):

  • As of now, it cannot collect information from remote minions
  • It doesn't work over Salt SSH. You need manually "ssh" there and run it manually.
  • Profiles are still quite basic.

Tests written?

Yes

@ghost ghost requested review from a team September 1, 2018 16:37
@isbm
Copy link
Contributor Author

isbm commented Sep 1, 2018

@gtmanfred @terminalmage @cachedout @rallytime Here. You have it. 😉

@cachedout
Copy link
Contributor

This has earned the much-coveted Awesome label!

I'm really happy about this feature, @isbm. I think it's absolutely fantastic! Great work here.

@cachedout
Copy link
Contributor

@isbm Can you start by addressing the lint errors? https://jenkinsci.saltstack.com/job/pr-lint/job/PR-49480/1/warnings52Result/new/

@isbm
Copy link
Contributor Author

isbm commented Sep 3, 2018

@cachedout I am exactly doing that right now! 😉

@isbm
Copy link
Contributor Author

isbm commented Sep 3, 2018

@cachedout hopefully this cleans it up.

@isbm
Copy link
Contributor Author

isbm commented Sep 4, 2018

@cachedout lints are now fixed. There is a case where I had to just mute W8470 (use with to immediately close file handler) but this is wrong since I have to pass not the content of the file but an opened file handler to the Tar archive, which then takes care of closing them on its own.

Copy link
Contributor

@cachedout cachedout left a 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.

@isbm
Copy link
Contributor Author

isbm commented Sep 7, 2018

@cachedout @rallytime any updates here?

@rallytime
Copy link
Contributor

Bah, sorry I meant to request a review from someone and I accidentally asked @cachedout to review again. My mistake!

@isbm
Copy link
Contributor Author

isbm commented Sep 10, 2018

@cachedout @terminalmage @rallytime any updates here?

@rallytime
Copy link
Contributor

@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. :)

Copy link
Contributor

@rallytime rallytime left a 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!

Copy link
Contributor

@meaksh meaksh left a 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.

scripts/salt-support Outdated Show resolved Hide resolved
return env.get_template(os.path.basename(path)).render(salt=caller, runners=runner).strip()


def get_profile(profile, caller, runner):
Copy link
Contributor

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):
Copy link
Contributor

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):
Copy link
Contributor

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):
Copy link
Contributor

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?

@cachedout cachedout merged commit 71531e3 into saltstack:develop Sep 29, 2018
@isbm isbm deleted the isbm-supportconfig branch October 21, 2018 13:52
@DmitryKuzmenko DmitryKuzmenko added the has master-port port to master has been created label Apr 22, 2020
DmitryKuzmenko pushed a commit to DSRCorporation/salt that referenced this pull request Apr 28, 2020
Salt-based supportconfig. Re-implementation of Support Config Tool in
Salt.
terminalmage pushed a commit to terminalmage/salt that referenced this pull request Aug 31, 2020
Salt-based supportconfig. Re-implementation of Support Config Tool in
Salt.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awesome code-jam has master-port port to master has been created
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants