| 2020-04-15 21:59:14 |
hamza |
bug |
|
|
added bug |
| 2020-04-23 20:56:46 |
Slawek Kaplonski |
neutron: status |
New |
Won't Fix |
|
| 2020-04-24 20:37:54 |
Miguel Lavalle |
neutron: status |
Won't Fix |
Triaged |
|
| 2020-04-24 20:38:03 |
Miguel Lavalle |
neutron: importance |
Undecided |
Wishlist |
|
| 2020-04-24 20:38:24 |
Miguel Lavalle |
summary |
Neutron ports dns_assignment does not match the designate DNS records for Neutron port |
[RFE] Neutron ports dns_assignment does not match the designate DNS records for Neutron port |
|
| 2020-04-24 20:39:28 |
Miguel Lavalle |
tags |
rfe |
rfe-triaged |
|
| 2020-05-08 14:43:32 |
Slawek Kaplonski |
tags |
rfe-triaged |
rfe-approved |
|
| 2020-05-08 14:43:35 |
Slawek Kaplonski |
neutron: status |
Triaged |
Confirmed |
|
| 2020-05-28 23:22:47 |
OpenStack Infra |
neutron: status |
Confirmed |
In Progress |
|
| 2020-05-28 23:22:47 |
OpenStack Infra |
neutron: assignee |
|
hamza (alqtaishat) |
|
| 2020-07-01 21:14:31 |
Slawek Kaplonski |
neutron: milestone |
|
victoria-2 |
|
| 2020-07-08 23:38:36 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Released |
|
| 2022-09-20 12:48:20 |
Edward Hope-Morley |
bug task added |
|
cloud-archive |
|
| 2022-09-20 12:48:31 |
Edward Hope-Morley |
nominated for series |
|
cloud-archive/victoria |
|
| 2022-09-20 12:48:31 |
Edward Hope-Morley |
bug task added |
|
cloud-archive/victoria |
|
| 2022-09-20 12:48:31 |
Edward Hope-Morley |
nominated for series |
|
cloud-archive/ussuri |
|
| 2022-09-20 12:48:31 |
Edward Hope-Morley |
bug task added |
|
cloud-archive/ussuri |
|
| 2022-09-20 12:48:40 |
Edward Hope-Morley |
cloud-archive/victoria: status |
New |
Fix Released |
|
| 2022-09-20 12:49:02 |
Edward Hope-Morley |
bug task added |
|
neutron (Ubuntu) |
|
| 2022-09-20 12:49:12 |
Edward Hope-Morley |
nominated for series |
|
Ubuntu Focal |
|
| 2022-09-20 12:49:12 |
Edward Hope-Morley |
bug task added |
|
neutron (Ubuntu Focal) |
|
| 2022-09-20 12:49:51 |
Edward Hope-Morley |
attachment added |
|
lp1873091-ussuri.debdiff https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1873091/+attachment/5617403/+files/lp1873091-ussuri.debdiff |
|
| 2022-09-20 15:14:41 |
Edward Hope-Morley |
description |
the Neutron port dns_assignment dont match the designate DNS records assigned to the Neutron port
as explained in the link below
https://docs.openstack.org/neutron/pike/admin/config-dns-int.html
when a user creates a neutron port using the command below
neutron port-create 37aaff3a-6047-45ac-bf4f-a825e56fd2b3 \
--dns-name my-vm --dns_domain port-domain.org.
The actual output for dns_assignment is:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.example.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.example.org."}
and the Designate DNS records is
67a8e83d-7e3c-4fb1-9261-0481318bb7b5 | A | my-vm.port-domain.org. | 203.0.113.9
5a4f671c-9969-47aa-82e1-e05754021852 | AAAA | my-vm.port-domain.org. | 2001:db8:10::9
while the expected output for dns-assignment:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.port-domain.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.port-domain.org."}
most likely right now the dns_domain is taken from the Neutron network dns_domain or from neutron dns_domain configuration
A good approach would be to always make the dns_assignment for Neutron port synced with the Designate DNS records if Designate is used |
the Neutron port dns_assignment dont match the designate DNS records assigned to the Neutron port
as explained in the link below
https://docs.openstack.org/neutron/pike/admin/config-dns-int.html
when a user creates a neutron port using the command below
neutron port-create 37aaff3a-6047-45ac-bf4f-a825e56fd2b3 \
--dns-name my-vm --dns_domain port-domain.org.
The actual output for dns_assignment is:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.example.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.example.org."}
and the Designate DNS records is
67a8e83d-7e3c-4fb1-9261-0481318bb7b5 | A | my-vm.port-domain.org. | 203.0.113.9
5a4f671c-9969-47aa-82e1-e05754021852 | AAAA | my-vm.port-domain.org. | 2001:db8:10::9
while the expected output for dns-assignment:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.port-domain.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.port-domain.org."}
most likely right now the dns_domain is taken from the Neutron network dns_domain or from neutron dns_domain configuration
A good approach would be to always make the dns_assignment for Neutron port synced with the Designate DNS records if Designate is used
=== Ubuntu SRU Details ===
[Impact]
If a network is created it assumed the dns_domain from neutron.conf if one is not provided when the network is created but if it we expect that one to take precendence. We also expect ports created on this network to use the network dns_domain. This was not happening and is fixed with this patch.
[Test Case]
* deploy Openstack Ussuri
* configure neutron-api dns-domain="test.dom1."
* create a network with --dns-domain test.dom2.
* create a vm with port on that network and check that the port is using test.dom2.
[Where things could go wrong]
This will not fix existing networks and ports but is not expected to cause any regressions. |
|
| 2022-09-20 16:24:16 |
Ubuntu Foundations Team Bug Bot |
tags |
rfe-approved |
patch rfe-approved |
|
| 2022-09-20 16:24:23 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2022-09-21 22:26:48 |
OpenStack Infra |
cloud-archive/ussuri: status |
New |
Fix Committed |
|
| 2022-09-26 19:27:32 |
Corey Bryant |
cloud-archive/ussuri: status |
Fix Committed |
Triaged |
|
| 2022-09-26 19:28:04 |
Corey Bryant |
cloud-archive: status |
New |
Fix Released |
|
| 2022-09-26 19:28:17 |
Corey Bryant |
neutron (Ubuntu Focal): status |
New |
Triaged |
|
| 2022-09-26 19:32:07 |
Corey Bryant |
neutron (Ubuntu Focal): importance |
Undecided |
High |
|
| 2022-09-26 19:32:10 |
Corey Bryant |
cloud-archive/ussuri: importance |
Undecided |
High |
|
| 2022-09-26 21:00:49 |
Corey Bryant |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-09-29 16:42:37 |
OpenStack Infra |
tags |
patch rfe-approved |
in-stable-train patch rfe-approved |
|
| 2022-09-29 16:43:25 |
OpenStack Infra |
tags |
in-stable-train patch rfe-approved |
in-stable-stein in-stable-train patch rfe-approved |
|
| 2022-10-21 10:08:39 |
Timo Aaltonen |
neutron (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2022-10-21 10:08:43 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2022-10-21 10:08:46 |
Timo Aaltonen |
tags |
in-stable-stein in-stable-train patch rfe-approved |
in-stable-stein in-stable-train patch rfe-approved verification-needed verification-needed-focal |
|
| 2022-10-24 13:11:36 |
Edward Hope-Morley |
description |
the Neutron port dns_assignment dont match the designate DNS records assigned to the Neutron port
as explained in the link below
https://docs.openstack.org/neutron/pike/admin/config-dns-int.html
when a user creates a neutron port using the command below
neutron port-create 37aaff3a-6047-45ac-bf4f-a825e56fd2b3 \
--dns-name my-vm --dns_domain port-domain.org.
The actual output for dns_assignment is:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.example.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.example.org."}
and the Designate DNS records is
67a8e83d-7e3c-4fb1-9261-0481318bb7b5 | A | my-vm.port-domain.org. | 203.0.113.9
5a4f671c-9969-47aa-82e1-e05754021852 | AAAA | my-vm.port-domain.org. | 2001:db8:10::9
while the expected output for dns-assignment:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.port-domain.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.port-domain.org."}
most likely right now the dns_domain is taken from the Neutron network dns_domain or from neutron dns_domain configuration
A good approach would be to always make the dns_assignment for Neutron port synced with the Designate DNS records if Designate is used
=== Ubuntu SRU Details ===
[Impact]
If a network is created it assumed the dns_domain from neutron.conf if one is not provided when the network is created but if it we expect that one to take precendence. We also expect ports created on this network to use the network dns_domain. This was not happening and is fixed with this patch.
[Test Case]
* deploy Openstack Ussuri
* configure neutron-api dns-domain="test.dom1."
* create a network with --dns-domain test.dom2.
* create a vm with port on that network and check that the port is using test.dom2.
[Where things could go wrong]
This will not fix existing networks and ports but is not expected to cause any regressions. |
the Neutron port dns_assignment dont match the designate DNS records assigned to the Neutron port
as explained in the link below
https://docs.openstack.org/neutron/pike/admin/config-dns-int.html
when a user creates a neutron port using the command below
neutron port-create 37aaff3a-6047-45ac-bf4f-a825e56fd2b3 \
--dns-name my-vm --dns_domain port-domain.org.
The actual output for dns_assignment is:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.example.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.example.org."}
and the Designate DNS records is
67a8e83d-7e3c-4fb1-9261-0481318bb7b5 | A | my-vm.port-domain.org. | 203.0.113.9
5a4f671c-9969-47aa-82e1-e05754021852 | AAAA | my-vm.port-domain.org. | 2001:db8:10::9
while the expected output for dns-assignment:
{"hostname": "my-vm", "ip_address": "203.0.113.9", "fqdn": "my-vm.port-domain.org."}
{"hostname": "my-vm", "ip_address": "2001:db8:10::9", "fqdn": "my-vm.port-domain.org."}
most likely right now the dns_domain is taken from the Neutron network dns_domain or from neutron dns_domain configuration
A good approach would be to always make the dns_assignment for Neutron port synced with the Designate DNS records if Designate is used
=== Ubuntu SRU Details ===
[Impact]
If a network is created it assumed the dns_domain from neutron.conf if one is not provided when the network is created but if it we expect that one to take precendence. We also expect ports created on this network to use the network dns_domain. This was not happening and is fixed with this patch.
[Test Case]
* deploy Openstack Ussuri
* configure neutron-api dns-domain="test.dom1."
* create a network with --dns-domain test.dom2.
* create a vm with port on that network and check that the port is using test.dom2.
* to check the domain for the new port you can use resolvectl inside the vm (dns_domain on the port i neutron will not be set)
[Where things could go wrong]
This will not fix existing networks and ports but is not expected to cause any regressions. |
|
| 2022-10-25 14:16:52 |
Corey Bryant |
cloud-archive/ussuri: status |
Triaged |
Fix Committed |
|
| 2022-10-25 14:16:55 |
Corey Bryant |
tags |
in-stable-stein in-stable-train patch rfe-approved verification-needed verification-needed-focal |
in-stable-stein in-stable-train patch rfe-approved verification-needed verification-needed-focal verification-ussuri-needed |
|
| 2022-11-09 11:38:17 |
Brian Murray |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2023-01-13 16:08:12 |
Edward Hope-Morley |
tags |
in-stable-stein in-stable-train patch rfe-approved verification-needed verification-needed-focal verification-ussuri-needed |
in-stable-stein in-stable-train patch rfe-approved verification-done-focal verification-needed verification-ussuri-needed |
|
| 2023-01-13 19:44:41 |
Edward Hope-Morley |
tags |
in-stable-stein in-stable-train patch rfe-approved verification-done-focal verification-needed verification-ussuri-needed |
in-stable-stein in-stable-train patch rfe-approved verification-done verification-done-focal verification-ussuri-done |
|
| 2023-01-23 11:20:28 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-01-23 11:21:30 |
Launchpad Janitor |
neutron (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2023-01-23 14:48:43 |
Corey Bryant |
neutron (Ubuntu): status |
New |
Invalid |
|
| 2023-01-23 14:56:47 |
Corey Bryant |
cloud-archive/ussuri: status |
Fix Committed |
Fix Released |
|
