-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Capabilities RFC #50617
Capabilities RFC #50617
Conversation
@cachedout bumpitybump! |
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 like this. Long term maybe we can combine it with some parameter spec decorators that could handle input validation and normalization. Assuming others agree, we'll probably want that as a separate RFC.
I approve of this one as it stands now.
@dwoz that is certainly another RFC. The input validation/normalisation is another topic and mostly relevant to the Interface RFC. On which you are also welcome to comment. 😉 |
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 think this is a very smart way to do this. One thought might be that we could perhaps simplify this even further by creating a custom jinja filter?
As much as I don't like having deeply nested objects like this, I do think that this is a good overall design. If there is a way to make this not as nested I would like it more. |
@cachedout it already is a Jinja filter. We only might add "shortcuts", but personally I afraid to clash with something else. Namespace is very good. @thatch45 well, if not nested, then we will have it like PHP. We then will be risking having clashes all over the place. |
@isbm Perhaps we could explore a way to "reserve" shortcuts somewhere in Salt to avoid clashes. It would be good if we could make these as short as possible while still avoiding potential clashes. |
But how? You need to start somewhere. Either it is a module or state. Then you have to refer to a function of that module. Then you should select what area you want to explore and so on. You cannot just say "reboot me a machine if 'foo' in documentation". Because Salt has absolutely no idea what exactly is that you want from it. Having shortcuts will make it harder because one will need to remember many things instead of one. Having a single entry also allows us to extend it to other areas I already wrote in the RFC as well as even different places yet to come. We are not going to pollute namespace with the whole sack of new reserved words, being afraid to screw up someone's SLS. 😀 Also single entry proposes to do this step by step, smoothly and invisible for whole current ecosystem of Salt users. Especially that we already have "salt" reserved. So we can simply extend that, instead of "capable":
In first case we introspect. In second we call. Third is just current way, doing the same as the second example. |
I love the idea of this. But I did want to note. That the "bonus feature" of salt.module.function already exists in salt. https://docs.saltstack.com/en/latest/topics/jinja/index.html#calling-salt-functions https://github.com/saltstack/salt/blob/develop/salt/renderers/jinja.py#L23-L42 However, if dropped in favor of this I would not complain. Also if this augmented the sysmod functionality that would be a good bonus. |
Syntax-wise yes. But the way I propose (and POC does already) is basically this: salt().module().function() So it will load only when you actually access it by calling and loading. Some internal Python tricks allows to get rid of Needless to say, this is not any new. The entire Zope is basically built on top of that. 😉
Primarily we could get rid of if foo.get('key', {}).get('otherkey', {}).get('somethingelse'):
... Much nicer to do just: if foo.key.otherkey.somethingelse:
... But as I said, this is all ideas for the future. Right now important is — capabilities. |
What does this PR do?
Describes presented on Salt Conference 2018 capabilities.
Please read it here.