[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
This bug was fixed in the package manila - 1:14.1.1-0ubuntu1.2~cloud0 --- manila (1:14.1.1-0ubuntu1.2~cloud0) focal-yoga; urgency=medium . * New update for the Ubuntu Cloud Archive. . manila (1:14.1.1-0ubuntu1.2) jammy; urgency=medium . * d/p/lp2074504.patch: Fix OVN connectivity issues in DHSS=True, Create ports as disabled with external networks (LP: #2074504). * d/p/lp2049507.patch: Retry on connection error to Neutron (LP: #2049507). ** Changed in: cloud-archive/yoga Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
This bug was fixed in the package manila - 1:18.0.1-0ubuntu2.2~cloud0 --- manila (1:18.0.1-0ubuntu2.2~cloud0) jammy-caracal; urgency=medium . * New update for the Ubuntu Cloud Archive. . manila (1:18.0.1-0ubuntu2.2) noble; urgency=medium . * d/p/lp2074504.patch: Fix OVN connectivity issues in DHSS=True, Create ports as disabled with external networks (LP: #2074504). ** Changed in: cloud-archive/caracal Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
This bug was fixed in the package manila - 1:14.1.1-0ubuntu1.2 --- manila (1:14.1.1-0ubuntu1.2) jammy; urgency=medium * d/p/lp2074504.patch: Fix OVN connectivity issues in DHSS=True, Create ports as disabled with external networks (LP: #2074504). * d/p/lp2049507.patch: Retry on connection error to Neutron (LP: #2049507). -- Rodrigo Barbieri Thu, 24 Apr 2025 14:26:02 + ** Changed in: manila (Ubuntu Jammy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
This bug was fixed in the package manila - 1:18.0.1-0ubuntu2.2 --- manila (1:18.0.1-0ubuntu2.2) noble; urgency=medium * d/p/lp2074504.patch: Fix OVN connectivity issues in DHSS=True, Create ports as disabled with external networks (LP: #2074504). -- Rodrigo Barbieri Thu, 24 Apr 2025 19:08:48 + ** Changed in: manila (Ubuntu Noble) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Verified noble-proposed using [Test Case] with the following output: # apt-cache policy manila-common manila-common: Installed: 1:18.0.1-0ubuntu2.2 Candidate: 1:18.0.1-0ubuntu2.2 Version table: *** 1:18.0.1-0ubuntu2.2 510 510 http://archive.ubuntu.com/ubuntu noble-proposed/universe amd64 Packages 100 /var/lib/dpkg/status 1:18.0.1-0ubuntu2.1 500 500 http://availability-zone-1.clouds.archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages 1:18.0.1-0ubuntu2 500 500 http://availability-zone-1.clouds.archive.ubuntu.com/ubuntu noble/universe amd64 Packages Successfully created and mounted a share inside a vm using DHSS=true backend before and after the patch. ** Tags removed: verification-needed-noble ** Tags added: verification-done-noble -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Ran tempest against Noble Caracal -proposed and these are the results:
==
Totals
==
Ran: 470 tests in 6698.5353 sec.
- Passed: 392
- Skipped: 70
- Expected Fail: 0
- Unexpected Success: 0
- Failed: 8
{1} setUpClass
(octavia_tempest_plugin.tests.scenario.v2.test_traffic_ops.TrafficOperationsScenarioTest)
[0.00s] ... FAILED
{0}
octavia_tempest_plugin.tests.scenario.v2.test_pool.PoolScenarioTest.test_UDP_LC_pool_with_listener_CRUD
[333.906004s] ... FAILED
{0}
octavia_tempest_plugin.tests.scenario.v2.test_pool.PoolScenarioTest.test_UDP_RR_pool_with_listener_CRUD
[338.794246s] ... FAILED
{0}
octavia_tempest_plugin.tests.scenario.v2.test_pool.PoolScenarioTest.test_UDP_RR_source_ip_pool_with_listener_CRUD
[333.418381s] ... FAILED
{0}
octavia_tempest_plugin.tests.scenario.v2.test_pool.PoolScenarioTest.test_UDP_SI_pool_with_listener_CRUD
[333.618897s] ... FAILED
{0}
heat_tempest_plugin.tests.api.test_heat_api.resources_delete_stack_with_resources.test_request
[0.225613s] ... FAILED
{0}
heat_tempest_plugin.tests.api.test_heat_api.environments_delete_envstack.test_request
[0.048977s] ... FAILED
{0}
heat_tempest_plugin.tests.api.test_heat_api.stacks_delete_stack.test_request
[0.094601s] ... FAILED
These failures are known to not be related to Manila or this patchset.
Of the 82 manila tests all passed:
$ grep manila /tmp/tmp.8Jvj67s669-openstack-release-test-results| grep "...
ok"| wc -l
82
$ grep manila /tmp/tmp.8Jvj67s669-openstack-release-test-results| grep
"FAILED"| wc -l
0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2074504
Title:
[SRU] Manila's NeutronNetworkPlugin with external networks doesn't
work with OVN
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Ok i take that back, we can deploy and test with Charmed OpenStack on Noble so will kick off that testing asap and post back with results. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Jammy Caracal was verified in https://bugs.launchpad.net/manila/+bug/2074504/comments/30 and since it is the same package as noble-proposed but Charmed OpenStack (used to deploy OpenStack for tests) has no support for Noble it could not be used. I believe this is why both were set. I will see if we can find a way to actually verify Noble. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
I don't see a verification for Noble (1:18.0.1-0ubuntu2.2) there? Resetting verification tags. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
I don't see a verification for Noble (1:18.0.1-0ubuntu2.2) there? Resetting verification tags. ** Tags removed: verification-done-noble ** Tags added: verification-needed-noble -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Hi all, sorry for the delay on this. Just performed Yoga SRU verification: ubuntu@juju-e0ef3b-sru-15:~$ dpkg -l | grep manila ii manila-api 1:14.1.1-0ubuntu1.2 all OpenStack shared file system as a service - API server ii manila-common1:14.1.1-0ubuntu1.2 all OpenStack shared file system as a service - common files ii manila-data 1:14.1.1-0ubuntu1.2 all Manila storage service - Data service ii manila-scheduler 1:14.1.1-0ubuntu1.2 all OpenStack shared file system as a service - Scheduler server ii manila-share 1:14.1.1-0ubuntu1.2 all OpenStack shared file system as a service - Share server ii python3-manila 1:14.1.1-0ubuntu1.2 all OpenStack shared file system as a service - Python 3 libs ubuntu@juju-e0ef3b-sru-15:~$ logout Connection to 10.149.3.144 closed. ubuntu@stg-reproducer-tiago-pasqualini-project-bastion:~$ openstack share show s1 +---+--+ | Field | Value | +---+--+ | access_rules_status | active | | availability_zone | nova | | create_share_from_snapshot_support| False | | created_at| 2025-08-20T15:09:02.488740 | | description | None | | export_locations | | | | id = f8df74a9-219a-44fd-b81d-add771320431| | | path = 10.254.0.4:/shares/share-48bd8ff7-bb94-4060-9e58-ce7a346ac097 | | | preferred = False | | | share_instance_id = 48bd8ff7-bb94-4060-9e58-ce7a346ac097 | | | is_admin_only = False | | | id = f3a05474-7712-40b4-990c-c24cb6db8bae| | | path = 10.254.0.4:/shares/share-48bd8ff7-bb94-4060-9e58-ce7a346ac097 | | | preferred = False | | | share_instance_id = 48bd8ff7-bb94-4060-9e58-ce7a346ac097 | | | is_admin_only = True | | has_replicas | False | | host | juju-e0ef3b-sru-15@generic#generic | | id| ff9139fc-075c-454d-8dac-6c90660b9003 | | is_public | False | | is_soft_deleted | False | | mount_snapshot_support| False | | name | s1 | | progress | 100% | | project_id| 5360f5b04067480781eed751bf4d657d | | properties| | | replication_type | None | | revert_to_snapshot_support| False | | scheduled_to_be_deleted_at| None | | share_group_id| None
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
I'm resetting the tag status, as it looks like only Caracal was validated. ** Tags removed: verification-done-jammy verification-noble-done verification-yoga-done ** Tags added: verification-needed-jammy verification-needed-noble verification-yoga-needed ** Tags removed: verification-done ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Tags removed: verification-needed verification-needed-jammy verification-yoga-needed ** Tags added: verification-done verification-done-jammy verification-yoga-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
I have performed the Caracal SRU verification with the steps suggested in the test case, with the generic driver in DHSS=True: ubuntu@juju-1cf976-sru-15:~$ dpkg -l | grep manila ii manila-api 1:18.0.1-0ubuntu2.2~cloud0 all OpenStack shared file system as a service - API server ii manila-common1:18.0.1-0ubuntu2.2~cloud0 all OpenStack shared file system as a service - common files ii manila-data 1:18.0.1-0ubuntu2.2~cloud0 all Manila storage service - Data service ii manila-scheduler 1:18.0.1-0ubuntu2.2~cloud0 all OpenStack shared file system as a service - Scheduler server ii manila-share 1:18.0.1-0ubuntu2.2~cloud0 all OpenStack shared file system as a service - Share server ii python3-manila 1:18.0.1-0ubuntu2.2~cloud0 all OpenStack shared file system as a service - Python 3 libs ubuntu@stg-reproducer-tiago-pasqualini-project-bastion:~/stsstack-bundles/openstack$ openstack share show s1 +---+---+ | Field | Value | +---+---+ | access_rules_status | active | | availability_zone | nova | | create_share_from_snapshot_support| False | | created_at| 2025-07-23T07:52:39.129489 | | description | None | | export_locations | | | | id = 81d6fa79-15bf-4f02-a232-dbd3503e1f6c | | | path = 10.254.0.14:/shares/share-daf099ae-cb9d-4af7-82a4-b33950753739 | | | preferred = False | | | share_instance_id = daf099ae-cb9d-4af7-82a4-b33950753739 | | | is_admin_only = False | | | id = 3b6099ae-77f1-47d0-866d-f3f5c22a5bbb | | | path = 10.254.0.14:/shares/share-daf099ae-cb9d-4af7-82a4-b33950753739 | | | preferred = False | | | share_instance_id = daf099ae-cb9d-4af7-82a4-b33950753739 | | | is_admin_only = True | | has_replicas | False | | host | juju-1cf976-sru-15@generic#generic | | id| ffe5eb23-25e1-4d6d-8592-e986f3ad6c53 | | is_public | False | | is_soft_deleted | False | | mount_snapshot_support| False | | name | s1 | | progress | 100% | | project_id| c085eefbffd04e6aa130ad1149279387 | | properties| | | replication_type | None | | revert_to_snapshot_support| False | | scheduled_to_be_deleted_at| None | | share_group_id| None
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Merge proposal linked: https://code.launchpad.net/~halves/ubuntu/+source/manila/+git/manila/+merge/488424 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Merge proposal linked: https://code.launchpad.net/~halves/ubuntu/+source/manila/+git/manila/+merge/488423 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Hello Goutham, or anyone else affected, Accepted manila into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/manila/1:18.0.1-0ubuntu2.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-noble. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: manila (Ubuntu Noble) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-noble ** Changed in: manila (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed-jammy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Description changed:
*** SRU TEMPLATE AT THE BOTTOM ***
Description
===
When using NeutronNetworkPlugin with DHSS=True, manila requests neutron
ports for creating network connections on share servers on the user
provided Share Network.
Deployers and users have the flexibility to use external networks (i.e.,
a "provider networks" in neutron parlance) as their Share Networks. When
they do this, they expect to use Neutron to merely perform IPAM. Neutron
does create ports to reserve IP addresses; however, we don't expect
these ports to work or respond to ARP requests. This worked even when
OVN was used as the ML2 plugin in the deployment; however, OVN had a
change in its default behavior [1]. This change makes OVN setup flows
for DOWN ports; when ARP responses are received from OVN ports, traffic
is effectively misrouted/dropped. This means that end users cannot reach
their share export paths from their eventual VMs/containers/bare metal
hosts. OVN has a configuration option to turn this behavior off
("ignore_lsp_down"). By default, OpenStack Neutron sets this
"ignore_lsp_down" option to False [2] - meaning OVN is not supposed to
setup flow table entries for any ports that are DOWN.
However, this behavior isn't working as one would expect.
Steps to reproduce
==
A chronological list of steps which will help reproduce the issue you hit:
* Create a provider network on OpenStack
* Configure manila with a DHSS=True driver that can use an "external" storage
system (example, NetApp)
* Create a share network mapped to the provider network
* Create a share with the share network
* Create a tenant VM
* Create appropriate access rule/s in manila
* Attempt to mount the share in the VM
Expected result
===
Share is reachable/mountable
Actual result
=
Share failed to be mounted. Cannot ping the export IPs either because the
provider network is unreachable. When you debug this further, you'll notice
packets are dropped, citing a MAC address mismatch.
Environment
===
1. Version of OpenStack Manila: OpenStack Wallaby
2. Which storage backend did you use: NetApp (although this should be a
problem with any non-generic DHSS=true backend)
3. Which networking type did you use? OVN
[1] https://www.mail-archive.com/[email protected]/msg60064.html
[2] https://review.opendev.org/c/openstack/neutron/+/896545
===
SRU DESCRIPTION
===
[Impact]
This issue blocks connectivity of users to external storage backends
when using OVN, therefore the users cannot access their shares.
[Test case]
We cannot reproduce the issue in Canonical lab as we don't have any
external storage with DHSS=True mode. I tried to reproduce it with the
generic driver in DHSS=True mode but couldn't. The included unit tests
should provide coverage. Additionally we have already provided test PPAs
to customers affected with the issue and they confirmed the issue was
addressed. Some upstream users have also validated the fix.
+ UPDATE: After discussing with Heitor, we agreed that we would do a smoke
+ test using the generic driver in DHSS=True mode because it goes through
+ the same code that is modified by the fix. The difference of why the
+ generic driver is not affected but other drivers are is because the
+ issue only manifests with real hardware that have physical ports, while
+ the generic driver only has virtual ports, so the OVN issue doesn't
+ happen, despite the code used to set things up being the same.
+ Therefore, a smoke test creating a share and accessing it in the generic
+ driver using DHSS=True will go through the modified code and confirm
+ that the code did not break with the update.
+
+ Steps:
+
+ 1) Deploy manila with generic driver in DHSS=True mode
+
+ 2) create a share network, a share, add access rules, and mount it
+ successfully, write a dummy file in it
+
+ 3) Install updated package
+
+ 4) create another share network, another share, add access rules, mount
+ it successfully, write a dummy file in it. Because it is a different
+ share network, no IPs or ports from step (2) should be re-used, but it
+ is best to confirm just to be sure that the resources are different.
+
+
[Where problems could occur]
The code only affects the neutron plugin for manila, which is used only
for DHSS=True mode. However, the code is shared between both OVN and OVS
modes, so attempting to fix the issue for OVN could potentially break
all the current users using OVS. The breakage wouldn't be immediate upon
installing the package, as the code is executed only when new share
servers are created. So as long as only shares are being created while
the existing share servers and networks were already functional prior to
the upgrade, the damage can be mitigated. On the other
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
Thanks for the patches, Rodrigo! I made some minor changes to debian/changelog, so the bug tracking uses the proper formatting. Looks good otherwise, sponsored for Jammy/Noble. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Changed in: manila (Ubuntu Noble) Importance: Undecided => Medium ** Changed in: manila (Ubuntu Noble) Assignee: (unassigned) => Rodrigo Barbieri (rodrigo-barbieri2010) ** Changed in: manila (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: manila (Ubuntu Jammy) Assignee: (unassigned) => Rodrigo Barbieri (rodrigo-barbieri2010) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Description changed:
*** SRU TEMPLATE AT THE BOTTOM ***
Description
===
When using NeutronNetworkPlugin with DHSS=True, manila requests neutron
ports for creating network connections on share servers on the user
provided Share Network.
Deployers and users have the flexibility to use external networks (i.e.,
a "provider networks" in neutron parlance) as their Share Networks. When
they do this, they expect to use Neutron to merely perform IPAM. Neutron
does create ports to reserve IP addresses; however, we don't expect
these ports to work or respond to ARP requests. This worked even when
OVN was used as the ML2 plugin in the deployment; however, OVN had a
change in its default behavior [1]. This change makes OVN setup flows
for DOWN ports; when ARP responses are received from OVN ports, traffic
is effectively misrouted/dropped. This means that end users cannot reach
their share export paths from their eventual VMs/containers/bare metal
hosts. OVN has a configuration option to turn this behavior off
("ignore_lsp_down"). By default, OpenStack Neutron sets this
"ignore_lsp_down" option to False [2] - meaning OVN is not supposed to
setup flow table entries for any ports that are DOWN.
However, this behavior isn't working as one would expect.
Steps to reproduce
==
A chronological list of steps which will help reproduce the issue you hit:
* Create a provider network on OpenStack
* Configure manila with a DHSS=True driver that can use an "external" storage
system (example, NetApp)
* Create a share network mapped to the provider network
* Create a share with the share network
* Create a tenant VM
* Create appropriate access rule/s in manila
* Attempt to mount the share in the VM
Expected result
===
Share is reachable/mountable
Actual result
=
Share failed to be mounted. Cannot ping the export IPs either because the
provider network is unreachable. When you debug this further, you'll notice
packets are dropped, citing a MAC address mismatch.
Environment
===
1. Version of OpenStack Manila: OpenStack Wallaby
2. Which storage backend did you use: NetApp (although this should be a
problem with any non-generic DHSS=true backend)
3. Which networking type did you use? OVN
[1] https://www.mail-archive.com/[email protected]/msg60064.html
[2] https://review.opendev.org/c/openstack/neutron/+/896545
===
SRU DESCRIPTION
===
[Impact]
This issue blocks connectivity of users to external storage backends
when using OVN, therefore the users cannot access their shares.
[Test case]
We cannot reproduce the issue in Canonical lab as we don't have any
external storage with DHSS=True mode. I tried to reproduce it with the
generic driver in DHSS=True mode but couldn't. The included unit tests
should provide coverage. Additionally we have already provided test PPAs
to customers affected with the issue and they confirmed the issue was
addressed. Some upstream users have also validated the fix.
[Where problems could occur]
The code only affects the neutron plugin for manila, which is used only
for DHSS=True mode. However, the code is shared between both OVN and OVS
modes, so attempting to fix the issue for OVN could potentially break
- all the current users using OVS. On the other hand, OVN users are broken
- without connectivity so the benefits generally outweight the risks here.
- If any issues arise, the package will have to be downgraded to restore
- the previous state for OVS users.
+ all the current users using OVS. The breakage wouldn't be immediate upon
+ installing the package, as the code is executed only when new share
+ servers are created. So as long as only shares are being created while
+ the existing share servers and networks were already functional prior to
+ the upgrade, the damage can be mitigated. On the other hand, OVN users
+ are broken without connectivity so the benefits generally outweight the
+ risks here. If any issues arise, the package will have to be downgraded
+ to restore the previous state for OVS users.
[Other Info]
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2074504
Title:
[SRU] Manila's NeutronNetworkPlugin with external networks doesn't
work with OVN
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Patch added: "lp2074504_jammy_yoga.debdiff" https://bugs.launchpad.net/cloud-archive/yoga/+bug/2074504/+attachment/5874022/+files/lp2074504_jammy_yoga.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Patch added: "lp2074504_noble_caracal.debdiff" https://bugs.launchpad.net/cloud-archive/yoga/+bug/2074504/+attachment/5874021/+files/lp2074504_noble_caracal.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Description changed:
*** SRU TEMPLATE AT THE BOTTOM ***
Description
===
When using NeutronNetworkPlugin with DHSS=True, manila requests neutron
ports for creating network connections on share servers on the user
provided Share Network.
Deployers and users have the flexibility to use external networks (i.e.,
a "provider networks" in neutron parlance) as their Share Networks. When
they do this, they expect to use Neutron to merely perform IPAM. Neutron
does create ports to reserve IP addresses; however, we don't expect
these ports to work or respond to ARP requests. This worked even when
OVN was used as the ML2 plugin in the deployment; however, OVN had a
change in its default behavior [1]. This change makes OVN setup flows
for DOWN ports; when ARP responses are received from OVN ports, traffic
is effectively misrouted/dropped. This means that end users cannot reach
their share export paths from their eventual VMs/containers/bare metal
hosts. OVN has a configuration option to turn this behavior off
("ignore_lsp_down"). By default, OpenStack Neutron sets this
"ignore_lsp_down" option to False [2] - meaning OVN is not supposed to
setup flow table entries for any ports that are DOWN.
However, this behavior isn't working as one would expect.
Steps to reproduce
==
A chronological list of steps which will help reproduce the issue you hit:
* Create a provider network on OpenStack
* Configure manila with a DHSS=True driver that can use an "external" storage
system (example, NetApp)
* Create a share network mapped to the provider network
* Create a share with the share network
* Create a tenant VM
* Create appropriate access rule/s in manila
* Attempt to mount the share in the VM
Expected result
===
Share is reachable/mountable
Actual result
=
Share failed to be mounted. Cannot ping the export IPs either because the
provider network is unreachable. When you debug this further, you'll notice
packets are dropped, citing a MAC address mismatch.
Environment
===
1. Version of OpenStack Manila: OpenStack Wallaby
2. Which storage backend did you use: NetApp (although this should be a
problem with any non-generic DHSS=true backend)
3. Which networking type did you use? OVN
[1] https://www.mail-archive.com/[email protected]/msg60064.html
[2] https://review.opendev.org/c/openstack/neutron/+/896545
===
SRU DESCRIPTION
===
[Impact]
This issue blocks connectivity of users to external storage backends
when using OVN, therefore the users cannot access their shares.
[Test case]
We cannot reproduce the issue in Canonical lab as we don't have any
external storage with DHSS=True mode. I tried to reproduce it with the
generic driver in DHSS=True mode but couldn't. The included unit tests
should provide coverage. Additionally we have already provided test PPAs
to customers affected with the issue and they confirmed the issue was
addressed. Some upstream users have also validated the fix.
[Where problems could occur]
The code only affects the neutron plugin for manila, which is used only
for DHSS=True mode. However, the code is shared between both OVN and OVS
modes, so attempting to fix the issue for OVN could potentially break
all the current users using OVS. The breakage wouldn't be immediate upon
installing the package, as the code is executed only when new share
servers are created. So as long as only shares are being created while
the existing share servers and networks were already functional prior to
the upgrade, the damage can be mitigated. On the other hand, OVN users
are broken without connectivity so the benefits generally outweight the
- risks here. If any issues arise, the package will have to be downgraded
- to restore the previous state for OVS users.
+ risks here. In case of regression, the previous funcionality can be
+ restored through package downgrade.
[Other Info]
For Jammy/Yoga, bugfix LP#2049507 will also be included.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2074504
Title:
[SRU] Manila's NeutronNetworkPlugin with external networks doesn't
work with OVN
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Description changed:
*** SRU TEMPLATE AT THE BOTTOM ***
Description
===
When using NeutronNetworkPlugin with DHSS=True, manila requests neutron
ports for creating network connections on share servers on the user
provided Share Network.
Deployers and users have the flexibility to use external networks (i.e.,
a "provider networks" in neutron parlance) as their Share Networks. When
they do this, they expect to use Neutron to merely perform IPAM. Neutron
does create ports to reserve IP addresses; however, we don't expect
these ports to work or respond to ARP requests. This worked even when
OVN was used as the ML2 plugin in the deployment; however, OVN had a
change in its default behavior [1]. This change makes OVN setup flows
for DOWN ports; when ARP responses are received from OVN ports, traffic
is effectively misrouted/dropped. This means that end users cannot reach
their share export paths from their eventual VMs/containers/bare metal
hosts. OVN has a configuration option to turn this behavior off
("ignore_lsp_down"). By default, OpenStack Neutron sets this
"ignore_lsp_down" option to False [2] - meaning OVN is not supposed to
setup flow table entries for any ports that are DOWN.
However, this behavior isn't working as one would expect.
Steps to reproduce
==
A chronological list of steps which will help reproduce the issue you hit:
* Create a provider network on OpenStack
* Configure manila with a DHSS=True driver that can use an "external" storage
system (example, NetApp)
* Create a share network mapped to the provider network
* Create a share with the share network
* Create a tenant VM
* Create appropriate access rule/s in manila
* Attempt to mount the share in the VM
Expected result
===
Share is reachable/mountable
Actual result
=
Share failed to be mounted. Cannot ping the export IPs either because the
provider network is unreachable. When you debug this further, you'll notice
packets are dropped, citing a MAC address mismatch.
Environment
===
1. Version of OpenStack Manila: OpenStack Wallaby
2. Which storage backend did you use: NetApp (although this should be a
problem with any non-generic DHSS=true backend)
3. Which networking type did you use? OVN
[1] https://www.mail-archive.com/[email protected]/msg60064.html
[2] https://review.opendev.org/c/openstack/neutron/+/896545
===
SRU DESCRIPTION
===
[Impact]
This issue blocks connectivity of users to external storage backends
when using OVN, therefore the users cannot access their shares.
[Test case]
We cannot reproduce the issue in Canonical lab as we don't have any
external storage with DHSS=True mode. I tried to reproduce it with the
generic driver in DHSS=True mode but couldn't. The included unit tests
should provide coverage. Additionally we have already provided test PPAs
to customers affected with the issue and they confirmed the issue was
addressed. Some upstream users have also validated the fix.
[Where problems could occur]
The code only affects the neutron plugin for manila, which is used only
for DHSS=True mode. However, the code is shared between both OVN and OVS
modes, so attempting to fix the issue for OVN could potentially break
all the current users using OVS. The breakage wouldn't be immediate upon
installing the package, as the code is executed only when new share
servers are created. So as long as only shares are being created while
the existing share servers and networks were already functional prior to
the upgrade, the damage can be mitigated. On the other hand, OVN users
are broken without connectivity so the benefits generally outweight the
risks here. If any issues arise, the package will have to be downgraded
to restore the previous state for OVS users.
[Other Info]
+
+ For Jammy/Yoga, bugfix LP#2049507 will also be included.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2074504
Title:
[SRU] Manila's NeutronNetworkPlugin with external networks doesn't
work with OVN
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN
** Also affects: manila (Ubuntu) Importance: Undecided Status: New ** Also affects: manila (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: manila (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: manila (Ubuntu Oracular) Importance: Undecided Status: New ** Changed in: manila (Ubuntu Oracular) Status: New => Fix Released ** Changed in: manila (Ubuntu Jammy) Status: New => In Progress ** Changed in: manila (Ubuntu) Status: New => Fix Released ** Changed in: manila (Ubuntu Noble) Status: New => In Progress ** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/bobcat Importance: Undecided Status: New ** Also affects: cloud-archive/yoga Importance: Undecided Status: New ** Also affects: cloud-archive/zed Importance: Undecided Status: New ** Also affects: cloud-archive/antelope Importance: Undecided Status: New ** Also affects: cloud-archive/epoxy Importance: Undecided Status: New ** Also affects: cloud-archive/dalmatian Importance: Undecided Status: New ** Also affects: cloud-archive/caracal Importance: Undecided Status: New ** Changed in: cloud-archive/epoxy Status: New => Fix Released ** Changed in: cloud-archive/dalmatian Status: New => Fix Released ** Changed in: cloud-archive/zed Status: New => Won't Fix ** Changed in: cloud-archive/bobcat Status: New => Won't Fix ** Changed in: cloud-archive/antelope Status: New => Won't Fix ** Changed in: cloud-archive/caracal Status: New => In Progress ** Changed in: cloud-archive/yoga Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2074504 Title: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
