-
Notifications
You must be signed in to change notification settings - Fork 36
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
Move conversion of specific provider to separate file #201
Comments
This is a good step in the right direction. I wonder whether we could go further, in the long term, where vendors can "register" a plugin with the converter? Doing so would mean vendors don't need to submit their conversion functions to the repo for use with oslo |
Good idea @kenfinnigan, I think we have to do it step by step. For now, we don't have a lot of external plugins, thus it won't be a lot of hustle for maintainers to merge, and review PRs. I think @fpiwowarczyk proposition is valid, we should provide structure and Go interface to be implemented by those plugins. Those plugins would be compiled in binary. They could then perform registration automatically in their Having mechanisms that allow the use of plugins that are not part of
|
I think we might be able to go in this direction soon. I agree it's not ideal that proprietary standards are maintained in an open source project, if we want to have ready to use conversion in I don't have a solution yet on how exactly we would manage it but I'd probably go with the |
I'm interested in seeing how we can get this working for Grafana SLO, however as that takes a JSON document in the request body, we'd need to convert it (and yes, I know that JSON and YAML are step-siblings, but using Oslo to create vendor-specific data should be a trivial thing IMHO :) ) |
I will try to create a PoC by the end of February, I also need this separation of concerns to better handle OpenSLO intergration with Nobl9 :) |
So, as we discussed on community meeting we don't really want expand this idea of converters and focus more on providing good sdk tools for developers, right? We can close this issue then. Imo the only thing we need to support related to conversion is moving between popular data types json/yaml etc. |
Summary
Currently we have Nobl9 convert method in one file as general convert methods. I think we should move vendor specific methods to separate directory to have cleaner code structure and more open for new vendors to add their convertes. Beside that currently we have in spec
metadata.annotations
which contain vendor specific fields, we don't have place to document things like that beside code, having separate folder for Nobl9 allows to document that there.Proposed structure
The text was updated successfully, but these errors were encountered: