-
Notifications
You must be signed in to change notification settings - Fork 260
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
✨ Add feature to create ports with custom options #876
Conversation
Welcome @macaptain! |
Hi @macaptain. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
b09e153
to
efe3693
Compare
// inherit port security groups from the instance if not explicitly specified | ||
securityGroups := net.PortOpts.SecurityGroups | ||
if securityGroups == nil { | ||
securityGroups = instanceSecurityGroups | ||
} |
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.
Can this logic move to before 126? it is easier to understand constructing security groups(from line 114-126) then construct nets(from line 128-164).
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.
The security groups can be set on a port and can be different per port, so I don't think we can put this before 126, before we've looped through the nets and ports in the spec.
SecurityGroups could be added as a field to the Network struct and we could set this default in lines 128-164, instead of in getOrCreatePort
. I wonder also if constructing nets should be pulled into a separate function, as I agree it takes some understanding, and could also use some tests. Let me make those changes and you can tell me what you think.
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.
Thanks, I understand we can not move this before 126. Please make a separate function as you think.
/ok-to-test |
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 gave it a first high-level review, overall lgtm.
@iamemilio if you have some time to spare to review this, that would be great :)
// no port found, so create the port | ||
description := net.PortOpts.Description | ||
if description == "" { | ||
description = fmt.Sprintf("Created by cluster-api-provider-openstack cluster %s", clusterName) |
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.
Should be adjusted once: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/pull/870/files is merged (which should be soon)
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've updated to use this new function to get the default description (if none is provided in the port options).
@macaptain I think we will get #863 and #870 merged soon, then you're a bit safer against rebase conflicts |
Sure, no problem, I don't mind rebasing when it's needed. |
Yup, just wanted to let you know in case you want to wait a day or so with the rebase so you only have to do it once. Not sure how problematic to rebase the conflicts will be. |
Thanks, I'll have a look at this today and try to fix up this failure. |
3f65607
to
7281a49
Compare
lgtm :) |
@macaptain Is this still WIP? |
@@ -116,6 +116,38 @@ type SubnetFilter struct { | |||
NotTagsAny string `json:"notTagsAny,omitempty"` | |||
} | |||
|
|||
type PortOpts 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.
as follow up, we may need consider add some samples in how to use this opts (not this PR)
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 can certainly add additional documentation in a follow up PR.
This commit adds a new field to the v1alpha4 API: OpenStackMachineTemplateSpec.ports. The list of ports are added per instance. Each port may be customized with options. These ports are created in addition to any ports created in the `networks:` field. If `networks:` is not specified, only the ports specified in `ports:` will be created and attached to the instance. If neither `networks:` nor `ports:` are specified, the instance will be connected to the default cluster network and subnet. This feature is very much based on the work on jsen-, and a lot of credit goes there for the implementation: kubernetes-sigs#778
} | ||
|
||
type FixedIP struct { | ||
SubnetID string `json:"subnetId"` |
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.
One thought: it would be possible here is to make the type SubnetParam
instead of specifying the subnet only with SubnetID. Then (with additional code) it would be possible to specify this subnet with a filter, like the networks can be specified with a filter. Would that be desirable? It would be different from the OpenShift interface. I also think it would be possible to add a SubnetFilter
as an additional optional field in the future if we wanted.
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.
That would be cool. That is probably a good idea for a lot of these fields that only take IDs as an input, but might be content for another iteration
I've taken WIP off the PR. I've been testing this manually and I'm happy with the implementation. The feature meets my requirements. The only question for me is would you prefer I use 'Filters' for NetworkId / SubnetId / SecurityGroups so that these fields can be chosen by details other than Id. If you want, I can look at implementing that before the API gets fixed in place. If not, let's look to merge this as it is. Thanks very much! |
I do not need filters for these fields. Another PR would be proposed if someone wants 😃 /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hidekazuna, macaptain 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 |
/remove-hold |
@sbueringer @jichenjc PTAL |
/lgtm let's merge this and continue evolution |
This commit adds a new field to the v1alpha4 API: OpenStackMachineTemplateSpec.ports.
The list of ports are added per instance. Each port may be customized with options. These ports are created in addition to any ports created in the
networks:
field.If
networks:
is not specified, only the ports specified inports:
will be created and attached to the instance. If neithernetworks:
norports:
are specified, the instance will be connected to the default cluster network and subnet.This feature is very much based on the work on @jsen-, and a lot of credit goes there for the implementation:
#778
Example spec to give you some idea. Creates exactly three ports, two ports on the same network on different subnets with different VNIC types and a further example showing how to add security groups.
What this PR does / why we need it:
I'd like to be able to have instances on different networks with different settings per port. In particular, customizable VNIC types and customizable security groups.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #788
Special notes for your reviewer:
This PR is about trying to get #778 merged to master, so firstly, huge credit + thanks to @jsen- for the implementation (plus the OpenShift fork was a very helpful reference so thanks to those working on that too). I've taken on board the comments in the original PR and:
In addition, I've changed the behavior slightly with regard to defaults:
networks:
isn't specified, you get your port on the default cluster network. Now if neithernetworks:
norports:
is specified, you get this default.NetworkID
used to be required. Now if unspecified, it defaults to the default cluster network.NameSuffix
used to be mandatory. Now if unspecified, it defaults to the 0-based index of the port of the instance.I've tried to keep the API consistent with this project, but also similar to the OpenShift fork, maybe @iamemilio could comment on that.
TODOs:
/hold