call correct mkdir when trying to create /etc/rhsm/facts

[evgeni]

os.path has no mkdir, but os does.

traceback without the patch:

Traceback (most recent call last):
  File "/bin/leapp", line 11, in <module>
    load_entry_point('leapp==0.16.0', 'console_scripts', 'leapp')()
  File "/usr/lib/python3.6/site-packages/leapp/cli/__init__.py", line 45, in main
    cli.command.execute('leapp version {}'.format(VERSION))
  File "/usr/lib/python3.6/site-packages/leapp/utils/clicmd.py", line 111, in execute
    args.func(args)
  File "/usr/lib/python3.6/site-packages/leapp/utils/clicmd.py", line 133, in called
    self.target(args)
  File "/usr/lib/python3.6/site-packages/leapp/cli/commands/upgrade/breadcrumbs.py", line 170, in wrapper
    breadcrumbs.save()
  File "/usr/lib/python3.6/site-packages/leapp/cli/commands/upgrade/breadcrumbs.py", line 116, in save
    self._save_rhsm_facts(doc['activities'])
  File "/usr/lib/python3.6/site-packages/leapp/cli/commands/upgrade/breadcrumbs.py", line 64, in _save_rhsm_facts
    os.path.mkdir('/etc/rhsm/facts')
AttributeError: module 'posixpath' has no attribute 'mkdir'

While at it, also catch OSError with errno 17, to safeguard against race
conditions if anything has created the directory between us checking for
it and us trying to create it.

[github-actions]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

• review please @oamg/developers to notify leapp developers of the review request
• /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp from PR#42, use /packit test oamg/leapp#42

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

• /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
• /packit test --labels beaker-minimal-8.9to9.3,kernel-rt-8.9to9.3 to schedule kernel-rt and beaker-minimal test sets for 8.9->9.3 upgrade path

[Deprecated] To launch on-demand regression testing public members of oamg organization can leave the following comment:

• /rerun to schedule basic regression tests using this pr build and latest upstream leapp build as artifacts
• /rerun 42 to schedule basic regression tests using this pr build and leapp*PR42* as artifacts
• /rerun-sst to schedule sst tests using this pr build and latest upstream leapp build as artifacts
• /rerun-sst 42 to schedule sst tests using this pr build and leapp*PR42* as artifacts

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

[evgeni]

review please @oamg/developers

[abadger]

Approving because this is a bug and the change fixes it.

Possible tangent: would we want to make this more robust as well? Something like this would remove an (unlikely) race condition:

    def _save_rhsm_facts(self, activities):
        if not os.path.exists('/etc/rhsm'):
            # If there's no /etc/rhsm folder just skip saving rhsm_facts
            return
        try:
            os.mkdir('/etc/rhsm/facts')
        except OSError as e:
            if e.errno == 17:
                # The directory already exists which is all we need.
                pass

[evgeni]

We could also use os.makedirs(…, exist_ok=True) instead of catching the OSError?

I don't have a strong preference, as long as the bug gets fixed :)

[evgeni]

We could also use os.makedirs(…, exist_ok=True) instead of catching the OSError?

Huh, exist_ok doesn't exist in Python2, which we probably still need to keep compat with?

[pirat89]

yep, so far we need to be still python2 compatible yet

[pirat89]

@evgeni do you plan to address also @abadger suggestion? for us, it's ok to merge it as it is, but if you want to address the change, we can wait. no rush :)

[evgeni]

There you go, addressed.

[abadger]

Thanks. Looks great!