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

Make external load balancer config optional #269

Closed
pablochacin opened this issue Feb 5, 2019 · 8 comments
Closed

Make external load balancer config optional #269

pablochacin opened this issue Feb 5, 2019 · 8 comments
Assignees
Labels
kind/design Categorizes issue or PR as related to design. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone

Comments

@pablochacin
Copy link
Contributor

Presently, if multiple control-plane replicas are specified, it is mandatory to specify an external-load-balancer node in the configuration. However, this node configuration can have only one replica and the image parameter is optional, therefore, it would be trivial for the create cluster command to provide the necessary values for launching an external load-balancer if needed.

Forcing to have the external-load-balancer node specification seams more a convenience for maintaining a consistent configuration format (a developer convenience) than a user convenience.

Therefore, it would be convenient for users to have the external load-balancer defined by default if multiple control plane are defined, making the node configuration necessary only if the defaults need to be overridden (e.g. change the image).

@neolit123
Copy link
Member

i will have a stab at this today.
/assign
/kind design
/priority important-soon

@k8s-ci-robot k8s-ci-robot added kind/design Categorizes issue or PR as related to design. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Feb 5, 2019
@BenTheElder
Copy link
Member

I'd like to actually remove it from the nodes field too or come up with something more clever because the node keys (eg kubeadm config) are not valid for the load balancer as well.

@neolit123
Copy link
Member

but the image field is valid if we want to support a custom LB, i guess?

@pablochacin
Copy link
Contributor Author

Actually the only reason not to remove the node definition is to been able to specify the load balancer. However, this could be a cluster parameter lile load-balancer-image

@BenTheElder
Copy link
Member

BenTheElder commented Feb 5, 2019

I think we should nest it at least like this so we can add other load balancer fields under a subsection if necessary later:

kind: Config
nodes:
  - ...
# optional with defaulting, applies to the control plane LB if one will be provisioned
loadBalancer:
  image:  ...

But you could also imagine more generally setting some control plane details:

kind: Config
nodes:
  - ...
# optional with defaulting, controls control plane details in general
controlPlane:
  # perhaps later we add a field like:
 # address: "127.0.0.1:6443"
 # optional with defaulting, applies to the control plane LB if one will be provisioned
  loadBalancer:
    image:  ...

@pablochacin
Copy link
Contributor Author

Adding it nested under controlPlane makes sense.

@BenTheElder BenTheElder added this to the 1.0 milestone Feb 6, 2019
@neolit123
Copy link
Member

/unassign
alpha3 will support this.

@BenTheElder
Copy link
Member

this is done.

@BenTheElder BenTheElder self-assigned this Mar 13, 2019
stg-0 pushed a commit to stg-0/kind that referenced this issue Sep 8, 2023
* bump capx versions

* update CHANGELOG
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. 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

No branches or pull requests

4 participants