[RFE] allow to create record on default zone from tenants

Bug #1843218 reported by Gregoire Mahe on 2019-09-09
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Gregoire Mahe

Bug Description

Neutron has, in DEFAULT section in neutron.conf file, a key dns_domain which is a domain fallback.

Basically, if we create port with neutron, the default dns assigment will be myport.defaultzone.com.

Currently, Designate Integration will create DNS record myport.defaultzone.com. A portIP

The problem is, defaultzone.com. can be created only inside one and only one tenant. So this feature works only for one tenant, because the others has not access to this zone.

One of the solution I propose, is to integrate tenantid variable into default zone. So basically, create <tenantid>.defaultzone.com.
on each tenants, to allow users to have their DNS record myport.<tenantid>.defaultzone.com. inside their own tenant.

To sumarize,

When the user do openstack port create --network public --dns-name myport port, a default record will be created at myport.<tenantid>.defaultzone.com.

So, when a user creates an instance with nova, or port with neutron, we want to create automatically dns record myport.<tenantid>.defaultzone.com. inside his own tenant. (A and AAAA fields)

We want to allow default DNS when a user creates instance without specifying dns domain / dns name. Like S3 with AWS, when you creates a bucket, you have a default dns. (I don't know if this is the same with EC2, but I think so.

description: updated
Miguel Lavalle (minsel) on 2019-09-13
tags: added: rfe
Miguel Lavalle (minsel) wrote :

Hi Gregoire,

Today, to create a record in Designate through the integration with Neutron, we don't use the dns_domain entry in neutron.conf. For the integration with Designate to create a record, the following conditions must be met:

1) The port's network has to have a non blank value in it dns_domain attribute
2) The port has to have a non blank value in it dns_name attribute
3) The zone that corresponds to the network's dns_domain value must exist already in designate under the tenant

What you are proposing is to create the records under <tenantid>.defaultzone.com., where defaultzone is the value of the dns_domain config option in neutron.conf. Am I understanding correctly?

If that is what you are proposing, who is going to create the zone is Designate?

Changed in neutron:
importance: Undecided → Wishlist
Gregoire Mahe (gregoiremahe) wrote :

Hello Miguel,

You understood correctly

I don't know what is the easiest, but I propose that neutron calls designate to create <tenantid>.defaultzone.com. if it doesn't exists. Basically, when the user creates a port or virtual machine with neutron / nova, neutron calls designate to create the zone and then the record for A, AAAA and PTR

Gregoire Mahe (gregoiremahe) wrote :


Actually I think It's better to setup <tenantid>.defaultzone.com. (even <tenantid>.<.regionname>.defaultzone.com.) when doing network set public --dns-domain instead of configuring it in neutron.conf file.

It would give more freedom to users

I'm gonna start coding the feature

Changed in neutron:
assignee: nobody → Gregoire Mahe (gregoiremahe)
status: New → In Progress
Miguel Lavalle (minsel) on 2019-09-19
Changed in neutron:
status: In Progress → Triaged
Miguel Lavalle (minsel) wrote :

Hi Gregoire,

Feel free to start coding. Be aware, though, that until the RFE is tagged as "rfe-confirmed" and we leave you a message explicitly indicating that it has been approved, it is still possible that we won't accept it. We are still in the clarification stage and you seem to be changing your proposal as you add responses above. So, let's first firm up your proposal:

1) Based on what you have stated in emails and here and the fact that you work for OVH, I have gleaned the following use case: you have users of a public cloud who all connect their VMs to a shared public cloud. Upon creation of these VMs, you want them to have a public DNS record published by Designate

2) The latest variation of your proposal is that you are going to associate a default zone name to the dns_domain attribute of the big shared public network

3) Every time a VM is created with a port in the public shared network, you are going to create a records in a zone named <tenantid>.<defaultzone>.com, <defaultzone> is the name associated to the public network's dns_domain attribute

Does this summarize your proposal?

Now, a couple of questions:

1) What is going to be the left part of your DNS record?

2) Currently, the Neutron - Designate integration has a number of behaviors, which we have to preserve. How are you going to enable the behavior you are proposing?

Gregoire Mahe (gregoiremahe) wrote :

Hi Miguel,

What you said is globally right :

1) That's right

2) Right again

3) That part is almost right : "Every time a VM is created with a port in the public shared network, you are going to create a records in a zone named <tenantid>.<defaultzone>.com"
Not every time, but only when the user doesn't specify his own custom zone

