[RFE] create option in neutron.conf to disable designate+neutron consistency

[Gregoire Mahe]

Hello,

This RFE concerns https://bugs.launchpad.net/neutron/+bug/1846703

We need to disable consistency on neutron + designate pairing. Here is our usecase :

We are a cloud provider which uses openstack solution. We are split into different services, a service dedicated to compute (neutron + nova/compute + glance), and another one dedicated to DNS (classic, geotargetting, anycast, and openstack designate).

As we want to use designate and allow a user to have default records on their VM, we're going to pair neutron and designate. Our need is to try designate at large scale, without impacting compute service. So that's why we would like to disable consistency

To do this, I propose, as I said on the bug related :

---

STEP #1 : Allow user to disable consistency

Next, we need to add an option on neutron.conf, to disable consistency (which is by default enabled)
We have to ignore designate failures on this case, and don't revert anything uppon failure

---

STEP #2 : Store consistency issues when consistency is disabled

The aim is to improve consistency by storing all consistency problems in the neutron database to be able to delete / creates record to recreate the consistency later

---

Thanks,

[Slawek Kaplonski (slaweq)]

Hi,

IIUC correctly, You can implement what You need in new designate driver: https://github.com/openstack/neutron/blob/master/neutron/services/externaldns/drivers/designate/driver.py and use this "insecure_designate" driver instead of this default one. Am I right?
If so, do it really need to be in-tree? I think that You can maybe implement it in some external repo maybe?

[Slawek Kaplonski (slaweq)]

According to what I discussed with Gregoire yesterday we agreed that this what is described in this rfe can be achieved by adding new dns driver, like https://github.com/openstack/neutron/blob/master/neutron/services/externaldns/drivers/designate/driver.py

My feeling on this rfe is that this is not common use case and it is more "OVH only". So I'm not sure if we should include such driver in neutron three.

But from the other hand, Gregoire confirmed me that they want to do it in u/s so we should have some place where we can maybe put such driver. Creating new project just for this don't make sense IMO.

So question to other driver team members is: do You have maybe any ideas about what would be the best place for such driver?
Or maybe You have other ideas about how to solve problem described in this RFE?

[Miguel Lavalle (minsel)]

I have to say that there are many people using the current DNS integration (including my employer) without a problem. So whatever is done in regards to this bug, has to preserve the current behavior. Whatever is done, has to be an optional behavior separate from the current driver

[Gregoire Mahe (gregoiremahe)]

So what I propose, is to keep this dns_integration with consistency for port deletion, and inconsistency for port creation.

Then, I propose to create another dns_integration module to either strengthen consistency or remove it.

Is that okay for everybody ?

[Slawek Kaplonski (slaweq)]

Hi Gregoire,

We discussed briefly Your proposal on last drivers meeting at 25.10.2019.
And we have some additional questions about it.

1. Can You explain in more details what You meant in Your last comment (#4)? Do You want to propose 2 different drivers now? One which will keep consistency for deletion of ports and second one which will not care about it? Or what exactly?

2. Can You describe in details what is the use case behind this proposal? And if this is OVH specific use case or something more general maybe?

[Gregoire Mahe (gregoiremahe)]

Hi Slawek,

sure, here is

2. At OVH, we have an openstack infrastructure in production since many years. Now, we want to add designate to that infrastructure.

We need to test designate infrastructure in production before proposing the service to the customers. So, we're gonna have a stable infrastructure (neutron, nova, keystone, etc), and a unstable one (designate). Because of this, we don't want designate issues (infra and code) to impact stable infrastructure (neutron and so on). So, if designate fails, we don't want any impact on neutron's side

Today, here is the designate driver behavior :

- On designate failure, port creation works, and the record is not created (inconsistent behavior)
- On designate failure, port deletion doesn't work, and the port is not deleted (consistent behavior)

That's not coherent

1. That current behavior seems to be OK for many openstack users, as mlavalle, so we should keep this driver afaiu

I suggest to add another driver to completely remove consistency for our usecase at OVH
In addition, I suggest to add a third driver to completely implement consistency for others openstack users (https://bugs.launchpad.net/neutron/+bug/1846703)

[Slawek Kaplonski (slaweq)]

We decided to not accept this rfe as this is trying to address very specific use case from one company. And even in this case it seems to be something like temporary solution.