TripleO deployment over IPV6
Hi Team, We were trying to perform IPV6-based deployment of TripleO. We are following the link: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.... As per our environment, we set the "ipv6_address_mode" to "dhcpv6-stateful" and tried undercloud deployment. It was successful. But when we try node introspection, openstack is not providing an IP that will be used for PXE booting the system. We have enabled PXE booting on the IPV6 network. On Dell machines, we get the following error: "PXE-E16: No offer received." For your reference, the undercloud file which we used is attached. We also tried to find the communication happening on the br-ctlplane interface when the machine tries to boot over IPV6 PXE boot. I am attaching those tcpdump records as well. We are unable to find the MAC address of our machines. *Questions:* 1. Is it even possible to perform tripleO deployment with IPV6? 2. Do we need to do some extra settings, so that our baremetal machines can be PXE booted? Thanks and Regards
Hi Takashi/ Team, Any inputs with respect to the same will be of great help. Thanks, Lokendra On Tue, Jul 25, 2023 at 4:29 PM Kushagr Gupta <kushagrguptasps.mun@gmail.com> wrote:
Hi Team,
We were trying to perform IPV6-based deployment of TripleO. We are following the link:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16....
As per our environment, we set the "ipv6_address_mode" to "dhcpv6-stateful" and tried undercloud deployment. It was successful.
But when we try node introspection, openstack is not providing an IP that will be used for PXE booting the system. We have enabled PXE booting on the IPV6 network. On Dell machines, we get the following error: "PXE-E16: No offer received."
For your reference, the undercloud file which we used is attached. We also tried to find the communication happening on the br-ctlplane interface when the machine tries to boot over IPV6 PXE boot. I am attaching those tcpdump records as well. We are unable to find the MAC address of our machines.
*Questions:* 1. Is it even possible to perform tripleO deployment with IPV6? 2. Do we need to do some extra settings, so that our baremetal machines can be PXE booted?
Thanks and Regards
-- ~ Lokendra skype: lokendrarathour
Greetings, I don't think I saw your original email. I suspect because you indicated there was an attachment, it might have been filtered for moderation by the mailing list. On Tue, Jul 25, 2023 at 6:24 AM Lokendra Rathour <lokendrarathour@gmail.com> wrote:
Hi Takashi/ Team, Any inputs with respect to the same will be of great help.
Thanks, Lokendra
On Tue, Jul 25, 2023 at 4:29 PM Kushagr Gupta < kushagrguptasps.mun@gmail.com> wrote:
Hi Team,
We were trying to perform IPV6-based deployment of TripleO. We are following the link:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16....
Try following the more recent documents, specifically OSP16.1 or 16.2.
As per our environment, we set the "ipv6_address_mode" to
"dhcpv6-stateful" and tried undercloud deployment. It was successful.
Good, that is required for IPv6 PXE.
But when we try node introspection, openstack is not providing an IP that
will be used for PXE booting the system. We have enabled PXE booting on the IPV6 network. On Dell machines, we get the following error: "PXE-E16: No offer received."
I suspect we will need to see the configuration. Paste.opendev.org?
For your reference, the undercloud file which we used is attached.
We also tried to find the communication happening on the br-ctlplane interface when the machine tries to boot over IPV6 PXE boot. I am attaching those tcpdump records as well. We are unable to find the MAC address of our machines.
I suspect this might be in the territory of the hardware, while being set for IPv6 network booting, maybe the configuration needs to be checked/reasserted on the interface level. It sounds as if it is using a different interface.
Not seeing the expected MAC addresses is rather suspect in this case, although PXE with v6 is a little different pattern wise. Have you tried mirroring the port your expecting to see traffic cross from the physical machine to see if it is seeing the announcements and issuing the DHCPv6 packets required? Additionally is this UEFI mode or Legacy BIOS mode?
*Questions:*
1. Is it even possible to perform tripleO deployment with IPV6? 2. Do we need to do some extra settings, so that our baremetal machines can be PXE booted?
Thanks and Regards
-- ~ Lokendra skype: lokendrarathour
Hi Team,Julia, @Julia Thank you for the response.
Additionally is this UEFI mode or Legacy BIOS mode? We are using UEFI.
We tried introspection for two nodes from the undercloud node. Te following is our observation: 1. Undercloud is assigning an IPV6 IP to the node. The PXE boot Failed with the following error: PXE-E99: Unexpected network error. On further debuging this issue, We found that a container: ironic_pxe_tftp is in unhealthy state. But this container should be running. On checking the logs, we found the following: " [root@undercloud-ete log]# podman logs 356715c49cd4 dnsmasq: bad command line options: try --help dnsmasq: bad command line options: try --help dnsmasq: bad command line options: try --help " We had previously raised this issue in 2022 as well: https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029062.htm... For this a bug was raised which was fixed https://bugs.launchpad.net/tripleo/+bug/1978892 We cross-verified, and the changes are present on our undercloud. But still we are unable to start the ironic_pxe_tftp container. Could you please help us with this? Thanks and Regards Kushagra Gupta On Tue, Jul 25, 2023 at 8:10 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
Greetings,
I don't think I saw your original email. I suspect because you indicated there was an attachment, it might have been filtered for moderation by the mailing list.
On Tue, Jul 25, 2023 at 6:24 AM Lokendra Rathour < lokendrarathour@gmail.com> wrote:
Hi Takashi/ Team, Any inputs with respect to the same will be of great help.
Thanks, Lokendra
On Tue, Jul 25, 2023 at 4:29 PM Kushagr Gupta < kushagrguptasps.mun@gmail.com> wrote:
Hi Team,
We were trying to perform IPV6-based deployment of TripleO. We are following the link:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16....
Try following the more recent documents, specifically OSP16.1 or 16.2.
As per our environment, we set the "ipv6_address_mode" to
"dhcpv6-stateful" and tried undercloud deployment. It was successful.
Good, that is required for IPv6 PXE.
But when we try node introspection, openstack is not providing an IP that
will be used for PXE booting the system. We have enabled PXE booting on the IPV6 network. On Dell machines, we get the following error: "PXE-E16: No offer received."
I suspect we will need to see the configuration. Paste.opendev.org?
For your reference, the undercloud file which we used is attached.
We also tried to find the communication happening on the br-ctlplane interface when the machine tries to boot over IPV6 PXE boot. I am attaching those tcpdump records as well. We are unable to find the MAC address of our machines.
I suspect this might be in the territory of the hardware, while being set for IPv6 network booting, maybe the configuration needs to be checked/reasserted on the interface level. It sounds as if it is using a different interface.
Not seeing the expected MAC addresses is rather suspect in this case, although PXE with v6 is a little different pattern wise. Have you tried mirroring the port your expecting to see traffic cross from the physical machine to see if it is seeing the announcements and issuing the DHCPv6 packets required?
Additionally is this UEFI mode or Legacy BIOS mode?
*Questions:*
1. Is it even possible to perform tripleO deployment with IPV6? 2. Do we need to do some extra settings, so that our baremetal machines can be PXE booted?
Thanks and Regards
-- ~ Lokendra skype: lokendrarathour
On Thu, Jul 27, 2023 at 4:41 AM Kushagr Gupta <kushagrguptasps.mun@gmail.com> wrote:
Hi Team,Julia,
@Julia Thank you for the response.
Additionally is this UEFI mode or Legacy BIOS mode? We are using UEFI.
We tried introspection for two nodes from the undercloud node. Te following is our observation: 1. Undercloud is assigning an IPV6 IP to the node.
The PXE boot Failed with the following error: PXE-E99: Unexpected network error.
I guess what is weird in this entire thing is it sounds like you're shifting over to what appears to be OPROM boot code in a network interface card, which might not support v6. Then again a port mirrored packet capture would be the needful item to troubleshoot further.
On further debuging this issue, We found that a container: ironic_pxe_tftp is in unhealthy state. But this container should be running. On checking the logs, we found the following: " [root@undercloud-ete log]# podman logs 356715c49cd4
dnsmasq: bad command line options: try --help
dnsmasq: bad command line options: try --help
dnsmasq: bad command line options: try --help
Are you able to extract the exact command line which is being passed to the dnsmasq process for that container launch? I guess I'm worried if somehow dnsmasq changed or if an old version is somehow in the container image you're using. "
We had previously raised this issue in 2022 as well:
https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029062.htm...
For this a bug was raised which was fixed https://bugs.launchpad.net/tripleo/+bug/1978892
We cross-verified, and the changes are present on our undercloud. But still we are unable to start the ironic_pxe_tftp container.
Could you please help us with this?
Thanks and Regards Kushagra Gupta
On Tue, Jul 25, 2023 at 8:10 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
Greetings,
I don't think I saw your original email. I suspect because you indicated there was an attachment, it might have been filtered for moderation by the mailing list.
On Tue, Jul 25, 2023 at 6:24 AM Lokendra Rathour < lokendrarathour@gmail.com> wrote:
Hi Takashi/ Team, Any inputs with respect to the same will be of great help.
Thanks, Lokendra
On Tue, Jul 25, 2023 at 4:29 PM Kushagr Gupta < kushagrguptasps.mun@gmail.com> wrote:
Hi Team,
We were trying to perform IPV6-based deployment of TripleO. We are following the link:
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16....
Try following the more recent documents, specifically OSP16.1 or 16.2.
As per our environment, we set the "ipv6_address_mode" to
"dhcpv6-stateful" and tried undercloud deployment. It was successful.
Good, that is required for IPv6 PXE.
But when we try node introspection, openstack is not providing an IP
that will be used for PXE booting the system. We have enabled PXE booting on the IPV6 network. On Dell machines, we get the following error: "PXE-E16: No offer received."
I suspect we will need to see the configuration. Paste.opendev.org?
For your reference, the undercloud file which we used is attached.
We also tried to find the communication happening on the br-ctlplane interface when the machine tries to boot over IPV6 PXE boot. I am attaching those tcpdump records as well. We are unable to find the MAC address of our machines.
I suspect this might be in the territory of the hardware, while being set for IPv6 network booting, maybe the configuration needs to be checked/reasserted on the interface level. It sounds as if it is using a different interface.
Not seeing the expected MAC addresses is rather suspect in this case, although PXE with v6 is a little different pattern wise. Have you tried mirroring the port your expecting to see traffic cross from the physical machine to see if it is seeing the announcements and issuing the DHCPv6 packets required?
Additionally is this UEFI mode or Legacy BIOS mode?
*Questions:*
1. Is it even possible to perform tripleO deployment with IPV6? 2. Do we need to do some extra settings, so that our baremetal machines can be PXE booted?
Thanks and Regards
-- ~ Lokendra skype: lokendrarathour
Hi Julia,Team, Thank you for the response @Julia Kreger <juliaashleykreger@gmail.com> On Thu, Jul 27, 2023 at 6:59 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I guess what is weird in this entire thing is it sounds like you're shifting over to what appears to be OPROM boot code in a network interface card, which might not support v6. Then again a port mirrored packet capture would be the needful item to troubleshoot further.
We have setup a local dnsmasq-dhcp server and TFTP server on a VM and tried PXE booting the same set of hardwares. The hardware are booting on IPV6 so I think the hardware supports IPV6 PXE booting.
Are you able to extract the exact command line which is being passed to the dnsmasq process for that container launch?
I guess I'm worried if somehow dnsmasq changed or if an old version is somehow in the container image you're using.
The command line which is getting executed is as follows: " "command": [ "/bin/bash", "-c", "BIND_HOST=ca:ca:ca:9900::171; /usr/sbin/dnsmasq --keep-in-foreground --log-facility=/var/log/ironic/dnsmasq.log --user=root --conf-file=/dev/null --listen-address=$BIND_HOST --port=0 --enable-tftp --tftp-root=/var/lib/ironic/tftpboot" ], " We found this command in the following: /var/lib/tripleo-config/container-startup-config/step_4/ironic_pxe_tftp.json Apart from this we also tried to install the openstack version zed. In this version, the container ironic_pxe_tftp is up and running but we were still getting the same error: [image: image.png] We tried to curl the file which the TFTP container provides from a remote machine(not the undercloud), but we are unable to curl it. [image: image.png] But when, we do the same thing from the undercloud, it is working fine: [image: image.png] We also set up an undercloud machine on ipv4 for comparison. When we tried to curl the image from a remote machine(not the undercloud) for this server, we were able to curl it. [image: image.png] On further digging, we found that in the zed release, the "ironic_pxe_tftp" is in *healthy *state while three containers namely: "ironic_api","ironic_conductor","ironic_pxe_http" are in *unhealthy *state but are up and running. We re-installed the undercloud on the fresh machine and re-tried node introspection after performing basic tasks like image upload, node registration. To our surprise, the Introspection was successful. and the nodes came in available state: [image: nodes_available_4.PNG] At this point we were also able to curl the file from a random machine: [image: image.png] But it all stopped once we restarted the undercloud node even though all the containers were up and running. We are further investigating this issue. Thanks and Regards Kushagra Gupta
Hi Juliya/ Team, We are yet failing to get the ipv6 provisioning. Steps/report shared by Kushagra needs your help. Thanks once again for your help. -Lokendra On Tue, Aug 8, 2023 at 6:12 PM Kushagr Gupta <kushagrguptasps.mun@gmail.com> wrote:
Hi Julia,Team,
Thank you for the response @Julia Kreger <juliaashleykreger@gmail.com>
On Thu, Jul 27, 2023 at 6:59 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I guess what is weird in this entire thing is it sounds like you're shifting over to what appears to be OPROM boot code in a network interface card, which might not support v6. Then again a port mirrored packet capture would be the needful item to troubleshoot further.
We have setup a local dnsmasq-dhcp server and TFTP server on a VM and tried PXE booting the same set of hardwares. The hardware are booting on IPV6 so I think the hardware supports IPV6 PXE booting.
Are you able to extract the exact command line which is being passed to the dnsmasq process for that container launch?
I guess I'm worried if somehow dnsmasq changed or if an old version is somehow in the container image you're using.
The command line which is getting executed is as follows: " "command": [ "/bin/bash", "-c", "BIND_HOST=ca:ca:ca:9900::171; /usr/sbin/dnsmasq --keep-in-foreground --log-facility=/var/log/ironic/dnsmasq.log --user=root --conf-file=/dev/null --listen-address=$BIND_HOST --port=0 --enable-tftp --tftp-root=/var/lib/ironic/tftpboot" ], " We found this command in the following:
/var/lib/tripleo-config/container-startup-config/step_4/ironic_pxe_tftp.json
Apart from this we also tried to install the openstack version zed. In this version, the container ironic_pxe_tftp is up and running but we were still getting the same error:
[image: image.png]
We tried to curl the file which the TFTP container provides from a remote machine(not the undercloud), but we are unable to curl it.
[image: image.png]
But when, we do the same thing from the undercloud, it is working fine:
[image: image.png]
We also set up an undercloud machine on ipv4 for comparison. When we tried to curl the image from a remote machine(not the undercloud) for this server, we were able to curl it.
[image: image.png]
On further digging, we found that in the zed release, the "ironic_pxe_tftp" is in *healthy *state while three containers namely: "ironic_api","ironic_conductor","ironic_pxe_http" are in *unhealthy *state but are up and running. We re-installed the undercloud on the fresh machine and re-tried node introspection after performing basic tasks like image upload, node registration. To our surprise, the Introspection was successful. and the nodes came in available state:
[image: nodes_available_4.PNG]
At this point we were also able to curl the file from a random machine:
[image: image.png]
But it all stopped once we restarted the undercloud node even though all the containers were up and running. We are further investigating this issue.
Thanks and Regards Kushagra Gupta
-- ~ Lokendra skype: lokendrarathour
Greetings, I would recommend verifying you can ping addresses, and then inspect firewall rules, since it sounds like the issue is rooted in the state of the undercloud node. I'm unaware of any specific configuration which would cause this, meaning you would realistically need to identify why the packets are not making it through to the service. -Julia On Thu, Aug 10, 2023 at 4:21 AM Lokendra Rathour <lokendrarathour@gmail.com> wrote:
Hi Juliya/ Team,
We are yet failing to get the ipv6 provisioning. Steps/report shared by Kushagra needs your help.
Thanks once again for your help.
-Lokendra
On Tue, Aug 8, 2023 at 6:12 PM Kushagr Gupta < kushagrguptasps.mun@gmail.com> wrote:
Hi Julia,Team,
Thank you for the response @Julia Kreger <juliaashleykreger@gmail.com>
On Thu, Jul 27, 2023 at 6:59 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I guess what is weird in this entire thing is it sounds like you're shifting over to what appears to be OPROM boot code in a network interface card, which might not support v6. Then again a port mirrored packet capture would be the needful item to troubleshoot further.
We have setup a local dnsmasq-dhcp server and TFTP server on a VM and tried PXE booting the same set of hardwares. The hardware are booting on IPV6 so I think the hardware supports IPV6 PXE booting.
Are you able to extract the exact command line which is being passed to the dnsmasq process for that container launch?
I guess I'm worried if somehow dnsmasq changed or if an old version is somehow in the container image you're using.
The command line which is getting executed is as follows: " "command": [ "/bin/bash", "-c", "BIND_HOST=ca:ca:ca:9900::171; /usr/sbin/dnsmasq --keep-in-foreground --log-facility=/var/log/ironic/dnsmasq.log --user=root --conf-file=/dev/null --listen-address=$BIND_HOST --port=0 --enable-tftp --tftp-root=/var/lib/ironic/tftpboot" ], " We found this command in the following:
/var/lib/tripleo-config/container-startup-config/step_4/ironic_pxe_tftp.json
Apart from this we also tried to install the openstack version zed. In this version, the container ironic_pxe_tftp is up and running but we were still getting the same error:
[image: image.png]
We tried to curl the file which the TFTP container provides from a remote machine(not the undercloud), but we are unable to curl it.
[image: image.png]
But when, we do the same thing from the undercloud, it is working fine:
[image: image.png]
We also set up an undercloud machine on ipv4 for comparison. When we tried to curl the image from a remote machine(not the undercloud) for this server, we were able to curl it.
[image: image.png]
On further digging, we found that in the zed release, the "ironic_pxe_tftp" is in *healthy *state while three containers namely: "ironic_api","ironic_conductor","ironic_pxe_http" are in *unhealthy *state but are up and running. We re-installed the undercloud on the fresh machine and re-tried node introspection after performing basic tasks like image upload, node registration. To our surprise, the Introspection was successful. and the nodes came in available state:
[image: nodes_available_4.PNG]
At this point we were also able to curl the file from a random machine:
[image: image.png]
But it all stopped once we restarted the undercloud node even though all the containers were up and running. We are further investigating this issue.
Thanks and Regards Kushagra Gupta
-- ~ Lokendra skype: lokendrarathour
Hi Team/Julia, Thank you for your constant help @Julia Kreger <juliaashleykreger@gmail.com> . We decided to install the wallaby release using online sources. We followed the link: https://docs.openstack.org/project-deploy-guide/tripleo-docs/wallaby/deploym... When the installation of the undercloud was successful, We found out that all the containers except ironic_pxe_http were in healthy state as opposed to the mentioned container which was in an unhealthy state. We collected the pcap files during the node introspection at this point, and following is our result: [image: image.png] As you can see, we are getting a read request from our baremetal node, but our tftp server is not replying with the acknowledgement message. We have seen in normal cases that at this point data transfer should begin which is not happening here. Apart from this the container ironic_pxe_http is an unhealthy state as mentioned previously. On inspecting the pod, we are getting the following error: ``` "Log": [ { "Start": "2023-08-22T13:03:17.113762224+05:30", "End": "2023-08-22T13:03:17.400862661+05:30", "ExitCode": 1, "Output": "/usr/sbin/httpd -DFOREGROUND\ncurl: (22) The requested URL returned error: 404 Not Found\n\n404 ca:ca:ca:9900::43:8088 0.000512 seconds" }, ``` We think that ca:ca:ca:9900::43:8088 is not a valid syntax. For IPV6 ips, it should be [ca:ca:ca:9900::43]:8088. Kindly note that this is our assumption. Could you please help us out with it? Thanks and Regards, Kushagra Gupta On Fri, Aug 11, 2023 at 2:44 AM Julia Kreger <juliaashleykreger@gmail.com> wrote:
Greetings,
I would recommend verifying you can ping addresses, and then inspect firewall rules, since it sounds like the issue is rooted in the state of the undercloud node. I'm unaware of any specific configuration which would cause this, meaning you would realistically need to identify why the packets are not making it through to the service.
-Julia
On Thu, Aug 10, 2023 at 4:21 AM Lokendra Rathour < lokendrarathour@gmail.com> wrote:
Hi Juliya/ Team,
We are yet failing to get the ipv6 provisioning. Steps/report shared by Kushagra needs your help.
Thanks once again for your help.
-Lokendra
On Tue, Aug 8, 2023 at 6:12 PM Kushagr Gupta < kushagrguptasps.mun@gmail.com> wrote:
Hi Julia,Team,
Thank you for the response @Julia Kreger <juliaashleykreger@gmail.com>
On Thu, Jul 27, 2023 at 6:59 PM Julia Kreger < juliaashleykreger@gmail.com> wrote:
I guess what is weird in this entire thing is it sounds like you're shifting over to what appears to be OPROM boot code in a network interface card, which might not support v6. Then again a port mirrored packet capture would be the needful item to troubleshoot further.
We have setup a local dnsmasq-dhcp server and TFTP server on a VM and tried PXE booting the same set of hardwares. The hardware are booting on IPV6 so I think the hardware supports IPV6 PXE booting.
Are you able to extract the exact command line which is being passed to the dnsmasq process for that container launch?
I guess I'm worried if somehow dnsmasq changed or if an old version is somehow in the container image you're using.
The command line which is getting executed is as follows: " "command": [ "/bin/bash", "-c", "BIND_HOST=ca:ca:ca:9900::171; /usr/sbin/dnsmasq --keep-in-foreground --log-facility=/var/log/ironic/dnsmasq.log --user=root --conf-file=/dev/null --listen-address=$BIND_HOST --port=0 --enable-tftp --tftp-root=/var/lib/ironic/tftpboot" ], " We found this command in the following:
/var/lib/tripleo-config/container-startup-config/step_4/ironic_pxe_tftp.json
Apart from this we also tried to install the openstack version zed. In this version, the container ironic_pxe_tftp is up and running but we were still getting the same error:
[image: image.png]
We tried to curl the file which the TFTP container provides from a remote machine(not the undercloud), but we are unable to curl it.
[image: image.png]
But when, we do the same thing from the undercloud, it is working fine:
[image: image.png]
We also set up an undercloud machine on ipv4 for comparison. When we tried to curl the image from a remote machine(not the undercloud) for this server, we were able to curl it.
[image: image.png]
On further digging, we found that in the zed release, the "ironic_pxe_tftp" is in *healthy *state while three containers namely: "ironic_api","ironic_conductor","ironic_pxe_http" are in *unhealthy *state but are up and running. We re-installed the undercloud on the fresh machine and re-tried node introspection after performing basic tasks like image upload, node registration. To our surprise, the Introspection was successful. and the nodes came in available state:
[image: nodes_available_4.PNG]
At this point we were also able to curl the file from a random machine:
[image: image.png]
But it all stopped once we restarted the undercloud node even though all the containers were up and running. We are further investigating this issue.
Thanks and Regards Kushagra Gupta
-- ~ Lokendra skype: lokendrarathour
That is correct, the address should be wrapped in a bracket. I would suspect it might be an issue of the original input. Specifically, from the original undercloud.conf file you posted to the list. local_ip = ca:ca:ca:9900::171/64 That seems wrong to me and it might actually be the fact that it is provided with a subnet mask, but I'm no expert in this specifically. Honestly, if you really want to take the TripleO route, you should likely consider exploring commercial support options. The community can only do so much for you in terms of a project (TripleO) which is shutting down[0], and wallaby[1][2] itself is in what is considered Extended Maintenance[3]. -Julia [0]: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032083... [1]: https://releases.openstack.org/ [2]: https://releases.openstack.org/#extended-maintenance-note [3]: https://docs.openstack.org/project-team-guide/stable-branches.html#maintenan... On Tue, Aug 22, 2023 at 9:25 PM Kushagr Gupta <kushagrguptasps.mun@gmail.com> wrote:
Hi Team/Julia,
Thank you for your constant help @Julia Kreger <juliaashleykreger@gmail.com>.
We decided to install the wallaby release using online sources. We followed the link:
https://docs.openstack.org/project-deploy-guide/tripleo-docs/wallaby/deploym...
When the installation of the undercloud was successful, We found out that all the containers except ironic_pxe_http were in healthy state as opposed to the mentioned container which was in an unhealthy state. We collected the pcap files during the node introspection at this point, and following is our result:
[trim]
As you can see, we are getting a read request from our baremetal node, but our tftp server is not replying with the acknowledgement message. We have seen in normal cases that at this point data transfer should begin which is not happening here.
Apart from this the container ironic_pxe_http is an unhealthy state as mentioned previously. On inspecting the pod, we are getting the following error:
``` "Log": [ { "Start": "2023-08-22T13:03:17.113762224+05:30", "End": "2023-08-22T13:03:17.400862661+05:30", "ExitCode": 1, "Output": "/usr/sbin/httpd -DFOREGROUND\ncurl: (22) The requested URL returned error: 404 Not Found\n\n404 ca:ca:ca:9900::43:8088 0.000512 seconds" }, ``` We think that ca:ca:ca:9900::43:8088 is not a valid syntax. For IPV6 ips, it should be [ca:ca:ca:9900::43]:8088. Kindly note that this is our assumption. Could you please help us out with it?
Thanks and Regards, Kushagra Gupta
On Fri, Aug 11, 2023 at 2:44 AM Julia Kreger <juliaashleykreger@gmail.com> wrote:
[trim]
participants (3)
-
Julia Kreger
-
Kushagr Gupta
-
Lokendra Rathour