| *** mriedem has quit IRC | 00:06 | |
| *** tssurya has quit IRC | 01:03 | |
| *** cdent has quit IRC | 01:16 | |
| *** ttsiouts has joined #openstack-placement | 01:59 | |
| *** ttsiouts has quit IRC | 02:33 | |
| *** takashin has quit IRC | 04:08 | |
| *** takashin has joined #openstack-placement | 04:15 | |
| *** cdent has joined #openstack-placement | 04:29 | |
| *** ttsiouts has joined #openstack-placement | 04:30 | |
| *** ttsiouts has quit IRC | 05:02 | |
| *** cdent has quit IRC | 05:06 | |
| openstackgerrit | qian wang proposed openstack/osc-placement master: Modify tox.ini and README.rst Replace openstack.org URLs with opendev.org URLs https://review.opendev.org/658270 | 06:12 |
|---|---|---|
| *** ttsiouts has joined #openstack-placement | 07:00 | |
| *** mcgigglier has joined #openstack-placement | 07:52 | |
| *** ttsiouts has quit IRC | 08:03 | |
| *** takashin has left #openstack-placement | 08:03 | |
| *** tssurya has joined #openstack-placement | 08:23 | |
| *** ttsiouts has joined #openstack-placement | 10:00 | |
| *** ttsiouts has quit IRC | 10:33 | |
| *** vdrok has quit IRC | 10:48 | |
| *** vdrok has joined #openstack-placement | 10:49 | |
| *** mkrai1 has joined #openstack-placement | 12:07 | |
| *** ttsiouts has joined #openstack-placement | 12:30 | |
| *** ttsiouts has quit IRC | 13:03 | |
| *** mriedem has joined #openstack-placement | 13:05 | |
| *** mcgigglier has quit IRC | 13:14 | |
| *** mcgiggler has joined #openstack-placement | 13:15 | |
| *** jaypipes has joined #openstack-placement | 13:32 | |
| *** mcgiggler has quit IRC | 13:58 | |
| *** ttsiouts has joined #openstack-placement | 15:00 | |
| *** ttsiouts has quit IRC | 15:34 | |
| *** cdent has joined #openstack-placement | 16:11 | |
| efried | cdent: 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 |
| cdent | yeah, I'm doing that right now | 16:28 |
| efried | coo, thx | 16:28 |
| *** efried is now known as fried_rolls | 16:28 | |
| fried_rolls | o/ | 16:28 |
| openstackgerrit | Chris Dent proposed openstack/placement master: Raise os-traits os-resource-classes constraints https://review.opendev.org/658419 | 16:44 |
| openstackgerrit | Chris Dent proposed openstack/osc-placement master: Dropping the py35 testing https://review.opendev.org/654652 | 17:06 |
| *** tssurya has quit IRC | 17:37 | |
| klindgren | So 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 migrations | 17:51 |
| klindgren | into placement, to make it so where we can upgrade older versions of placement db schemas? | 17:51 |
| cdent | klindgren: 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-placement | 18:21 | |
| openstackgerrit | Merged openstack/os-traits master: Update SEV trait docs to avoid misleading people https://review.opendev.org/655671 | 18:22 |
| *** fried_rolls is now known as efried | 18:52 | |
| klindgren | It looks like the migrations for placement were actually pretty simple. | 18:56 |
| klindgren | So I just translated those into some simple mysql queries. To add the columns and index's. | 18:57 |
| cdent | klindgren: that's probably a better option. if you saved that away somewhere, we could point people to it | 18:58 |
| klindgren | I do have it saved, still working on a getting a full ENV up and making sure I didn't possibly miss stuff. | 18:59 |
| cdent | when 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/interesting | 18:59 |
| openstackgerrit | Eric Fried proposed openstack/placement master: Add NUMANetworkFixture for gabbits https://review.opendev.org/657463 | 19:00 |
| openstackgerrit | Eric Fried proposed openstack/placement master: Gabbi test cases for can_split https://review.opendev.org/658192 | 19:00 |
| *** dklyle_ has joined #openstack-placement | 19:02 | |
| *** david-lyle has quit IRC | 19:04 | |
| *** tssurya_ has joined #openstack-placement | 19:23 | |
| *** mriedem has quit IRC | 20:44 | |
| cdent | In case anyone cares, no pupdate today, and I'll be flying during the next scheduled meeting | 21:23 |
| *** jaypipes has quit IRC | 21:24 | |
| *** jaypipes has joined #openstack-placement | 21:24 | |
| efried | I care, cdent. I care deeply. | 21:29 |
| cdent | thanks efried | 21:29 |
| cdent | i'll do an interim week-in-denver summary during the week next week | 21:29 |
| cdent | and then a monster pupdate come friday | 21:29 |
| cdent | assuming i haven't died from jetlag | 21:30 |
| efried | sounds good. I think it will be useful to have a short list of 'most important' for placement teamers. | 21:30 |
| cdent | yes | 21:30 |
| efried | I'm going to go write some more tests for nested magic. | 21:30 |
| efried | Any preference what I go after next? | 21:31 |
| cdent | one mo | 21:31 |
| cdent | looking at https://storyboard.openstack.org/#!/story/2005575 I don't think it really matters what comes next | 21:32 |
| cdent | group_policy changes fit well with your drawing so you might have some state left that could just go into test | 21:32 |
| cdent | i'm pretty sure "placement teamers" are placemats | 21:34 |
| openstackgerrit | Eric Fried proposed openstack/os-resource-classes master: Propose ACCELERATOR_{FPGA|GPU} resource classes https://review.opendev.org/657464 | 21:35 |
| edleafe | cdent: you sure treat us like placemats :( | 21:37 |
| cdent | I've started some work on a perfload with nested. nothing to report yet as the work thus far is making placeload create a nested structure | 21:37 |
| cdent | edleafe: yes, I spill my prosecco on you | 21:38 |
| efried | cdent: "group_policy changes"? | 21:43 |
| efried | I don't even remember talking about that | 21:43 |
| cdent | efried: same_subtree (the images on that story) | 21:44 |
| efried | ah, same_subtree, roger | 21:47 |
| efried | cdent: I get the idea you may not be fresh of brain enough for this discussion, but I at least want to plant the seed | 21:47 |
| efried | I've mentioned this in a review or two I think | 21:47 |
| * cdent is listening but making no promises | 21:48 | |
| efried | but we may want to re-evaluate the appropriateness of having group_policy at all at this point. | 21:48 |
| efried | like, 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 |
| cdent | same_subtree is supposed to _be_ a group_policy, right? | 21:49 |
| efried | is it? | 21:49 |
| cdent | originally yes | 21:49 |
| efried | I mean, yeah; it is a group policy that only affects the groups you name in it. | 21:49 |
| cdent | group_policy=same_subtree:value,valuel,value | 21:49 |
| efried | oh, wow, no, I hadn't thought of it that way at all. | 21:49 |
| cdent | see http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html | 21:50 |
| efried | I had thought it was literally going to be ?same_subtree=suffix1,suffix2 | 21:50 |
| efried | yeah, emails, but we hadn't really ever settled on an exact syntax anywhere | 21:50 |
| efried | prolly why we should have a speclet | 21:50 |
| cdent | yes, we should | 21:50 |
| cdent | what I've been doing with creating the story is to try to make it easy for whoever is creating the spec to create it | 21:51 |
| cdent | (so that references are in one place when building things) | 21:51 |
| efried | thing is, what if there are leftovers after you've applied all the same_subtree and can_split things? | 21:51 |
| efried | I.e. the "default group policy" | 21:51 |
| cdent | I'm not really parsing that question | 21:51 |
| efried | Like let's say same_subtree=_suff1,_suff2&can_split_suff3 but we also have resources_suff4 and required_suff5 and... | 21:52 |
| efried | So group_policy=none|isolate could still apply to _suff4 and _suff5 and... | 21:53 |
| cdent | are you askiing "what grouping policy would apply to suff4 and 5?" | 21:53 |
| efried | yeah | 21:54 |
| cdent | I reckon that's up to you, gibi, sundar, tetsuro to decide as you have the use cases | 21:54 |
| * cdent doesn't have a strong opinion | 21:54 | |
| cdent | if making same_subtree being a separate thing makes it easier to define a "policy for everything else" than that makes sense | 21:55 |
| cdent | but my comments on the story were simply relfecting a (gappy) synthesis of what's been on the emails and drawings | 21:55 |
| efried | Yeah, I'm not criticizing shortcomings in the story :P I'm asking for a bit of brainstorming. | 21:56 |
| efried | same_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 |
| efried | But I have no idea what can_split_suff3=$RC_LIST&group_policy=isolate means. | 21:57 |
| efried | Does it mean, like, *must*_split? | 21:57 |
| efried | That sounds pretty whack and not useful | 21:58 |
| efried | so maybe we just say group_policy doesn't affect can_split at all. | 21:58 |
| cdent | I 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 |
| efried | that makes sense. | 21:59 |
| cdent | must split is an interesting concept, though | 21:59 |
| efried | thing is, we may eventually (possibly sooner rather than later) want to apply 'none' or 'isolate' to different same_subtreeZ | 21:59 |
| cdent | but we have other ways to express that | 21:59 |
| efried | right, must_split is effectively numbered groups + group_policy=isolate. | 21:59 |
| efried | Though I guess must_split kinda implies some of the algorithmic splitting we've been talking about. | 22:00 |
| efried | But I don't really see a need to go there. | 22:00 |
| efried | soon | 22:00 |
| cdent | the more 400s we can raise in response to whackness the better | 22:00 |
| cdent | fail early, etc | 22:00 |
| efried | amen brother | 22:00 |
| efried | but we're not saying that can_split and group_policy are mutually exclusive. | 22:01 |
| efried | Because I can use can_split along with other granular groups where I need a group policy | 22:01 |
| cdent | yes | 22:01 |
| efried | also with same_subtree as noted above. | 22:01 |
| cdent | the stuff in can_split needs to be "it's own thing" | 22:01 |
| cdent | but everything else can follow others rules | 22:02 |
| efried | Yes. 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 IRC | 22:03 | |
| *** tssurya_ is now known as tssurya | 22:03 | |
| efried | for 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 |
| efried | same_subtree=isolate:_suff2,suff3 | 22:03 |
| cdent | your "^Yes..." statement sounds right. But at the moment, implementing that sounds...mind numbing. Even with edleafe's magical tools. | 22:03 |
| * cdent dies | 22:04 | |
| efried | same_subtree=can_share:_suff2,suff3 | 22:04 |
| edleafe | cdent: Hey, it's not the graph stuff that needs magic to work! | 22:04 |
| cdent | edleafe: any technology sufficiently... | 22:04 |
| efried | group_policy=isolate:suff2,suff3;can_share:suff3,suff4 | 22:04 |
| * efried hates the semicolon | 22:05 | |
| efried | we 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 |
| efried | yeah, ugh, rather repeat the qparam | 22:06 |
| efried | still seems like there's a need for a default overall group_policy though. | 22:06 |
| efried | and I would prefer it to be a default on the server, not required like it is today. | 22:06 |
| efried | I still can't remember all the convolutions that led to that decision. | 22:07 |
| efried | I think it was dansmith's fault. I'll blame him anyway. | 22:07 |
| cdent | I 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 |
| dansmith | wat? | 22:07 |
| efried | dansmith: I'm writing history so that you're responsible for group_policy being required rather than having a default. | 22:08 |
| efried | I don't know whether that's what really happened. Don't care. Your fault. | 22:09 |
| efried | anyway, 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 |
| cdent | seems a good start | 22:11 |
| efried | Given that I'll have forgotten all of this by Monday, I should probably scribble down a summary of this conversation somewhere. | 22:11 |
| cdent | that would be great | 22:11 |
| efried | didn't really want to own the spec | 22:11 |
| efried | but I guess I can start it. | 22:11 |
| cdent | I think it is likely we're going to have a few false starts with this stuff, and that's okay | 22:12 |
| efried | cdent: remind me how we're doing topic branch names under placement+storyboard? | 22:12 |
| efried | story/###? | 22:12 |
| cdent | yes | 22:12 |
| efried | ight | 22:12 |
| efried | and do I need a task for a spec? | 22:13 |
| cdent | ideally, yes | 22:13 |
| efried | ight | 22:13 |
| efried | And do you want one all-encompassing spec for nested magic things? | 22:13 |
| efried | can_split + same_subtree + resourceless groups + arbitrary suffixes | 22:14 |
| cdent | I 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 |
| efried | okay. | 22:16 |
| efried | tbc, I'm not going to make this complete or polished. It's going to be a rough and partial brain dump | 22:16 |
| cdent | that's fine | 22:16 |
| cdent | some writing is almost always better than none | 22:18 |
| efried | that's optimistic | 22:19 |
| cdent | once I'm back online next week I'll be doing some info management that should help clarify the picture and narrow some focus. I hope | 22:19 |
| cdent | I'm always hopeful but never optimistic | 22:19 |
| cdent | gonna go look at the blue room | 22:20 |
| cdent | have a good weekend. will see everybody tuesday | 22:20 |
| *** cdent has quit IRC | 22:20 | |
| openstackgerrit | Eric Fried proposed openstack/os-resource-classes master: Propose ACCELERATOR_{FPGA|GPU} resource classes https://review.opendev.org/657464 | 22:33 |
| *** jaypipes has quit IRC | 23:01 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!