| opendevreview | Takashi Kajinami proposed openstack/puppet-manila stable/wallaby: Allow mulitple GlusterFS backends https://review.opendev.org/c/openstack/puppet-manila/+/855561 | 00:06 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/puppet-manila stable/wallaby: Allow mulitple GlusterFS backends https://review.opendev.org/c/openstack/puppet-manila/+/855561 | 01:30 |
| opendevreview | OpenStack Proposal Bot proposed openstack/manila-ui master: Imported Translations from Zanata https://review.opendev.org/c/openstack/manila-ui/+/856003 | 03:58 |
| opendevreview | Takashi Kajinami proposed openstack/puppet-manila stable/wallaby: Allow mulitple GlusterFS backends https://review.opendev.org/c/openstack/puppet-manila/+/855561 | 07:47 |
| opendevreview | kiran pawar proposed openstack/manila master: Implement share backup https://review.opendev.org/c/openstack/manila/+/343980 | 08:01 |
| opendevreview | kiran pawar proposed openstack/python-manilaclient master: Implement share backup https://review.opendev.org/c/openstack/python-manilaclient/+/344671 | 08:19 |
| stephenfin | vkmc: gouthamr: Any chance you folks could look at https://review.opendev.org/c/openstack/manila/+/855967 to avoid failures coming down the pipeline with oslo.db 12.1.0? | 10:26 |
| vkmc | stephenfin, o/ sure thing | 10:27 |
| *** dviroel|out is now known as dviroel | 11:19 | |
| opendevreview | Stephen Finucane proposed openstack/manila master: test: Rename Database fixture to DatabaseFixture https://review.opendev.org/c/openstack/manila/+/856140 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: test: Add warning fixture https://review.opendev.org/c/openstack/manila/+/856141 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: db: Use oslo_db.sqlalchemy.enginefacade https://review.opendev.org/c/openstack/manila/+/856142 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: db: Prepare 'model_query' for migration to enginefacade https://review.opendev.org/c/openstack/manila/+/856143 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: db: Migrate "service" APIs to enginefacade https://review.opendev.org/c/openstack/manila/+/856144 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: db: Migrate "quota" APIs to enginefacade https://review.opendev.org/c/openstack/manila/+/856145 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: db: Migrate "quota class" APIs to enginefacade https://review.opendev.org/c/openstack/manila/+/856146 | 14:59 |
| opendevreview | Stephen Finucane proposed openstack/manila master: db: Migrate "quota usage" APIs to enginefacade https://review.opendev.org/c/openstack/manila/+/856147 | 14:59 |
| *** dviroel is now known as dviroel|lunch | 15:29 | |
| carloss | Hello all! I'd like to communicate to you my plans to postpone this week's bugsquash by one week. We have some feature freeze exceptions at the moment and I think it would be ideal to have the change owners and reviewers focused on getting those changes merged | 15:58 |
| carloss | ashrodri gouthamr vhari vkmc dviroel|lunch felipe_rodrigues caiquemello[m] nahimsouza[m] | 15:58 |
| vhari | carloss++ | 15:58 |
| carloss | how does this sound to you? | 15:59 |
| gouthamr | yes i agree carloss - sounds like the right approach | 16:01 |
| carloss | thanks for the input :) | 16:04 |
| *** dviroel|lunch is now known as dviroel | 16:26 | |
| dviroel | carloss: +1 | 16:26 |
| sfernand | hey gouthamr are you available? | 16:32 |
| gouthamr | sfernand: depends :) how can i help? | 16:33 |
| sfernand | I would like your guidance for a issue I'm working on :) | 16:33 |
| sfernand | gouthamr: hahha it is regarding https://bugs.launchpad.net/charm-manila/+bug/1987315 | 16:33 |
| sfernand | we kind of started a discussin last week during the manila meeting | 16:34 |
| gouthamr | ah yes; catching up on the comments after | 16:35 |
| sfernand | and what is going on is that they trying to set up contrail net with Neutron, but the way that the contral plugin deals with provider:network_type is a bit different from what we uselly expected in our manila neutron plugin | 16:36 |
| gouthamr | i see; it's strange that the API doesn't return that key... | 16:37 |
| sfernand | for customer perpecpective they just want to have the network_type checking removed, but I'm not sure this would be the proper solution, if we should consider a new manila plugin for contrail instead | 16:37 |
| sfernand | yep | 16:37 |
| gouthamr | setting it to None is okay (manila's network plugin doesn't care, just gathering info for drivers that may have restrictions) | 16:37 |
| sfernand | their request is to remove the following check from the manila_neutron_plugin: | 16:39 |
| sfernand | if not (segmentation_id and network_type): | 16:39 |
| sfernand | msg = ("No matching neutron_physical_net_name found for %s " | 16:39 |
| sfernand | "(found: %s)." % (phy, phy_nets)) | 16:39 |
| * gouthamr does some code reading | 16:39 | |
| gouthamr | gimme a bit sfernand | 16:39 |
| sfernand | ok ok | 16:40 |
| gouthamr | "now when we create a network with type as VLAN it replaces the field with 'None', as the communication is taken care by its own mechanism." -- | 16:45 |
| gouthamr | irccloud disconnected on me | 16:54 |
| sfernand | I'm trying to figure out how flat nets are handled here | 16:56 |
| sfernand | would multi segments be enabled in Neutron if they choose for a flat net type instead? | 16:57 |
| gouthamr | sfernand: the segment we care about can still be a flat network; i feel like the API inconsistency is our problem - the field "provider:network_type" doesn't exist in the "segments" list elements | 17:03 |
| gouthamr | neutron's API ref has called it out in a couple of places; for example: https://docs.openstack.org/api-ref/network/v2/index.html?expanded=show-segment-details-detail#segments | 17:04 |
| gouthamr | or https://docs.openstack.org/api-ref/network/v2/index.html?expanded=show-segment-details-detail#multiple-provider-extension | 17:04 |
| gouthamr | they say they're using a vlan network; so i'm assuming the API is atleast providing a valid segmentation ID | 17:05 |
| gouthamr | maybe we should ask a question on the ML and loop in some neutron folks; could it be a bug that the segment's network_type isn't being exposed only with the open contrail plugin? | 17:07 |
| sfernand | I wonder if they set type vlan just to meet netapp driver requirement, in their tests IIRC both network_type and segmentation_id were set to None | 17:16 |
| sfernand | so I'm not sure if is that a question of not having the network_type exposed | 17:21 |
| sfernand | a question on the ML is a good idea | 17:21 |
| gouthamr | sfernand: it sure isn't for some of our drivers - they expect to validate that field against what they support: https://codesearch.opendev.org/?q=network_type&i=nope&literal=nope&files=manila%2Fshare%2Fdrivers%2F&excludeFiles=&repos= | 17:23 |
| sfernand | but they all support None as a valid option | 17:25 |
| sfernand | right? | 17:25 |
| sfernand | ops I can tell they all support but the ones you found in hound they all seems to handle network_type as None, In the netapp driver for example it is going to do the same operations as it was set to flat | 17:29 |
| gouthamr | yes | 17:30 |
| sfernand | I can't tell* | 17:30 |
| gouthamr | ack; we shouldn't need to, unless its something the neutron folks agree we need to support | 17:31 |
| gouthamr | i'd assume None to mean flat too - it could be from nova networking | 17:32 |
| gouthamr | or not: https://review.opendev.org/c/openstack/manila/+/410450/19/manila/network/nova_network_plugin.py#b158 | 17:35 |
| gouthamr | sfernand: so we should probably establish our constraints in that ML post - manila's share drivers care about the segmentation style and ID because they need to create ports on the storage device and not all network segmentation protocols are natively supported by all storage backends; is the opencontrail plugin unique in not providing these details? | 17:38 |
| gouthamr | if yes, it seems like something that can be fixed with another API call or by fixing the opencontrail plugin; if not, we'd have to implement some new logic in manila's network plugin layer and likely in the share drivers | 17:39 |
| sfernand | agree; I will work on a ML post | 17:43 |
| opendevreview | Merged openstack/manila master: Fix compatibility with oslo.db 12.1.0 https://review.opendev.org/c/openstack/manila/+/855967 | 17:49 |
| sfernand | is the open contrail plugin in tree? | 17:49 |
| gouthamr | sfernand: thanks! i think it's this one: https://github.com/tungstenfabric/tf-neutron-plugin | 18:02 |
| *** dviroel is now known as dviroel|biab | 21:19 | |
| opendevreview | Merged openstack/manila-ui master: Imported Translations from Zanata https://review.opendev.org/c/openstack/manila-ui/+/856003 | 22:03 |
| opendevreview | Merged openstack/manila master: test: Rename Database fixture to DatabaseFixture https://review.opendev.org/c/openstack/manila/+/856140 | 22:04 |
| *** dviroel|biab is now known as dviroel | 23:17 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!