Please explore alternative options to get the information necessary for the Synthetic Monitoring plugin. The requirements for this issue to be considered resolved are:
[ ] Ensure the subscription look-up comes from dependencies that are directly within the @grafana/synthetic-monitoring-dev team's sphere of influence
[ ] That the relevant integration tests have been added
Additional considerations
When considering alternative options please consider what information we might need other than the org's subscription type in the future. Having access to the full gcom api is very appealing in terms of adding new features and maintaining velocity, however it isn't strictly necessary and doesn't follow the principle of least privilege.
If we were to explore options of adding the user's org subscription type in the SM api please consider what other information would be useful to be exposed for future product development (pricing information comes to mind immediately so we could easily show costs and help check management for interested admins).
Lastly, when considering solutions please consider what steps would need to be taken to accommodate access to the api. If we were to copy the hg-cloud-home-admin app's approach and add the gcom api routes to our plugin.json what information would we need to add to our provisioning files? How would we gather / add that information to existing stacks?
Problem
When solving https://github.com/grafana/synthetic-monitoring-app/issues/914 we introduced a dependency on the
hg-cloud-home-app
by utilizing the gcom api routes they provide as defined in theirplugin.json
. This is a brittle dependency as they are free to change any aspect of their plugin at any time and should not have to concern themselves with if they are breaking any other plugins they are not responsible for.Completion criteria
Please explore alternative options to get the information necessary for the Synthetic Monitoring plugin. The requirements for this issue to be considered resolved are:
Additional considerations
When considering alternative options please consider what information we might need other than the org's subscription type in the future. Having access to the full gcom api is very appealing in terms of adding new features and maintaining velocity, however it isn't strictly necessary and doesn't follow the principle of least privilege.
If we were to explore options of adding the user's org subscription type in the SM api please consider what other information would be useful to be exposed for future product development (pricing information comes to mind immediately so we could easily show costs and help check management for interested admins).
Lastly, when considering solutions please consider what steps would need to be taken to accommodate access to the api. If we were to copy the
hg-cloud-home-admin
app's approach and add the gcom api routes to ourplugin.json
what information would we need to add to our provisioning files? How would we gather / add that information to existing stacks?