<div dir="ltr"><div dir="ltr">Hi Harald,<div>Thanks once again for your support, we tried activating the parameters:</div><div>ServiceNetMap:<br> IronicApiNetwork: provisioning<br> IronicNetwork: provisioning<br></div><div>at environments/network-environments.yaml</div><div><img src="cid:ii_kzh13oin0" alt="image.png" width="472" height="113"><br></div><div>After changing these values the updated or even the fresh deployments are failing. </div><div><br></div><div>The command that we are using to deploy the OpenStack overcloud:</div><div><i>openstack overcloud deploy --templates \<br> -n /home/stack/templates/network_data.yaml \<br> -r /home/stack/templates/roles_data.yaml \<br> -e /home/stack/templates/node-info.yaml \<br> -e /home/stack/templates/environment.yaml \<br> -e /home/stack/templates/environments/network-isolation.yaml \<br> -e /home/stack/templates/environments/network-environment.yaml \<br> -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml \<br> -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml \<br> -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml \<br> -e /home/stack/templates/ironic-config.yaml \<br> -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \<br> -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \<br> -e /home/stack/containers-prepare-parameter.yaml</i><br></div><div><br></div><div>**/home/stack/templates/ironic-config.yaml :</div><div>(overcloud) [stack@undercloud ~]$ cat /home/stack/templates/ironic-config.yaml<br>parameter_defaults:<br> IronicEnabledHardwareTypes:<br> - ipmi<br> - redfish<br> IronicEnabledPowerInterfaces:<br> - ipmitool<br> - redfish<br> IronicEnabledManagementInterfaces:<br> - ipmitool<br> - redfish<br> IronicCleaningDiskErase: metadata<br> IronicIPXEEnabled: true<br> IronicInspectorSubnets:<br> - ip_range: 172.23.3.100,172.23.3.150<br> IPAImageURLs: '["<a href="http://30.30.30.1:8088/agent.kernel">http://30.30.30.1:8088/agent.kernel</a>", "<a href="http://30.30.30.1:8088/agent.ramdisk">http://30.30.30.1:8088/agent.ramdisk</a>"]'<br> IronicInspectorInterface: 'br-baremetal'<br></div><div><br></div><div>Also the baremetal network(provisioning)(172.23.3.x) is routed with ctlplane/admin network (30.30.30.x)</div><div><br></div><div><b>Query:</b></div><div><ol><li>any other location/way where we should add these so that they are included without error.</li></ol></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><b>ServiceNetMap:</b></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><b> IronicApiNetwork: provisioning</b></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><b> IronicNetwork: provisioning</b></div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> 2. Also are these commands(mentioned above) configure Baremetal services are fine.</div></blockquote><div><br></div><div>Best Regards,</div><div>Lokendra</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 9, 2022 at 11:55 PM Harald Jensas <<a href="mailto:hjensas@redhat.com">hjensas@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/9/22 15:58, Lokendra Rathour wrote:<br>
> Hi Harald,<br>
> Responding on behalf of Anirudh's email:<br>
> Thanks for the response and we now do understand that we are getting IP <br>
> from the expected DHCP server.<br>
> <br>
> We tried the scenario and here are our findings, Our admin and internal <br>
> endpoints are on subnet: 30.30.30.x<br>
> public : 10.0.1.x<br>
> <br>
> (overcloud) [stack@undercloud ~]$ *OpenStack endpoint list | grep ironic*<br>
> | 04c163251e5546769446a4fa4fa20484 | regionOne | ironic | <br>
> baremetal | True | admin | <a href="http://30.30.30.213:6385" rel="noreferrer" target="_blank">http://30.30.30.213:6385</a> <br>
> <<a href="http://30.30.30.213:6385" rel="noreferrer" target="_blank">http://30.30.30.213:6385</a>> |<br>
> | 5c8557ae639a4898bdc6121f6e873724 | regionOne | ironic | <br>
> baremetal | True | internal | <a href="http://30.30.30.213:6385" rel="noreferrer" target="_blank">http://30.30.30.213:6385</a> <br>
> <<a href="http://30.30.30.213:6385" rel="noreferrer" target="_blank">http://30.30.30.213:6385</a>> |<br>
> | 62e07a3b2f3f4158bb27d8603a8f5138 | regionOne | ironic-inspector | <br>
> baremetal-introspection | True | public | <a href="http://10.0.1.88:5050" rel="noreferrer" target="_blank">http://10.0.1.88:5050</a> <br>
> <<a href="http://10.0.1.88:5050" rel="noreferrer" target="_blank">http://10.0.1.88:5050</a>> |<br>
> | af29bd64513546409f44cc5d56ea1082 | regionOne | ironic-inspector | <br>
> baremetal-introspection | True | internal | <a href="http://30.30.30.213:5050" rel="noreferrer" target="_blank">http://30.30.30.213:5050</a> <br>
> <<a href="http://30.30.30.213:5050" rel="noreferrer" target="_blank">http://30.30.30.213:5050</a>> |<br>
> | b76cdb5e77c54fc6b10cbfeada0e8bf5 | regionOne | ironic-inspector | <br>
> baremetal-introspection | True | admin | <a href="http://30.30.30.213:5050" rel="noreferrer" target="_blank">http://30.30.30.213:5050</a> <br>
> <<a href="http://30.30.30.213:5050" rel="noreferrer" target="_blank">http://30.30.30.213:5050</a>> |<br>
> | bd2954f41e49419f85669990eb59f51a | regionOne | ironic | <br>
> baremetal | True | public | <a href="http://10.0.1.88:6385" rel="noreferrer" target="_blank">http://10.0.1.88:6385</a> <br>
> <<a href="http://10.0.1.88:6385" rel="noreferrer" target="_blank">http://10.0.1.88:6385</a>> |<br>
> (overcloud) [stack@undercloud ~]$<br>
> <br>
> <br>
> we are following the flat default n/w approach for ironic provisioning, <br>
> for which we are creating a flat network on baremetal physnet. we are <br>
> still getting IP from neutron range (172.23.3.220 - 172.23.3.240) - <br>
> 172.23.3.240.<br>
> <br>
> Further, we found that once IP (172.23.3.240) is allocated to baremetal <br>
> node, it looks for 30.30.30.220( IP of one of the three controllers) for <br>
> pxe booting.<br>
> Checking the same controllers logs we found that<br>
> <br>
> *`/var/lib/ironic/tftpboot/pxelinux.cfg/` directory exists,* but then <br>
> there is *no file matching the mac *address of the baremetal node.<br>
> <br>
> Also checking the *extra_dhcp_opts* we found this:<br>
> (overcloud) [stack@undercloud ~]$ *openstack port show <br>
> d7e573bf-1028-437a-8118-a2074c7573b2 | grep "extra_dhcp_opts"*<br>
> <br>
> | extra_dhcp_opts | ip_version='4', opt_name='tag:ipxe,67',<br>
> opt_value='<a href="http://30.30.30.220:8088/boot.ipxe" rel="noreferrer" target="_blank">http://30.30.30.220:8088/boot.ipxe</a><br>
> <<a href="http://30.30.30.220:8088/boot.ipxe" rel="noreferrer" target="_blank">http://30.30.30.220:8088/boot.ipxe</a>>' <br>
> <br>
> <br>
> image.png<br>
> *Few points as observations:*<br>
> <br>
> 1. Although the baremetal network (172.23.3.x) is routable to the admin<br>
> network (30.30.30.x), but it gets timeout at this window.<br>
<br>
It should be able to download the file over a routed network.<br>
<br>
> 2. in TCPDump we are only getting read requests.<br>
<br>
If you have access check the switches and routers if you can see the <br>
traffic being dropped/blocked somewhere on the path?<br>
<br>
<br>
I'm not 100% sure what parameters you used when deploying, but did you <br>
try to change the ServiceNetMap for IronicApiNetwork, IronicNetwork?<br>
<br>
If you set that to the name of the baremetal network (172.23.3.x)?<br>
<br>
ServiceNetMap:<br>
IronicApiNetwork: baremetal_network<br>
IronicNetwork: baremetal_network<br>
<br>
The result will be that the http server will listen on 172.23.3.x, and <br>
the extra_dhcp_opts should point to 172.23.3.x as well.<br>
<br>
<br>
> 3. `openstack baremetal node list<br>
> 1. (overcloud) [stack@undercloud ~]$ openstack baremetal node list<br>
> +--------------------------------------+------+---------------+-------------+--------------------+-------------+<br>
> | UUID | Name | Instance UUID |<br>
> Power State | Provisioning State | Maintenance |<br>
> +--------------------------------------+------+---------------+-------------+--------------------+-------------+<br>
> | 7066fbe1-9c29-4702-9cd4-2b55daf19630 | bm1 | None |<br>
> power on | clean wait | False |<br>
> +--------------------------------------+------+---------------+-------------+--------------------+-------------+<br>
> 4. `openstack baremetal node show <node-uuid>`<br>
> 1.<br>
> <br>
> (overcloud) [stack@undercloud ~]$ openstack baremetal node show bm1<br>
> +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+<br>
> | Field | Value <br>
> <br>
> <br>
> <br>
> |<br>
> +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+<br>
> | allocation_uuid | None <br>
> <br>
> <br>
> <br>
> |<br>
> | automated_clean | None <br>
> <br>
> <br>
> <br>
> |<br>
> | bios_interface | no-bios <br>
> <br>
> <br>
> <br>
> |<br>
> | boot_interface | ipxe <br>
> <br>
> <br>
> <br>
> |<br>
> | chassis_uuid | None <br>
> <br>
> <br>
> <br>
> |<br>
> | clean_step | {} <br>
> <br>
> <br>
> <br>
> |<br>
> | conductor | overcloud-controller-0.localdomain <br>
> <br>
> <br>
> <br>
> |<br>
> | conductor_group | <br>
> <br>
> <br>
> <br>
> |<br>
> | console_enabled | False <br>
> <br>
> <br>
> <br>
> |<br>
> | console_interface | ipmitool-socat <br>
> <br>
> <br>
> <br>
> |<br>
> | created_at | 2022-02-09T14:21:24+00:00 <br>
> <br>
> <br>
> <br>
> |<br>
> | deploy_interface | iscsi <br>
> <br>
> <br>
> <br>
> |<br>
> | deploy_step | {} <br>
> <br>
> <br>
> <br>
> |<br>
> | description | None <br>
> <br>
> <br>
> <br>
> |<br>
> | driver | ipmi <br>
> <br>
> <br>
> <br>
> |<br>
> | driver_info | {'ipmi_address': '10.0.1.183',<br>
> 'ipmi_username': 'hsc', 'ipmi_password': '******',<br>
> 'ipmi_terminal_port': 623, 'deploy_kernel':<br>
> '9e1365b6-261a-42a2-abfe-40158945de57', 'deploy_ramdisk':<br>
> 'fe608dd2-ce86-4faf-b4b8-cc5cb143eb56'} |<br>
> | driver_internal_info | {'agent_erase_devices_iterations': 1,<br>
> 'agent_erase_devices_zeroize': True,<br>
> 'agent_continue_if_ata_erase_failed': False,<br>
> 'agent_enable_ata_secure_erase': True,<br>
> 'disk_erasure_concurrency': 1, 'last_power_state_change':<br>
> '2022-02-09T14:23:39.525629'} |<br>
> | extra | {} <br>
> <br>
> <br>
> <br>
> |<br>
> | fault | None <br>
> <br>
> <br>
> <br>
> |<br>
> | inspect_interface | inspector <br>
> <br>
> <br>
> <br>
> |<br>
> | inspection_finished_at | None <br>
> <br>
> <br>
> <br>
> |<br>
> | inspection_started_at | None <br>
> <br>
> <br>
> <br>
> |<br>
> | instance_info | {} <br>
> <br>
> <br>
> <br>
> |<br>
> | instance_uuid | None <br>
> <br>
> <br>
> <br>
> |<br>
> | last_error | None <br>
> <br>
> <br>
> <br>
> |<br>
> | maintenance | False <br>
> <br>
> <br>
> <br>
> |<br>
> | maintenance_reason | None <br>
> <br>
> <br>
> <br>
> |<br>
> | management_interface | ipmitool <br>
> <br>
> <br>
> <br>
> |<br>
> | name | bm1 <br>
> <br>
> <br>
> <br>
> |<br>
> | network_interface | flat <br>
> <br>
> <br>
> <br>
> |<br>
> | owner | None <br>
> <br>
> <br>
> <br>
> |<br>
> | power_interface | ipmitool <br>
> <br>
> <br>
> <br>
> |<br>
> | power_state | power on <br>
> <br>
> <br>
> <br>
> |<br>
> | properties | {'cpus': 20, 'cpu_arch': 'x86_64',<br>
> 'capabilities': 'boot_option:local,boot_mode:uefi', 'memory_mb':<br>
> 63700, 'local_gb': 470, 'vendor': 'hewlett-packard'} <br>
> <br>
> |<br>
> | protected | False <br>
> <br>
> <br>
> <br>
> |<br>
> | protected_reason | None <br>
> <br>
> <br>
> <br>
> |<br>
> | provision_state | clean wait <br>
> <br>
> <br>
> <br>
> |<br>
> | provision_updated_at | 2022-02-09T14:24:05+00:00 <br>
> <br>
> <br>
> <br>
> |<br>
> | raid_config | {} <br>
> <br>
> <br>
> <br>
> |<br>
> | raid_interface | no-raid <br>
> <br>
> <br>
> <br>
> |<br>
> | rescue_interface | agent <br>
> <br>
> <br>
> <br>
> |<br>
> | reservation | None <br>
> <br>
> <br>
> <br>
> |<br>
> | resource_class | bm1 <br>
> <br>
> <br>
> <br>
> |<br>
> | storage_interface | noop <br>
> <br>
> <br>
> <br>
> |<br>
> | target_power_state | None <br>
> <br>
> <br>
> <br>
> |<br>
> | target_provision_state | available <br>
> <br>
> <br>
> <br>
> |<br>
> | target_raid_config | {} <br>
> <br>
> <br>
> <br>
> |<br>
> | traits | [] <br>
> <br>
> <br>
> <br>
> |<br>
> | updated_at | 2022-02-09T14:24:05+00:00 <br>
> <br>
> <br>
> <br>
> |<br>
> | uuid | 7066fbe1-9c29-4702-9cd4-2b55daf19630<br>
> <br>
> <br>
> <br>
> |<br>
> | vendor_interface | ipmitool <br>
> <br>
> <br>
> <br>
> |<br>
> +------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+<br>
> (overcloud) [stack@undercloud ~]$<br>
> <br>
> <br>
> <br>
> *Queries:*<br>
> <br>
> * What are the settings we can do for successfully pxe-boot of the<br>
> baremetal node and provisioning our node successfully ?<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Tue, Feb 8, 2022 at 6:27 PM Harald Jensas <<a href="mailto:hjensas@redhat.com" target="_blank">hjensas@redhat.com</a> <br>
> <mailto:<a href="mailto:hjensas@redhat.com" target="_blank">hjensas@redhat.com</a>>> wrote:<br>
> <br>
> On 2/7/22 13:47, Anirudh Gupta wrote:<br>
> > Hi Julia,<br>
> ><br>
> > Thanks a lot for your responses and support.<br>
> > To Update on the ongoing issue, I tried deploying the overcloud with<br>
> > your valuable suggestions i.e by passing "*DhcpAgentNotification:<br>
> true*"<br>
> > in ironic-overcloud.yaml<br>
> > The setup came up successfully, but with this configuration the IP<br>
> > allocated on the system is one which is being configured while<br>
> creating<br>
> > the subnet in openstack.<br>
> ><br>
> > image.png<br>
> ><br>
> > The system is still getting the IP (172.23.3.212) from neutron. The<br>
> > subnet range was configured as *172.23.3.210-172.23.3.240 *while<br>
> > creating the provisioning subnet.<br>
> <br>
> <br>
> The node is supposed to get an IP address from the neutron subnet on<br>
> the<br>
> provisioning network when:<br>
> a) provisioning node<br>
> b) cleaning node.<br>
> <br>
> When you do "baremetal node provide" cleaning is most likely<br>
> automatically initiated. (Since cleaning is enabled by default for<br>
> Ironic in overcloud AFIK.)<br>
> <br>
> The only time you will get an address from the IronicInspectorSubnets<br>
> (ip_range: 172.23.3.100,172.23.3.150 in your case) is when you start<br>
> ironic node introspection.<br>
> <br>
> > The system gets stuck here and no action is performed after this.<br>
> ><br>
> <br>
> It seems the system is getting an address from the expected DHCP<br>
> server,<br>
> but it does not boot. I would start looking into the pxe properties in<br>
> the DHCP Reply.<br>
> <br>
> What is the status of the node in ironic at this stage?<br>
> `openstack baremetal node list`<br>
> `openstack baremetal node show <node-uuid>`<br>
> <br>
> Check the `extra_dhcp_opts` on the neutron port, it should set the<br>
> nextserver and bootfile parameters. Does the bootfile exist in<br>
> /var/lib/ironic/tftpboot? Inspect the<br>
> `/var/lib/ironic/tftpboot/pxelinux.cfg/` directory, you should see a<br>
> file matching the MAC address of your system. Does the content make<br>
> sense?<br>
> <br>
> Can you capture DHCP and TFTP traffic on the provisioning network?<br>
> <br>
> > Is there any way to resolve this and make successful <br>
> provisioning the<br>
> > baremetal node in *TripleO Train Release* (Since RHOSP 16 was on<br>
> Train,<br>
> > so I thought to go with that version for better stability)<br>
> ><br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index</a>><br>
> <br>
> ><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/release_notes/index</a>>><br>
> ><br>
> > I have some queries:<br>
> ><br>
> > 1. Is passing "*DhcpAgentNotification: true" *enough or do we<br>
> have to<br>
> > make some other changes as well?<br>
> <br>
> I belive in train "DhcpAgentNotification" defaults to True.<br>
> The change to default to false was added more recently, and it was not<br>
> backported.<br>
> (<a href="https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761</a><br>
> <<a href="https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/tripleo-heat-templates/+/801761</a>>)<br>
> <br>
> NOTE, the environment for enabling ironi for the overcloud<br>
> 'environments/services/ironic-overcloud.yaml' overrides this to 'true'<br>
> in later releases.<br>
> <br>
> > 2. Although there are some security concerns specified in the<br>
> document,<br>
> > but Currently I am focusing on the default flat bare<br>
> metal approach<br>
> > which has dedicated interface for bare metal Provisioning.<br>
> There is<br>
> > one composable method approach as well. Keeping aside the<br>
> security<br>
> > concerns, which approach is better and functional?<br>
> > 1.<br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning</a>><br>
> > <br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning</a> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/bare_metal_provisioning/prerequisites-for-bare-metal-provisioning</a>>><br>
> <br>
> Both should work, using the composable network is more secure since<br>
> baremetal nodes does not have access to the control plane network.<br>
> <br>
> > 3. Will moving to upper openstack release version make this<br>
> deployment<br>
> > possible?<br>
> > 1. If Yes, which release should I go with as till wallaby the<br>
> > ironic-overcloud.yml file has no option of including<br>
> > "*DhcpAgentNotification: true*" by default<br>
> > 1.<br>
> <a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml</a><br>
> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml</a>><br>
> > <br>
> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml</a> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/environments/services/ironic-overcloud.yaml</a>>><br>
> ><br>
> ><br>
> > Looking forward for your valuable feedback/response.<br>
> ><br>
> > Regards<br>
> > Anirudh Gupta<br>
> ><br>
> ><br>
> > On Fri, Feb 4, 2022 at 8:54 PM Anirudh Gupta <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a><br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>><br>
> > <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > Surely I'll revert the status once it gets deployed.<br>
> > Bdw the suspicion is because of Train Release or it is<br>
> something else?<br>
> ><br>
> > Regards<br>
> > Anirudh Gupta<br>
> ><br>
> > On Fri, 4 Feb, 2022, 20:29 Julia Kreger,<br>
> > <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>>><br>
> > wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Feb 4, 2022 at 5:50 AM Anirudh Gupta<br>
> > <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>><br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>>> wrote:<br>
> ><br>
> > Hi Julia<br>
> ><br>
> > Thanks for your response.<br>
> ><br>
> > Earlier I was passing both ironic.yaml and<br>
> > ironic-overcloud.yaml located at path<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/<br>
> ><br>
> > My current understanding now says that since I am<br>
> using OVN,<br>
> > not OVS so I should pass only ironic-overcloud.yaml in my<br>
> > deployment.<br>
> ><br>
> > I am currently on Train Release and my default<br>
> > ironic-overcloud.yaml file has no such entry<br>
> > DhcpAgentNotification: true<br>
> ><br>
> ><br>
> > I suspect that should work. Let us know if it does.<br>
> ><br>
> > I would add this there and re deploy the setup.<br>
> ><br>
> > Would that be enough to make my deployment successful?<br>
> ><br>
> > Regards<br>
> > Anirudh Gupta<br>
> ><br>
> ><br>
> > On Fri, 4 Feb, 2022, 18:40 Julia Kreger,<br>
> > <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>><br>
> > <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>>> wrote:<br>
> ><br>
> > It is not a matter of disabling OVN, but a matter of<br>
> > enabling the dnsmasq service and notifications.<br>
> ><br>
> ><br>
> <a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml</a><br>
> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml</a>><br>
> > <br>
> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml</a> <<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ironic-overcloud.yaml</a>>><br>
> > may provide some insight.<br>
> ><br>
> > I suspect if you're using stable/wallaby based<br>
> branches<br>
> > and it is not working, there may need to be a patch<br>
> > backported by the TripleO maintainers.<br>
> ><br>
> > On Thu, Feb 3, 2022 at 8:02 PM Anirudh Gupta<br>
> > <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>><br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>>> wrote:<br>
> ><br>
> > Hi Julia,<br>
> ><br>
> > Thanks for your response.<br>
> > For the overcloud deployment, I am executing the<br>
> > following command:<br>
> ><br>
> > openstack overcloud deploy --templates \<br>
> > -n /home/stack/templates/network_data.yaml \<br>
> > -r /home/stack/templates/roles_data.yaml \<br>
> > -e /home/stack/templates/node-info.yaml \<br>
> > -e /home/stack/templates/environment.yaml \<br>
> > -e<br>
> > <br>
> /home/stack/templates/environments/network-isolation.yaml<br>
> > \<br>
> > -e<br>
> > <br>
> /home/stack/templates/environments/network-environment.yaml<br>
> > \<br>
> > -e<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml<br>
> > \<br>
> > -e<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml<br>
> > \<br>
> > -e<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml<br>
> > \<br>
> > -e<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml<br>
> > \<br>
> > -e<br>
> /home/stack/templates/ironic-config.yaml \<br>
> > -e<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml<br>
> > \<br>
> > -e<br>
> > <br>
> /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml<br>
> > \<br>
> > -e<br>
> /home/stack/containers-prepare-parameter.yaml<br>
> ><br>
> > I can see some OVN related stuff in my roles_data<br>
> > and environments/network-isolation.yaml<br>
> ><br>
> > [stack@undercloud ~]$ grep -inr "ovn"<br>
> > roles_data.yaml:34: *OVNCMSOptions:<br>
> > "enable-chassis-as-gw"*<br>
> > roles_data.yaml:168: -<br>
> > *OS::TripleO::Services::OVNDBs*<br>
> > roles_data.yaml:169: -<br>
> > *OS::TripleO::Services::OVNController*<br>
> > roles_data.yaml:279: -<br>
> > *OS::TripleO::Services::OVNController*<br>
> > roles_data.yaml:280: -<br>
> > *OS::TripleO::Services::OVNMetadataAgent*<br>
> > environments/network-isolation.yaml:16:<br>
> > *OS::TripleO::Network::Ports::OVNDBsVipPort:<br>
> > ../network/ports/vip.yaml*<br>
> > *<br>
> > *<br>
> > What is your recommendation and how to disable<br>
> > OVN....should I remove it from<br>
> roles_data.yaml and<br>
> > then render so that it doesn't get generated<br>
> > in environments/network-isolation.yaml<br>
> > Please suggest some pointers.<br>
> ><br>
> > Regards<br>
> > Anirudh Gupta<br>
> > *<br>
> > *<br>
> > *<br>
> > *<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > It seems OVN is getting installed in ironic<br>
> ><br>
> ><br>
> > On Fri, Feb 4, 2022 at 1:36 AM Julia Kreger<br>
> > <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>><br>
> > <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a><br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>>> wrote:<br>
> ><br>
> > My guess: You're running OVN. You need<br>
> > neutron-dhcp-agent running as well. OVN<br>
> disables<br>
> > it by default and OVN's integrated DHCP<br>
> service<br>
> > does not support options for network booting.<br>
> ><br>
> > -Julia<br>
> ><br>
> > On Thu, Feb 3, 2022 at 9:06 AM Anirudh Gupta<br>
> > <<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a><br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>><br>
> > <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a><br>
> <mailto:<a href="mailto:anyrude10@gmail.com" target="_blank">anyrude10@gmail.com</a>>>> wrote:<br>
> ><br>
> > Hi Team<br>
> ><br>
> > I am trying to Provision Bare Metal Node<br>
> > from my tripleo Overcloud.<br>
> > For this, while deploying the<br>
> overcloud, I<br>
> > have followed the *"default flat"<br>
> *network<br>
> > approach specified in the below link<br>
> ><br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning</a>><br>
> > <br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning</a> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-planning</a>>><br>
> ><br>
> > Just to highlight the changes, I have<br>
> > defined the<br>
> ><br>
> > *ironic-config.yaml*<br>
> ><br>
> > parameter_defaults:<br>
> > ...<br>
> > ...<br>
> > IronicIPXEEnabled: true<br>
> > IronicInspectorSubnets:<br>
> > - ip_range:<br>
> *172.23.3.100,172.23.3.150*<br>
> > IronicInspectorInterface:<br>
> 'br-baremetal'<br>
> ><br>
> > Also modified the file<br>
> > *~/templates/network-environment.yaml*<br>
> ><br>
> > parameter_defaults:<br>
> > NeutronBridgeMappings:<br>
> > datacentre:br-ex,baremetal:br-baremetal<br>
> > NeutronFlatNetworks:<br>
> datacentre,baremetal<br>
> ><br>
> > With this I have Followed all the<br>
> steps of<br>
> > creating br-baremetal bridge on<br>
> controller,<br>
> > given in the link below:<br>
> ><br>
> ><br>
> <a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy</a><br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy</a>><br>
> > <br>
> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy</a> <<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15/html/bare_metal_provisioning/sect-deploy</a>>><br>
> ><br>
> > - type: ovs_bridge<br>
> > name: br-baremetal<br>
> > use_dhcp: false<br>
> > members:<br>
> > - type: interface<br>
> > name: nic3<br>
> ><br>
> > Post Deployment, I have also create a<br>
> flat<br>
> > network on "datacentre"<br>
> physical network and<br>
> > subnet having the range<br>
> > *172.23.3.200,172.23.3.240 *(as suggested<br>
> > subnet is same as of inspector and<br>
> range is<br>
> > different) and the router<br>
> ><br>
> > Also created a baremetal node and ran<br>
> > *"openstack baremetal node manage<br>
> bm1", *the<br>
> > state of which was a success.<br>
> ><br>
> > Observation:<br>
> ><br>
> > On executing "openstack baremetal node<br>
> > *provide* bm1", the machine gets power on<br>
> > and ideally it should take an IP from<br>
> ironic<br>
> > inspector range and PXE Boot.<br>
> > But nothing of this sort happens and<br>
> we see<br>
> > an IP from neutron range "*172.23.3.239*"<br>
> > (attached the screenshot)<br>
> ><br>
> > image.png<br>
> ><br>
> > I have checked overcloud ironic inspector<br>
> > podman logs alongwith the tcpdump.<br>
> > In tcpdump, I can only see dhcp discover<br>
> > request on br-baremetal and nothing<br>
> happens<br>
> > after that.<br>
> ><br>
> > I have tried to explain my issue in<br>
> detail,<br>
> > but I would be happy to share more<br>
> details<br>
> > in case still required.<br>
> > Can someone please help in resolving<br>
> my issue.<br>
> ><br>
> > Regards<br>
> > Anirudh Gupta<br>
> ><br>
> <br>
> <br>
> <br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div>