-
Notifications
You must be signed in to change notification settings - Fork 90
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
Extend resource configuration API to include resource metadata #19
Conversation
594fdae
to
d5053ea
Compare
pkg/meta/resource.go
Outdated
} | ||
|
||
// NewProviderMetadataFromFile loads metadata from the specified YAML-formatted file | ||
func NewProviderMetadataFromFile(path string) (*ProviderMetadata, error) { |
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.
If we're planning on keeping this as single file, would it make sense to use go:embed
similar to schema so we don't need to worry about reading files in Upjet?
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.
Looks like that if we use go:embed
, we don't need to add RootDir
and ProviderMetadataPath
fields to config.Provider
, which is preferable.
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 at some point it's better to split the monolithic provider-metadata.yaml
file. My proposal would be to do the per-resource splitting in further rounds, but we may also do so as part of the ongoing https://github.com/upbound/official-providers/issues/19 issue.
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.
Honestly, I can be convinced either way regarding single or multiple files. But if we do end up going with a single file, I'd prefer to go:embed
it so that we do not deal with file reading at all in Upjet.
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.
Done. We now go:embed
the monolithic provider metadata file. We may later split the provider metadata per resource in the future as discussed.
Thanks @muvaf for the comments! |
Signed-off-by: Alper Rifat Ulucinar <[email protected]>
- Rename Resource.TitleName as Title - Add field documentation for Resource Signed-off-by: Alper Rifat Ulucinar <[email protected]>
Signed-off-by: Alper Rifat Ulucinar <[email protected]>
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.
Thank you @ulucinar ! It's all coming together!!
pkg/config/provider.go
Outdated
ProviderMetadataPath string | ||
// ProviderMetadata is the scraped provider metadata | ||
// from the corresponding Terraform registry. | ||
ProviderMetadata string |
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.
Since we're using this only in NewProvider
, would it make sense to not expose it in Provider
struct?
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.
Done.
pkg/pipeline/example.go
Outdated
"spec": map[string]interface{}{ | ||
"forProvider": exampleParams, | ||
"providerConfigRef": map[string]interface{}{ | ||
"name": "example", | ||
"name": "default", |
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.
nit: we can omit providerConfigRef
altogether since it defaults to default
.
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.
Done.
pkg/registry/resource.go
Outdated
// NewProviderMetadataFromFile loads metadata from the specified YAML-formatted document | ||
func NewProviderMetadataFromFile(providerMetadata string) (*ProviderMetadata, error) { | ||
metadata := &ProviderMetadata{} | ||
if err := yaml.Unmarshal([]byte(providerMetadata), metadata); err != nil { |
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.
Since we're converting to []byte
anyway, we might consider accepting providerMetadata
as []byte
in NewProvider
. go:embed
supports it.
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.
Done.
Signed-off-by: Alper Rifat Ulucinar <[email protected]>
Signed-off-by: Alper Rifat Ulucinar <[email protected]>
Description of your changes
Fixes #6
This PR extends the existing upjet resource configuration API to allow configuration & overrides related to the resource metadata (probably scraped from Terraform registry). Some possible configuration scenarios covered as of now:
azurerm_key_vault_access_policy.example-user
'skey_permissions
attribute.region
attribute for all/select resources inprovider-aws
location
references inprovider-azure
I have:
make reviewable
to ensure this PR is ready for review.backport release-x.y
labels to auto-backport this PR if necessary.How has this code been tested
A resource specific metadata override example:
Or, as expected, a provider-wide metadata configuration can be performed as follows (in for example,
config/provider.go
):An example manifest generated using these configuration overrides on top of scraped metadata:
To configure a unique name to be generated by the test runner, one may use:
The generated example manifest now contains:
which is to be substituted by the test runner at runtime with a random RFC1123 subdomain string.