-
-
Notifications
You must be signed in to change notification settings - Fork 199
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
Fix reclass #1135
Fix reclass #1135
Conversation
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 don't have much time right now, but at first glance, it looks like that this adds several arguments which I highly wanted to avoid. Maybe you could add why these changes are needed. compose_node_name
may not be supported right now and I have to look into it, but passing it to the get_inventory()
method violates the encapsulation of the inventory.
I believe I have addressed your concerns and reduced the change to the essential |
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.
Thanks for the refactoring, I still see some issues with these changes:
-
We should think of a cleaner and generic way to have
global
arguments, instead of setting each argument toglobal
. I would propose a change to the scope of the arguments, so that we don't have a<cmd-name>
namespace and aglobal
namespace, but have namespaces (and parsers) per core-kapitan-functionality (e.g. compile, inventory, logging, dumping .... Then we would have all arguments regarded to the inventory in one group and get several benefits out of it. -
The Inventory-Interface was designed, to have a standardised way to get the inventory ressources. With overwriting the
__init__
method for reclass, we break out of this conzept and lose the standardisation. We should render the inventory inrender_targets()
. -
compose_node_name
is now a kapitan-concept and can be applied to all inventory_backends. When reading the configfile for reclass, we simply can override the config dictionary and read the value from the kapitan args. The current solution (before the interface) where you had to configure thereclass_config.yml
, was not the best, because kapitan should control the behavior of its inventory and there should no changes be made in inventory-specific configfiles.
Sorry for that essay, but I designed the interface with improvements to encapsulation and clear responsibilties in mind, and I still think, we should keep these. If there are any concerns or clear advantages for these changes, let us dicuss them!
Hey, I've created #1138 to fix |
I didn't see this PR on Friday, but I think #1141 partially addresses the excessive amount of times that Kapitan 0.33.x renders the Reclass inventory. I have no hard preference on whether we go with the more substantial changes here or my minimal fix in #1141. From the PR description:
Note that there's cases where we actually need to re-render the Reclass inventory (e.g. after fetching remote inventories). |
Can you explain, what do you mean here? Because when I tested, I ensured that it renders only once in the actual inventory rendering step. Afterwards its used from the cache. And fetching dependencies or remote inventories works fine as well. I tested it with my fix #1138, so the current version may be broken. |
The currently released version (and as far as I can see #1138 as well) has a mismatch between |
Fixes #
Proposed Changes
Docs and Tests