[tripleo][ironic] What I had to do to get standalone ironic working with ovn enabled
I'm using the tripleo standalone install to set up an Ironic test environment. With recent tripleo master, the deploy started failing because the DockerOvn*Image parameters weren't defined. Here's what I did to get everything working: 1. I added to my deploy: -e /usr/share/tripleo-heat-templates/environment/services/neutron-ovn-standalone.yaml With this change, `openstack tripleo container image prep` correctly detected that ovn was enabled and generated the appropriate image parameters. 2. environments/services/ironic.yaml sets: NeutronMechanismDrivers: ['openvswitch', 'baremetal'] Since I didn't want openvswitch enabled in this deployment, I explicitly set the mechanism drivers in a subsequent environment file: NeutronMechanismDrivers: ['ovn', 'baremetal'] 3. The neutron-ovn-standalone.yaml environment explicitly disables the non-ovn neutron services. Ironic requires the services of the neutron_dhcp_agent, so I had to add: OS::TripleO::Services::NeutronDhcpAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-dhcp-container-puppet.yaml With this in place, the ironic nodes were able to receive dhcp responses and were able to boot. 3. In order to provide the baremetal nodes with a route to the nova metadata service, I added the following to my deploy: NeutronEnableForceMetadata: true This provides the baremetal nodes with a route to 169.254.169.254 via the neutron dhcp namespace. 4. In order get the metadata service to respond correctly, I also had to enable the neutron metadata agent: OS::TripleO::Services::NeutronMetadataAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-metadata-container-puppet.yaml This returned my Ironic deployment to a functioning state: I can successfully boot baremetal nodes and provide them with configuration information via the metadata service. I'm curious if this was the *correct* solution, or if there was a better method of getting things working. -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |
On Tue, Feb 19, 2019 at 9:19 PM Lars Kellogg-Stedman <lars@redhat.com> wrote:
I'm using the tripleo standalone install to set up an Ironic test environment. With recent tripleo master, the deploy started failing because the DockerOvn*Image parameters weren't defined. Here's what I did to get everything working:
1. I added to my deploy:
-e /usr/share/tripleo-heat-templates/environment/services/neutron-ovn-standalone.yaml
With this change, `openstack tripleo container image prep` correctly detected that ovn was enabled and generated the appropriate image parameters.
2. environments/services/ironic.yaml sets:
NeutronMechanismDrivers: ['openvswitch', 'baremetal']
Since I didn't want openvswitch enabled in this deployment, I explicitly set the mechanism drivers in a subsequent environment file:
NeutronMechanismDrivers: ['ovn', 'baremetal']
3. The neutron-ovn-standalone.yaml environment explicitly disables the non-ovn neutron services. Ironic requires the services of the neutron_dhcp_agent, so I had to add:
OS::TripleO::Services::NeutronDhcpAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-dhcp-container-puppet.yaml
With this in place, the ironic nodes were able to receive dhcp responses and were able to boot.
3. In order to provide the baremetal nodes with a route to the nova metadata service, I added the following to my deploy:
NeutronEnableForceMetadata: true
This provides the baremetal nodes with a route to 169.254.169.254 via the neutron dhcp namespace.
4. In order get the metadata service to respond correctly, I also had to enable the neutron metadata agent:
OS::TripleO::Services::NeutronMetadataAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-metadata-container-puppet.yaml
This returned my Ironic deployment to a functioning state: I can successfully boot baremetal nodes and provide them with configuration information via the metadata service.
I'm curious if this was the *correct* solution, or if there was a better method of getting things working.
I think you're hitting https://bugs.launchpad.net/tripleo/+bug/1816663 Dan has proposed a patch https://review.openstack.org/#/c/637989/. This is a side effect of switch to ovn by default i believe
-- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |
On 20/02/19 5:15 PM, Lars Kellogg-Stedman wrote:
I'm using the tripleo standalone install to set up an Ironic test environment. With recent tripleo master, the deploy started failing because the DockerOvn*Image parameters weren't defined. Here's what I did to get everything working:
1. I added to my deploy:
-e /usr/share/tripleo-heat-templates/environment/services/neutron-ovn-standalone.yaml
With this change, `openstack tripleo container image prep` correctly detected that ovn was enabled and generated the appropriate image parameters.
2. environments/services/ironic.yaml sets:
NeutronMechanismDrivers: ['openvswitch', 'baremetal']
Since I didn't want openvswitch enabled in this deployment, I explicitly set the mechanism drivers in a subsequent environment file:
NeutronMechanismDrivers: ['ovn', 'baremetal']
Can you provide your full deployment command. I think it is most likely that the order of environment files is resulting in an incorrect value in NeutronMechanismDrivers. You may be able to confirm this by looking at the resulting plan file with something like: openstack object save --file - overcloud plan-environment.yaml
3. The neutron-ovn-standalone.yaml environment explicitly disables the non-ovn neutron services. Ironic requires the services of the neutron_dhcp_agent, so I had to add:
OS::TripleO::Services::NeutronDhcpAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-dhcp-container-puppet.yaml
With this in place, the ironic nodes were able to receive dhcp responses and were able to boot.
3. In order to provide the baremetal nodes with a route to the nova metadata service, I added the following to my deploy:
NeutronEnableForceMetadata: true
This provides the baremetal nodes with a route to 169.254.169.254 via the neutron dhcp namespace.
4. In order get the metadata service to respond correctly, I also had to enable the neutron metadata agent:
OS::TripleO::Services::NeutronMetadataAgent: /usr/share/openstack-tripleo-heat-templates/deployment/neutron/neutron-metadata-container-puppet.yaml
This returned my Ironic deployment to a functioning state: I can successfully boot baremetal nodes and provide them with configuration information via the metadata service.
I'm curious if this was the *correct* solution, or if there was a better method of getting things working.
On Thu, Feb 21, 2019 at 10:54:33AM +1300, Steve Baker wrote:
2. environments/services/ironic.yaml sets:
NeutronMechanismDrivers: ['openvswitch', 'baremetal']
Since I didn't want openvswitch enabled in this deployment, I explicitly set the mechanism drivers in a subsequent environment file:
NeutronMechanismDrivers: ['ovn', 'baremetal']
Can you provide your full deployment command. I think it is most likely that the order of environment files is resulting in an incorrect value in NeutronMechanismDrivers. You may be able to confirm this by looking at the resulting plan file with something like:
openstack object save --file - overcloud plan-environment.yaml
The arguments to 'tripleo deploy' look like this: deploy_args=( -e /usr/share/openstack-tripleo-heat-templates/environments/standalone/standalone-tripleo.yaml -r /usr/share/openstack-tripleo-heat-templates/roles/Standalone.yaml # Thisssets NeutronMechanismDrivers: ['openvswitch', 'baremetal'] -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml # This sets NeutronMechanismDrivers: ovn and disables # OS::TripleO::Services::NeutronMetadataAgent and # OS::TripleO::Services::NeutronDhcpAgent -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-standalone.yaml # This sets NeutronMechanismDrivers: ['ovn', 'baremetal'] and re-enables # OS::TripleO::Services::NeutronMetadataAgent and # OS::TripleO::Services::NeutronDhcpAgent -e ./standalone_parameters.yaml ) The above is used in the following command line: sudo openstack tripleo deploy \ --templates $TEMPLATES \ --local-ip=192.168.23.1/24 \ --output-dir deploy \ --standalone \ "${deploy_args[@]}" \ -e ./container-images.yaml -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |
On Thu, Feb 21, 2019 at 10:54:33AM +1300, Steve Baker wrote:
1. I added to my deploy:
-e /usr/share/tripleo-heat-templates/environment/services/neutron-ovn-standalone.yaml
With this change, `openstack tripleo container image prep` correctly detected that ovn was enabled and generated the appropriate image parameters.
Can you provide your full deployment command. I think it is most likely that the order of environment files is resulting in an incorrect value in NeutronMechanismDrivers. You may be able to confirm this by looking at the resulting plan file with something like:
Upon closer inspection, I believe you are correct. The problem is twofold: - First, by default, NeutronMechanismDrivers is unset. So if you simply run: openstack tripleo container image prepare -e container-prepare-parameters.yaml ...you get no OVN images. - Second, the ironic.yaml environment file explicitly sets: NeutronMechanismDrivers: ['openvswitch', 'baremetal'] So if ironic.yaml is included after something like neutron-ovn-standalone.yaml, it will override the value. Is this one bug or two? Arguably, ironic.yaml shouldn't be setting NeutronMechanismDrivers explicitly like that (although I don't know if there is an "append" mechanism). But shouldn't NeutronMechanismDrivers default to 'ovn', if that's the default mechanism now? -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |
On Wed, 2019-02-20 at 19:21 -0500, Lars Kellogg-Stedman wrote:
On Thu, Feb 21, 2019 at 10:54:33AM +1300, Steve Baker wrote:
1. I added to my deploy:
-e /usr/share/tripleo-heat- templates/environment/services/neutron-ovn-standalone.yaml
With this change, `openstack tripleo container image prep` correctly detected that ovn was enabled and generated the appropriate image parameters.
Can you provide your full deployment command. I think it is most likely that the order of environment files is resulting in an incorrect value in NeutronMechanismDrivers. You may be able to confirm this by looking at the resulting plan file with something like:
Upon closer inspection, I believe you are correct. The problem is twofold:
- First, by default, NeutronMechanismDrivers is unset. So if you simply run:
openstack tripleo container image prepare -e container-prepare- parameters.yaml
...you get no OVN images.
- Second, the ironic.yaml environment file explicitly sets:
NeutronMechanismDrivers: ['openvswitch', 'baremetal']
So if ironic.yaml is included after something like neutron-ovn-standalone.yaml, it will override the value.
Is this one bug or two? Arguably, ironic.yaml shouldn't be setting NeutronMechanismDrivers explicitly like that (although I don't know if there is an "append" mechanism). But shouldn't NeutronMechanismDrivers default to 'ovn', if that's the default mechanism now?
The 'ovn' driver does not support VNIC_BAREMETAL type, so we should load a mechanism driver that does support VNIC_BAREMETAL when using ironic. With the switch to ovn by default in TripleO maybe ironic.yaml environment file should be updated to set: NeutronMechanismDrivers: ['ovn', 'baremetal'] We could also add the DCHP agent and Metadata agent, as these also seem to be required for ironic use, according previous messages in this thread? OS::TripleO::Services::NeutronDhcpAgent: /usr/share/openstack- tripleo-heat-templates/deployment/neutron/neutron-dhcp-container- puppet.yaml NeutronEnableForceMetadata: true OS::TripleO::Services::NeutronMetadataAgent: /usr/share/openstack- tripleo-heat-templates/deployment/neutron/neutron-metadata-container- puppet.yaml https://github.com/openstack/networking-ovn/blob/master/networking_ovn/ml2/m...
participants (4)
-
Alex Schultz
-
Harald Jensås
-
Lars Kellogg-Stedman
-
Steve Baker