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

Propose updates to ExternalEntity CRD named port usage #1227

Closed
abhiraut opened this issue Sep 10, 2020 · 10 comments
Closed

Propose updates to ExternalEntity CRD named port usage #1227

abhiraut opened this issue Sep 10, 2020 · 10 comments
Assignees
Labels
kind/design Categorizes issue or PR as related to design. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Comments

@abhiraut
Copy link
Contributor

Lets discuss the proposal based on discussion #1084 (comment) on this issue.

In a nutshell, it is proposed that we update the ExternalEntity CRD spec to remove named ports per interface and instead associate named ports with the entity itself. This would require a change in the GroupMember struct used in internal communications.
Following are the proposed changes:

ExternalEntity CRD

type ExternalEntitySpec struct {
        Endpoints []Endpoint
+       Ports []NamedPort
        ExternalNode string
}
type Endpoint struct {
        IP string
        Name string
-       Ports []NamedPort
}

Change proposed to the GroupMember struct:

type GroupMember struct {
	Pod *PodReference
	ExternalEntity *ExternalEntityReference
	IPs []IPAddress
	Ports []NamedPort
}
@abhiraut abhiraut added the kind/design Categorizes issue or PR as related to design. label Sep 10, 2020
@abhiraut
Copy link
Contributor Author

/cc @jianjuns @tnqn @suwang48404 @Dyanngg

@Dyanngg Dyanngg added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Sep 10, 2020
@Dyanngg
Copy link
Contributor

Dyanngg commented Sep 10, 2020

Thanks @abhiraut for creating the issue. CC @wenyingd as the proposed GroupMember struct change affects dual stack pod processing.

@Dyanngg
Copy link
Contributor

Dyanngg commented Sep 10, 2020

@suwang48404 Are we good with the proposed change in EE crd? i.e.

--- a/build/yamls/base/crds.yml
+++ b/build/yamls/base/crds.yml
@@ -547,16 +547,16 @@ spec:
                     format: ipv4
                   name:
                     type: string
-                  ports:
-                    type: array
-                    items:
-                      type: object
-                      properties:
-                        protocol:
-                          type: string
-                        port:
-                          x-kubernetes-int-or-string: true
-                        name:
-                          type: string
+            ports:
+              type: array
+              items:
+                type: object
+                properties:
+                  protocol:
+                    type: string
+                  port:
+                    x-kubernetes-int-or-string: true
+                  name:
+                    type: string
             externalNode:
               type: string

@suwang48404
Copy link
Contributor

suwang48404 commented Sep 10, 2020

I am sorry, what is difference before and after this change? can u summarize, yaml is bit harder to read.

If we are going to change EE format, it will have impact on projects already depends on its older format. So versioning may be a good way to go on this?

Thx, Su

@Dyanngg
Copy link
Contributor

Dyanngg commented Sep 10, 2020

As summarized in the issue base, the proposed change is to move the ports array from being a property of endpoint, to a property that belongs to the base spec of externalEntity. This way we do not duplicate this information for each endpoint. @abhiraut to comment on versioning

@jianjuns
Copy link
Contributor

type GroupMember struct {
	Pod *PodReference
	ExternalEntity *ExternalEntityReference
	IPs []IPAddress
	Ports []NamedPort
}

Questions

  1. IPs are used in AddressGroup only right?
  2. For AppliedToGroup, do we have the requirements to apply to part of interfaces/endpoints in the VM?

@abhiraut
Copy link
Contributor Author

yes for 1. i was thinking we will do what we have been doing with GroupMemberPod conversions, i.e. includeIP only if generating GroupMember for AddressGroups

  1. @suwang48404 could answer that one

@jianjuns
Copy link
Contributor

Thought over. Anyway we might extend GroupMember to have an Endpoints field then. So, the current definition looks good.

@github-actions
Copy link
Contributor

github-actions bot commented Apr 1, 2021

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment, or this will be closed in 180 days

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 1, 2021
@Dyanngg
Copy link
Contributor

Dyanngg commented Apr 3, 2021

fixed by #1335

@Dyanngg Dyanngg closed this as completed Apr 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/design Categorizes issue or PR as related to design. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants