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

include the virtualname in the file name for core modules #50812

Merged
merged 2 commits into from
Feb 20, 2019

Conversation

gtmanfred
Copy link
Contributor

What does this PR do?

There is a condition in the loader for salt, where you could end up with finding modules taking forever.

When loading modules, we look at

  1. the name of the module is the name of the .py file, if it matches what is being called, we use that one.
  2. The name of the module is in the name of the .py file, we then load all of those and check if the virtualname matches, and if it does, we use that one.
  3. start from the top, alphabetically, and go down the list of modules, until we find one that has the correct virtualname.

This is usually not a problem, unless you are using some module that hits part 3, and is after esxi.py and possibly vsphere.py because those use the @Depends decorator, which takes longer to run when loading, and can cause it to take a really long time for the lazyloader to load the module you are looking for.

This PR adds a unittest to make sure there are no modules in the core modules of salt that fall into the third category, so that we make sure to optimize loading of salt core modules (3 can still be hit by users custom modules)

Tests written?

Yes

Commits signed with GPG?

Yes

@gtmanfred
Copy link
Contributor Author

ugh, it only works on py3, i need to fix this for py2 as well.

@gtmanfred
Copy link
Contributor Author

still need to fix autodoc

@gtmanfred
Copy link
Contributor Author

@saltstack/team-core can someone look at this?

Thanks,
Daniel

===================
======================
salt.modules.ebuildpkg
======================
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this file need to be renamed?


# Import salt libs
from salt.ext import six

log = logging.getLogger(__name__)


def __virtual__():
return dson, 'Failed to load: dson module not installed'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will probably break if dson is installed. The first value in the tuple should be either a string or a bool, in this case it's either a module or None.

@dwoz
Copy link
Contributor

dwoz commented Feb 8, 2019

@gtmanfred are you able to resolve the conflicts here?

@gtmanfred
Copy link
Contributor Author

Yeah, I need to do that and fix the tests still, i will try to get to it later today.

@gtmanfred
Copy link
Contributor Author

Rebase done, waiting on the test suite to run so that I can see what tests need to be fixed.

@gtmanfred
Copy link
Contributor Author

@dubb-b something is going on with bootstrapping of the tests and possibly nexus.

Thanks,
Daniel

@dubb-b
Copy link

dubb-b commented Feb 12, 2019

@dubb-b something is going on with bootstrapping of the tests and possibly nexus.

Thanks,
Daniel

@gtmanfred looks like more-itertools that CherryPy depends on releases 6.0.0 and we need to pin earlier version for py2. They went py3 only.

@gtmanfred
Copy link
Contributor Author

@dwoz this should be all ready to go once the tests pass

Make sure that the virtualname is included in the actual filename of
core modules.  This will help speed up loading of modules that need to
use the virtualname, so that we hit @Depends decorators less.
@gtmanfred
Copy link
Contributor Author

I squashed the commits so it would be easier to merge forward.

@dwoz dwoz merged commit e08f08d into saltstack:2018.3 Feb 20, 2019
@gtmanfred gtmanfred deleted the virtualnames branch February 20, 2019 14:01
@gtmanfred
Copy link
Contributor Author

Thanks @dwoz

@cachedout
Copy link
Contributor

Does this need a changelog entry?

@gtmanfred
Copy link
Contributor Author

Makes sense to me, i will write something for the 2018.3.5 release doc.

@damon-atkins
Copy link
Contributor

Just thought I point out this discussion #30533 on module names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants