| *** markstur has joined #openstack-manila | 00:51 | |
| openstackgerrit | Goutham Pacha Ravi proposed openstack/manila master: [DevRef] Add code review guideline https://review.openstack.org/609598 | 00:58 |
|---|---|---|
| *** erlon has joined #openstack-manila | 01:37 | |
| *** ianychoi has quit IRC | 02:10 | |
| *** ianychoi has joined #openstack-manila | 02:10 | |
| *** toabctl has quit IRC | 02:19 | |
| *** toabctl has joined #openstack-manila | 02:23 | |
| *** erlon has quit IRC | 04:08 | |
| *** markstur has quit IRC | 04:15 | |
| *** markstur has joined #openstack-manila | 05:07 | |
| *** markstur has quit IRC | 06:10 | |
| *** e0ne has joined #openstack-manila | 06:24 | |
| *** e0ne has quit IRC | 06:44 | |
| *** e0ne has joined #openstack-manila | 06:48 | |
| *** e0ne has quit IRC | 07:07 | |
| *** pcaruana has joined #openstack-manila | 07:36 | |
| *** luizbag has joined #openstack-manila | 09:19 | |
| openstackgerrit | Nguyen Hai Truong proposed openstack/manila master: Add python 3.6 unit test job https://review.openstack.org/615796 | 09:21 |
| *** ganso has joined #openstack-manila | 09:53 | |
| *** erlon has joined #openstack-manila | 10:24 | |
| *** e0ne has joined #openstack-manila | 11:11 | |
| ganso | tbarron: good morning Tom! | 11:41 |
| ganso | tbarron: I replied to your comment in https://review.openstack.org/#/c/391805 | 11:41 |
| ganso | tbarron: also, if you please explain in more detail your comment in https://review.openstack.org/#/c/609537/ | 11:43 |
| ganso | tbarron: I am not sure I understand it clearly | 11:43 |
| ganso | gouthamr: Jens Harbott just sent an email to the mailing list about neutron migration to Bionic Beaver | 12:15 |
| *** erlon has quit IRC | 12:19 | |
| *** e0ne has quit IRC | 12:29 | |
| *** e0ne has joined #openstack-manila | 12:43 | |
| tbarron | ganso w.r.t. 391805 I think your spec ought to explain that it's essentially an already-approved-spec in newton, authored by someone else. So far as I can see it has nop mention of the original spec. | 13:15 |
| ganso | tbarron: it wasn't approved in newton | 13:15 |
| ganso | tbarron: it never received +2s, never merged | 13:15 |
| tbarron | ganso: I'm looking at https://review.openstack.org/#/c/323646, isn't that the original for your spec? | 13:18 |
| tbarron | ganso: your spec doesn't even mention it though they are the same except for e.g. the work assignee and a few small changes | 13:19 |
| ganso | tbarron: wth I am confused now. Why did gouthamr ever propose https://review.openstack.org/#/c/391805/1 ? | 13:19 |
| ganso | tbarron: I was pushing patchsets to a change gouthamr proposed | 13:20 |
| tbarron | ganso: because I think we never implemented 323646? He was trying to carry it forward? | 13:21 |
| ganso | tbarron: this is weird, an already approved spec shouldn't need another spec to carry it forward (unless it needs updates) | 13:21 |
| ganso | tbarron: let me compare the text | 13:22 |
| tbarron | ganso: at least you see where I'm coming from now, right? | 13:22 |
| ganso | tbarron: yes | 13:22 |
| tbarron | ganso: cool | 13:22 |
| tbarron | ganso: on the other subject for a sec | 13:22 |
| tbarron | https://review.openstack.org/#/c/609537/ | 13:23 |
| tbarron | I think it's a well-written spec but I worry about it hard coding a particular "efficiency policy" in the scheduler. | 13:23 |
| tbarron | It's a reasonable policy, but may not be what every cloud admin wants. | 13:24 |
| ganso | tbarron: yes, this is why I listed an alternative. I thought about this and we could have a discussion to have the alternative become the main proposal | 13:24 |
| tbarron | So I'm suggesting that we may want to consider making these policies configurable. | 13:24 |
| tbarron | I don't know that my suggestion would be the best way, but one way might be to have the list of possible destination pools/backends associate each of these | 13:25 |
| tbarron | with a weight and a max capacity | 13:25 |
| ganso | tbarron: so the "Control the placement optimization by back end" alternative would become the main proposal, which is just add a boolean config option to driver.py to say "prefer_same_pool" | 13:25 |
| tbarron | (I think this is a design pattern, not my immediate invention) | 13:25 |
| ganso | tbarron: hmmmmmm this is a bit similar to the string value of "create_share_from_snapshot_in_other_backends" | 13:26 |
| tbarron | If all the weights and max capacities are the same then we have a "spread it out" policy. | 13:26 |
| ganso | tbarron: which is the "replication_group" idea borrowed from the replication design. The string value would allow the scheduler to indentify compatible backends | 13:26 |
| tbarron | If local pool has high weight and no capacity limit and the others have some lower weight or lower capacity then we have policies more like what you hard-code | 13:27 |
| ganso | tbarron: hmmm so you want to "spread it out" only if it is the same? it will hardly ever be "exactly the same" | 13:27 |
| tbarron | ganso: yeah, I'm suggesting that the string value might be turned into a list of tuples | 13:27 |
| tbarron | backend, pool, weight, max cap | 13:28 |
| tbarron | a list of those | 13:28 |
| ganso | tbarron: the list of tuples may require more maintenance from the admin, to add a new backend to the list every time a new backend is added. In this case, it would actually need adding new backends to the list of all stanzas. While the string being the same accomplishes the same thing without requiring maintenance | 13:28 |
| tbarron | but anyways I tend to agree that the policy aspect of that spec may need some discussion | 13:29 |
| tbarron | ganso: no question that hard-coding the policy would require less of the cloud admin | 13:29 |
| ganso | tbarron: no no I meant the string value of create_share_from_snapshot_in_other_backends | 13:30 |
| tbarron | but perhaps there could be default values that yield something like your hard-cocde policy | 13:30 |
| tbarron | ganso: I think I understand: using the simple string value for create_share_from_snapshot_in_other_backends is simpler than | 13:30 |
| tbarron | having weights and max_cap for each item in the set that this string selects | 13:31 |
| tbarron | I agree that it's simpler. | 13:31 |
| tbarron | But may not yield the result that the cloud admin wants. | 13:31 |
| ganso | tbarron: what you are suggesting is something smart that depending on weight, capacity decides whether to create locally or spread it out, instead of being a flag on/off that determines a fixed behavior per backend | 13:31 |
| tbarron | ganso: right | 13:32 |
| tbarron | And I don't know what we should decide; it just seems an important thing to settle before approving and implementing this spec. | 13:32 |
| ganso | tbarron: ok, we would to discuss how that rule looks like. As to what would be the threshold weight and capacity values for the scheduler to decide differently | 13:33 |
| ganso | tbarron: s/would to discuss/would need to discuss | 13:33 |
| ganso | tbarron: ok, I will think more about it today and update the spec, promoting the alternative to main proposal | 13:34 |
| tbarron | ganso: agree. Offhand I would think max cap could be a percentage and weight could be a small integral scale. | 13:34 |
| ganso | tbarron: ok | 13:34 |
| ganso | tbarron: back to the replication spec, since the change gouthamr proposed was actually renaming the old spec, there would not be an old spec to reference | 13:35 |
| ganso | tbarron: in that case, what should we do? drop this change and consider it approved? or merge the updated? can we consider it already approved then? | 13:36 |
| *** zul has joined #openstack-manila | 13:47 | |
| *** eharney has joined #openstack-manila | 13:48 | |
| ganso | tbarron: just saw your comment in the patch | 13:49 |
| tbarron | ganso: I think you should follow the pattern in https://review.openstack.org/#/c/593391/ | 13:50 |
| tbarron | That doesn't require referring to the "other" patch since they are the same :) | 13:50 |
| tbarron | You can then propose a small change to it putting you as the implementer, etc. | 13:51 |
| ganso | tbarron: ok, so I just move them and keep everything the same as the original | 13:51 |
| ganso | tbarron: ok | 13:51 |
| tbarron | ganso: that way it will be clear that this is essentially already approved and people won't have to compare (as I did, and you just did) with the original off in some oter place | 13:52 |
| ganso | tbarron: agree, will make the changes. Thanks Tom! | 13:52 |
| tbarron | thank you! | 13:53 |
| *** kaisers has quit IRC | 14:04 | |
| *** kaisers has joined #openstack-manila | 14:10 | |
| *** dustins has joined #openstack-manila | 14:12 | |
| *** erlon has joined #openstack-manila | 14:55 | |
| *** e0ne has quit IRC | 15:06 | |
| *** markstur has joined #openstack-manila | 15:51 | |
| arne_wiebalck | Hi Manila, could someone update me on what the status/plan is for adding manila to the common openstack client? | 16:21 |
| gouthamr | arne_wiebalck: slated for Stein, i'm coordinating the work | 16:22 |
| arne_wiebalck | gouthamr: uh, nice! | 16:22 |
| gouthamr | arne_wiebalck: we should have the code upstream by M2 | 16:23 |
| *** erlon has quit IRC | 16:25 | |
| arne_wiebalck | gouthamr: great, thx! | 16:28 |
| openstackgerrit | Quique Llorente proposed openstack/puppet-manila master: Install python3-manila in Fedora or RedHat > 7 https://review.openstack.org/615932 | 16:33 |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Add spec for Manage-Unmanage of Share Servers https://review.openstack.org/607342 | 16:40 |
| ganso | tbarron: addressed your concerns on 607342, will work on the others now | 16:46 |
| *** erlon has joined #openstack-manila | 16:52 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Move approved spec to Stein https://review.openstack.org/391805 | 16:56 |
| ganso | tbarron: ^ part 1 | 16:57 |
| *** erlon has quit IRC | 17:03 | |
| openstackgerrit | Rodrigo Barbieri proposed openstack/manila-specs master: Improvements to spec "Extend the design of share networks to span subnets" https://review.openstack.org/615947 | 17:09 |
| ganso | tbarron: ^ part 2 | 17:09 |
| *** e0ne has joined #openstack-manila | 17:32 | |
| *** e0ne has quit IRC | 18:03 | |
| *** e0ne has joined #openstack-manila | 18:06 | |
| bswartz | tbarron gouthamr ganso: can we get together this afternoon for a bit to discuss https://review.openstack.org/#/c/391805/ | 18:09 |
| ganso | bswartz: yep, I am free, waiting for tbarron and gouthamr | 18:10 |
| *** e0ne has quit IRC | 18:24 | |
| *** ociuhandu has joined #openstack-manila | 18:42 | |
| *** ociuhandu has quit IRC | 18:45 | |
| *** dustins has quit IRC | 18:59 | |
| *** dustins has joined #openstack-manila | 18:59 | |
| gouthamr | ganso bswartz: late ack, i can get on a call with you folks, tbarron is OOO today | 19:08 |
| ganso | bswartz, gouthamr: I only have a few minutes left | 19:09 |
| ganso | bswartz, gouthamr: we can start the meeting but then I'll have to leave | 19:10 |
| gouthamr | oh, tomorrow looks good too - tbarron'll be on and off tomorrow and day after, but is really on PTO for the next three weeks, barring his participation at the Berlin Summit | 19:10 |
| ganso | :O | 19:11 |
| *** luizbag has quit IRC | 19:15 | |
| *** markstur has quit IRC | 19:17 | |
| *** markstur has joined #openstack-manila | 19:39 | |
| *** markstur has quit IRC | 19:40 | |
| *** markstur has joined #openstack-manila | 19:40 | |
| bswartz | So should we just meet the 3 of us and bring tbarron up to speed later? | 19:44 |
| bswartz | Should use use the thursday meeting to get into detail on this topic? | 19:44 |
| bswartz | Other options include trying to get a time extension for this spec if we really want to see it land in Stein, or just giving up on meeting the Stein deadline, but continuing to flesh out the proposal for the "T" release | 19:51 |
| gouthamr | bswartz: either works for me.. i haven't looked at ganso's changes deeply, but if there are major concerns, it'd be nice to flush them out right away | 19:54 |
| ganso | bswartz: based on today's discussion with tbarron where we acknowledged that the Replication in DHSS=True spec was approved in Newton, I suppose we can consider it already approved for Stein as is. So the multi-address family improvement would need another approval I guess | 19:54 |
| bswartz | Oh that distinction | 20:30 |
| bswartz | Yes we can separately consider the multi-AZ changes from the multiple-subnets in one AZ changes, but I don't advise it | 20:30 |
| bswartz | There's a reason we kept punting on this work and trying to converge on a perfect design | 20:31 |
| bswartz | If you don't consider both cases you might design yourself into a corner | 20:31 |
| *** mmethot_ is now known as mmethot | 20:38 | |
| bswartz | ganso gouthamr: ^ | 20:38 |
| *** pcaruana has quit IRC | 21:31 | |
| *** dustins has quit IRC | 22:11 | |
| *** ganso has quit IRC | 22:51 | |
| *** erlon has joined #openstack-manila | 23:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!