[RFE] Allow specifying dns_domain when creating a port

[Conrad Kimball]

When creating a port, allow specifying a dns_domain instead of inheriting dns_domain from the network.

In our enterprise we do not tie DNS domains to networks - we use the DNS domain of a VM port to indicate the business unit or the infrastructure function of a VM. Thus our data center networks routinely have VM ports with a variety of DNS domains, with the choice of DNS domain left to the person deploying the VM instance.

To carry this practice into OpenStack, we will extend our data center network into OpenStack using a provider network, and we need the ability to create ports on that network with various dns_names furnished by the VM creator.

[Armando Migliaccio (armando-migliaccio)]

@Reedip: don't start working on it. We may never want to allow this use case. Wait for drivers direction.

[Miguel Lavalle (minsel)]

The bug suggests that dns_domain is being used in for tagging purposes. Ports and floating ips dns_name and dns_domain attributes have consequences: if an external DNS service is configured, Neutron is going to try to set up the dns_name in the dns_domain in the external DNS service. Furthermore, the zone indicated by dns_domain is expected to exist in the external DNS service.

If the purpose is only tagging, please consider the Neutron tags extension, which was created exactly with this in mind: http://docs.openstack.org/newton/networking-guide/ops-resource-tags.html. Although in its present form it only applies to networks right now, work is under way to extend it to other resources, including ports: https://review.openstack.org/#/c/413662/

[Conrad Kimball (conrad-kimball)]

I'm puzzled about "may never want to allow this use case" - curious about what is the thinking behind that comment? To me it's an obvious use case, and I was astonished that the design did not already accommodate this use case. Network topologies and DNS name spaces are fundamentally independent things. If somebody wants to operationally link those, I suppose it's OK for them, but do not force that operational linkage onto the world.

Who are the "drivers" that you look to for direction?

[Armando Migliaccio (armando-migliaccio)]

@Conrad: my comment was motivated by not knowing what might be required to fulfill the particular use case. I am not ruling out the use case yet, but if an RFE requires a complete rewrite of what we have, it's very likely that we would want absolute consensus that it is the right thing to do and that we can commit resources to make it happen.

You can find members of the neutron drivers here:

https://launchpad.net/~neutron-drivers

[Akihiro Motoki (amotoki)]

I am not sure the bug just suggests that dns_domain is used for tagging purpose.

In a provider network deployment scenarios, all VMs belong to a single network. There may be a case where some set of VMs belong to service A with foo.example.net and other set of VMs belong to service B with bar.example.net. In such case, dns_domain per port might be needed. I think it is a valid use case.

We already allows users to assign both dns_domain and dns_name for a specific floating IP, so I am not sure there is a reason we do not allow dns_domain per port.

Note that if the self-service network model is used, you can define neutron network per service (i.e. business unit in the bug description) and assign dns-domain for individual neutron network.

[Conrad Kimball (conrad-kimball)]

Yes, you got it. We need the ability to have VMs with different, user-specified dns_domains all on the same provider network.

Conrad Kimball
Associate Technical Fellow
Chief Architect, Enterprise Cloud Services
Application Infrastructure Services / Global IT Infrastructure / Information Technology & Data Analytics
<email address hidden>
P.O. Box 3707, Mail Code 7M-TE
Seattle, WA  98124-2207
Bellevue 33-11 bldg, office 3A6-3.9
Mobile:  [phone]

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Akihiro Motoki
Sent: Thursday, March 30, 2017 12:43 PM
To: Kimball, Conrad <email address hidden>
Subject: [Bug 1650678] Re: [RFE] Allow specifying dns_domain when creating a port

I am not sure the bug just suggests that dns_domain is used for tagging purpose.

In a provider network deployment scenarios, all VMs belong to a single network. There may be a case where some set of VMs belong to service A with foo.example.net and other set of VMs belong to service B with bar.example.net. In such case, dns_domain per port might be needed. I think it is a valid use case.

We already allows users to assign both dns_domain and dns_name for a specific floating IP, so I am not sure there is a reason we do not allow dns_domain per port.

Note that if the self-service network model is used, you can define neutron network per service (i.e. business unit in the bug description) and assign dns-domain for individual neutron network.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1650678

Title:
  [RFE] Allow specifying dns_domain when creating a port

Status in neutron:
  Triaged

Bug description:
  When creating a port, allow specifying a dns_domain instead of
  inheriting dns_domain from the network.

  In our enterprise we do not tie DNS domains to networks - we use the
  DNS domain of a VM port to indicate the business unit or the
  infrastructure function of a VM. Thus our data center networks
  routinely have VM ports with a variety of DNS domains, with the choice
  of DNS domain left to the person deploying the VM instance.

  To carry this practice into OpenStack, we will extend our data center
  network into OpenStack using a provider network, and we need the
  ability to create ports on that network with various dns_names
  furnished by the VM creator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1650678/+subscriptions

[Akihiro Motoki (amotoki)]

This is approved in the driver meeting.

@Conrad, do you plan to implement it, or do we need any volunteer?

http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-03-30-22.01.log.html#l-144

[Conrad Kimball (conrad-kimball)]

Good news - thank you.

We are unable to implement this, sorry. Wish we could, but we are OpenStack newbies without the skills to do so, and we have corporate hurdles to contributing to open source :-(

I will feed this to the company we are getting our commercially supported distribution from, if that helps.

Conrad Kimball
Associate Technical Fellow
Chief Architect, Enterprise Cloud Services
Application Infrastructure Services / Global IT Infrastructure / Information Technology & Data Analytics
<email address hidden>
P.O. Box 3707, Mail Code 7M-TE
Seattle, WA  98124-2207
Bellevue 33-11 bldg, office 3A6-3.9
Mobile:  [phone]

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Akihiro Motoki
Sent: Thursday, March 30, 2017 5:34 PM
To: Kimball, Conrad <email address hidden>
Subject: [Bug 1650678] Re: [RFE] Allow specifying dns_domain when creating a port

This is approved in the driver meeting.

@Conrad, do you plan to implement it, or do we need any volunteer?

http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-03-30-22.01.log.html#l-144

** Tags removed: rfe
** Tags added: rfe-approved

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1650678

Title:
  [RFE] Allow specifying dns_domain when creating a port

Status in neutron:
  Triaged

Bug description:
  When creating a port, allow specifying a dns_domain instead of
  inheriting dns_domain from the network.

  In our enterprise we do not tie DNS domains to networks - we use the
  DNS domain of a VM port to indicate the business unit or the
  infrastructure function of a VM. Thus our data center networks
  routinely have VM ports with a variety of DNS domains, with the choice
  of DNS domain left to the person deploying the VM instance.

  To carry this practice into OpenStack, we will extend our data center
  network into OpenStack using a provider network, and we need the
  ability to create ports on that network with various dns_names
  furnished by the VM creator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1650678/+subscriptions

[Miguel Lavalle (minsel)]

@Conrad,

I know the relevant code very well. If you don't find a resource to implement, I can do it. Alternatively, if you find a resource, I can guide that person. Let me know how you want to proceed

[Reedip (reedip-banerjee-deactivatedaccount)]

I can also help out if need be

[Conrad Kimball (conrad-kimball)]

Please go ahead, Miguel, Reedip, or any others that are interested.

I simply submitted the enhancement request; I'm not in a position to recommend or decide how the work gets done.

Conrad Kimball
Associate Technical Fellow
Chief Architect, Enterprise Cloud Services
Application Infrastructure Services / Global IT Infrastructure / Information Technology & Data Analytics
<email address hidden>
P.O. Box 3707, Mail Code 7M-TE
Seattle, WA  98124-2207
Bellevue 33-11 bldg, office 3A6-3.9
Mobile:  [phone]

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Miguel Lavalle
Sent: Thursday, April 06, 2017 4:30 PM
To: Kimball, Conrad <email address hidden>
Subject: [Bug 1650678] Re: [RFE] Allow specifying dns_domain when creating a port

@Conrad,

I know the relevant code very well. If you don't find a resource to implement, I can do it. Alternatively, if you find a resource, I can guide that person. Let me know how you want to proceed

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1650678

Title:
  [RFE] Allow specifying dns_domain when creating a port

Status in neutron:
  Triaged

Bug description:
  When creating a port, allow specifying a dns_domain instead of
  inheriting dns_domain from the network.

  In our enterprise we do not tie DNS domains to networks - we use the
  DNS domain of a VM port to indicate the business unit or the
  infrastructure function of a VM. Thus our data center networks
  routinely have VM ports with a variety of DNS domains, with the choice
  of DNS domain left to the person deploying the VM instance.

  To carry this practice into OpenStack, we will extend our data center
  network into OpenStack using a provider network, and we need the
  ability to create ports on that network with various dns_names
  furnished by the VM creator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1650678/+subscriptions

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/457035

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/457101

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/459891

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/468697

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/459891
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=5c1914856339042d83a133abbedd7906a1124f9e
Submitter: Jenkins
Branch: master

commit 5c1914856339042d83a133abbedd7906a1124f9e
Author: Miguel Lavalle <email address hidden>
Date: Tue Apr 25 18:26:46 2017 -0500

    Define dns-domain-ports extension

    This patch introduces the API definition for the dns_domain_ports
    extension

    Change-Id: I79a96e72daa5baf579fcece2a703a47b8059423e
    Partial-Bug: #1650678

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/457101
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=190b31e03a1d2ea9be9fd764acab53da8c226a35
Submitter: Jenkins
Branch: master

commit 190b31e03a1d2ea9be9fd764acab53da8c226a35
Author: Miguel Lavalle <email address hidden>
Date: Sun Apr 16 18:28:06 2017 -0500

    Add dns_domain attribute to ports in the API

    This change adds a dns_domain attribute to ports in the API.

    This patchset belongs to a series that adds dns_domain attribute
    functionality to ports.

    Change-Id: Ied1f2f0c1e96ae21c309b6e6fed9e3c602b0450b
    Partial-Bug: #1650678

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/457035
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=727039bce88233babf8bda19442df79e5c5f1592
Submitter: Jenkins
Branch: master

commit 727039bce88233babf8bda19442df79e5c5f1592
Author: Miguel Lavalle <email address hidden>
Date: Sat Apr 15 19:26:51 2017 -0500

    Add port dns_domain to DB and object models

    This patchset adds a new dns_domain attribute to the PortDNS DB model
    and OVO object.

    This patchset belongs to a series that adds dns_domain attribute
    functionality to ports.

    Change-Id: Ib1ea7d0faee4f0544141fdcbb75164aadcfc5056
    Partial-Bug: #1650678

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/491873

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/491873
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=37d33b2fcd4a1dde356df3b4b4a2f739afb6876c
Submitter: Jenkins
Branch: master

commit 37d33b2fcd4a1dde356df3b4b4a2f739afb6876c
Author: Kevin Benton <email address hidden>
Date: Tue Aug 8 10:57:37 2017 -0700

    Allow extension driver to provide multiple aliases

    This allows extensions to supercede older extensions
    if they provide all of the same functionality plus more.
    This is used by the DNS domain port extension driver.

    Change-Id: I3e91669a83e9e16039f4063bf54b511cec94cecc
    Partial-bug: #1650678

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/468697
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4a7753325999ef1e5c77f6131cfe03b2cfa364a7
Submitter: Jenkins
Branch: master

commit 4a7753325999ef1e5c77f6131cfe03b2cfa364a7
Author: Miguel Lavalle <email address hidden>
Date: Sat May 27 18:27:34 2017 -0500

    Add port dns_domain processing logic

    This patchset adds logic to the ML2 DNS integration extension to process
    a new dns_domain attribute associated to ports.

    This patchset belongs to a series that adds dns_domain attribute
    functionality to ports.

    DocImpact: Ports have a new dns_domain attribute, that takes precedence
               over networks dns_domain when published to an external DNS
               service.

    APIImpact: Users can now specify a dns_domain attribute in port POST and
               PUT operations.

    Change-Id: I02d8587d3a1f9f3f6b8cbc79dbe8df4b4b99a893
    Partial-Bug: #1650678

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/493108

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/493108
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bda14668119ea6c884b46983b187f55f2d55b3dd
Submitter: Jenkins
Branch: stable/pike

commit bda14668119ea6c884b46983b187f55f2d55b3dd
Author: Miguel Lavalle <email address hidden>
Date: Sat May 27 18:27:34 2017 -0500

    Add port dns_domain processing logic

    This patchset adds logic to the ML2 DNS integration extension to process
    a new dns_domain attribute associated to ports.

    This patchset belongs to a series that adds dns_domain attribute
    functionality to ports.

    DocImpact: Ports have a new dns_domain attribute, that takes precedence
               over networks dns_domain when published to an external DNS
               service.

    APIImpact: Users can now specify a dns_domain attribute in port POST and
               PUT operations.

    Change-Id: I02d8587d3a1f9f3f6b8cbc79dbe8df4b4b99a893
    Partial-Bug: #1650678
    (cherry picked from commit 4a7753325999ef1e5c77f6131cfe03b2cfa364a7)