-
Notifications
You must be signed in to change notification settings - Fork 31
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
create a application like system #1665
Comments
Signed-off-by: R.I.Pienaar <[email protected]>
#1666 adds a super basic version of this with no input validation etc,
Simply symlink
|
This allows applications to be built that wraps RPC and KV components. Application definitions are documented using a schema and are validated on loading, from the definition a CLI app is built that can have nested sub commands and more. Application definitions goes in files called x-app.yaml, a symlink from x to choria would then load x-app.yaml and construct the CLI when x is invoked. An additional config file can be read called applications.yaml that can be accessed via go templates in the definition in a few places. The config and definitions can live in ., ~/.config/choria/builder or /etc/choria/builder. Paths are using XDG, but its a super primitive implementation for the moment, will be refined via issue 1624, thus paths and file names are subject to change Signed-off-by: R.I.Pienaar <[email protected]>
This allows applications to be built that wraps RPC and KV components. Application definitions are documented using a schema and are validated on loading, from the definition a CLI app is built that can have nested sub commands and more. Application definitions goes in files called x-app.yaml, a symlink from x to choria would then load x-app.yaml and construct the CLI when x is invoked. An additional config file can be read called applications.yaml that can be accessed via go templates in the definition in a few places. The config and definitions can live in ., ~/.config/choria/builder or /etc/choria/builder. Paths are using XDG, but its a super primitive implementation for the moment, will be refined via issue 1624, thus paths and file names are subject to change Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) initial basic working app framework
Draft docs PR here choria-io/website#90 |
* Adds specified batching * Adds specified filters * Adds specified display * Adds a progress bar and support disabling Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) expand the rpc command for builder
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) adds a escape function to handle user input
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) allow output format to be forced
Some notes on enhancements while trying to build something with this:
|
* Adds a prompt to confirm any action * Adds a prompt to confirm rpc without a filter * Adds kv history Signed-off-by: R.I.Pienaar <[email protected]>
* Adds a prompt to confirm any action * Adds a prompt to confirm rpc without a filter * Adds kv history Signed-off-by: R.I.Pienaar <[email protected]>
* Adds a prompt to confirm any action * Adds a prompt to confirm rpc without a filter * Adds kv history Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) Additions to application builder
Will merge settings allowing for hard coded filters augmented with cli supplied ones Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) allow filter and std filter to be used together
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) support rendering json in kv history and get
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) various bug fixes and template parse filters
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) move filter to a more appropriate place
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) fix json rendering of kv history
(#1665) Update builder.json: small schema fixes
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) use choria-io/appbuilder for core appbuilder behaviors
Also update dependencies Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) add transforms to kv and some bug fixes
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) improve kv validate error message
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) use appbuilder transform, add rpc validations
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) allow discovery method and options to be templat parsed
Signed-off-by: R.I.Pienaar <[email protected]>
Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) allow kv bucket and key to be templates
Closing this, future enhancements as new issues. |
Also update dependencies Signed-off-by: R.I.Pienaar <[email protected]>
Also update dependencies Signed-off-by: R.I.Pienaar <[email protected]>
(#1665) ensure batching works in app builder rpc command
mco applications were ruby plugins that was used to build CLI tools, primarily they were used to render results differently and less frequently about doing multiple chained requests (puppet runall)
For a large portion of things really all thats needed now is a way to construct complex
choria req
commands.I imagine that:
Would just do, and it would be enough:
If there was a way to create dynamically a cli thats essentially just macros around rpc, kv, external commands etc it would allow them to make a local utility that has easy to discover features without that is just a wrapper.
This could be defined using a YAML file like this:
The text was updated successfully, but these errors were encountered: