Neutron doesn't update Designate with some use cases

[Kobi Samoray]

Neutron and Designate integration covers use cases for ports which are exposed via floating IPs, or reside on provider networks.
However, the following use cases aren't being covered:
1. Ports reside on a no-NAT network, which is routable from outside the Openstack deployment.
2. Ports on any network which need exposure via DNS: e.g an app uses FQDNs to intercommunicate between app components.

As the no-NAT attribute belongs to the router, and not to the network, it might be tricky to detect port exposure via this attribute: a user could attach a network with some ports on it to a no-NAT network and so they're exposed even though they weren't during creation.
Or a router might be changed from NAT to no-NAT and vice versa.
To simplify I would suggest adding an attribute to the network via an extension, which would indicate that this network's ports should be published on the DNS.
So for networks which need exposure via DNS, we could flag these networks and force the DNS publishing.

[Miguel Lavalle (minsel)]

Hi Koby,

I want to explore and clarify the requirement you are talking about here:

1) Have you read this section of the Networking guide: https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html#use-case-3-ports-are-published-directly-in-the-external-dns-service?

2) How is the use case described in that section of the Networking Guide different to what you are proposing?

[Kobi Samoray (ksamoray)]

Use case #3 is for external/provider networks.
Two cases which I suggested are different as:
a) We could expose an overlay network externally via addition to a no-nat Neutron router.
b) It's legit to use FQDNs within projects networks, even with no external access. It's not a classic public cloud use case, yet still legit.

[Dr. Jens Harbott (j-harbott)]

I think that these are valid use cases, I have another similar one: public IPv6 networks in project networks according to https://cloudbau.github.io/openstack/neutron/networking/ipv6/2017/09/11/neutron-pike-ipv6.html , where users get public IPv6 addresses for their instances and want to have DNS records for these.

My use case would even go a step further in that I would want to select per subnet whether DNS entries are published and not only per network. One idea I had was to use the address scope property of the subnet for making that decision, but having an explicit flag that can be specified per network, subnet or even per port would probably be the most flexible solution.

[Miguel Lavalle (minsel)]

Hi Kobi,

Jens proposal in #3 is "having an explicit flag that can be specified per network, subnet or even per port would probably be the most flexible solution". That is a more general case that includes the proposal you made in #1, isn't it?

I assume that the domain / zone would come from the dns_domain attribute of the network and the dns_name would be the port's. Is this assumption correct?

[Kobi Samoray (ksamoray)]

Hi Miguel,
Jens' proposal extends mine. Or we can see this as three separate cases if you want (network/subnet/port).
I guess that we could extend each of the above with 'dns_publish_fixed_ip' attribute, which will use the dns_domain and dns_name as you suggested, if both are set.

[Salvatore Orlando (salvatore-orlando)]

It all boils down to granularity indeed. Port-level is the most granular of course.
On the other hand, coarse-grained approaches such as network or subnet maybe provide better UX for common use cases; if one only wants to expose a port in a network maybe this is already covered by the floating IP approach.

It is also possible to devise a mechanism where the attribute could be set at different levels of granularity. That would bring in additional complexity (both for implementation and usage). Personally at this time I would not consider a scenario where more granular settings can override base settings.

Thinking about subnets vs networks, maybe the subnet is a better choice as it will allow for uniquely identifying the IP that should be registered for a host.

One last point would be about floating IPs registered in designate: should a distinct host name be used for internal IPs?

[Miguel Lavalle (minsel)]

The way a see it, if we implemented the 'dns_publish_fixed_ip' at network, subnet and port level, we would enable the each user to select the level of complexity she is willing to handle, so maybe from the UX point of view it won't have a negative impact. Of course, it increases the complexity of implementation.

As for using a distinct host name for the internal port IP is there is also a floating IP involved (I believe that is what Salvatore meant), I think there are two alternatives based on what we have currently implemented. If the floating IP has its own dns_name and dns_domain set, we register those in DNS under the floating ip address and we register the dns_doamin / dns_name of the port and its network under the fixed ips if 'dns_publish_fixed_ip' is set. If the floating ip doesn't have its dns_name and dns_domain defined and the port / network / subnet have 'dns_publish_fixed_ip' set, then we don't register the floating ip, only the fixed ips. Thoughts?

[Salvatore Orlando (salvatore-orlando)]

Hi Miguel. Thanks for your answer.

Regarding complexity: This is mostly about implementation, correct. There is surely great flexibility for users. However, I think there is also an usage complexity too however: for instance if dns_publish_fixed_ip=True or a port, but then if it is False for one of the subnets where the port has an IP, what should be the right thing to do? Does the port setting override the subnet setting, or not? This will also bring up another topic that (from what I recall) the community has deliberately avoided in the past, ie: whether "None" and "False" mean two different things.

Regarding potential conflicts with floating ip I think your suggestion would work fine.

[Miguel Lavalle (minsel)]

I see now Salvatore's point about excessive complexity. So I think we can attempt to move forward with Kobi's original idea of adding dns_publish_fixed_ip attribute at the network level. I'll mark this rfe as triaged and bring it up during the next drivers meeting. Let's see what feedback we get from them

[Miguel Lavalle (minsel)]

The drivers team discussed this RFE during today's meeting. The consensus was to add dns_publish_fixed_ip at the subnet level. We would like to hear feedback from the submitter and other interested parties over the next few days, so we can retake the discussion in the next meeting. Thanks to everybody for their opinions

[Dr. Jens Harbott (j-harbott)]

Per subnet would be fine for me.

[Miguel Lavalle (minsel)]

During the drivers meeting on October 5th we decided to hold a little longer on a decision on this RFE to give opportunity to other stakeholders to provide feedback

[Kobi Samoray (ksamoray)]

Either per network or subnet sounds reasonable.

[Dr. Jens Harbott (j-harbott)]

Just to make sure that it doesn't get lost in the long history:

Per network would not accomodate my use case of having tenant networks mixing private IPv4 addresses, nat-ted towards the outside, with publically routed IPv6 addresses.

Btw. has someone already volunteered to do the implementation? I could help with testing and reviewing, but I think I'd struggle to get the database part done properly.

[Miguel Lavalle (minsel)]

This RFE has been approved during today's drivers meeting

[Miguel Lavalle (minsel)]

@Jens,

Nobody has volunteered to implement this RFE. I'll wait a couple of weeks and if nobody volunteers, I will implement it myself

[Francois Deppierraz (francois-ctrlaltdel)]

Hi folks,

Jumping in the discussion as another future user of this feature.

Our use-case is creating dns records for routed ipv4 networks (same address scope) in a project-specific dns zone (say my_instance.project.my-corp) and it looks like the proposed solution of adding a dns_publish_fixed_ip attribute to the subnet would work well.

Thanks for your work!

[Salvatore Orlando (salvatore-orlando)]

Miguel - I and Kobi would be happy to work on the implementation

[Dr. Jens Harbott (j-harbott)]

@Salvatore: Do you still intend to handle this? Otherwise please unassign yourself and let someone else take over.

[Romain (romain-chanu)]

Hello,

I was the one on IRC who asked for some help about this subject... All our networks are routed by external router but we want to be able to publish new instances in DNS.

I finally changed the file neutron/plugins/ml2/extensions/dns_integration.py

    def external_dns_not_needed(self, context, network):
        if network['dns_domain']:
            return False
        else:
            return True

But I do not know if it doesnt affect others parts. For example, zone transfer is not working at all... Gonna post a bug in designate section

[Marco Schuster (interone-ms)]

I can confirm that removing the check from #20 works for my use case (which is similar to the one brought up in #17), and would suggest that an additional attribute on the Network object (e.g. "dns_force_entries", default=False) be created, so that users wishing to use automated DNS publishing are able to do so while keeping the "old" behavior as default for backwards compatibility.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/662405

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/662409

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/662405
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=56e0979fdd5d3b11b2c3e37492d76e9726fd747a
Submitter: Zuul
Branch: master

commit 56e0979fdd5d3b11b2c3e37492d76e9726fd747a
Author: Jens Harbott <email address hidden>
Date: Fri May 24 13:39:24 2019 +0000

    Add 'dns_publish_fixed_ip' attribute to Subnet

    Add a new attribute ``dns_publish_fixed_ip`` into ``subnet``
    resource. This attribute will be used to indicate whether to publish DNS
    records for fixed IPs from this subnet.

    Neutron patch: https://review.opendev.org/662409

    Thanks go to [0] which I took as a reference to create this patch.

    [0] I1371fc0b47c0015423e4346ffd43d39c8264b1a3

    Change-Id: I08ef19fcc06559c92ae3f8e6e66c5fd896815232
    Partial-Bug: 1784879

[OpenStack Infra (hudson-openstack)]

Change abandoned by Mohammed Naser (<email address hidden>) on branch: master
Review: https://review.opendev.org/654008
Reason: replaced by work in 662409

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/662409
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=57bc6d167b44b4c898626aad2ad840ed85b7df17
Submitter: Zuul
Branch: master

commit 57bc6d167b44b4c898626aad2ad840ed85b7df17
Author: Jens Harbott <email address hidden>
Date: Tue Dec 3 15:27:53 2019 +0000

    Allow to select subnets to publish DNS records

    As described in [0] a new attribute ``dns_publish_fixed_ip`` is added
    to subnets, allowing to specify directly whether DNS records should be
    published for this subnet. This overrides the previous behaviour that
    makes this decision based on various properties of the network that
    the subnet is contained in, see [1].

    [0] https://launchpad.net/bugs/1784879
    [1] https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html

    Change-Id: I14605ead2694d9e9422b3d7b519aed2e3c340e2a
    Partial-Bug: 1784879

[Dr. Jens Harbott (j-harbott)]

Patches to neutron-tempest-plugin, SDK and OSC also got merged, so I'd consider this thing finished.
https://review.opendev.org/679833
https://review.opendev.org/680384
https://review.opendev.org/679834