Skip to content
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: Support provider.vpcEgress configuration #271

Merged
merged 12 commits into from
Sep 3, 2021

Conversation

fcr1193
Copy link
Contributor

@fcr1193 fcr1193 commented Aug 26, 2021

Hey! I made some updates from this PR #250 (thanks @arei)

This PR address to issues with defining VPC connectors for a google cloud function:

  • First, VPC Connectors can be named with a url (which is the current pattern) or with just the name of the connector if it is within the same project and region. This is described here: https://cloud.google.com/functions/docs/reference/rest/v1/projects.locations.functions#resource:-cloudfunction
  • Second, this PR adds the ability to specify a VPC Egress setting. This is done using the vpcEgress property in the serverless.yml file. This property can take one of four different values:
    • ALL_TRAFFIC
    • PRIVATE_RANGES_ONLY
    • ALL (A shortcut for ALL_TRAFFIC)
    • PRIVATE (A shortcut for PRIVATE_RANGES_ONLY)

I would appreciate if you can give me feedback @pgrzesik

Thank you!

@fcr1193 fcr1193 changed the title Updates to allow VPC Connector configuration Updates to allow VPC Connector Egress Settings configuration Aug 26, 2021
@edgaregonzalez
Copy link

Hi @pgrzesik, do you think that we can move this PR? This feature will be helpful.
Thank you

edgaregonzalez
edgaregonzalez previously approved these changes Aug 27, 2021
Copy link

@edgaregonzalez edgaregonzalez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @fcr1193 - I've checked the changes and it looks okay, but I don't think it's working as intended. Additionally, it would be great to cover proposed changes by tests (see the original PR) so we're sure that they're working correctly and do not break existing functionality

@@ -57,6 +58,17 @@ module.exports = {
});
}

if (funcObject.vpcEgress) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we applying this only if vpcEgress is set directly on function? What is the purpose of provider level setting then? It will never be effective as it will be always overriden by value set on function or not applied at all

Copy link
Contributor Author

@fcr1193 fcr1193 Aug 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! sorry, I'm not following you here. What do you mean that the value will be overwritten?

I have the following configuration (https://i.imgur.com/7kENrcp.png) in my serverless.yml file. I think vpcEgress is configured at the function level.

I deployed using this fork and got the following result:

https://i.imgur.com/tb748wY.png

I wait your answer, thank you!

Copy link
Contributor

@pgrzesik pgrzesik Aug 31, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean here is that while we support vpcEgress setting on provider level, it will never take effect because the logic is applied only when the setting is applied directly on function. I would assume that if it's only set on provider level, then it should be applied to all functions in service, correct?

In the provided example you set the value on function level and that case is covered well, but if you'd like to apply it across your service and set it on provider.vpcEgress, then it just does not work at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! i think i got it, i just applied the change to make it through the provider level.
do you think it's ok?
thanks!

package/lib/compileFunctions.js Outdated Show resolved Hide resolved
Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @fcr1193 - I think the logic needs to be changed to support vpcEgress set on provider level, please let me know what do you think.

@fcr1193 fcr1193 requested a review from pgrzesik August 31, 2021 15:52
Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @fcr1193 👋 Thanks for update, unfortunatelly I don't think it's working at the moment, the tests are failing as I believe now function-level setting is fully ignored. Please see my comments and let me know what do you think

@@ -57,6 +59,15 @@ module.exports = {
});
}

if (vpcEgress) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like now it ignores the setting on function level, is that the case or am I missing something here? It should override provider-level setting with function-specifc setting

@@ -767,4 +767,129 @@ describe('CompileFunctions', () => {
});
});
});

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to add test case that covers support for provider-level setting as well as how provider-level setting is overriden by more specific function-level configuration

@fcr1193
Copy link
Contributor Author

fcr1193 commented Sep 1, 2021

Hey @pgrzesik how are you? I just added some updates, let me know what you think! thanks!

@fcr1193 fcr1193 requested a review from pgrzesik September 1, 2021 19:53
Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @fcr1193 🙇 I have a few minor remarks and we should be good to go 👍

@@ -20,11 +20,14 @@ module.exports = {
this.serverless.service.getAllFunctions().forEach((functionName) => {
const funcObject = this.serverless.service.getFunction(functionName);

funcObject.vpcEgress = funcObject.vpcEgress || this.serverless.service.provider.vpcEgress;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's assign it to a new variable instead of mutating the original funcObject

});
});

it('should replace vpc egress private at provider level for a vpc egress all defined at function level', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need just a single test for provider being overrided by function level setting. These further tests are not really needed so let's remove them

@fcr1193 fcr1193 requested a review from pgrzesik September 3, 2021 12:51
@fcr1193
Copy link
Contributor Author

fcr1193 commented Sep 3, 2021

Hey @pgrzesik, how are you? thanks for your review, I just updated this!

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @fcr1193 - it looks great 👍

@pgrzesik pgrzesik changed the title Updates to allow VPC Connector Egress Settings configuration feat: Support provider.vpcEgress configuration Sep 3, 2021
@pgrzesik pgrzesik merged commit 269df15 into serverless:master Sep 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants