-
Notifications
You must be signed in to change notification settings - Fork 226
Consolidate service naming nomenclature #213
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
Consolidate service naming nomenclature #213
Conversation
e2c095c to
640b4f8
Compare
vijtrip2
left a comment
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.
LGTM! Very nice work!
|
/test all |
jaypipes
left a comment
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 actually think #211 should be reverted.
If there are services like opensearchservice and elbv2 that have a name for the model package in aws-sdk-go/models/apis directory, we should add a field to the generator.yaml file that allows the code generator to understand this. Asking developers to both remember to supply a --model-name argument and remember what that argument value should be is a bad contributor experience, particularly for the team that is maintaining those peculiar services.
Yeah in retrospect this is a way better solution. I absolutely agree. I have created #215 to revert this. |
4c2b753 to
c50ecb1
Compare
c50ecb1 to
b3df21c
Compare
|
None of the e2e tests will pass, because none of them have been updated to runtime |
It's not that the tests are not compiling the controllers properly. They are. It's that the tests are starting the controller using a now-deprecated flag:
|
ACK runtime v0.15.0 removed support for the `--aws-account-id` controller flag but our deployment templates were still adding this flag to the controller entrypoint args, which causes tests to fail with: ``` unknown flag: --aws-account-id ``` Related: aws-controllers-k8s#213 See: aws-controllers-k8s/runtime@6080101 Signed-off-by: Jay Pipes <jaypipes@gmail.com>
ACK runtime v0.15.0 removed support for the `--aws-account-id` controller flag but our deployment templates were still adding this flag to the controller entrypoint args, which causes tests to fail with: ``` unknown flag: --aws-account-id ``` Related: #213 See: aws-controllers-k8s/runtime@6080101 Signed-off-by: Jay Pipes <jaypipes@gmail.com> By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
fea3a3b to
fe2c5fd
Compare
|
/test dynamodb-controller-test |
ACK runtime v0.15.0 removed support for the `--aws-account-id` controller flag but our deployment templates were still adding this flag to the controller entrypoint args, which causes tests to fail with: ``` unknown flag: --aws-account-id ``` Related: aws-controllers-k8s#213 See: aws-controllers-k8s/runtime@6080101 Signed-off-by: Jay Pipes <jaypipes@gmail.com> By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
jaypipes
left a comment
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.
Much cleaner. ++
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jaypipes, RedbackThomson, vijtrip2 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Issue #, if available: aws-controllers-k8s/community#994
Description of changes:
This pull request replaces all templates and variables with a defined nomenclature. The current code-generator uses service name terms interchangeably, which eventually lead to the linked issue. While PR #211 solved the logical issue of overriding the service model name, in some cases, it did not do a clear job of clarifying what names exist for any service and when they are applicable.
There are 3 different names that are used to programmatically reference a service. Here are the terms I am using in this PR to refer to them, and their given purpose:
metadata.serviceIDfield from the modelapi-2.jsonfileapi-2.jsonfileSome examples on when these differ:
sfnfor its ID and alias, butstatesfor its model nameelbv2for its alias, butelasticloadbalancingv2for its ID and model nameThere are also 2 names defined in the controller metadata file that are not used in any parts of the code, but are used in documentation:
Amazon Elastic Cloud Compute)EC2)By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.