| *** hoonetorg has quit IRC | 00:35 | |
| *** hoonetorg has joined #openstack-manila | 00:37 | |
| *** hoonetorg has quit IRC | 00:40 | |
| *** hoonetorg has joined #openstack-manila | 00:40 | |
| *** markstur has quit IRC | 02:38 | |
| openstackgerrit | Merged openstack/manila master: [LVM][IPv6] Quagga changes to support Bionic Beaver https://review.openstack.org/614802 | 03:27 |
|---|---|---|
| *** markstur has joined #openstack-manila | 04:08 | |
| *** markstur has quit IRC | 06:03 | |
| *** pcaruana has joined #openstack-manila | 07:20 | |
| *** pcaruana has quit IRC | 07:34 | |
| *** pcaruana has joined #openstack-manila | 07:40 | |
| *** e0ne has joined #openstack-manila | 09:24 | |
| *** a-pugachev has joined #openstack-manila | 09:34 | |
| *** a-pugachev has quit IRC | 09:34 | |
| *** a-pugachev has joined #openstack-manila | 09:39 | |
| *** ganso has joined #openstack-manila | 09:39 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Add spec for Manage-Unmanage of Share Servers https://review.openstack.org/607342 | 10:19 |
| openstackgerrit | Maurice Schreiber proposed openstack/manila master: [api-ref] Added share servers show and corrected path to details https://review.openstack.org/607170 | 10:34 |
| *** carthaca has joined #openstack-manila | 10:35 | |
| openstackgerrit | hulina proposed openstack/manila master: check all_tenants value in share_networks api https://review.openstack.org/618991 | 11:51 |
| openstackgerrit | Helen Walsh proposed openstack/manila master: VMAX manila doc - support for IPv6 https://review.openstack.org/612457 | 12:18 |
| openstackgerrit | Merged openstack/manila master: NeutronBindNetworkPlugin: fix multi segment neutron data save. https://review.openstack.org/593111 | 12:41 |
| openstackgerrit | Merged openstack/manila master: [CI][LVM] Run the LVM job on Bionic Beaver https://review.openstack.org/608761 | 14:12 |
| *** mmethot has quit IRC | 14:13 | |
| *** mmethot has joined #openstack-manila | 14:17 | |
| *** dustins has joined #openstack-manila | 14:30 | |
| *** carthaca has quit IRC | 15:05 | |
| *** carthaca has joined #openstack-manila | 15:07 | |
| *** carthaca2 has joined #openstack-manila | 15:07 | |
| *** carthaca2 has quit IRC | 15:07 | |
| *** e0ne has quit IRC | 16:21 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Create share from snapshots in another pool or back end https://review.openstack.org/609537 | 16:30 |
| *** luizbag has joined #openstack-manila | 16:39 | |
| *** markstur has joined #openstack-manila | 16:54 | |
| *** a-pugachev_ has joined #openstack-manila | 17:00 | |
| ganso | gouthamr: ping | 17:03 |
| *** a-pugachev has quit IRC | 17:04 | |
| *** a-pugachev_ is now known as a-pugachev | 17:04 | |
| *** a-pugachev has quit IRC | 17:17 | |
| *** e0ne has joined #openstack-manila | 17:31 | |
| *** luizbag has quit IRC | 17:36 | |
| *** e0ne has quit IRC | 17:44 | |
| *** e0ne has joined #openstack-manila | 17:57 | |
| *** markstur has quit IRC | 18:17 | |
| *** pcaruana has quit IRC | 18:47 | |
| gouthamr | ganso: pong | 18:56 |
| ganso | gouthamr: hey Goutham! | 18:57 |
| ganso | gouthamr: I updated my specs, hopefully adressing your feedback | 18:57 |
| *** markstur has joined #openstack-manila | 18:57 | |
| ganso | gouthamr: s/feedback/concerns | 18:57 |
| ganso | gouthamr: I am writing the "share server with multiple subnets" spec now | 18:57 |
| gouthamr | ganso: ty, i'll take a look sometime today - are we pushing any of these to "T"? or are you writing a different one? | 18:57 |
| ganso | gouthamr: when I finish and upload it, and I'll back to reviewing your specs | 18:57 |
| ganso | gouthamr: the only "T" spec I am proposing is "share server with multiple subnets" | 18:58 |
| gouthamr | ganso: okay, bswartz suggested a call to discuss these concerns if we're unable to sort this out in review | 18:59 |
| ganso | gouthamr: bswartz will return on monday I suppose | 18:59 |
| ganso | gouthamr: let's try to sort them out sooner if possible | 19:00 |
| gouthamr | ganso: ack, yeah.. attendance here will be dwindling everyday this week | 19:00 |
| gouthamr | ganso: i don't think you answered my concerns about "Create share from snapshots in another pool or back end" | 19:05 |
| gouthamr | ganso: I wasn't suggesting the use of the data-service as an alternative.. "However, any driver-specific optimizations that could allow the operation to be performed more efficiently between compatible drivers would not be able to be used." - I was suggesting its use as a supplement to fully resolve this issue.. | 19:06 |
| gouthamr | ganso: my concern is the complicated scheduling logic that seems almost like a one-off for this situation | 19:07 |
| ganso | gouthamr: what about it is complicated? | 19:10 |
| gouthamr | ganso: you're adding a post-weigher for starters.. which limits the way weighers currently work | 19:12 |
| gouthamr | ganso: you should be able to add multiple weighers that can work in any order, and if the admin wanted, they could skew the weighing by doing what bswartz proposed with his stochastic weigher | 19:13 |
| ganso | gouthamr: this behavior would only be intended for a "create_share_from_snapshot" method in the scheduler. The logic will be split from "create_share" | 19:14 |
| gouthamr | ganso: yes, i get that, that's one of the reasons i think this can be done in a more simple/straightforward manner, generically. | 19:18 |
| ganso | gouthamr: I don't think we should expose to users anything that could control this. Like a "--take-your-time" parameter or something like that. I believe it is something that should be smart in our end. | 19:20 |
| gouthamr | ganso: the spec says that administrators also need to tell us what the spread ratio is (backend_share_spread_required_discrepancy) - how would we expect them to know? | 19:20 |
| gouthamr | ganso: yes! it's unfortunate that we'd be exposing limits within a cloud, but as a user, i might expect all clones to be instantaneous | 19:21 |
| gouthamr | ganso: and with the proposal, some clones will be instantaneous and some others could take a long time | 19:22 |
| gouthamr | ganso: and there's no way for the end user/application to have any expectations | 19:22 |
| *** e0ne has quit IRC | 19:22 | |
| ganso | gouthamr: as the spec says, the administrator may not want to have all shares spread out to not lose so much COW efficiency, so it is something the administrator would need to tweak, like the over_provisoning_ratio... It does not really solve the use case of "I want to use this snapshot as an image so for this one I always want to spread out" as this is user-facing and the user shouldn't be concerned about that. For | 19:23 |
| ganso | that use case in particular (which my spec is not focused on), it may be better to use metadata | 19:23 |
| ganso | gouthamr: yes, there isn't, that's why at the default discrepancy value the source pool will be preferred. And if it is to be created in another AZ (which is one important use cases to address IMO), then it is completely understandable to take longer, as the user will have specified an additional parameter that results in that | 19:25 |
| gouthamr | the user won't be thinking about spreading out their data - imo, they'd just want a "clone" and if the cloud can't do it efficiently, to let them know so - it is like level setting their expectations | 19:26 |
| gouthamr | ganso: yes, the AZ issue is currently a bug that we must fix | 19:27 |
| ganso | gouthamr: so in your proposal, when specifying a different AZ, the user would always have to specify "--take-your-time" ? | 19:28 |
| ganso | gouthamr: or else it will always result in the "this cannot be done efficiently, please specify --take-your-time" error, correct? | 19:28 |
| gouthamr | ganso: yes | 19:28 |
| ganso | gouthamr: ok, so the simpler approach I was thinking about before tbarron's feedback (you can check the earlier patchsets), I was thinking about always using the source pool unless a different AZ is specified. What do you think of that? | 19:29 |
| gouthamr | ganso: how about different backends in the same AZ? | 19:30 |
| gouthamr | s/how/what | 19:30 |
| ganso | gouthamr: in the example above it would always stick to the source pool if it is to be created in the same AZ | 19:31 |
| *** a-pugachev has joined #openstack-manila | 19:32 | |
| gouthamr | ganso: backtracking, theoretically the fastest would be to create the clone in the same pool, then across pools in the same backend, and then among homogeneous backends in the same AZ and then among homogenous backends in different AZs, and then heterogenous backends in the same AZ and finally heterogenous backends in different AZs | 19:34 |
| gouthamr | if manila were to actively consider the differences between homogenous and heterogenous backends, you'll evolve a replication design | 19:35 |
| ganso | gouthamr: yup that was my original proposal, considering "homogenous" only as "compatible". "heterogenous" could be accomplished with the data service | 19:35 |
| gouthamr | okay, i didn't read your spec back then, did you and bswartz discuss this offline? | 19:37 |
| gouthamr | he had similar concerns as i did, and was suggesting a call to give his opinion | 19:37 |
| ganso | gouthamr: yes, but bswartz really wanted a user-facing parameter like "--spread-please", even though users shouldn't know about this stuff. That is his first comment in gerrit | 19:38 |
| gouthamr | ganso: yeah, my concern was "time" more than spread | 19:39 |
| ganso | gouthamr: probably his suggestion changed a bit after I changed to include the discrepancy config option, as that was my approach for spreading, but then his following comment was about the snapshot as an image use case. Which I believe should not be within the scope of the spec | 19:39 |
| *** a-pugachev has quit IRC | 19:39 | |
| ganso | gouthamr: my original concern was as well. tbarron was concerned about having a configurable spread factor | 19:39 |
| gouthamr | ganso: i was thinking we can evolve this further by caching snapshots in multiple hosts | 19:39 |
| ganso | gouthamr: just to solve that use case? | 19:41 |
| gouthamr | ganso: nope, building this out in phases | 19:41 |
| ganso | gouthamr: I mean, as a different spec, perfect, in another phase, but unrelated to the current proposal | 19:41 |
| ganso | gouthamr: yep | 19:41 |
| gouthamr | ganso: can you schedule a call on monday with tbarron and bswartz and anyone else who would like to discuss | 19:43 |
| ganso | gouthamr: will tbarron be back from PTO? | 19:43 |
| gouthamr | ganso: lm check | 19:43 |
| gouthamr | ganso: he's back on 26th/Monday | 19:45 |
| ganso | gouthamr: ok perfect, I'll schedule the meeting | 19:46 |
| gouthamr | ganso: good stuff | 19:46 |
| ganso | gouthamr: are you going to be here from tomorrow to friday? | 19:46 |
| gouthamr | ganso: sparingly, tomorrow | 19:46 |
| ganso | gouthamr: ok | 19:46 |
| gouthamr | ganso: i'm here today... hey, i had a TripleO question for you | 19:46 |
| ganso | gouthamr: go ahead | 19:47 |
| gouthamr | ganso: did you guys certify manila/ontap/dhss=True on OSP13? | 19:47 |
| ganso | gouthamr: yes | 19:47 |
| gouthamr | ganso: okay, did you have any deployment issues, wrt neutron? | 19:48 |
| ganso | gouthamr: hmmm not really. We configured it like our CI is configured in MSVM jobs | 19:48 |
| ganso | gouthamr: since it doesn't run scenario tests, we didn't face problems | 19:49 |
| gouthamr | ganso: did you use the heat templates or manually configure on a deployed server? | 19:49 |
| ganso | gouthamr: heat templates | 19:49 |
| gouthamr | ganso: okay, ty.. i wonder what stage this got introduced: https://bugs.launchpad.net/puppet-manila/+bug/1802393 | 19:49 |
| openstack | Launchpad bug 1802393 in puppet-manila "THT deploys manila.conf with deprecated settings for neutron and nova" [Undecided,In progress] - Assigned to David Vallee Delisle (valleedelisle) | 19:49 |
| ganso | gouthamr: oh, I remember now, we may have used the standalone plugin. I don't remember for sure | 19:50 |
| gouthamr | ganso: ouch | 19:50 |
| gouthamr | :) | 19:50 |
| ganso | gouthamr: I didn't have that keystone problem | 19:50 |
| gouthamr | ganso: you wouldn't, if you used standalone | 19:50 |
| ganso | gouthamr: oooooooooohhhhhhh I remember the problem now | 19:51 |
| ganso | gouthamr: we had the network ccleanup problem | 19:51 |
| ganso | gouthamr: because of dynamic credentials | 19:51 |
| gouthamr | ganso: sure, but you'd've worked around that with using pre-provisioned creds? | 19:51 |
| ganso | gouthamr: if I recall correctly, I had to create manual credentials to disable dynamic creds | 19:52 |
| ganso | gouthamr: yes | 19:52 |
| ganso | gouthamr: then, that was one of the problems solved. So I don't remember if I really ended up using standalone or not. I tried many things, and in the end I may have reverted to not using standalone after I solved the dynamic creds problem | 19:52 |
| ganso | gouthamr: if you have access to the certification data we submitted, you could check the configuration | 19:53 |
| gouthamr | ganso: okay.. the problem in LP 1802393 is manila interacting with nova and neutron | 19:54 |
| openstack | Launchpad bug 1802393 in puppet-manila "THT deploys manila.conf with deprecated settings for neutron and nova" [Undecided,In progress] https://launchpad.net/bugs/1802393 - Assigned to David Vallee Delisle (valleedelisle) | 19:54 |
| ganso | gouthamr: if not I can check it for you tomorrow | 19:54 |
| ganso | gouthamr: I am running late now, gotta run | 19:54 |
| gouthamr | ganso: i don't have access to it, but would like to see the templates used if you do :) | 19:54 |
| gouthamr | ganso: yep.. no rush, tty tomorrow | 19:54 |
| *** a-pugachev has joined #openstack-manila | 20:18 | |
| *** ganso has quit IRC | 22:29 | |
| *** markstur has quit IRC | 23:16 | |
| *** dustins has quit IRC | 23:19 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!