Bug 1318543
| Summary: | [Neutron] - Engine adds a trailing hash to non-neutron hosts, too. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Michael Burman <mburman> | ||||||
| Component: | BLL.Network | Assignee: | Marcin Mirecki <mmirecki> | ||||||
| Status: | CLOSED EOL | QA Contact: | Michael Burman <mburman> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 3.6.3.3 | CC: | bugs, danken, mburman, myakove, rhev-integ, sbonazzo, ylavi | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: |
During external nic allowaction, the value of the binding:host_id property sent from engine to the host must be the same as was set during the automated neutron agent install during host installation, or just the host name if the agent was installed manually.
The engine will now differentiate between hosts isntalled either way, and send an appropriate value of the property.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-07-29 11:15:17 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1314375, 1316049 | ||||||||
| Attachments: |
|
||||||||
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Michael, would you attach neutron.conf of the said host? ovirt-host-deploy.log may also be helpful. Created attachment 1142065 [details]
neutron conf
moving to 4.0, as this most probably affects only our generic network provider, not the existing 3.6 neutron integration. This was discovered by QE while certifying OSP 8 on 3.6. Therefore this affects 3.6 as well. Why was this re-targeted then? the trailing hash is an intentional addition, that is accompanied with a compatible configuration in neutron.conf. in 4.0, for generic external providers, we do not configure the host and should use its default fqdn hostname. Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA. Readding to 3.6 to back port once we have it merged in 4.0, so we can certify OSP 8 certain flows for 3.6 as well. Verification procedure.
To verify this bug, please also check (besides checking that the port is UP) if the request to Openstack Neutron contains the correct string.
You can check this using the Neutron mock.
After adding a port (or starting a vm with such), observe the log of the mock.
It will report the data received from the engine:
PUT: /v2.0/ports/port_id_2
Body:
{
"port" : {
"binding:host_id" : "192.168.120.20-1ae73b",
"security_groups" : null
}
}
The binding:host_id must have the hash added if the host had Neutron installed automatically when added to engine, or must not otherwise.
Verified on - 3.6.8-0.1.el6 |
Created attachment 1137326 [details] neutron server log and engine log Description of problem: [Neutron] - When engine allocate new port it's generate a host value that cause the binding:vif_type to binding_failed. Engine generates wrong host id value and because of that the binding:vif_type is failed --> vega05.qa.lab.tlv.redhat.com-937e64 instead of --> vega05.qa.lab.tlv.redhat.com - The value of the binding is not only the host name but: host.getHostName() + "-" + DigestUtils.md5Hex(host.getId().toByteArray()).substring(0, 6) When creating a port with correct host name, binding succeed: - Wrong host_id value --> [root@localhost ~(keystone_admin)]# neutron port-show badf795b-415b-4f9d-b6c0-aaf7a45e567d +-----------------------+-----------------------------------------------------------------------------------------------------+ | Field | Value | +-----------------------+-----------------------------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | vega05.qa.lab.tlv.redhat.com-937e64 | | binding:profile | {} | | binding:vif_details | {} | | binding:vif_type | binding_failed | | binding:vnic_type | normal - Correct host_id value --> [root@localhost ~(keystone_admin)]# neutron port-show 5c454e58-b119-48f1-94bf-1bb4ade52472 +-----------------------+-----------------------------------------------------------------------------------------------------+ | Field | Value | +-----------------------+-----------------------------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | vega05.qa.lab.tlv.redhat.com | | binding:profile | {} | | binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} | | binding:vif_type | ovs | | binding:vnic_type | normal Version-Release number of selected component (if applicable): 3.6.3.4-0.1.el6.noarch How reproducible: 100 Steps to Reproduce: 1. Install external provider(neutron osp 8) in rhev 2. Import neutron network and run VM with it 3. Check the server.log, the network status in neutron and the port status. Actual results: All networks that 'ovirt' owns are DOWN and the binding:vif_type is binding_failed VM can't get ip from neutron's dhcp Expected results: Engine should generate the correct host_id when allocating new ports, so the binding:vif_type will be 'ovs'