Dual-stack support #213
steven.hardy
amorgante
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: suse-edge/Factory#213
Reference in New Issue
Block a user
No description provided.
Delete Branch "mchiappero/Factory:dual-stack"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Dual stack changes, opening mainly as I need some automated build.
The way the ironic-image processes are bound to internet sockets is mainly by PROVISIONING_IP or PROVISIONING_INTERFACE, that is, by looking up a specific address on an interface, or a specific interface for a workable address. Introduce two new utility functions in ironic-common.sh for these two purposes: get_interface_of_ip: returns the name of the interface where the IP address provided as argument is found get_ip_of_interface: returns the first IP associated to the interface provided as argument These two functions will be put into use in subsequent commits. Signed-off-by: Marco Chiappero <marco.chiappero@suse.com>0bc2daef56to412c22c5dc412c22c5dcto5488424be681f7820063to84c10d362d84c10d362dto64dbd45461c508493bd6to39cc72476a39cc72476ato3075872a0c3075872a0ctoe6481eb220e6481eb220to653a8e5b2c653a8e5b2cto1eb9fd63181eb9fd6318tof98d3d5c1ef98d3d5c1etoa3096005faa3096005fato84174e428c84174e428cto8630cca6178630cca617todbc8e0975bdbc8e0975btobb815874ae9c526f084etof260540edbf260540edbto3b51a9d144WIP: dual-stackto dual-stackOkay, I think it's good to go now, if you could PTAL... There are only a couple of things I would like to explore, that is, 1) the use of IRONIC_URL_HOSTNAME in ironic.conf for CONDUCTOR_HOST and host_ip when available 2) the use of ::1 when we have IRONIC_IPV6 for ProxyPass in Apache.
Other than that, I have a few manual tests I would like to run before being reasonably safe it's all right, but it's starting to look good to me, so take a look and let me know if there is anything that doesn't look good to you.
On a side note, setting the LISTEN_ALL_INTERFACES to false requires a change for the liveness and readiness probes... I wonder if we should let the user choose if to bind on localhost in addition to the provisioning/hostname IP(s). What do you think?
Oh, and need to reword a few commit messages.
3b51a9d144to54357a748a54357a748ato6dd551f7db6dd551f7dbtoe5f765ec69LGTM overall, few things need attention, would be nice to have a matching PR upstream, so that we keep in sync as much as possible.
@@ -24,3 +24,3 @@#!ArchExclusiveLine: aarch64RUN if [ "$(uname -m)" = "aarch64" ];then \zypper --installroot /installroot --non-interactive install --no-recommends python311-devel python311 python311-pip python311-sushy-oem-idrac python311-proliantutils python311-sushy python311-pyinotify python3-ironicclient git curl sles-release tar gzip vim gawk dnsmasq dosfstools apache2 apache2-mod_wsgi ipcalc ipmitool iproute2 procps qemu-tools sqlite3 util-linux xorriso tftp ipxe-bootimgs python311-sushy-tools crudini openstack-ironic; \zypper --installroot /installroot --non-interactive install --no-recommends python311-devel python311 python311-pip python311-sushy-oem-idrac python311-proliantutils python311-sushy python311-pyinotify python3-ironicclient git curl sles-release tar gzip vim gawk dnsmasq dosfstools apache2 apache2-mod_wsgi ipcalc ipmitool iproute2 bind-utils procps qemu-tools sqlite3 util-linux xorriso tftp ipxe-bootimgs python311-sushy-tools crudini openstack-ironic; \nit: might be easier to maintain by having a first RUN instruction with all packages common for the two architectures, then a RUN line for each architecture with arch-specific items
Or a variable pulled by both, to avoid unnecessary layers in the container.
The layers here are in first stage container, and OBS will not be able to follow a variable here, so better split in two here
@@ -43,4 +124,1 @@local interface="provisioning"if [[ -n "${PROVISIONING_IP}" ]]; thenWe may want to keep this kind of behavior of setting the interface from the IP as this information is used by PXE setup.
It still works that way, the interface name is derived at wait_for_interface_or_ip now from the PROVISIONING_IP (fixing a lookup at a point where the IP might not be present anyway) and set into PROVISIONING_INTERFACE . What changes is the use of "provisioning" as default value, which will result in an obscure error when looking it up on the system: it's best to fail cleanly.
That being said, since PROVISIONING_INTERFACE is an input, it should not be changed, it's one of the many hints of how little design and thinking it has gone through these scripts.
@nbelouin @steven.hardy Regarding the VirtualHost directive for the Ironic API, I wonder if it shouldn't include any IRONIC_EXTERNAL_IP or IRONIC_EXTERNAL_HTTP_URL. If so... it has always been buggy then?
Edit: I mean, listen to ALL, but Ironic API that should be reachable by both the provisioning network (either by hostname or IPs) and the BMC one (either by hostname or IPs). Unfortunately Ironic can have many different combinations and corner cases...
dual-stackto Dual-stack supporte5f765ec69toe2d38a867c