| *** tommylikehu has joined #openstack-manila | 00:58 | |
| *** pcaruana has joined #openstack-manila | 07:46 | |
| openstackgerrit | inspurericzhang proposed openstack/manila-tempest-plugin master: [Trivial Fix] update home-page url https://review.openstack.org/613858 | 08:23 |
|---|---|---|
| openstackgerrit | kay proposed openstack/python-manilaclient master: Add missing organizational unit (--ou) parameter in manila cli https://review.openstack.org/613298 | 08:39 |
| *** e0ne has joined #openstack-manila | 08:45 | |
| *** gregsfortytwo has quit IRC | 09:39 | |
| *** luizbag has joined #openstack-manila | 10:33 | |
| *** ganso has joined #openstack-manila | 10:57 | |
| *** zigo has quit IRC | 11:17 | |
| *** vkmc has quit IRC | 11:17 | |
| *** Reepicheep has quit IRC | 11:18 | |
| *** Reepicheep has joined #openstack-manila | 11:21 | |
| *** vkmc has joined #openstack-manila | 11:22 | |
| *** e0ne has quit IRC | 11:25 | |
| *** e0ne has joined #openstack-manila | 11:34 | |
| *** erlon has joined #openstack-manila | 11:35 | |
| *** jmlowe has quit IRC | 12:34 | |
| *** e0ne has quit IRC | 12:58 | |
| *** tpsilva has joined #openstack-manila | 13:02 | |
| *** zigo has joined #openstack-manila | 13:13 | |
| *** e0ne has joined #openstack-manila | 13:19 | |
| *** jmlowe has joined #openstack-manila | 13:22 | |
| *** e0ne has quit IRC | 13:24 | |
| *** e0ne has joined #openstack-manila | 13:30 | |
| *** jmlowe has quit IRC | 14:16 | |
| *** jmlowe has joined #openstack-manila | 14:37 | |
| openstackgerrit | Silvan Kaiser proposed openstack/manila stable/queens: Fix mutable default argument in Quobyte jsonrpc https://review.openstack.org/613951 | 14:58 |
| *** irclogbot_1 has joined #openstack-manila | 15:04 | |
| *** markstur has joined #openstack-manila | 15:11 | |
| *** jmlowe has quit IRC | 15:14 | |
| *** jmlowe has joined #openstack-manila | 15:30 | |
| *** dustins has joined #openstack-manila | 15:42 | |
| *** jmlowe has quit IRC | 15:56 | |
| *** jmlowe has joined #openstack-manila | 15:58 | |
| *** eharney has joined #openstack-manila | 16:20 | |
| *** e0ne has quit IRC | 16:36 | |
| *** jmlowe has quit IRC | 17:01 | |
| *** tommylikehu has quit IRC | 17:28 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Add spec for Manage-Unmanage of Share Servers https://review.openstack.org/607342 | 17:29 |
| *** jmlowe has joined #openstack-manila | 17:36 | |
| *** eharney has quit IRC | 17:55 | |
| *** dustins_ has joined #openstack-manila | 17:57 | |
| *** dustins has quit IRC | 17:58 | |
| *** eharney has joined #openstack-manila | 18:05 | |
| *** dschoenb__ has joined #openstack-manila | 18:29 | |
| *** dustins_ has quit IRC | 18:32 | |
| *** erlon has quit IRC | 18:41 | |
| *** jmlowe has quit IRC | 18:46 | |
| *** jmlowe has joined #openstack-manila | 18:55 | |
| ganso | tbarron, gouthamr: hey folks, I'd like your opinion on a detail of manage/unmanage with dhss=True | 18:56 |
| *** dschoenb__ is now known as dustins | 18:56 | |
| ganso | tbarron, gouthamr: at PTG we discussed that the admin will have to create the network allocations in neutron manually before attempting to manage the share server | 18:56 |
| ganso | tbarron, gouthamr: and then we would ask the driver what the driver's allocations are so we can validate. There are some information that we can use to validate. | 18:57 |
| ganso | tbarron, gouthamr: at first I thought about only validating if the port IP address is the same as the backend allocation IP. This works but the segmentation ID may be different so there could be no proper connectivity | 18:58 |
| ganso | tbarron, gouthamr: The neutron port does not have segmentation ID information, but the network it is in has, and the share network also has. So I could validate the segmentation ID to make sure the admin is managing a share server which has allocations that match the network it is in | 18:59 |
| ganso | tbarron, gouthamr: my concern is that some drivers may not be able to retrieve this information from their backend. I would like to know if, from your experience with the ceph driver and other drivers, if it makes sense request the segmentation ID information from the backends | 19:00 |
| tbarron | ganso: in a meeting currently but will try to digest the above. ceph driver is currently DHSS=false only so ... | 19:02 |
| ganso | tbarron: but how does the ceph driver/backend handle VLAN IDs? can it create several network interfaces with different segmentation IDs? or does it not make such distinctions or cannot retrieve such info? | 19:03 |
| ganso | tbarron: even in DHSS=False you could create segmented network interfaces in backends (for those that support such). I am trying to get an idea if it generally expected that a backend supports this kind of functionality | 19:04 |
| gouthamr | ganso: currently, the deployer/admin sets up networking for the CEPHFS driver - and they can configure only one vip per backend | 19:05 |
| ganso | gouthamr: so the ceph backend does not care about segmentation IDs, it always expect L2 connectivity to just work, since it operates on a single interface. Correct? | 19:06 |
| gouthamr | yes | 19:07 |
| tbarron | yes | 19:07 |
| gouthamr | i | 19:07 |
| ganso | ok, thanks. This addresses my concern, it may be too much to ask for segmentation IDs from backends | 19:07 |
| gouthamr | what would you like to validate from the backend? | 19:07 |
| ganso | gouthamr: that the allocations the admin created in neutron match the allocations in the backend | 19:08 |
| *** jmlowe has quit IRC | 19:08 | |
| ganso | gouthamr: in my example, the IPs match, but the segmentation ID doesn't, thus, if not validated, it will say that manage operation was successful, but it is not going to work | 19:08 |
| tbarron | ganso: ganso i'm confused, aren't you doing validation in the context of manage/unmanage for dhss=true? why are you asking about capabilities of dhss=false. | 19:09 |
| gouthamr | ganso: the allocations in the backend may be: i have been configured to support VLANS 200-1000, but i don't know that i am, the network provider does | 19:10 |
| gouthamr | how are you planning on querying ONTAP for that info? | 19:11 |
| ganso | tbarron: just to get a general idea of what information I can expect from a backend | 19:11 |
| ganso | gouthamr: ONTAP can create several interfaces on different segmentation IDs | 19:11 |
| ganso | gouthamr: so this would work for ONTAP | 19:11 |
| gouthamr | ganso: hmmm, true, that's how we would expect the tenant network to be different from the admin network on a backend's SVM | 19:13 |
| gouthamr | in case of DHSS=True | 19:13 |
| gouthamr | ganso: for CEPHFS, we don't support configuring an "admin" network | 19:13 |
| gouthamr | (yet) | 19:13 |
| ganso | gouthamr: this approach is not really necessary to address the admin network concern. Just to validate if the allocation is correct. | 19:14 |
| ganso | gouthamr: without further validating, the admin can create just about any port and neutron and say that's the one that is supposed to be correct | 19:15 |
| ganso | gouthamr: since we trust the admin to do the right choices, we may not need to do any further validation | 19:15 |
| gouthamr | ganso: agreed, i was noting that supporting multiple network segments was how we envisioned "admin networks" to work | 19:15 |
| ganso | gouthamr: but if they don't make the correct choices they would end up pulling their hair trying to figure out why it does not work | 19:16 |
| gouthamr | ganso: hmmm, how do you validate that today with creation of share servers? | 19:16 |
| gouthamr | s/you/we :) | 19:17 |
| ganso | gouthamr: today it is under control of neutron, which picks the network, creates the ports, and uses those ports (along with their segmentation ID) and passes that information to the driver. So it cannot go wrong this way | 19:17 |
| gouthamr | ganso: yes, but the backend may not be plugged in to the same physical network and the VLAN segments on both ends (tenant networking in OpenStack and networking in ONTAP) may be different | 19:18 |
| gouthamr | (your DHSS=True CI works this way ^) | 19:19 |
| ganso | gouthamr: physically we cannot make sure of that. My suggestion was to prevent something like: ONTAP has an interface with segmentation ID 150, and the admin created the neutron ports on a network with segmentation ID 160. This is not correct. In case they both match, we would expect them to work, but as you said, it may not work if things are not physically connected | 19:21 |
| gouthamr | maybe we can validate that the neutron port info matches the neutron subnet used in the share network? | 19:21 |
| ganso | gouthamr: I already validate that | 19:21 |
| ganso | gouthamr: I search for the ports in the neutron network+subnet that the admin inputs when managing the share server | 19:22 |
| gouthamr | ganso: in your example, if the admin provides VLAN 160, shouldn't you create new network interfaces on VLAN 160? | 19:22 |
| gouthamr | ganso: i mean, ignore the existing network created outside manila | 19:23 |
| ganso | gouthamr: the workflow is: 1) ONTAP has pre-existing network interfaces, with a certain segmentation ID. 2) Admin must create the ports on the proper network, should be one that matches what the backend already has. | 19:23 |
| ganso | gouthamr: we don't create new interfaces when managing a share server | 19:23 |
| ganso | gouthamr: the admin creates ports on neutron that should match what the backend has | 19:24 |
| gouthamr | "should be one that matches what the backend already has" - why? | 19:25 |
| gouthamr | not scope creeping, just want to understand the rationale | 19:26 |
| *** dustins has quit IRC | 19:26 | |
| ganso | gouthamr: because the purpose of creating those in neutron is to make sure neutron doesn't try to use that port for something else later. In other words, it is a reservation. From that point of view, it could really mean nothing, but validating this could help the admin do a successful manage or debug an unsuccessful one | 19:27 |
| *** eharney has quit IRC | 19:32 | |
| gouthamr | ganso: hmmm okay - i guess creating new interfaces may be scope creep for a "manage" operation, so i suggest pushing the validation into the driver - at present i can't think of a way to retrieve segmentation info from other backends | 19:32 |
| *** jmlowe has joined #openstack-manila | 19:47 | |
| *** luizbag has quit IRC | 19:58 | |
| *** erlon has joined #openstack-manila | 20:00 | |
| *** erlon has quit IRC | 20:08 | |
| *** eharney has joined #openstack-manila | 20:34 | |
| *** dustins has joined #openstack-manila | 20:43 | |
| *** eharney has quit IRC | 20:48 | |
| *** dustins has quit IRC | 21:15 | |
| *** arne_wiebalck has quit IRC | 21:23 | |
| *** e0ne has joined #openstack-manila | 21:29 | |
| *** e0ne has quit IRC | 21:36 | |
| *** pcaruana has quit IRC | 21:57 | |
| *** tpsilva has quit IRC | 22:58 | |
| *** ganso has quit IRC | 23:18 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!