Friday, 2019-05-10

*** mriedem has quit IRC00:06
*** tssurya has quit IRC01:03
*** cdent has quit IRC01:16
*** ttsiouts has joined #openstack-placement01:59
*** ttsiouts has quit IRC02:33
*** takashin has quit IRC04:08
*** takashin has joined #openstack-placement04:15
*** cdent has joined #openstack-placement04:29
*** ttsiouts has joined #openstack-placement04:30
*** ttsiouts has quit IRC05:02
*** cdent has quit IRC05:06
openstackgerritqian wang proposed openstack/osc-placement master: Modify tox.ini and README.rst Replace openstack.org URLs with opendev.org URLs  https://review.opendev.org/65827006:12
*** ttsiouts has joined #openstack-placement07:00
*** mcgigglier has joined #openstack-placement07:52
*** ttsiouts has quit IRC08:03
*** takashin has left #openstack-placement08:03
*** tssurya has joined #openstack-placement08:23
*** ttsiouts has joined #openstack-placement10:00
*** ttsiouts has quit IRC10:33
*** vdrok has quit IRC10:48
*** vdrok has joined #openstack-placement10:49
*** mkrai1 has joined #openstack-placement12:07
*** ttsiouts has joined #openstack-placement12:30
*** ttsiouts has quit IRC13:03
*** mriedem has joined #openstack-placement13:05
*** mcgigglier has quit IRC13:14
*** mcgiggler has joined #openstack-placement13:15
*** jaypipes has joined #openstack-placement13:32
*** mcgiggler has quit IRC13:58
*** ttsiouts has joined #openstack-placement15:00
*** ttsiouts has quit IRC15:34
*** cdent has joined #openstack-placement16:11
efriedcdent: about to head out for rolls, but - are you proposing patch for l-c bump to match u-c for os-traits and os-resource-classes? I'll want to rebase my test series on that, as you probably noticed.16:27
cdentyeah, I'm doing that right now16:28
efriedcoo, thx16:28
*** efried is now known as fried_rolls16:28
fried_rollso/16:28
openstackgerritChris Dent proposed openstack/placement master: Raise os-traits os-resource-classes constraints  https://review.opendev.org/65841916:44
openstackgerritChris Dent proposed openstack/osc-placement master: Dropping the py35 testing  https://review.opendev.org/65465217:06
*** tssurya has quit IRC17:37
klindgrenSo one thing - on moving to stein placement with pike nova/neutron we ran into is the DB migrate script, basically just does a mysql dump from the nova db of specific tables and imports those into the placement db.  But it assumes that the database is at the rocky level.  Which in our case or some other people may not be the case.  But placement in stein does not have any of the old DB migrations.  Thoughts on including the old db migrations17:51
klindgreninto placement, to make it so where we can upgrade older versions of placement db schemas?17:51
cdentklindgren: given you're in a bit of an edge case, I wouldn't us to have extraneous-to-most-people migrations in placement. What you might be able to do is use a copy of modern nova code to run migrations on a full duplicate of nova-api, and then from that duplicate copy to a placement db (with just the tables placement cares about)17:56
*** tssurya has joined #openstack-placement18:21
openstackgerritMerged openstack/os-traits master: Update SEV trait docs to avoid misleading people  https://review.opendev.org/65567118:22
*** fried_rolls is now known as efried18:52
klindgrenIt looks like the migrations for placement were actually pretty simple.18:56
klindgrenSo I just translated those into some simple mysql queries. To add the columns and index's.18:57
cdentklindgren: that's probably a better option. if you saved that away somewhere, we could point people to it18:58
klindgrenI do have it saved, still working on a getting a full ENV up and making sure I didn't possibly miss stuff.18:59
cdentwhen it stabilizes, maybe post a message to the mailing list describing what you did to make this fun and games go. I suspect other people would find it useful/interesting18:59
openstackgerritEric Fried proposed openstack/placement master: Add NUMANetworkFixture for gabbits  https://review.opendev.org/65746319:00
openstackgerritEric Fried proposed openstack/placement master: Gabbi test cases for can_split  https://review.opendev.org/65819219:00
*** dklyle_ has joined #openstack-placement19:02
*** david-lyle has quit IRC19:04
*** tssurya_ has joined #openstack-placement19:23
*** mriedem has quit IRC20:44
cdentIn case anyone cares, no pupdate today, and I'll be flying during the next scheduled meeting21:23
*** jaypipes has quit IRC21:24
*** jaypipes has joined #openstack-placement21:24
efriedI care, cdent. I care deeply.21:29
cdentthanks efried21:29
cdenti'll do an interim week-in-denver summary during the week next week21:29
cdentand then a monster pupdate come friday21:29
cdentassuming i haven't died from jetlag21:30
efriedsounds good. I think it will be useful to have a short list of 'most important' for placement teamers.21:30
cdentyes21:30
efriedI'm going to go write some more tests for nested magic.21:30
efriedAny preference what I go after next?21:31
cdentone mo21:31
cdentlooking at https://storyboard.openstack.org/#!/story/2005575 I don't think it really matters what comes next21:32
cdentgroup_policy changes fit well with your drawing so you might have some state left that could just go into test21:32
cdenti'm pretty sure "placement teamers" are placemats21:34
openstackgerritEric Fried proposed openstack/os-resource-classes master: Propose ACCELERATOR_{FPGA|GPU} resource classes  https://review.opendev.org/65746421:35
edleafecdent: you sure treat us like placemats :(21:37
cdentI've started some work on a perfload with nested. nothing to report yet as the work thus far is making placeload create a nested structure21:37
cdentedleafe: yes, I spill my prosecco on you21:38
efriedcdent: "group_policy changes"?21:43
efriedI don't even remember talking about that21:43
cdentefried: same_subtree (the images on that story)21:44
efriedah, same_subtree, roger21:47
efriedcdent: I get the idea you may not be fresh of brain enough for this discussion, but I at least want to plant the seed21:47
efriedI've mentioned this in a review or two I think21:47
* cdent is listening but making no promises21:48
efriedbut we may want to re-evaluate the appropriateness of having group_policy at all at this point.21:48
efriedlike, I think we're edging toward making it nonsensical and/or replacing its purpose with other things (like can_split and same_subtree)21:48
cdentsame_subtree is supposed to _be_ a group_policy, right?21:49
efriedis it?21:49
cdentoriginally yes21:49
efriedI mean, yeah; it is a group policy that only affects the groups you name in it.21:49
cdentgroup_policy=same_subtree:value,valuel,value21:49
efriedoh, wow, no, I hadn't thought of it that way at all.21:49
cdentsee http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html21:50
efriedI had thought it was literally going to be ?same_subtree=suffix1,suffix221:50
efriedyeah, emails, but we hadn't really ever settled on an exact syntax anywhere21:50
efriedprolly why we should have a speclet21:50
cdentyes, we should21:50
cdentwhat I've been doing with creating the story is to try to make it easy for whoever is creating the spec to create it21:51
cdent(so that references are in one place when building things)21:51
efriedthing is, what if there are leftovers after you've applied all the same_subtree and can_split things?21:51
efriedI.e. the "default group policy"21:51
cdentI'm not really parsing that question21:51
efriedLike let's say same_subtree=_suff1,_suff2&can_split_suff3 but we also have resources_suff4 and required_suff5 and...21:52
efriedSo group_policy=none|isolate could still apply to _suff4 and _suff5 and...21:53
cdentare you askiing "what grouping policy would apply to suff4 and 5?"21:53
efriedyeah21:54
cdentI reckon that's up to you, gibi, sundar, tetsuro to decide as you have the use cases21:54
* cdent doesn't have a strong opinion21:54
cdentif making same_subtree being a separate thing makes it easier to define a "policy for everything else" than that makes sense21:55
cdentbut my comments on the story were simply relfecting a (gappy) synthesis of what's been on the emails and drawings21:55
efriedYeah, I'm not criticizing shortcomings in the story :P I'm asking for a bit of brainstorming.21:56
efriedsame_subtree=_suff1,_suff2&group_policy=isolate presumably means that _suff1 and _suff2 have to come from different providers in the same subtree, whereas same_subtree=_suff1,_suff2&group_policy=none would mean that they could possibly come from the same provider. That makes sense I guess.21:57
efriedBut I have no idea what can_split_suff3=$RC_LIST&group_policy=isolate means.21:57
efriedDoes it mean, like, *must*_split?21:57
efriedThat sounds pretty whack and not useful21:58
efriedso maybe we just say group_policy doesn't affect can_split at all.21:58
cdentI would think that can_split is its own thing and what amounts to an override for that rc in that group.21:59
cdent(ignores group policy)21:59
efriedthat makes sense.21:59
cdentmust split is an interesting concept, though21:59
efriedthing is, we may eventually (possibly sooner rather than later) want to apply 'none' or 'isolate' to different same_subtreeZ21:59
cdentbut we have other ways to express that21:59
efriedright, must_split is effectively numbered groups + group_policy=isolate.21:59
efriedThough I guess must_split kinda implies some of the algorithmic splitting we've been talking about.22:00
efriedBut I don't really see a need to go there.22:00
efriedsoon22:00
cdentthe more 400s we can raise in response to whackness the better22:00
cdentfail early, etc22:00
efriedamen brother22:00
efriedbut we're not saying that can_split and group_policy are mutually exclusive.22:01
efriedBecause I can use can_split along with other granular groups where I need a group policy22:01
cdentyes22:01
efriedalso with same_subtree as noted above.22:01
cdentthe stuff in can_split needs to be "it's own thing"22:01
cdentbut everything else can follow others rules22:02
efriedYes. So I guess the simple thing is: can_split and group_policy are unrelated; and group_policy applies to granular groups and same_subtree in the way that you think; and unless we demonstrate an immediate use case, group_policy is still "global" - applies to all the granular groups in the whole request.22:02
*** tssurya has quit IRC22:03
*** tssurya_ is now known as tssurya22:03
efriedfor the sake of the exercise, suggestions for a syntax that would allow group_policy to be different for different... pieces of the request?22:03
efriedsame_subtree=isolate:_suff2,suff322:03
cdentyour "^Yes..." statement sounds right. But at the moment, implementing that sounds...mind numbing. Even with edleafe's magical tools.22:03
* cdent dies22:04
efriedsame_subtree=can_share:_suff2,suff322:04
edleafecdent: Hey, it's not the graph stuff that needs magic to work!22:04
cdentedleafe: any technology sufficiently...22:04
efriedgroup_policy=isolate:suff2,suff3;can_share:suff3,suff422:04
* efried hates the semicolon22:05
efriedwe could just allow repeating group_policy and support isolate: and can_share: prefixes to lists of suffixes.22:05
cdent(you can't use semicolon within the values of query parameters without escapes because it is the modern version of &, so pipe is often better)22:06
cdent(parens because that'st not really relevant now)22:06
efriedyeah, ugh, rather repeat the qparam22:06
efriedstill seems like there's a need for a default overall group_policy though.22:06
efriedand I would prefer it to be a default on the server, not required like it is today.22:06
efriedI still can't remember all the convolutions that led to that decision.22:07
efriedI think it was dansmith's fault. I'll blame him anyway.22:07
cdentI think you have a much more clear picture of when these things might be used, or at least a sufficient model of the abstraction for it to be something you can think about. I haven't (yet) got a natural facility with the meaning of the concept of group_policy. I have to think hard each time it is used.22:07
dansmithwat?22:07
efrieddansmith: I'm writing history so that you're responsible for group_policy being required rather than having a default.22:08
efriedI don't know whether that's what really happened. Don't care. Your fault.22:09
efriedanyway, cdent I think for now it's probably fine to keep the global group_policy and let it act upon same_subtree in the intuitive (hah) way. And get more granular with group_policy later as/if needed.22:10
cdentseems a good start22:11
efriedGiven that I'll have forgotten all of this by Monday, I should probably scribble down a summary of this conversation somewhere.22:11
cdentthat would be great22:11
efrieddidn't really want to own the spec22:11
efriedbut I guess I can start it.22:11
cdentI think it is likely we're going to have a few false starts with this stuff, and that's okay22:12
efriedcdent: remind me how we're doing topic branch names under placement+storyboard?22:12
efriedstory/###?22:12
cdentyes22:12
efriedight22:12
efriedand do I need a task for a spec?22:13
cdentideally, yes22:13
efriedight22:13
efriedAnd do you want one all-encompassing spec for nested magic things?22:13
efriedcan_split + same_subtree + resourceless groups + arbitrary suffixes22:14
cdentI feel that those things are closely tied enough that they may as well be in the same spec (that's what we found during the disparate threads: they bled) but the most important thing to be specified, I think, is same_subtree and then resourceless groups. The rest of them are more straightforward/algorithmic.22:15
efriedokay.22:16
efriedtbc, I'm not going to make this complete or polished. It's going to be a rough and partial brain dump22:16
cdentthat's fine22:16
cdentsome writing is almost always better than none22:18
efriedthat's optimistic22:19
cdentonce I'm back online next week I'll be doing some info management that should help clarify the picture and narrow some focus. I hope22:19
cdentI'm always hopeful but never optimistic22:19
cdentgonna go look at the blue room22:20
cdenthave a good weekend. will see everybody tuesday22:20
*** cdent has quit IRC22:20
openstackgerritEric Fried proposed openstack/os-resource-classes master: Propose ACCELERATOR_{FPGA|GPU} resource classes  https://review.opendev.org/65746422:33
*** jaypipes has quit IRC23:01

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!