-
Notifications
You must be signed in to change notification settings - Fork 0
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
Potential design for moving service information out of connection config #29
Comments
I have pushed some rough changes to the It would be great if you could test it out in this branch and share your feedback with us. Once the table design is finalized, I will push the cleanup code changes and documentation updates before raising the PR. Changes Overview:
The overall functionality will remain the same. Previously, results were obtained per connection per service ID. Now, results will be obtained per connection per
I have invited a user with the "Access to billing, stats & analytics" role but am still able to list services with that user's API Key. Steps to test the changes in the
@cody, please review the table design and let me know if it looks good. Any suggestions would be highly appreciated. Thanks! |
I wanted to provide an update: I've pushed additional changes to the same branch, Changes overview:
Please let me know if these changes look good or if any adjustments are needed. I'm open to making changes based on your suggestions. Thanks! |
Is your feature request related to a problem? Please describe.
Currently, each connection requires a service ID, which makes it difficult to get all service info (which can be done with an aggregator, but feels a bit cumbersome). Also, for resources that don't require service information, a user shouldn't need to pass service info into the connection.
Describe the solution you'd like
service_id
in the connection configfastly_service
, that lists services and gets info for services (possibly no change to the existing table)listServices
function in thefastly_service
table could be used as a parent hydrate for any other table that requires a service ID, so it’d list all resources of that table type for each service returned fromlistServices
fastly_service
tableHowever, some possible limitations:
Describe alternatives you've considered
Creating an aggregator and a connection for each service
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: