add design for managing IPs on secondary networks #39
Conversation
dhellmann
requested review from
celebdor,
imain,
hardys,
juliakreger,
russellb and
markmc
| the external DHCP server pass PXE requests to the dnsmasq instance | ||
| that is part of the metal3 deployment, and which might change hosts | ||
| and IPs if the pod is restarted. | ||
|
|
There was a problem hiding this comment.
Well, I guess we could do this, but I think it would require writing a new dhcp option backend for ironic and having some kind of agent on the dhcp server to update the configurations. Currently dnsmasq and ironic need to have access to the same filesystem.
There was a problem hiding this comment.
Yeah, this is an alternative so the details won't matter as much because we aren't going to do it.
There was a problem hiding this comment.
Ironic is working with static configuration in this case, and as long as it points back to a vip that ironic can be on, then the world is a happy place. If not, then... we'll need to be able to set configuration.
There was a problem hiding this comment.
AFAIK ironic only manages the pxe configuration - the dnsmasq configuration is static and in a different container to the ironic conductor?
There was a problem hiding this comment.
the dnsmasq configuration is static - yes, in a different container to the ironic conductor - yes (although built from ironic's Dockerfile for some reason). What ironic does modify is PXE configuration, but this is not related to the discussion.
There was a problem hiding this comment.
Right I see, I was confused. It's really just the TFTP config we are updating. So we could separate those if we wanted.
| 1. Ensure the IPAM service is deployed along with the other metal3 | ||
| components. | ||
| 1. Update the metal3 machine controller to allocate IPs and create | ||
| host-specific ignition configurations containing the IPs. |
There was a problem hiding this comment.
A few of these work items are OpenShift / CoreOS specific, the "installer" and "ignition" references.
The machine controller is not involved today in creating the ignition config (or cloud-init config, or whatever user data is in use), so maybe this should go somewhere else.
I expect management of secondary interfaces should be done by something else, like https://github.com/nmstate/kubernetes-nmstate
an IPAM component allocating addresses for secondary network interfaces could then create the CRs that specify that the interface should be configured with that IP, and applying the configuration would be done by kubernetes-nmstate
There was a problem hiding this comment.
Yeah, I was trying to make sure I didn't miss anything. Should I move this doc to an internal location?
There was a problem hiding this comment.
no need for it to be internal. It just depends if we come up with something that's more generally useful, or is an OpenShift specific integration thing. If it's just for OpenShift integration, the openshift-metal3 github org has a docs repo as well that hasn't been used much yet.
Speaking of OpenShift specific solutions and how to do network config ... I wonder if the existing MachineConfig resource is enough, provided by the machine-config-operator. We can create those resources to drop new config files on nodes, or to replace existing config files.
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
metal3-io-bot
added
the
lifecycle/stale
|
Stale issues close after 30d of inactivity. Reopen the issue with /close |
|
@metal3-io-bot: Closed this PR. In response to this:
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. |
No description provided.