Salt modules depends on utils are not loaded via salt loader #32500
Description of Issue/Question
Salt Modules depends on utils are not loaded via salt loader.
We have a custom module and custom utils create at location _modules and _utils on master /srv/salt.
Steps to Reproduce Issue
salt 'minion' sys.list_modules test*
salt 'minion' test_mod.echo
error in log: 2016-04-11 08:13:32,126 [salt.loaded.ext.module.test_mod][ERROR ] Got exception No module named test_utils: Traceback (most recent call last):
This issue is reproducible in Salt version 2015.5.10 and 2015.8.8.2.
The text was updated successfully, but these errors were encountered:
I don't believe
Here are few additional test which makes module dependent on utils to load via salt loader and works fine
Following is the example which we tried and failed to load. Please let us know if its not supported.
So let me describe the use case that we have in mind and see what the best way to accomplish this...
We have a number of actual modules and runners that we have written as various parts of a more complex system. In that system there are a number of "utility" modules that are shared across multiple of these modules and runners. Theses include things like an enumeration of status constants and the like.
What we would like is to have these shared modules installed once in the /srv/salt/_utils on the master and have them available for use in the runners and the modules. We originally experimented with copying these to both the _runners and the _modules directory. The problem with that solution is that they become "modules" and "runners" even though we don't really want them directly callable from the outside. Using utils is not so bad for making one or two dynamic calls, but it is a bit cumbersome for constants and the like.
The other option would be to install these into the site-packages on all of the places where we have salt-minions that use them. This seems to be not ideal as it limits the usefulness of the Salt module distribution to the minions.
What is confusing to me is that even though it was not a supported case it seemed to actually work when we happen to have a dynamic grain in the system? I am really perplexed that this somehow caused the _utils to be available to the python loader. The other odd thing is that even without the dynamic grains it will pick up the _utils once we restart the actual minions. The problem with rebooting minions as part of a state are documented elsewhere and seem to make the whole distribution process that we are trying to implement much less reliable.
You have a lot of concerns here so let me see if I can restate a few and respond where I can.
I'm able to place a module in
From modules inside
Is your concern that you're limited to access the returns of functions inside your custom utility module instead of having the entire namespace exported, so that you could declare constants independently of functions? Or is is that the workflow I'm describing above doesn't work for you at all?
Regarding the second part of your question, with the dynamic grains. I'm not sure I follow what's happening here. Could you post a step-by-step reproduction case that illustrates the issue? I might just be missing something obvious here. Thanks.
Was support for raw imports added in the meantime? I see the following in the doc:
"... Also you could even write your utility modules in object oriented fashion ... And import them into other custom modules:
but when I try to do this, I get an ImportError.
I tried to implement this in #46841 myself, and while the result kind of sort of worked, there were nasty side-effects. The solution consisted of making sure
It would be great if someone more knowledgeable could point a better way to resolve this.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.