| *** erlon has joined #openstack-manila | 00:03 | |
| openstackgerrit | Nguyen Hai Truong proposed openstack/manila master: [Trivial Fix] Correct spelling error of "throughput" https://review.openstack.org/615459 | 01:51 |
|---|---|---|
| *** erlon has quit IRC | 02:21 | |
| *** pcaruana has joined #openstack-manila | 05:23 | |
| *** pcaruana has quit IRC | 05:32 | |
| *** zul has quit IRC | 05:49 | |
| *** e0ne has joined #openstack-manila | 06:17 | |
| *** e0ne has quit IRC | 06:36 | |
| *** arne_wiebalck has quit IRC | 07:52 | |
| *** arne_wiebalck_ has joined #openstack-manila | 07:57 | |
| *** pcaruana has joined #openstack-manila | 08:06 | |
| *** e0ne has joined #openstack-manila | 09:10 | |
| *** pcaruana has quit IRC | 09:31 | |
| *** pcaruana has joined #openstack-manila | 09:32 | |
| *** luizbag has joined #openstack-manila | 09:41 | |
| *** ganso has joined #openstack-manila | 09:55 | |
| *** tpsilva has joined #openstack-manila | 11:31 | |
| *** erlon has joined #openstack-manila | 11:52 | |
| openstackgerrit | Merged openstack/manila master: [Trivial Fix] Correct spelling error of "throughput" https://review.openstack.org/615459 | 12:03 |
| *** e0ne_ has joined #openstack-manila | 12:37 | |
| *** e0ne has quit IRC | 12:40 | |
| *** zul has joined #openstack-manila | 13:16 | |
| *** dustins has joined #openstack-manila | 14:03 | |
| *** jiaopengju has quit IRC | 15:14 | |
| *** jiaopengju has joined #openstack-manila | 15:14 | |
| *** arne_wiebalck_ is now known as arne_wiebalck | 15:57 | |
| *** markstur has joined #openstack-manila | 16:06 | |
| *** pcaruana has quit IRC | 16:06 | |
| *** e0ne_ has quit IRC | 16:36 | |
| *** openstackgerrit has quit IRC | 16:48 | |
| *** e0ne has joined #openstack-manila | 17:57 | |
| *** jmlowe has quit IRC | 18:30 | |
| ganso | gouthamr, tbarron: ping | 18:30 |
| tbarron | ganso pong | 18:31 |
| ganso | tbarron: hey Tom! | 18:31 |
| tbarron | hi | 18:31 |
| ganso | tbarron: I am not sure if you had the specs yet | 18:31 |
| ganso | tbarron: but I would like to discuss the Replication one in more detail, because there is a very important detail we missed during our PTG discussion | 18:32 |
| tbarron | ganso: I *have* them, I just am swamped with a lot of work, trying to get to them | 18:32 |
| ganso | tbarron: is it ok for you to discuss it right now? | 18:32 |
| tbarron | ganso: go ahead, at least pose the question/issue | 18:33 |
| tbarron | but honestly I know less about replication than bswartz and gouthamr :) | 18:34 |
| ganso | tbarron: at the PTG we discussed the Replication spec update, from what gouthamr had already composed, to an update I proposed that would allow share servers to serve IPv4+IPv6 export locations at the same time | 18:34 |
| ganso | tbarron: I had a meeting with bswartz on friday in which we discussed the details of that spec, and bswartz noticed that with the change I was proposing, I would need to send more than 1 subnet to the driver to create network allocations when creating the share server | 18:36 |
| ganso | tbarron: in other words, if the driver says it needs 2 allocations (for instance, because it has 2 nodes), we would need to send 4 allocations, 2 per subnet | 18:36 |
| ganso | tbarron: the problems is, all drivers that support DHSS=True are currently wired to receive only 1 subnet | 18:37 |
| ganso | tbarron: I've been thinking a lot, and it seems there is no way to implement the change I am proposing without breaking existing implementations, or leading to a bad user experience when running outdated drivers | 18:38 |
| tbarron | ganso: ouch | 18:39 |
| ganso | tbarron: outdated drivers = drivers that wouldn't have caught up with the supposedly merged change | 18:39 |
| ganso | tbarron: So, taking a step back | 18:40 |
| tbarron | ganso: so the core change would be OK if you could change all the drivers too, but ... (step back) | 18:40 |
| ganso | tbarron: yes | 18:41 |
| ganso | tbarron: gouthamr probably had this in mind when he first wrote the spec | 18:41 |
| ganso | tbarron: by reverting the spec to his original proposal (without my changes), we could have Replication in DHSS=True, with the same IPv4 and IPv6 limitations we have today | 18:41 |
| ganso | tbarron: and it wouldn't break the existing drivers | 18:41 |
| ganso | tbarron: it is far from what we would like multi-subnet share servers to be | 18:42 |
| ganso | tbarron: but the limitations exist today, and they would continue to exist | 18:42 |
| ganso | tbarron: except that we could still have Replication in DHSS=True | 18:42 |
| tbarron | and when you have replication with DHSS=False you would have multi-address family support though, right? | 18:44 |
| ganso | tbarron: this all started when we introduced IPv6 support, and we probably imagined that we would like to someday have share servers serving both IPv4+IPv6 but we cannot get there without impacting the existing drivers. | 18:44 |
| ganso | tbarron: in DHSS=False you can have anything you want =) | 18:44 |
| tbarron | ganso: from a product standpoint is it worthwhile to support replication with single addr family limitation? | 18:46 |
| tbarron | ganso: and is there a good migration path from there? | 18:46 |
| ganso | tbarron: I will have to double check with my customer if it solves tthe use case with this limitation. Otherwise, probably not worth it | 18:46 |
| tbarron | ganso: Presumably in this cycle you would only be implementing this for Netapp and for an OpenSource reference driver, right? | 18:47 |
| tbarron | Which of the latter, zfs? | 18:47 |
| ganso | tbarron: either ZFS or Container | 18:47 |
| ganso | tbarron: but it wouldn't break anything with other drivers | 18:47 |
| tbarron | ganso: yeah, better not :) | 18:48 |
| ganso | tbarron: so what is your opinion on this? | 18:49 |
| tbarron | ganso: How many of the DHSS=True back ends are going to eventually want to change their interface even if they don't support replication? | 18:49 |
| ganso | tbarron: we have no idea | 18:49 |
| tbarron | ganso: In your shoes I think that I'd want a migration path at least to dual address family with replicaiton so that my | 18:50 |
| ganso | tbarron: there doesn't seem to be any interest on investing it (at least right now) | 18:50 |
| ganso | s/investing it/investing on it | 18:50 |
| tbarron | customers don't have to make a tradeoff forever between running single address only plus replicatioon or | 18:50 |
| tbarron | mutli-address family without | 18:51 |
| ganso | tbarron: they are already making this tradeoff, since we introduced IPv6 | 18:51 |
| ganso | tbarron: before we had IPv6, customers wanted IPv6 and Replication in DHSS=True | 18:51 |
| gouthamr | multi-family support needs to be baked in separately anyway, with a migration path, since right now you can only pick ipv4 or ipv6 but not both with DHSS=True | 18:51 |
| ganso | tbarron: then we implemented IPv6, and customers still want Replication in DHSS=True, and multi-address family share servers. We can deliver just Replication in DHSS=True. | 18:52 |
| tbarron | ganso: no becasuse their tradeoff currenty is between DHSS=False with replication and multiaddr vs DHSS=True w/o replication | 18:52 |
| tbarron | but with multi-addr | 18:52 |
| tbarron | ah, not with multi-addr | 18:53 |
| tbarron | family | 18:53 |
| tbarron | one or other in DHSS=True | 18:53 |
| ganso | tbarron: but customers that are already tied with DHSS=True because of its advantages don't have replication | 18:53 |
| *** jmlowe has joined #openstack-manila | 18:53 | |
| ganso | gouthamr: yep, it would be easy to kill 2 birds with one stone if we had all the driver maintainers involved | 18:54 |
| ganso | tbarron: I was aiming for that ^ | 18:55 |
| ganso | gouthamr, tbarron: but it still doesn't prevent us from doing this incrementally | 18:55 |
| ganso | tbarron: we could even separate the multi-address improvement to another spec, and it would be less work | 18:55 |
| tbarron | ganso: well it seems like you have to; the question as you say it makes sense for you since you are currently the only dhss=True back end that is interested | 18:56 |
| ganso | gouthamr, tbarron: if you are onboard with that, I would like to go ahead (or back actually? xD) with this | 18:56 |
| tbarron | gouthamr: what do you think? I'm inclined to think it's less risky for sure in that it doesn't impace any drivers that aren't doing it. | 18:58 |
| gouthamr | ack, i think it'd be the right thing to do | 18:58 |
| tbarron | gouthamr: bswartz: ganso: my main concern would be that if zfs or container breaks then someone will need to fix it. | 18:59 |
| tbarron | the more compexity we have in gate the more overhead we have with fewer maintainers | 18:59 |
| tbarron | at least they don't vote | 18:59 |
| *** openstackgerrit has joined #openstack-manila | 19:00 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila master: [LVM][IPv6] Quagga changes to support Bionic Beaver https://review.openstack.org/614802 | 19:00 |
| tbarron | like that stuff ^^^ :) | 19:01 |
| * gouthamr is still unsure what broke | 19:01 | |
| ganso | tbarron: indeed, since I would be the one implementing Replication DHSS=True in either Container or ZFS, I would be the one up to fix related breakages in the gate | 19:01 |
| tbarron | ganso: :) | 19:04 |
| * tbarron keeps irc logs | 19:04 | |
| ganso | tbarron: lol | 19:05 |
| ganso | tbarron, gouthamr, bswartz: alright, I'll make the change then | 19:05 |
| tbarron | gouthamr: any bright ideas on why all the ipv6 tests fail on the lvm job with https://review.openstack.org/#/c/615297/ ? | 19:08 |
| * tbarron is stumped | 19:08 | |
| gouthamr | tbarron: ^^ i still don't know, the address-scope issue seemingly went away with the neutronclient-->osc change, but looks like we can't reach ipv6 VMs now | 19:09 |
| ganso | gouthamr, tbarron: I saw the errors and I have no clue :( | 19:10 |
| tbarron | gouthamr: yup. I noted some neutron log tracebacks but dunno if they are related. | 19:10 |
| gouthamr | tbarron: so i rebased the quagga config changes on the devstack plugin "fix" to see if we'll see the same issue, if it doesn't fail, i'll squash these changes | 19:10 |
| tbarron | gouthamr: ok, I was thinking that would be worth a try. | 19:11 |
| gouthamr | yes, looked at neutronclient, neutron, neutron-dynamic-routing and neutron-lib for any red flags - only neutron seems to have a flurry of changes in teh past few days | 19:16 |
| *** luizbag has quit IRC | 19:16 | |
| *** tpsilva has quit IRC | 19:22 | |
| *** zul has quit IRC | 19:24 | |
| bswartz | 10 IF gate is broken THEN | 19:41 |
| bswartz | 20 blame neutron | 19:41 |
| bswartz | 30 GOTO 10 | 19:41 |
| bswartz | gouthamr: I looked at your change -- did OSC have a command syntax change or something? I thought the point of OSC was that it was stable | 19:42 |
| gouthamr | bswartz: nope, we were using neutronclient, which seems to have a problem | 19:42 |
| bswartz | Oh I see | 19:43 |
| bswartz | Yeah I remember now that these command didn't exist in OSC at the time which required using neutron client | 19:43 |
| gouthamr | yes | 19:44 |
| gouthamr | came in last cycle i suppose | 19:44 |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Extend the design of share networks to span subnets https://review.openstack.org/391805 | 19:57 |
| ganso | bswartz: ^ | 19:57 |
| *** jmlowe has quit IRC | 20:19 | |
| bswartz | ganso: I might be missing something but I think you ignored my comment | 20:34 |
| bswartz | ganso: Also I'm not sure I agree with the only-one-default-subnet restriction | 20:34 |
| *** jmlowe has joined #openstack-manila | 20:39 | |
| *** e0ne has quit IRC | 20:45 | |
| *** erlon has quit IRC | 21:13 | |
| *** e0ne has joined #openstack-manila | 22:02 | |
| *** e0ne has quit IRC | 22:05 | |
| *** markstur has quit IRC | 22:33 | |
| *** ganso has quit IRC | 22:48 | |
| *** dustins has quit IRC | 22:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!