-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(appmesh): change VirtualService provider to a union-like class #11978
Conversation
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 great @dfezzie ! A few comments here, mainly related to this comment that I made: #9490 (comment) .
Please also add addVirtualService()
methods to both IVirtualNode
and IVirtualRouter
.
Also, I'm fairly sure that's the last point that's left of #9490, so I would add Fixes #9490
to the PR description 🙂.
* @default - At most one of virtualRouter and virtualNode is allowed. | ||
*/ | ||
readonly virtualNode?: IVirtualNode; | ||
readonly virtualServiceProvider?: VirtualServiceProvider; |
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.
2 changes here:
- Let's move this property to
VirtualServiceProps
below. - Let's remove the
mesh
property fromVirtualServiceProps
(no reason to provide it redundantly when aVirtualRouter
orVirtualNode
were provided).
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.
-
Do we not need the provider in the base props? How else will we define what type of resource backs the virtual service?
-
Since the provider is optional, I don't think we can remove the
mesh
property. We still need to know what mesh the VS is created as a part of. We can enforce the mesh properties on the VS and Provider do match.
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.
- We do not, because the provider will be evident from the resource that the
addService
method will be on. For example, forVirtualNode
, it will be:
public addService(props: VirtualServiceBaseProps): IVirtualService: {
return new VirtualService(this, 'VirtualService', {
...props,
provider: ServiceProvider.virtualNode(this),
});
}
And similarly for Mesh
and VirtualRouter
.
- The
provider
should be required, of course 🙂.
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.
So I've provided a comment on #9490 that argues we should not have an addService
method on the IVirtualNode
and IVirtualRouter
classes. Will wait on your response before I do anything here.
Co-authored-by: Adam Ruka <adamruka@amazon.com>
Pull request has been modified.
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.
Putting in "Request changes" to clear this from my ToDo list. @dfezzie make sure to re-request my review when this is ready!
I ended up getting sidetracked and haven't addressed all the feedback quite yet |
No worries, it's all good 🙂 |
Sorry for the long delay. Holidays snuck up on me and then this PR fell off my radar 😅 I've provided a comment on #9490 about the changes requested. Depending on your response there, we may be able to call this PR good to go. |
Pull request has been modified.
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.
@dfezzie I have no problems with not having addService()
methods in IVirtualNode
and IVirtualRouter
. If that's the case, I think you might want to get rid of the existing addVirtualService()
method in IMesh
as well...?
Having said that, I do feel strongly that requiring the user to provide the Mesh twice when creating a Virtual Service with a provider is a mistake (as both a VirtualNode and VirtualRouter already have a Mesh). It's just poor usability.
If you're very opposed to my idea of having a third none()
VirtualServiceProvider, let's at least make IMesh
an optional argument when creating a VirtualService
, and we will not not require it when a provider
has been given. How does that sound?
Pull request has been modified.
I've added the I'm having issues deploying the integ test to my own account, seeing
Not sure if there's a bug with the deprecated props in |
I had to remove ACMPCA and ACM from the integ tests as App Mesh does validate the existence of the resources, and as a result you cannot just import from a fake ARN. I think that should fix the last of the issues with the build. |
backendsDefaultClientPolicy: appmesh.ClientPolicy.fileTrust({ | ||
certificateChain: 'path-to-certificate', | ||
}), |
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.
Not sure when I removed this. Will add back.
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 almost perfect @dfezzie! Just a tiny change in Mesh
, and this will be ready to be shipped.
@@ -89,10 +89,15 @@ abstract class MeshBase extends cdk.Resource implements IMesh { | |||
/** | |||
* Adds a VirtualService with the given id | |||
*/ | |||
public addVirtualService(id: string, props: VirtualServiceBaseProps = {}): VirtualService { | |||
public addVirtualService( |
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.
Sorry, I don't understand these changes 😕.
The whole point of having addVirtualService()
on Mesh is so that you don't have to provide the Mesh again. But with your changes, you can do something like:
const mesh = new appmesh.Mesh(...);
mesh.addVirtualService({
virtualServiceProvider.none(mesh),
});
which just doesn't make sense to me.
I would revert all of these changes here, and this method should be:
public addVirtualService( | |
public addVirtualService(id: string, props: VirtualServiceBaseProps = {}): VirtualService { | |
return new VirtualService(this, id, { | |
...props, | |
virtualServiceProvider: VirtualServiceProvider.none(this), | |
}); | |
} |
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 guess I was thinking of it more as a utility method, a quick way to add a new Virtual Service to your mesh, similar to how we add other resources like Virtual Nodes. If you cannot specify a provider, then essentially the method is useless as it will never produce a usable Virtual Service. If you created a VS as a placeholder and then went to add a provider you would have to remove it from the addVirtualService
method into a new VirtualService(...)
call. How it is here, you could have addVirtualService('VirtualService')
in one synthesized stack which uses the none
method as the default. Later, you could come along and add a different provider if you so choose.
We can remove the method all together if you feel it does not fit well.
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 guess I was thinking of it more as a utility method, a quick way to add a new Virtual Service to your mesh
Right, but if you want to specify any property of the created Service, then it doesn't really save anything, right?
mesh.addVirtualService('Service', {
virtualServiceName: 'MyService',
provider: VirtualServiceProvider.none(mesh),
});
Doesn't save anything over
new VirtualService(this, 'Service', {
virtualServiceName: 'MyService',
provider: VirtualServiceProvider.none(mesh),
});
I think it doesn't make too much sense to over-emphasize the "add a VirtualService to the Mesh with only default properties" use case - it seems to just lead to an awkward API.
, similar to how we add other resources like Virtual Nodes.
Notice that all other methods in the AppMesh module like addVirtualNode()
, addVirtualGateway()
, etc. do not allow you to specify the main owning resource, like the Mesh, again.
I don't think this inconsistency is worth it. I would either not allow passing virtualServiceProvider
in addVirtualService()
, or get rid of this method completely, whichever you prefer (if you go with the later, don't forget to add a BREAKING CHANGE note to the PR description).
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.
For now, let's remove it. You're right that there is no real difference between the two method calls
Pull request has been modified.
Addressed a few comments, waiting for a response before making any final updates 👍 |
…irtualServiceProvider class
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 great! Couple of cosmetic changes before we merge this in.
Pull request has been modified.
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 great @dfezzie!
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Fixes #9490
BREAKING CHANGE: the properties virtualRouter and virtualNode of VirtualServiceProps have been replaced with the union-like class VirtualServiceProvider
addVirtualService
has been removed fromIMesh
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license