About the second part of your point, I think it depends on how we will implement the feature. (see below)

About your questions :

1) The left part of the DNS record should be the servername by default, and can be choosen by the user by using --dns-name while creating port. It's actually the current behavior. We just need to variabilize <tenantid> inside the zone name. If the user uses --dns-domain on port creation, his own zone will be used instead of default zone (<tenantid>.<defaultzone>.com)

2) I have an idea of the way to implement it, but I am open to discuss about that and change the way to do it if necessary.

Here is the definition of DNS label from neutron's code point of vue :
A DNS Label is a set of characters from 1 to 63 long (defined in the RFC), with alpha-numerical characters plus hyphen (it's actually all ascii characters in the RFC, but anyway)
The labels are validated with a regular expression on neutron-lib.

What I propose is to change this regex, to keep the condition above, but allow label equal to <tenantid>. Then, on DNS integration, just replace this label by the tenantid (the data is accessible from almost all functions in dns-integration)

I Actually already did the feature, waiting to be added to OVH organization on launchpad to push the code.

What do you think about the way I propose ?

Grégoire -

Miguel Lavalle (minsel) wrote :

Yes, I think we are going in the right direction. Thanks for your responses. I think we are ready to discuss this proposal in the drivers meeting. I will talk to Slawek to see when we can schedule it for discussion.

tags: added: rfe-confirmed
removed: rfe
Miguel Lavalle (minsel) wrote :

I will leave you here a comment when the RFE is scheduled for discussion so you can attend the meeting. You don't have to. We will discuss it whether you are in attendance or not. But if you want to, you will be welcome

Slawek Kaplonski (slaweq) wrote :

IMO this is ready to be discussed in drivers meeting. I will add it to agenda but probably we will not be able to discuss it this week.

tags: added: rfe-triaged
removed: rfe-confirmed
Slawek Kaplonski (slaweq) wrote :


On today's drivers meeting we approved this RFE: http://eavesdrop.openstack.org/meetings/neutron_drivers/2019/neutron_drivers.2019-10-04-14.00.log.html#l-171

Next step now is for reported of this RFE to write spec for it.

@Greg: all specs are in repository https://github.com/openstack/neutron-specs - You should propose patch with new spec to this repository. Workflow is exactly the same as for Neutron patches. If You will need any help, ping me on IRC (my nick is slaweq)

tags: added: rfe-approved
removed: rfe-triaged

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

commit b27c012972d8b4a0282e55573cc3aa6b8efd71eb
Author: Gregoire Mahe <email address hidden>
Date: Wed Oct 2 09:48:42 2019 +0200

    Allow <project_id>, <project_name>, <user_id> and <user_name> as DNS label

    A DNS label is a alphanumerical text seperated by period(s).
    (i.e. label1.label2.label2.com.)
    Here we allow a label to be equal keywords defined which will be eval later

    Related-Bug: #1843218
    Needed-By: https://review.opendev.org/#/c/686343/
    Change-Id: I6a1b983cf1bb0d6d04ec75b4725f39f29dc4c2ba

Changed in neutron:
milestone: none → ussuri-1
Changed in neutron:
milestone: ussuri-1 → none

Reviewed: https://review.opendev.org/687458
Committed: https://git.openstack.org/cgit/openstack/neutron-specs/commit/?id=f0963c1f0b0e9bd1ee587897eccd1d8c4ce4930b
Submitter: Zuul
Branch: master

commit f0963c1f0b0e9bd1ee587897eccd1d8c4ce4930b
Author: Gregoire Mahe <email address hidden>
Date: Wed Oct 9 08:32:25 2019 +0200

    Allow user to create default record on port creation from shared network

    Related-Bug: #1843218
    Change-Id: Id393b62ddfd3f9f010c7d7898a564a211b3405a4

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

commit dac97d1f2df502d04b2316a51a964cc9a8090f4e
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jun 15 22:50:43 2020 +0200

    Add new shim API extension for dns domain with keywords

    Change-Id: Ia659e7b20464da4b87cbc69681c7db54bccea41b
    Related-Bug: #1843218

Zoltan Arnold Nagy (zoltan) wrote :

Are there still missing pieces of this that need to be merged upstream?

Slawek Kaplonski (slaweq) wrote :

Yes, we still need to merge https://review.opendev.org/#/c/686343/ and then tests patch https://review.opendev.org/733994

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers