| openstackgerrit | Mark Sturdevant proposed openstack/manila: GPFS CES: Fix bugs related to access rules not found https://review.openstack.org/411010 | 00:28 |
|---|---|---|
| tommylikehu | ping bswartz | 00:35 |
| tommylikehu | I wanna to talk with you about your comments here https://review.openstack.org/#/c/362786/29/specs/ocata/manila-ipv6.rst line #58 | 00:37 |
| tommylikehu | bswartz: with that words, I am trying to state we gonna support both True configuration in the future. we gonna support either IPv4 or IPv6 this time. | 00:37 |
| *** gouthamr has quit IRC | 00:45 | |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 00:55 |
| *** furlongm has joined #openstack-manila | 01:01 | |
| *** furlongm_ has quit IRC | 01:02 | |
| *** furlongm has quit IRC | 01:10 | |
| *** furlongm has joined #openstack-manila | 01:12 | |
| *** mtan_____ has joined #openstack-manila | 01:26 | |
| *** mtanino has quit IRC | 01:27 | |
| *** mtan_____ has quit IRC | 01:31 | |
| *** xinyanzhang has joined #openstack-manila | 01:52 | |
| bswartz | tommylikehu: why not support both? | 01:55 |
| bswartz | tommylikehu: I'd like the spec to describe both the short term and long term goals if they're not the same | 01:55 |
| bswartz | clearly in the long term we want to handle support for v4+v6 with a single plugin | 01:55 |
| bswartz | if it can't be done in the short term we should explain that and describe what we will do in Ocata | 01:56 |
| tommylikehu | Yes, Pike | 01:56 |
| tommylikehu | It's already explained what we gonna do in Ocata | 01:57 |
| bswartz | I want to avoid anyone getting the impression that the only way to get both v4 and v6 is to use 2 plugins | 01:57 |
| tommylikehu | so your suggestion we should say more words about this? | 01:57 |
| openstackgerrit | Mark Sturdevant proposed openstack/manila: GPFS: Add update_access() https://review.openstack.org/409950 | 01:57 |
| tommylikehu | make it more clear | 01:57 |
| bswartz | tommylikehu: please describe the long term goal, which is that both v4 and v6 can be true at the same time, and describe how that should work | 01:58 |
| bswartz | then also describe possible short term limitations in ocata | 01:58 |
| tommylikehu | thanks, I will add this | 01:59 |
| openstackgerrit | Tina Tang proposed openstack/manila: [Dell EMC Unity] Support create share smaller than 3 GB https://review.openstack.org/408448 | 02:25 |
| openstackgerrit | wlhc proposed openstack/manila: Closes-Bug: #1391830 https://review.openstack.org/411034 | 02:30 |
| openstack | bug 1391830 in openstack-org "Clarify what students should put in 'Affiliation'" [Low,Fix released] https://launchpad.net/bugs/1391830 - Assigned to wlhc (wlhc) | 02:30 |
| *** sapcc-bot has quit IRC | 02:30 | |
| *** tuanluong has joined #openstack-manila | 02:59 | |
| *** wlhc has joined #openstack-manila | 03:01 | |
| *** harlowja has quit IRC | 03:03 | |
| *** nherciu_ has quit IRC | 03:03 | |
| *** wlhc has quit IRC | 03:04 | |
| *** nherciu has joined #openstack-manila | 03:04 | |
| *** wlhc has joined #openstack-manila | 03:05 | |
| *** wlhc has quit IRC | 04:24 | |
| *** wlhc has joined #openstack-manila | 04:24 | |
| *** gaurangt has joined #openstack-manila | 06:12 | |
| *** lpetrut has joined #openstack-manila | 06:29 | |
| *** lpetrut has quit IRC | 07:24 | |
| *** rraja has joined #openstack-manila | 07:30 | |
| *** zhugaoxiao has quit IRC | 07:39 | |
| *** zhugaoxiao has joined #openstack-manila | 07:39 | |
| *** lpetrut has joined #openstack-manila | 07:40 | |
| openstackgerrit | Tina Tang proposed openstack/manila: [Dell EMC Unity] Support create share smaller than 3 GB https://review.openstack.org/408448 | 07:53 |
| *** lpetrut has quit IRC | 08:09 | |
| *** pcaruana has joined #openstack-manila | 08:37 | |
| *** dsariel has quit IRC | 08:37 | |
| *** ociuhandu has joined #openstack-manila | 08:40 | |
| *** rraja has quit IRC | 08:51 | |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 08:57 |
| *** ociuhandu has quit IRC | 09:00 | |
| *** ociuhandu has joined #openstack-manila | 09:01 | |
| *** wlhc has quit IRC | 09:01 | |
| *** ociuhandu has quit IRC | 09:22 | |
| *** lpetrut has joined #openstack-manila | 09:45 | |
| *** lpetrut1 has joined #openstack-manila | 09:47 | |
| *** lpetrut has quit IRC | 09:49 | |
| *** lpetrut1 is now known as lpetrut | 09:49 | |
| *** zhugaoxiao has quit IRC | 09:50 | |
| *** zhugaoxiao has joined #openstack-manila | 09:51 | |
| openstackgerrit | Merged openstack/manila-image-elements: Pin docutils version https://review.openstack.org/409944 | 09:52 |
| *** dsariel has joined #openstack-manila | 09:52 | |
| *** rraja has joined #openstack-manila | 09:57 | |
| *** ganso has joined #openstack-manila | 09:58 | |
| openstackgerrit | Digvijay Ukirde proposed openstack/manila: Add support for manage/unmanage in GPFS driver https://review.openstack.org/374705 | 10:06 |
| *** alyson_ has joined #openstack-manila | 10:08 | |
| *** openstackgerrit has quit IRC | 10:18 | |
| *** tpsilva has joined #openstack-manila | 10:20 | |
| *** openstackgerrit has joined #openstack-manila | 10:22 | |
| openstackgerrit | Tina Tang proposed openstack/manila: [Dell EMC Unity] Support create share smaller than 3 GB https://review.openstack.org/408448 | 10:22 |
| *** digvijay2016 has joined #openstack-manila | 10:22 | |
| *** lseki has joined #openstack-manila | 10:28 | |
| *** lpetrut has quit IRC | 10:31 | |
| *** lpetrut has joined #openstack-manila | 10:31 | |
| *** ociuhandu has joined #openstack-manila | 10:38 | |
| *** timcl1 has joined #openstack-manila | 10:55 | |
| *** timcl has quit IRC | 10:56 | |
| *** ociuhandu has quit IRC | 11:03 | |
| *** ociuhandu has joined #openstack-manila | 11:36 | |
| *** tuanluong has quit IRC | 11:36 | |
| *** furlongm_ has joined #openstack-manila | 11:40 | |
| tbarron | ping vponomaryov re: StandaloneNetworkPlugin and ipv4/ipv6 configuration ... | 11:40 |
| tbarron | vponomaryov: no rush, is there any reason this plugin cannot support both IPv4 and IPv6 at the same time eventually? | 11:41 |
| *** furlongm has quit IRC | 11:41 | |
| openstackgerrit | zhongjun proposed openstack/manila: [TrivalFIx] Move share type filter tempest to test_scheduler_stats.py https://review.openstack.org/409641 | 11:44 |
| tbarron | vponomaryov: reading spec 362786, I'm trying to figure if we can used the same network_plugin_ipv4/6_enabled options both for neutron and for standalone plugins (with 'standalone_network_plugin_ip_version' as a depreacate way to set either IPv4=True and IPv6=False or IPv6=True and IPv4=False | 11:44 |
| tbarron | vponomaryov: or if you think that StandAloneNetworkPlugin is somehow fundamentally different from neutron plugins in this regard and will always be just IPv4 and not IPv6 or IPv6 and not IPv4 | 11:45 |
| tbarron | vponomaryov: that's all ... :() | 11:45 |
| *** ociuhandu has quit IRC | 11:47 | |
| *** furlongm_ has quit IRC | 11:50 | |
| *** ociuhandu has joined #openstack-manila | 11:52 | |
| vponomaryov | tbarron: instance of standalone network plugin always have only one network | 12:03 |
| tbarron | vponomaryov: today, but is there anything fundamental about that. Could we give it both ipv4 and ipv6 gateways and subnets via configuration? | 12:04 |
| vponomaryov | tbarron: so, instance of standalone network plugin will always work with only one IP version | 12:04 |
| *** david-lyle has quit IRC | 12:05 | |
| *** digvijay2016 has quit IRC | 12:05 | |
| *** digvijay2016 has joined #openstack-manila | 12:05 | |
| *** david-lyle has joined #openstack-manila | 12:05 | |
| vponomaryov | tbarron: fundamental? I just stated that we use only single network for config-based network plugins | 12:06 |
| vponomaryov | tbarron: and it is strange to say support both IP versions at the same time having only ONE network | 12:07 |
| vponomaryov | same about SIngleNeutronNetworkPlugin | 12:07 |
| tbarron | vponomaryov: it doesn't seem strange to me to have ONE physical and Layer 2 network infrastructure with both IPv4 and IPv6 connectivity end-to-end. | 12:09 |
| tbarron | at layer 3 | 12:09 |
| vponomaryov | how is it related to manila's architecture? | 12:10 |
| *** porrua has joined #openstack-manila | 12:10 | |
| tbarron | vponomaryov: probably I don't understand the plugin architecture yet then | 12:10 |
| vponomaryov | you can have any amount of networks below the manila | 12:11 |
| vponomaryov | but you configure only one net per config-based network plugin | 12:11 |
| *** scottda has quit IRC | 12:11 | |
| vponomaryov | you can configure standalone network plugin to be used for user and admin export locations | 12:12 |
| vponomaryov | it will be 2 different configuration | 12:12 |
| *** yankee has joined #openstack-manila | 12:12 | |
| vponomaryov | configurations | 12:12 |
| vponomaryov | with 2 different networks | 12:12 |
| vponomaryov | of any IP version | 12:13 |
| tbarron | vponomaryov: naively, I can configure static routes and dhcp and exports on linux systems for both ipv4 and ipv6 concurrently, so I would naively expect to be able to configure standalone like that for user, or for admin export locations, independently of one another. | 12:13 |
| vponomaryov | tbarron: and again, I stated that plugin "supports" both de facto, but works only with one of them - the one which is configured | 12:15 |
| vponomaryov | tbarron: I distinguish "enabled", "supported" and "configured" IP versions | 12:16 |
| tbarron | vponomaryov: i'm just failing to see whay a standalone plugin *could not* support both at the same time, I heard you that it *does not*. But let me go back and study. Not trying to argue here. | 12:16 |
| vponomaryov | it supports both, works with only one | 12:17 |
| vponomaryov | only one is enabled | 12:17 |
| vponomaryov | because only one is configured | 12:17 |
| tbarron | vponomaryov: let me rephrase so I don't use the word "support" since that is confusiing things. | 12:17 |
| tbarron | vponomaryov: I am failing to see whey a standalone plugin *could not* be implemented in a way that it can be configured for and work with both IPv4 and IPv6 subnet ranges and gateways at the same time. I know that as implemented today it *does not* allow that. | 12:19 |
| vponomaryov | why exactly standalone network plugin? | 12:19 |
| vponomaryov | ANY config-based network plugin | 12:19 |
| tbarron | vponomaryov: one would need to provide via config an IPv4 gateway and via config an IPv6 gateway, and an IPv4 subnet range and and IPv6 subnet range | 12:20 |
| *** furlongm has joined #openstack-manila | 12:23 | |
| vponomaryov | what is the use case? | 12:23 |
| vponomaryov | and why single instance of network plugin should handle both at once? | 12:23 |
| tbarron | vponomaryov: the use case is that the network infra has both ipv4&ipv6 enabled in the OpenStack cloud, and in the external/provider network to the storage backend, and the storage backend is capbable of both ipv4 and ipv6 exports. | 12:24 |
| tbarron | vponomaryov: and that compute instances may use either address family | 12:24 |
| tbarron | when doing mounts | 12:24 |
| vponomaryov | let's assume, what about econd q? | 12:25 |
| vponomaryov | second* | 12:25 |
| vponomaryov | tbarron: also, are you aware about https://review.openstack.org/391805 ? | 12:26 |
| tbarron | vponomaryov: yeah, somewhat aware | 12:28 |
| vponomaryov | tbarron: if you really need more than one network to be used for dynamically created share servers, but with fixed networks, then it is question of redesigning of getting instances of network plugins | 12:28 |
| tbarron | vponomaryov: the second question was? | 12:29 |
| vponomaryov | (14:23:18) vponomaryov: and why single instance of network plugin should handle both at once? | 12:29 |
| *** yankee has quit IRC | 12:31 | |
| tbarron | vponomaryov: ty. So could one configure *two* instances of StandAlone (or neutron single) network plugin for my use case? | 12:31 |
| tbarron | (two for user, or two for admin) | 12:32 |
| vponomaryov | tbarron: for the moment - one as user net and other as admin net | 12:32 |
| vponomaryov | so, it is not question of this spec | 12:32 |
| vponomaryov | it is question of amount of nets per direction - user or admin | 12:32 |
| *** yankee has joined #openstack-manila | 12:32 | |
| vponomaryov | without any regards to IP version | 12:33 |
| tbarron | vponomaryov: so here "net" is one to one with L3 subnet | 12:33 |
| vponomaryov | we can say so | 12:34 |
| tbarron | vponomaryov: that is a fundamental invariant in manila network plugin architecture as we know it | 12:34 |
| tbarron | so only the multi-network neutron plugin (I ignore nova net as it is dead) could do both ipv4 and ipv6 in one plugin, and that's precisely because it is multi-net | 12:35 |
| vponomaryov | it is because it gets info via its "call" interfaces only | 12:36 |
| vponomaryov | network info | 12:36 |
| vponomaryov | consider that there is no config for it, only handling of input data | 12:36 |
| vponomaryov | in this case it just does not matter what to handle | 12:37 |
| vponomaryov | it is not the merit of the neutron | 12:37 |
| *** yankee has quit IRC | 12:37 | |
| vponomaryov | it is restriction of possibility to get info somewhere | 12:38 |
| vponomaryov | for config-based plugins, for example | 12:38 |
| vponomaryov | so, your question is not related to IPv6 spec - at all | 12:39 |
| vponomaryov | it is completely separate issue | 12:39 |
| tbarron | vponomaryov: I think it has implications for the IPv6 spec though, do you not think so? bswartz is asking | 12:39 |
| tbarron | I think reasonably | 12:39 |
| vponomaryov | and, I would say, exactly this issue should be solved first if we want it be solved | 12:40 |
| tbarron | for the spec to say how the use case I describe would be supported, across the plugins. | 12:40 |
| vponomaryov | no how | 12:40 |
| tbarron | even if in ocata we restrict a single plugin to one address family. | 12:40 |
| tbarron | no how ? :D | 12:41 |
| tbarron | are you saying I am alone in considering this case and confused about the conversation around the spec? quite possibly ... | 12:41 |
| vponomaryov | nohow while this "absent yet" spec is solved | 12:41 |
| tbarron | vponomaryov: I don | 12:41 |
| vponomaryov | which should be solved first | 12:41 |
| vponomaryov | tbarron: everyone is confused about this spec | 12:43 |
| vponomaryov | tbarron: because it tries to change lots of things under one specific goal - support IPv6 | 12:43 |
| tbarron | I don't think I am alone on this and it would help if you remark in your review of the spec that plugins should not allow use of ipv4 and ipv6 at the same time yet because that would require solving this more fundamental issue first | 12:43 |
| tbarron | we would have to either allow multiple plugins at the same time (to the same storage) or change the plugin architecture (if that could be done) to allow use of multiple addr families in the same plugiin instance | 12:45 |
| tbarron | vponomaryov: ^^^ pleases correct any miswordings/misunderstandings ^^^ | 12:45 |
| vponomaryov | yes ^, but it is completely different goal that is out of scope for this one | 12:45 |
| vponomaryov | with clarification multiple plugins per direction - user and admin | 12:46 |
| tbarron | everything I'm saying is * 2 for user and admin ... | 12:47 |
| *** chlong has joined #openstack-manila | 12:51 | |
| *** xinyanzhang has quit IRC | 12:53 | |
| *** xinyanzhang has joined #openstack-manila | 12:54 | |
| *** jprovazn has joined #openstack-manila | 12:54 | |
| *** catintheroof has joined #openstack-manila | 13:00 | |
| *** catintheroof has quit IRC | 13:01 | |
| *** catintheroof has joined #openstack-manila | 13:01 | |
| *** ociuhandu has quit IRC | 13:09 | |
| *** ociuhandu has joined #openstack-manila | 13:11 | |
| *** alyson_ has quit IRC | 13:16 | |
| *** jprovazn has quit IRC | 13:25 | |
| *** erlon has joined #openstack-manila | 13:38 | |
| *** gouthamr has joined #openstack-manila | 13:45 | |
| *** tommylikehu_ has joined #openstack-manila | 13:49 | |
| *** tommylikehu_ has quit IRC | 13:50 | |
| *** tommylikehu_ has joined #openstack-manila | 13:51 | |
| *** scottda has joined #openstack-manila | 13:59 | |
| *** lpetrut has quit IRC | 14:10 | |
| tommylikehu_ | ping vponomaryov | 14:12 |
| tommylikehu_ | hello vponomaryov | 14:12 |
| vponomaryov | tommylikehu_: pong | 14:13 |
| tommylikehu_ | Thanks I wanna talk with you about the comments in IPv6 spec :) | 14:13 |
| tommylikehu_ | just few minutes | 14:13 |
| tommylikehu_ | point 3 about 'another seperated spec' | 14:14 |
| tommylikehu_ | I am stating we gonna make the neutron network plugins support both IPv4 and IPv6 enabled in not this spec, not Ocata, but another spec and another time, | 14:14 |
| vponomaryov | tommylikehu_: have you read history of this chat? | 14:15 |
| vponomaryov | for today? | 14:15 |
| tommylikehu_ | with bswartz? | 14:15 |
| vponomaryov | http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2016-12-15.log.html#t2016-12-15T11:40:13 | 14:16 |
| vponomaryov | with tbarron | 14:16 |
| tommylikehu_ | saddly no | 14:17 |
| *** dustins has joined #openstack-manila | 14:20 | |
| *** gouthamr has quit IRC | 14:20 | |
| *** chlong has quit IRC | 14:20 | |
| *** chlong has joined #openstack-manila | 14:22 | |
| *** lpetrut has joined #openstack-manila | 14:25 | |
| *** chlong has quit IRC | 14:26 | |
| *** chlong has joined #openstack-manila | 14:27 | |
| *** gouthamr has joined #openstack-manila | 14:28 | |
| *** yankee has joined #openstack-manila | 14:29 | |
| *** eharney has joined #openstack-manila | 14:30 | |
| tommylikehu_ | ping vponomaryov | 14:32 |
| tommylikehu_ | checked the log | 14:33 |
| tommylikehu_ | thanks | 14:33 |
| vponomaryov | yes? | 14:33 |
| tommylikehu_ | my question here is | 14:33 |
| tommylikehu_ | point 3 I am stating we gonna make the neutron network plugins(not configure one) support both IPv4 and IPv6 enabled in not this spec, not Ocata, but another spec and another time, does this more correct for you? | 14:33 |
| tommylikehu_ | and for the rest we gonna support either IPv4 or IPv6 enabled at this spec | 14:35 |
| *** breitz_ has quit IRC | 14:37 | |
| *** breitz has joined #openstack-manila | 14:37 | |
| vponomaryov | tommylikehu_: to reduce confusion, I propose to say explicitly, that questions of amount of networks supported by network plugins is out of scope for your spec | 14:39 |
| vponomaryov | tommylikehu_: your spec is about making them support IPv6 | 14:40 |
| vponomaryov | tommylikehu_: keeping amount of supported network at once unchanged | 14:40 |
| vponomaryov | s/network/networks/ | 14:40 |
| vponomaryov | and in this case no new config options will be required | 14:41 |
| vponomaryov | they could be required solving that other goal | 14:41 |
| vponomaryov | goal of supporting multiple networks | 14:41 |
| *** xyang_ has joined #openstack-manila | 14:42 | |
| tommylikehu_ | one network could have both IPv4 and IPv6 subnets | 14:42 |
| tommylikehu_ | How can we deal this case? | 14:43 |
| vponomaryov | it can have several subnets without regards to IPv6 | 14:43 |
| vponomaryov | at all | 14:43 |
| vponomaryov | it is questions of amount of networks | 14:43 |
| vponomaryov | not their IP version | 14:43 |
| tbarron | tommylikehu_: I understood bswartz to be asking that the spec say how to support use of ipv4 + ipv6 with the same network plugin at the same time on the same share network but | 14:44 |
| tbarron | tommylikehu_: vponomaryov is saying that is not possible without re-thinking how we do network plugins | 14:45 |
| tbarron | vponomaryov: correct if I misunderstood | 14:45 |
| vponomaryov | tbarron: the answer for bswartz's concern s you understood it, is my response -> we should track that activity in separate spec, because it is related to amount of supported networks/subnets at once, not exactly to IP versions | 14:46 |
| vponomaryov | current architecture - one network per network plugin | 14:47 |
| tommylikehu_ | network=subnet ? | 14:47 |
| tbarron | two IP versions on one share network would be a case of two subnets on one share network which is not supported with current architecture | 14:47 |
| vponomaryov | tbarron: right | 14:48 |
| *** dsariel has quit IRC | 14:48 | |
| tbarron | tommylikehu_: ^^^ so it doesn't make sense to pursue two IPversions in any single network plugin - neutron single net or Standalone, before dealing with that more fundamental issue. | 14:48 |
| vponomaryov | tommylikehu_: technically, "subnet" is sub-network, which is network too | 14:49 |
| vponomaryov | tommylikehu_: and if we support only one network, then we do not care about whose it is subnet | 14:49 |
| tommylikehu_ | so we should remove the part of support both IPv4 and IPv6 enabled in network plugins? | 14:50 |
| tbarron | tommylikehu_: neutron multi-network could have a mix of ipv6 and ipv4 share networks but it likely doesn't make sense to do that if eventually we are going to have to figure out how to handle the multi-subnet on single share network issue for the other plugins | 14:51 |
| tbarron | tommylikehu_: be careful with word "support" - you'll get in trouble with vponomaryov :D | 14:51 |
| tommylikehu_ | already.. | 14:52 |
| tbarron | tommylikehu_: use 'use' & 'configure' and 'deploy' - you can't do them both *at the same time on the same share network even if the plugin "supports" both (at different times on different share nets) | 14:52 |
| vponomaryov | tommylikehu_: it should be rewritten | 14:53 |
| vponomaryov | tommylikehu_: saying what is part your spec and what is not | 14:53 |
| vponomaryov | tommylikehu_: and supporting multiple networks per network plugin *is not* part of your spec | 14:53 |
| tommylikehu_ | ok...... | 14:53 |
| *** xyang_ has quit IRC | 14:55 | |
| *** yankee has quit IRC | 14:57 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila: [DEBUG] Testing migration in various CIs https://review.openstack.org/365774 | 14:58 |
| *** xyang_ has joined #openstack-manila | 14:59 | |
| vponomaryov | bswartz: meeting? | 15:01 |
| *** cknight has joined #openstack-manila | 15:03 | |
| *** chlong has quit IRC | 15:03 | |
| openstackgerrit | Ben Swartzlander proposed openstack/manila-specs: Eliminate Race Conditions Spec https://review.openstack.org/396255 | 15:07 |
| openstackgerrit | Vitaliy Levitski proposed openstack/manila: debug https://review.openstack.org/411370 | 15:13 |
| openstackgerrit | Victoria Martinez de la Cruz proposed openstack/manila: Setting up a development env with devstack instructions https://review.openstack.org/408275 | 15:17 |
| *** shausy has joined #openstack-manila | 15:23 | |
| openstackgerrit | Arne Wiebalck proposed openstack/manila-ui: Ignore current share's size in extend quota bar https://review.openstack.org/411382 | 15:30 |
| openstackgerrit | Arne Wiebalck proposed openstack/manila-ui: Replace 'Extend Share' by 'Resize Share' https://review.openstack.org/411384 | 15:32 |
| *** shausy has quit IRC | 15:37 | |
| *** gaurangt has left #openstack-manila | 15:40 | |
| *** digvijay2016 has quit IRC | 15:44 | |
| *** lpetrut has quit IRC | 15:53 | |
| bswartz | okay guys sorry I'm out of touch I've been driving my wife to the doctor and stuff | 16:02 |
| bswartz | I'll be online again shorrtly and updating spec then pinging you all | 16:02 |
| *** timcl has joined #openstack-manila | 16:03 | |
| tommylikehu_ | ok~ | 16:03 |
| tbarron | bswartz: sorry bout that, anything we can do to help? | 16:03 |
| tbarron | on this side that is | 16:03 |
| *** timcl1 has quit IRC | 16:06 | |
| *** tommylikehu_ has quit IRC | 16:08 | |
| *** tommylikehu_ has joined #openstack-manila | 16:10 | |
| *** mtanino has joined #openstack-manila | 16:18 | |
| openstackgerrit | Valeriy Ponomaryov proposed openstack/manila: [DNM] debug 3.0 https://review.openstack.org/410366 | 16:20 |
| ganso | vponomaryov: ping | 16:29 |
| bswartz | tbarron: I'm back | 16:40 |
| bswartz | it's just that we've have flu going around my house, despite flu shots, so people have been sick and I've been working from home to avoid spreading pestilence | 16:41 |
| *** xyang_ has quit IRC | 16:42 | |
| bswartz | remarkably I feel fine, although I do have a post nasal drip and a cough | 16:42 |
| *** pcaruana has quit IRC | 16:42 | |
| *** xyang_ has joined #openstack-manila | 16:42 | |
| bswartz | I'm going to push another rev of my spec shortly, and I expect tommylikehu_ and gouthamr to do the same | 16:42 |
| bswartz | I'll be pinging everyone until we reach decisions on these specs | 16:43 |
| tommylikehu_ | sure | 16:43 |
| gouthamr | sure thing bswartz | 16:43 |
| bswartz | ganso: you still here? | 16:44 |
| ganso | bswartz: yes | 16:44 |
| bswartz | ganso: I'm happy to change the title, but what about the filename? | 16:44 |
| ganso | bswartz: rename according to the title? | 16:44 |
| bswartz | you think I should rename it too? | 16:44 |
| ganso | bswartz: I think it would be better if the filename matches the title | 16:45 |
| bswartz | hmmm the title might be loooong | 16:45 |
| bswartz | how about "Mechanism to Prevent Race Conditions" | 16:46 |
| bswartz | that's not too long | 16:46 |
| ganso | bswartz: LGTM | 16:46 |
| bswartz | ganso: what about the exinst LP blueprint? it still has the old name | 16:49 |
| bswartz | existing* | 16:49 |
| ganso | bswartz: I think that's not a problem | 16:50 |
| bswartz | ganso: regarding your 3rd comment, I'm not sure how many changes the implementation of the spec will require | 16:55 |
| bswartz | ganso: the point I was trying to make was that microversion bumps would be attached to changes which added new states, but patches that simply add locks won't include version bumps | 16:55 |
| ganso | bswartz: if your spec scope will not implement any of the state transitions, it will delegate that, then you will not bump microversion | 16:56 |
| bswartz | we're going to add the snapshotting state at least | 16:57 |
| bswartz | not sure if any others will emerge | 16:57 |
| ganso | bswartz: if you're adding the snapshotting state, then you're bumping | 16:57 |
| ganso | bswartz: when they emerge, they will bump as well | 16:57 |
| bswartz | yes | 16:57 |
| bswartz | I thought that's what I said in the spec | 16:57 |
| bswartz | maybe it's not clear | 16:57 |
| ganso | bswartz: I was not sure if the scope was including the snapshotting transition was well or just the mechanism | 16:58 |
| bswartz | ganso: the answer is, we'll do as much as possible | 16:58 |
| *** xyang_ has quit IRC | 16:59 | |
| ganso | bswartz: maybe just clarify that ^ | 16:59 |
| bswartz | I don't see elimination of race conditions as a binary thing -- it's an ideal that we aim for, even though we can never hope to achieve it | 16:59 |
| bswartz | that's like writing a spec titled "fix all bugs" | 17:00 |
| ganso | bswartz: state that the scope of spec is to implement the mechanism and snapshotting state transition, that's all | 17:00 |
| bswartz | okay I think the new rev makes that clear | 17:00 |
| bswartz | I'll push it | 17:00 |
| openstackgerrit | Ben Swartzlander proposed openstack/manila-specs: Mechanism to Prevent Race Conditions Spec https://review.openstack.org/396255 | 17:01 |
| *** timcl has quit IRC | 17:05 | |
| tommylikehu_ | ping vponomaryov | 17:05 |
| ganso | bswartz: one more -1 | 17:06 |
| bswartz | keep them coming! | 17:07 |
| bswartz | please tell me it's not another spelling error though | 17:07 |
| bswartz | otherwise I'll be forced to install a spell checker | 17:07 |
| ganso | bswartz: it is not | 17:07 |
| openstackgerrit | zhongjun proposed openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 17:08 |
| openstackgerrit | Ben Swartzlander proposed openstack/manila-specs: Mechanism to Prevent Race Conditions Spec https://review.openstack.org/396255 | 17:10 |
| tommylikehu_ | Is someone checking my patch. hope this version could be closer | 17:11 |
| bswartz | tommylikehu_: reading now | 17:12 |
| ganso | bswartz: one more -1 | 17:13 |
| ganso | bswartz: you almost got it | 17:14 |
| bswartz | ganso: I think you're wrong | 17:14 |
| bswartz | I left out "bp" because I understand it's not required | 17:14 |
| ganso | bswartz: if you add, gerrit create a link to launchpad | 17:14 |
| bswartz | ganso: is it documented? | 17:14 |
| ganso | bswartz: and it automatically searches for the blueprint | 17:14 |
| ganso | bswartz: I've seen the documentation before, I don't remember if leaving it out is an accepted variant | 17:15 |
| ganso | bswartz: http://docs.openstack.org/infra/manual/developers.html | 17:15 |
| ganso | bswartz: the example uses "blueprint" | 17:16 |
| ganso | bswartz: "bp" also works | 17:16 |
| ganso | bswartz: so I guess leaving it out is not an option | 17:16 |
| openstackgerrit | Ben Swartzlander proposed openstack/manila-specs: Mechanism to Prevent Race Conditions Spec https://review.openstack.org/396255 | 17:16 |
| * bswartz sighs at how fragile this infrastructure is | 17:16 | |
| *** timcl has joined #openstack-manila | 17:17 | |
| bswartz | tommylikehu_, zhongjun: I like this new language better | 17:19 |
| tommylikehu_ | :) | 17:19 |
| bswartz | gouthamr: are you going to do anything in you spec about new->denying? | 17:20 |
| bswartz | seems like everyone is getting lunch, so I'll do the same | 17:24 |
| bswartz | bbiab | 17:24 |
| *** dustins has quit IRC | 17:25 | |
| tommylikehu_ | you guys just left a little man waiting in the midnight... | 17:27 |
| *** catinthe_ has joined #openstack-manila | 17:36 | |
| *** catintheroof has quit IRC | 17:38 | |
| *** mtanino has quit IRC | 17:42 | |
| tbarron | ganso: good to know about "waiting on jenkins" with docs. People do that in other circumstances too though and I don't fully get it. Maybe if there's something non-voting that matters for one's own vote? | 17:44 |
| tommylikehu_ | tbarron: just two of us around? | 17:45 |
| tbarron | tommylikehu_: i'm eating my lunch at my desk :D | 17:45 |
| *** xyang_ has joined #openstack-manila | 17:51 | |
| *** tommylikehu_ has quit IRC | 17:52 | |
| *** dustins has joined #openstack-manila | 18:07 | |
| *** chlong has joined #openstack-manila | 18:14 | |
| bswartz | tommylikehu: I know it's late we'll keep trying to get the ipv6 spec merged | 18:17 |
| bswartz | if any issues come up that I can fix I'll do them myself | 18:17 |
| * bswartz wonders if gouthamr is back from lunch yet | 18:26 | |
| gouthamr | bswartz: i'm back | 18:26 |
| gouthamr | bswartz: talking to tbarron about the comments | 18:26 |
| bswartz | gouthamr: do we need to do anything regarding new->denying? | 18:26 |
| gouthamr | bswartz: new->denying can still happen | 18:27 |
| gouthamr | bswartz: it's not noted in the spec | 18:27 |
| bswartz | tbarron gouthamr: you're welcome to discuss it in the channel | 18:27 |
| bswartz | gouthamr: so do you plan to push an update? | 18:27 |
| gouthamr | bswartz: yes.. got concerns though | 18:27 |
| tbarron | so there are a variety of ways denies can race with allows. | 18:28 |
| tbarron | api prevents denies for a rule until it is created, but it is created in the api. | 18:28 |
| tbarron | so with the right tight loop of denies, or more plausibly | 18:29 |
| bswartz | tbarron: I'm not sure I see the problem | 18:29 |
| tbarron | multiple api services (as we have now), some slow, some fast | 18:29 |
| tbarron | it can happen | 18:29 |
| bswartz | as long as the API service holds locks around the state changes, we can simply establish a last-change-wins order | 18:29 |
| gouthamr | tbarron: i can copy-paste from the other window | 18:29 |
| *** ianychoi has quit IRC | 18:30 | |
| tbarron | gouthamr: +1 | 18:30 |
| tbarron | bswartz: I"m not saying it's a problem, it's an arg for new->deny state change | 18:30 |
| gouthamr | <gouthamr> if you have a loop running deny-access to a bunch of users/IPs | 18:30 |
| gouthamr | [13:23:10] <tbarron> or multiple API services (like we do today) and one is slow | 18:30 |
| gouthamr | [13:23:29] <tbarron> or has a long cast to the share service | 18:30 |
| gouthamr | [13:23:49] <tbarron> or the 'new' is "queued" and not yet applying | 18:30 |
| gouthamr | [13:24:16] <tbarron> or (tomorrow) you have active-active share services and the allow/new went to one and | 18:30 |
| gouthamr | [13:24:37] <tbarron> another picked up the deny without having itself gotten a cast for the new | 18:30 |
| gouthamr | [13:25:05] <tbarron> or delete share, delete replica, unamanage share came in and set off a big batch of these at the right time | 18:30 |
| tbarron | bswartz: spec doesn't currently have it | 18:30 |
| tbarron | my remark at line 182 in https://review.openstack.org/#/c/399049/16/specs/ocata/fix-and-improve-access-rules.rst | 18:31 |
| gouthamr | currently we look into the database, if there are any "applying" rules we know the driver is applying rules, so we hold off | 18:31 |
| bswartz | right I think we all understand that if you send a allow followed immediately by a deny, both will get processed and the deny should win, although the share may be accessible for an unspecified amount of time | 18:31 |
| *** harlowja has joined #openstack-manila | 18:31 | |
| tbarron | bswartz: deny should win and can if you look into the database. | 18:32 |
| bswartz | we just need to make sure the state machine allows for this sequence of events | 18:32 |
| tbarron | gouthamr: my point is that the allow may not yet be applying when the deny arrives. | 18:32 |
| tbarron | gouthamr: it's just a tweak to your approach. | 18:33 |
| tbarron | bswartz: +1 | 18:33 |
| bswartz | okay I think I see the problem here | 18:33 |
| tbarron | that's point #1: gouthamr you agree? | 18:33 |
| gouthamr | in the code currently, the share instance is locked | 18:33 |
| bswartz | the state machine is capturing 2 important things -- the desired end state as well as the "progress" of any ongoing changes | 18:34 |
| gouthamr | i.e, if there are any changes happening, we lock the share instance | 18:34 |
| bswartz | perhaps a better design would split those 2 things | 18:34 |
| gouthamr | but those locks are without any database help | 18:34 |
| tbarron | gouthamr: i like your approach of not locking long! | 18:34 |
| gouthamr | tbarron: i meant in the proposed patch | 18:34 |
| tbarron | just look at the DB again after you let denies cancel out the new state | 18:35 |
| gouthamr | https://review.openstack.org/#/c/369668/3/manila/share/access.py@69 | 18:35 |
| gouthamr | when i redid this for the spec with database states, i ignored the denies racing case | 18:35 |
| ganso | vponomaryov: ping | 18:36 |
| gouthamr | well, i have always had an alternate proposal :P | 18:36 |
| bswartz | gouthamr: what's that | 18:36 |
| gouthamr | how about using share_instance's access_rules_status for locking | 18:36 |
| bswartz | ? | 18:36 |
| tbarron | gouthamr: why lock? just change it to deny. | 18:36 |
| gouthamr | if it is out_of_sync, it means something's happening and everything else will get queued | 18:37 |
| tbarron | then lock around the inspection of the DB right before you call into the driver | 18:37 |
| tbarron | keep it simple and avoid locks | 18:37 |
| tbarron | keep state in the DB | 18:37 |
| bswartz | tbarron: no | 18:37 |
| tbarron | bswartz: I'm not saying avoid *all* locks | 18:38 |
| bswartz | anything read from or written to the DB needs locks to avoid races to those reads/writes | 18:38 |
| tbarron | bswartz: +! | 18:38 |
| tbarron | +1 | 18:38 |
| bswartz | tbarron: what you said is a contradiction though | 18:38 |
| gouthamr | +1 ^ that's the problem we're trying to fix.. not doing it is keeping the problem forever | 18:38 |
| bswartz | you said avoid locks -- we cannot | 18:38 |
| tbarron | bswartz: i left off "where not required", hit CR too soon | 18:38 |
| bswartz | I think it's pretty clear where they're required and not required though, and that was the point of *my* spec | 18:39 |
| gouthamr | the share_instance's access_rules_status will only be modified by the share manager | 18:39 |
| bswartz | every read or write to one of these state fields in any service needs to be done while holding a lock | 18:39 |
| tbarron | what I'm trying to say (and do say in my review remarks) is that we don't have to prevent a deny of a rule when the corresponding apply is in flight but not yet applied | 18:39 |
| tbarron | bswartz: +1 | 18:40 |
| bswartz | the only way to avoid a lock is to avoid examining state | 18:40 |
| gouthamr | tbarron: we probably do need to | 18:40 |
| tbarron | bswartz: red herring, sorry I took you there. Your spec has my +2 and I don't mean to be saying anythying otherwise now. | 18:40 |
| tbarron | gouthamr: ? | 18:40 |
| gouthamr | tbarron: a deny can come in when the rule is being applied, but we won't call the driver right away | 18:41 |
| tbarron | yes | 18:41 |
| gouthamr | tbarron: we will allow the driver to return and recurse over the method | 18:41 |
| tbarron | agree, that's my first point in the review | 18:41 |
| gouthamr | tbarron: yep.. | 18:41 |
| tbarron | when it recurses what will it find? | 18:41 |
| gouthamr | tbarron: that the rule's been denied, so it will call into the method again | 18:42 |
| tbarron | any 'new' should have been overwritten by 'deny' in the api. | 18:42 |
| gouthamr | tbarron: it can be | 18:42 |
| gouthamr | tbarron: i just haven't stated taht in the spec - that will be rectified | 18:42 |
| tbarron | gouthamr: so if you allow the overwrite, the worst that can happen is that multiple casts for the same rule will come into the manager. | 18:43 |
| tbarron | whether the cast was triggered by an apply request or a deny request does not matter. | 18:43 |
| gouthamr | yes, currently does not matter | 18:43 |
| bswartz | the transition from new->denying can race with the transition from new->applying too | 18:43 |
| gouthamr | bswartz: that will be locked | 18:43 |
| tbarron | That is my point at line 264 in the review | 18:43 |
| bswartz | if denying wins, the driver should only get invoked once | 18:43 |
| bswartz | if applying wins, the driver should get invoked twice | 18:44 |
| *** xyang_ has quit IRC | 18:44 | |
| tbarron | bswartz: the cast may have already been launched from api to manager by then | 18:44 |
| gouthamr | bswartz: yes.. | 18:44 |
| tbarron | so the manager has to do the right thing no matter which cast gets there first. | 18:44 |
| bswartz | tbarron: indeed, that race only happens when the RPC reaches the manager around the same time the second REST call comes in | 18:44 |
| tbarron | it can do that if it basically does what goutham says: inspect the DB. | 18:45 |
| markstur | How can we make progress on IPv6? | 18:45 |
| tbarron | markstur: vote +2 | 18:45 |
| markstur | Seems like we don't have a plan for net plugins yet | 18:45 |
| markstur | Can we just say that if the share-net returns and ip_version that doesn't match the driver capabilities then the driver will barf | 18:46 |
| bswartz | markstur: we decided in the meeting on approach (2) | 18:46 |
| markstur | err... return an error | 18:46 |
| bswartz | markstur: and we also said we could postpone the implementation of that until later | 18:46 |
| tbarron | markstur: I thought the spec was revised to indicate that we would support aproach #2 but not yet in ocata | 18:46 |
| markstur | bswartz: We don't have spec to do that in "O" | 18:46 |
| *** eharney has quit IRC | 18:46 | |
| * markstur goes to look again | 18:47 | |
| bswartz | markstur: did you read zhongjun's latest PS? | 18:47 |
| markstur | I think Clinton threatened to -2 that | 18:49 |
| markstur | that concept | 18:49 |
| tbarron | markstur: clinton's remark was 10:30ish eastern time, meeting was 11-12 and he was there | 18:50 |
| markstur | OK. So I'm still doubting that the share-network part is ironed out, but | 18:50 |
| tbarron | markstur: clinton's remark about -2 was made w/o the context of valeriy's info that plugiins would have to be re-architected first. | 18:51 |
| markstur | but I don't see anything that we would regret in "P" | 18:51 |
| gouthamr | tbarron bswartz: i'll push up a new PS in a bit for the access-rules spec | 18:51 |
| tbarron | gouthamr: can we talk through the other points in the review? | 18:51 |
| tbarron | #1) was allow new->deny | 18:52 |
| *** xyang_ has joined #openstack-manila | 18:52 | |
| gouthamr | tbarron: #1 -> no concerns, it was missed out | 18:52 |
| tbarron | #2) was line 264: no need to carry access_rules parameter in the new consolidated rpcapi | 18:52 |
| *** harlowja has quit IRC | 18:52 | |
| gouthamr | #2) that's what the spec means, but does not say | 18:52 |
| gouthamr | like the way you put it : | 18:52 |
| gouthamr | :P | 18:52 |
| tbarron | since you have to look at the DB in the manager anyways | 18:53 |
| tbarron | k | 18:53 |
| *** xyang_ has quit IRC | 18:53 | |
| gouthamr | the consolidation was solely because both the services have access to the database and can look into the db and figure out the work that needs done | 18:53 |
| gouthamr | ^ that's how it's stated in the spec | 18:53 |
| tbarron | Agreed, and carrying that parameter still would be confusing. | 18:54 |
| tbarron | since you might send an "apply" and it would trigger a deny. | 18:54 |
| *** dustins has quit IRC | 18:54 | |
| gouthamr | tbarron: and unnecessary, can add that detail. | 18:54 |
| tbarron | all you are doing is triggering the manager to send updates | 18:54 |
| gouthamr | yep | 18:54 |
| tbarron | #3) line 270 | 18:54 |
| tbarron | when processing a deny, calling into the driver and waiting for it to return, | 18:55 |
| tbarron | we also need to hold off on any new updates. | 18:55 |
| tbarron | so i would propose someghing like: put rule in 'deny' state (like 'new') in the API. | 18:56 |
| bswartz | markstur: good point about the share networks | 18:56 |
| tbarron | when you process it in the manager, move it to 'denying' (like 'aplying') | 18:56 |
| *** ociuhandu has quit IRC | 18:56 | |
| tbarron | "queue" other requests if any rules are applying or denying | 18:56 |
| markstur | There isn't enough there for the share-net(subnet), the plug-in, and the share-type to all be validated before the driver gets it | 18:56 |
| markstur | but drivers could do some validation when they add IPv6 (or before to prevent it) | 18:57 |
| bswartz | markstur: thanks for raising that issue I'm going to have to think it through | 18:57 |
| gouthamr | tbarron: would you need a "deny" state, why can't we use the share instance's access_rules_status and lock with that | 18:58 |
| gouthamr | tbarron: this patch does not invalidate the share instance's access_rules_status field | 18:58 |
| gouthamr | though we did bring that up before | 18:58 |
| tbarron | gouthamr: hmm | 18:59 |
| *** timcl1 has joined #openstack-manila | 19:00 | |
| tbarron | gouthamr: if you use access_rules_status to make the decsion to queue up new updates then why do you need new->applying in the map.state? | 19:01 |
| gouthamr | tbarron: because we still need to know what rules are not yet picked up for an update | 19:01 |
| *** cknight has quit IRC | 19:02 | |
| *** timcl has quit IRC | 19:02 | |
| tbarron | gouthamr: and denying is picked up or not? | 19:02 |
| *** catintheroof has joined #openstack-manila | 19:02 | |
| tbarron | cast comes in for a deny, db state for the rule is as it was set in the api. | 19:03 |
| tbarron | denying. | 19:03 |
| tbarron | we call update_access into the driver. | 19:03 |
| tbarron | you leave that rule in denying. | 19:03 |
| gouthamr | yep | 19:03 |
| tbarron | but any allow rules get changed to applying | 19:03 |
| gouthamr | tbarron: yes | 19:03 |
| tbarron | supose there were no allow rules in that update | 19:04 |
| tbarron | we come out of the driver | 19:04 |
| gouthamr | and delete any denying rules | 19:04 |
| tbarron | ok | 19:04 |
| *** dustins has joined #openstack-manila | 19:05 | |
| tbarron | when we were in the driver, how did we know we were busy again? | 19:05 |
| tbarron | so that we'd queue up new stuff? | 19:05 |
| gouthamr | we set the share instance's access_rules_status to "out_of_sync" | 19:05 |
| gouthamr | and we do that ONLY in the share manager | 19:05 |
| tbarron | but line 141, that could have been done in the api, right? for an allow that hasn't arrived yet, or hasn't arrived at this share manager | 19:06 |
| *** catinthe_ has quit IRC | 19:06 | |
| gouthamr | our locking code will look like this: 1) Acquire a lock, look into the database, is the share_instance's access_rules_status "Active", then update it to "out_of_sync", look for any "new" and "denying" rules, release the lock. | 19:07 |
| gouthamr | if the access_rules_status was "out_of_sync", log and leave - nothing to do | 19:08 |
| tbarron | actually, in the spec at line 174 you set share_instance.access_rules_status to 'out_of_sync' for a delete/deny in the api | 19:08 |
| tbarron | i was working off what the spec says, not what you are describing now | 19:09 |
| gouthamr | yes | 19:09 |
| gouthamr | tbarron: this is new, i.e, those state transitions will not happen in the API | 19:09 |
| gouthamr | tbarron: for share_instance.access_rules_status | 19:09 |
| bswartz | markstur: okay so the way I think about it, today share-networks limit you to a single neutron subnet for your shares, meaning a user will never be able to ask for a v4+v6 share with a share network | 19:09 |
| bswartz | markstur: that's a significant shortcoming in the end-user API but not something we're changing with this proposal | 19:10 |
| gouthamr | tbarron: this also means that the share_instance.access_rules_status can never be anything but "active" or "out_of_sync" | 19:10 |
| markstur | bswartz: Right. Of course the user could pick the "wrong" one | 19:10 |
| bswartz | all we're adding is the more explicit understanding of v4/v6 support in the scheduler | 19:10 |
| bswartz | markstur: exactly | 19:11 |
| bswartz | markstur: and if you pick the wrong one you get a classic "no host found" scheduler error and your share goes nowhere | 19:11 |
| markstur | Eventually the scheduler could make sure the subnet will work with the sharetype, driver and netplugin | 19:11 |
| gouthamr | tbarron: in the API, we need logic to interpret what the collective access_rules_status is, for a given share or share instance | 19:11 |
| markstur | For now it would go to the driver and be up to the driver to find the wrong IP type? | 19:12 |
| tbarron | gouthamr: hmm, or you could keep share_instance.access_rules status as is, with error as a possiblity, to ease rollup of state for report/display purposes and use deny->denying | 19:12 |
| tbarron | gouthamr: but i'm not dug in on that. I'll look at the new spec with those changes, but I'm a slow thinker and will have to read it somewhat carefully. | 19:12 |
| bswartz | markstur: oh you're right, without additional logic in the scheduler, the scheduler will pick a host and the failure won't occur until share-server creation | 19:12 |
| tbarron | what you are describing is quite a bit different than what is written down now. | 19:13 |
| bswartz | adding that logic in the scheduler to avoid that doomed scenario wouldn't be terribly hard though | 19:13 |
| gouthamr | tbarron: yes | 19:13 |
| bswartz | markstur: unless I'm missing something else? | 19:13 |
| markstur | bswartz: Yeah. I don't think we'll painted into a corner. We just don't have a spec for that. | 19:13 |
| tbarron | gouthamr: we're cool then, ping me when you want. | 19:13 |
| * gouthamr thought of a gif to post to tbarron if irc were slack | 19:14 | |
| tbarron | gouthamr: i'm on telegram | 19:14 |
| gouthamr | lol | 19:14 |
| *** dustins_ has joined #openstack-manila | 19:14 | |
| markstur | I'm using LimeChat. It'll show me a gif (I think) | 19:15 |
| * bswartz is thankful we don't use slack for real work | 19:15 | |
| markstur | venn diagram for slack and realwork shows some intersection | 19:16 |
| markstur | it's just hard to see it because the giphys get in the way | 19:17 |
| gouthamr | lol | 19:17 |
| *** dustins has quit IRC | 19:17 | |
| bswartz | #dieslackdie | 19:17 |
| * markstur checks to see if IBM slack has a #dieslackdie channel yet | 19:19 | |
| bswartz | rraja, csaba: ping | 19:20 |
| bswartz | rraja, csaba: infra informs me that the glusterfs CI jobs are still on trusty and it needs urgently to be moved to xenial | 19:21 |
| rraja | bswartz: that's right. csaba was working on this. i'll follow up with. thanks! | 19:24 |
| rraja | s/with/with him/ | 19:24 |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila: [DEBUG] Testing migration in various CIs https://review.openstack.org/365774 | 19:28 |
| *** vponomaryov1 has joined #openstack-manila | 19:34 | |
| *** timcl1 has quit IRC | 19:35 | |
| *** cknight has joined #openstack-manila | 19:36 | |
| *** dustins_ is now known as dschoenb | 19:38 | |
| *** dschoenb is now known as dustins | 19:38 | |
| rhagarty | ameade, vponomaryov: re https://review.openstack.org/#/c/315730/12/specs/ocata/manila-share-groups.rst. Can I help out with the Horizon piece? I'm currently working on cinder version of this in Horizon. | 19:38 |
| *** timcl has joined #openstack-manila | 19:39 | |
| *** dsariel has joined #openstack-manila | 19:39 | |
| *** eharney has joined #openstack-manila | 19:43 | |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila: Add mountable snapshots support to HNAS driver https://review.openstack.org/411474 | 19:47 |
| *** dustins has quit IRC | 19:48 | |
| vponomaryov1 | ganso: pong | 19:48 |
| vponomaryov1 | ganso: reading history for several hours | 19:48 |
| * vponomaryov1 reading... | 19:48 | |
| *** dustins has joined #openstack-manila | 19:48 | |
| vponomaryov1 | rhagarty: ho one has worked on UI part, if I am not mistaken | 19:49 |
| vponomaryov1 | rhagarty: so, if you want to, sure, you can contribute ) | 19:50 |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila-specs: Add a spec to fix and improve Access Rules https://review.openstack.org/399049 | 19:50 |
| rhagarty | vponomaryov1: sounds good. I work with markstur so I'll coordinate with him to come up with plan. | 19:52 |
| *** mtanino has joined #openstack-manila | 19:53 | |
| ganso | vponomaryov1: I am leaving now, I will have to talk to you tomorrow | 19:53 |
| bswartz | ganso: what is your feeling on ipv6 spec | 19:54 |
| bswartz | oh nm I see you voted | 19:55 |
| openstackgerrit | Tiago Pasqualini da Silva proposed openstack/manila: Add mountable snapshots support to HNAS driver https://review.openstack.org/411474 | 19:55 |
| bswartz | vponomaryov vponomaryov1: you haven't voted on specs | 19:56 |
| vponomaryov1 | bswartz: I am on it | 19:57 |
| bswartz | okay just making sure -- I know it's getting late | 19:57 |
| bswartz | huawei folks already went to bed | 19:57 |
| gouthamr | tbarron: https://review.openstack.org/399049 | 20:06 |
| tbarron | gouthamr: looking | 20:13 |
| gouthamr | tbarron: thanks | 20:13 |
| vponomaryov1 | gouthamr: please, explain why you use word "deny" as state when it is verb in imperative mood? Does it mean this rule is scheduled for deletion? | 20:14 |
| vponomaryov1 | but not being processed yet? | 20:15 |
| bswartz | vponomaryov1: I suspect it's to differentiate between something that will be denied vs something the manager is currently denying | 20:15 |
| gouthamr | vponomaryov1: yes | 20:15 |
| gouthamr | vponomaryov1: "to_be_denied" or "to_deny" better? | 20:15 |
| bswartz | personally I don't like mixing these 2 things, but it may be more complicated to split the 1 state machine into 2 state machines | 20:15 |
| vponomaryov1 | gouthamr: I would say "scheduled" is the right word here to use | 20:16 |
| vponomaryov1 | gouthamr: it is exactly what is going on in this case | 20:16 |
| gouthamr | vponomaryov1: scheduled, how? | 20:16 |
| gouthamr | vponomaryov1: "deny" is an equivalent of "new" | 20:16 |
| vponomaryov1 | gouthamr: "scheduled_for_deletion"? | 20:17 |
| gouthamr | vponomaryov1: in the access_deny path | 20:17 |
| bswartz | gouthamr: I think he means queued | 20:17 |
| bswartz | queued_for_delete/deny | 20:17 |
| vponomaryov1 | bswartz: is there specific diff between queued and scheduled? | 20:17 |
| bswartz | vponomaryov: the words have subtly different meanings but in this case it's not too relevant -- queued is just a shorter word | 20:18 |
| gouthamr | vponomaryov1 bswartz: yes, "scheduled" conflicts with "scheduler" | 20:18 |
| *** xyang_ has joined #openstack-manila | 20:18 | |
| bswartz | also, "scheduled" implies "will happen at a specific future time" where "queued" implies" will happen as soon as possible" | 20:19 |
| gouthamr | vponomaryov1 bswartz: how about changing "new" to "queued_to_apply" and "deny" to "queued_to_deny" | 20:19 |
| vponomaryov1 | gouthamr: i like it | 20:19 |
| tbarron | gouthamr: I just added my +2, but IMO it would be better to avoid both the word 'scheduled' (for reasons just stated) and queued. | 20:19 |
| tbarron | gouthamr: I misunderstood the intent of the latter word in an earlier review round, as I thought it implied order where it doesn't (in this case). | 20:20 |
| gouthamr | tbarron: :P yes, not really an ordered thing for the word "queue" | 20:20 |
| tbarron | gouthamr: it's more like "deferred" | 20:21 |
| bswartz | gouthamr: I don't have a strong opinion other than the behavior | 20:21 |
| tbarron | gouthamr: but at this point I don't mind the word "queued" (better than "scheduled") | 20:21 |
| bswartz | the words don't matter as much as the behavior -- we can come in at the end of the implementation phase and change the names | 20:21 |
| tbarron | you can queue up a batch at depth one | 20:21 |
| vponomaryov1 | so, everyone agreee to gouthamr proposal? | 20:22 |
| tbarron | bswartz: my +2 on that spec is sticky at this point :) | 20:22 |
| tbarron | vponomaryov1: +2 from me | 20:22 |
| *** catintheroof has quit IRC | 20:22 | |
| bswartz | okay | 20:22 |
| gouthamr | tbarron: lol, too bad you have to enforce sticky manually | 20:23 |
| tbarron | gouthamr: I was hoping if I mentioned it to bswartz he'd just remember it's there :) | 20:23 |
| bswartz | I feel okay about that spec, I feel enough thought has gone into it that we're arguing about minor details | 20:25 |
| vponomaryov1 | bswartz: sometimes, proper naming is not "minor" thing | 20:25 |
| bswartz | vponomaryov1: I agree it's something that's important to get right, but it something that's easy to change | 20:26 |
| vponomaryov1 | bswartz: especially when we already agreed )) | 20:27 |
| bswartz | well we can agree now | 20:28 |
| bswartz | on state names | 20:28 |
| bswartz | vponomaryov: did you post comments in the spec on the ones you want to change? | 20:28 |
| bswartz | let's do that and push another patchset and go from there | 20:29 |
| bswartz | gouthamr: https://review.openstack.org/#/c/396255/ | 20:32 |
| gouthamr | bswartz: will look and worflow | 20:32 |
| *** xyang_ has quit IRC | 20:33 | |
| openstackgerrit | Merged openstack/manila-specs: Add spec for enable IPv6 in manila https://review.openstack.org/362786 | 20:35 |
| tbarron | bswartz: what tool did you use to make that state diagram? vi to write DOT? | 20:35 |
| *** catintheroof has joined #openstack-manila | 20:35 | |
| bswartz | tbarron: yeah graphviz is a very simple language to learn | 20:35 |
| bswartz | tbarron: the docs are excellent | 20:35 |
| *** xyang_ has joined #openstack-manila | 20:36 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila-specs: Add a spec to fix and improve Access Rules https://review.openstack.org/399049 | 20:38 |
| tbarron | If I had been here at the beginning I would have argued that we should not have called our access apis allow and *deny* but rather allow and *delete*. | 20:44 |
| tbarron | Our "deny" deletes a rule. | 20:45 |
| tbarron | In the world of packet access rules "denies" instert a bitmask, just like allows do, but with drop or reject type actions. | 20:45 |
| tbarron | so people with networking backgrounds can get confused too easily by our access lists. | 20:46 |
| tbarron | ours are simpler, order doesn't matter, and I think adequate. | 20:46 |
| bswartz | tbarron: the semantics of the API were quite different originally | 20:46 |
| bswartz | allow/deny made sense in the original context | 20:46 |
| tbarron | bswartz: sure, my remarks are pretty much parenthetical at this point in our history. | 20:47 |
| tbarron | so in the original context I might not have made the argument that I say I would have :) | 20:47 |
| tbarron | gouthamr: my +2 "stuck" | 20:48 |
| gouthamr | tbarron: :) | 20:48 |
| * bswartz pours cyanoacrylate on tbarron's +2 buton | 20:49 | |
| tbarron | hey, while you guys are here, i'm looking at removing the nova network plugins since they are no longer generally supported: http://docs.openstack.org/releasenotes/nova/unreleased.html | 20:54 |
| tbarron | and was wondering what sort of api compatability or not we want to keep for share net creation and modification. | 20:54 |
| *** Yogi1 has joined #openstack-manila | 20:54 | |
| tbarron | share net creation and modification allow an optional nova-network argument. | 20:55 |
| gouthamr | tbarron: we can't maintain backwards compatibility for that argument | 20:55 |
| tbarron | which won't work in ocata most likely | 20:55 |
| tbarron | gouthamr: so can we just drop it with a microversion bump and have lower versions print a warning that it won't work starting in ocata (or earlier) ? | 20:56 |
| gouthamr | bswartz: i found a possible mistake in your state transition diagram, will all of you get pissed if i -1 :P | 20:56 |
| bswartz | gouthamr: mention it here | 20:56 |
| gouthamr | bswartz: replication_change is for promoting replicas | 20:57 |
| bswartz | I wouldn't be at all surprised if it's not completely accurate | 20:57 |
| bswartz | gouthamr: oh duh | 20:57 |
| tbarron | gouthamr: bswartz if you have to fix it, maybe just put in the pointer to devref and put the diagram there? | 20:57 |
| gouthamr | bswartz: yeah, no biggie, i don't like that state transition diagram in the specs anyway.. i would like the correct version in the devref | 20:57 |
| bswartz | yeah the diagram will evolve over time as we add states and we'll probably find bugs and fix them over time | 20:57 |
| gouthamr | bswartz: it's nice to see for now | 20:57 |
| gouthamr | :) | 20:57 |
| bswartz | to let's not notpick the actual state diagram | 20:57 |
| tbarron | yeah, having it in the doc sets a good example to start us off with, but a pointer will work better going forwards | 20:58 |
| bswartz | gouthamr: remind me what state changes occurs when a replica is added | 20:58 |
| gouthamr | bswartz: none, | 20:58 |
| bswartz | k | 20:59 |
| *** porrua has quit IRC | 20:59 | |
| gouthamr | bswartz: the share has no status of its own.. it's the share instance, and that aggregation matters a lot, currently | 20:59 |
| bswartz | gouthamr: yeah I realized that as I was writing the doc | 21:00 |
| bswartz | and I couldn't think of a clear way to express the relationships | 21:00 |
| bswartz | the correct thing would be to document the stare instance state machine and separate document how share state is computed from that | 21:00 |
| openstackgerrit | Victoria Martinez de la Cruz proposed openstack/manila-image-elements: Enables end user to pick share protocol https://review.openstack.org/400411 | 21:01 |
| openstackgerrit | Victoria Martinez de la Cruz proposed openstack/manila-image-elements: Removes LXC/LXD support on manila-image-elements https://review.openstack.org/405629 | 21:01 |
| openstackgerrit | Victoria Martinez de la Cruz proposed openstack/manila-image-elements: Adds support for NFS Ganesha https://review.openstack.org/411500 | 21:01 |
| gouthamr | bswartz: +1 - when we move that to the devref, we can.. that's a good starting point though. | 21:01 |
| bswartz | gouthamr: the problem is that what I just mentioned would be hard to process mentally | 21:02 |
| gouthamr | bswartz: if you have the share instance instead of the share? | 21:06 |
| openstackgerrit | Merged openstack/manila-specs: Mechanism to Prevent Race Conditions Spec https://review.openstack.org/396255 | 21:06 |
| bswartz | gouthamr: then you'd only have half the picture | 21:07 |
| tbarron | gouthamr: on the nova-net thing we have to bump the microversion when we drop that arg to share net create and modify, right? | 21:16 |
| bswartz | tbarron: yes | 21:16 |
| tbarron | gouthamr: if we do that, do we just leave old microversions as they are and let them break with ocata? | 21:16 |
| gouthamr | tbarron: i fear that would be the case | 21:16 |
| bswartz | tbarron: old microversions continue to accept the parameter, you just get an error | 21:17 |
| gouthamr | tbarron: what is your database upgrade like? | 21:17 |
| tbarron | bswartz: gouthamr or do we put a warning message in there with the old microversions? | 21:17 |
| tbarron | gouthamr: it would just be to drop that column on upgrade and add the column on downgrade | 21:17 |
| gouthamr | tbarron: we should fail the API rather than silently ignoring... because we need to make sure that the share network is usable | 21:17 |
| tbarron | gouthamr: no attempt to populate the field | 21:17 |
| bswartz | tbarron: warnings aren't communicated through the API -- any warning would go in the log files and the release notes | 21:18 |
| tbarron | ok, so client side is just bump microversion and drop the nova-net argument. | 21:18 |
| gouthamr | tbarron: iirc we should fail the database upgrade | 21:18 |
| gouthamr | tbarron: and ask administrators to cleanup share networks that have nova-network in them | 21:19 |
| tbarron | api side is just fail if the argument is supplied | 21:19 |
| bswartz | gouthamr: without a clean rollback path, failing the upgrade is dangerous | 21:19 |
| bswartz | you could be left in a state where the code and the schema can't work together | 21:19 |
| tbarron | DB upgrade: if share networks have non-null nova-network field, ... | 21:19 |
| tbarron | I could keep the DB schema for a release or more and just not use that field. | 21:20 |
| bswartz | whose +2 are we missing on gouthamr's spec | 21:21 |
| tbarron | don't populate it from the api, remove the nova net plugin and no one consumes the field. | 21:21 |
| bswartz | oh, nobody's | 21:21 |
| gouthamr | bswartz: everyone's at this point | 21:21 |
| gouthamr | :P | 21:21 |
| bswartz | just we got +1s from xyang and vponomaryov | 21:21 |
| gouthamr | except Tom's sticky | 21:21 |
| bswartz | gouthamr: it's late enough that we're not going to get some people | 21:21 |
| bswartz | I'll just diff PS16 and P18 | 21:22 |
| bswartz | crap that's a lot of diff | 21:22 |
| gouthamr | xyang_ vponomaryov markstur toabctl ganso: https://review.openstack.org/#/c/399049/ | 21:22 |
| tbarron | that's what I did | 21:22 |
| gouthamr | oh, i see ganso's comment saying he'll workflow it tonight | 21:22 |
| gouthamr | cknight: https://review.openstack.org/#/c/399049/ | 21:22 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/manila-image-elements: Updated from global requirements https://review.openstack.org/411506 | 21:23 |
| * tbarron confesses he didn't look at the sphinx output this last patch | 21:23 | |
| *** lseki has quit IRC | 21:30 | |
| openstackgerrit | Merged openstack/manila-image-elements: Updated from global requirements https://review.openstack.org/411506 | 21:47 |
| *** dustins has quit IRC | 21:48 | |
| bswartz | cknight, ganso: one more PS https://review.openstack.org/#/c/399049/18 | 21:50 |
| ganso | bswartz: I am reviewing at this moment | 21:50 |
| ganso | bswartz: s/reviewing/reviewing it | 21:51 |
| bswartz | k I'm headed out for a few, be back later | 21:51 |
| *** cknight has quit IRC | 21:51 | |
| *** eharney has quit IRC | 21:52 | |
| openstackgerrit | Merged openstack/manila-specs: Add a spec to fix and improve Access Rules https://review.openstack.org/399049 | 22:00 |
| ganso | gouthamr: ^ | 22:01 |
| markstur | </spec_cram_day> | 22:02 |
| *** xyang_ has quit IRC | 22:04 | |
| gouthamr | ganso: :) thanks | 22:04 |
| *** ianychoi has joined #openstack-manila | 22:04 | |
| *** Yogi1 has quit IRC | 22:16 | |
| *** gouthamr has quit IRC | 22:16 | |
| *** vponomaryov1 has left #openstack-manila | 22:21 | |
| *** tpsilva has quit IRC | 22:21 | |
| *** ianychoi has quit IRC | 22:38 | |
| *** tommylikehu_ has joined #openstack-manila | 22:40 | |
| *** tommylikehu_ has quit IRC | 22:42 | |
| *** cknight has joined #openstack-manila | 22:43 | |
| *** ianychoi has joined #openstack-manila | 22:44 | |
| openstackgerrit | Merged openstack/manila: Setting up a development env with devstack instructions https://review.openstack.org/408275 | 22:44 |
| *** catintheroof has quit IRC | 22:46 | |
| *** xyang_ has joined #openstack-manila | 22:53 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/manila: Updated from global requirements https://review.openstack.org/411065 | 22:54 |
| *** xyang_ has quit IRC | 22:55 | |
| *** xyang_ has joined #openstack-manila | 23:01 | |
| *** xyang_ has quit IRC | 23:02 | |
| *** tommylikehu_ has joined #openstack-manila | 23:07 | |
| *** tommylikehu_ has quit IRC | 23:12 | |
| *** catintheroof has joined #openstack-manila | 23:17 | |
| *** catintheroof has quit IRC | 23:17 | |
| *** catintheroof has joined #openstack-manila | 23:18 | |
| *** cdelatte has quit IRC | 23:55 | |
| *** harlowja has joined #openstack-manila | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!