14:00:06 #startmeeting nova-scheduler 14:00:07 Meeting started Mon Oct 22 14:00:06 2018 UTC and is due to finish in 60 minutes. The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:10 The meeting name has been set to 'nova_scheduler' 14:00:31 \o 14:01:22 o/ 14:02:02 o/ 14:02:03 o/ 14:02:26 o/ 14:02:50 #link agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting 14:02:57 o 14:03:17 Not a lot going today. If you have something to discuss, get ready to draw. 14:03:31 #topic last meeting 14:03:31 #link last minutes: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-10-15-14.00.html 14:03:31 Any old business? 14:03:40 * cdent stands ready 14:04:07 #topic specs and review 14:04:07 #link latest pupdate: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135877.html 14:04:07 Spec review tomorrow. ^ has a nice list of placement-related specs. 14:04:28 I will be spending today working on a new "placement config yaml file" spec. 14:05:18 resource provider config yaml spec, yes? 14:05:55 Yes, that makes more sense. It will be a synthesis of 14:05:55 #link Jay's Rocky provider-config-file proposal: https://review.openstack.org/#/c/550244/2/specs/rocky/approved/provider-config-file.rst 14:05:55 and the file format bits of 14:05:55 #link Konstantinos's device-placement-passthrough spec: https://review.openstack.org/#/c/591037/8/specs/stein/approved/device-placement-model.rst 14:05:55 (which was based on 14:05:56 #link Eric's device-passthrough spec: https://review.openstack.org/#/c/579359/10/doc/source/specs/rocky/device-passthrough.rst 14:05:56 ) 14:06:21 * cdent blinks 14:06:35 it will be nice for there to be options to be explicit 14:06:54 what do you mean? 14:07:56 a provider config file allows people to make statements about the config of their providers, explicitly, rather than the virt driver producing a bunch of things that _might_ be different from desired 14:08:08 (just make a general assertion that ambiguity is no fun) 14:09:01 oh, don't worry, there will still be plenty of non-fun ambiguity. I imagine most of the time people will compose their provider.yaml files after first seeing what nova/virt does to their providers by default. 14:09:11 hawt 14:09:43 but the hope is that said provider.yaml file will allow you to tweak most of the things you would want to tweak, and their presence in that file will do what you would expect. 14:10:05 Anything else about specs? 14:10:32 not from me 14:10:57 #link nrp use in nova: Series still starting at https://review.openstack.org/#/c/606050/ (no change since last week) 14:10:57 Matt asked for a rebase on some cleanup patches that'll make the series more sane and less confusing. 14:11:10 gibi_off: is off today and tomorrow, plans to get to it on Wed. 14:11:45 Any other reviews to bring up? 14:11:55 nawp 14:12:00 that rebase, 14:12:06 will depend on dropping the caching scheduler 14:12:06 oh, actually... 14:12:13 i don't know how long that needs to sit 14:12:33 the one user i know of has +1ed the removal 14:12:35 and it's in the ML 14:12:46 It went like a whole weekend, didn't it? 14:13:12 i'd say once gibi gets his series rebased then it's ok to drop if no one has spoken up by then 14:13:33 wfm 14:13:40 that. will. be. awesome. 14:14:03 cdent: did you have reviews to bring up? (other than Extraction which will be a separate topic) 14:14:24 What I was gonna say is that the stack of grenade, devstack, tempest, integration test, etc, jobs is hung up on needing some database stuff. Right now it uses a stub table creator: 14:14:29 #link stub table creator https://review.openstack.org/#/c/600161/ 14:14:46 #topic Extraction 14:14:46 (^ /me just decided this gets its own topic) 14:14:50 which _might_ be useful to go ahead and merge as a temporary thing so we can move those integration tests forward 14:15:13 why aren't we just waiting for alembic stuff? 14:15:31 because it's not clear how long that is going to take 14:15:38 I've got the alembic stuf sort of working, but the sqla code doesn't see the tables. 14:15:39 but that's certainly an option 14:15:48 My lack of sqla understanding is the bottleneck 14:16:09 if you want to push up extant code I can look at it in your off hours? 14:16:40 sure, I could do that. I was going to hack a bit more once this meeting is over and I get more caffeine 14:17:04 drop a messsage somewhere with your state when you let go of it tonight, and I can play with it tomorrow morning 14:17:13 riger that 14:17:16 roger, even 14:18:14 Anything else related to extraction? 14:18:19 the other extraction thing I wanted to mention is something along the lines of "what's up with docs". We haven't really got a solid plan there, yet. Ideas? Thoughts? 14:18:36 if the docs are going to be published from the placement repo, 14:18:42 then nova's docs just need redirect links 14:19:52 is that what you meant, cdent? Publishing the docs? Or were you talking about conten? 14:19:53 t 14:19:59 all of it 14:20:06 when we publish, we need redirect links 14:20:31 sure, so it's just a two-step, 14:20:36 but just publishing is not enough because the content is currently embedded in the context of nova without a notion of placement being first class 14:20:41 get the docs publishing with the desired content, 14:20:54 and then push a nova patch to change the redirects and drop the nova placement docs i guess 14:20:56 and we don't currently have anyone thinking about that content as far as I know 14:21:09 so mostly I'm saying "hey, we need to think about that content" 14:21:23 tetsuro: any chance you've got time for ^ ? 14:21:45 within that is also: the api-ref is published and managed separately so we could go ahead and switch that whenever we like, as the api is currently frozen 14:21:45 I think the focus on meeting the extraction goals has lessened the interest in working on docs 14:22:04 efried: You mean I clean up the content of the placement docs? 14:22:04 indeed, but we can't say we are extracted without being able to publish docs, presumably? 14:22:20 tetsuro: Yes, de-nova-ify and get them ready to publish. 14:22:39 I wouldn't think so, but writing down what has to be done has definitely focused efforts on those things 14:23:04 tetsuro: Last doc you did, you made it look easy :) The reward for good work is... 14:24:28 efried: Okay, I have time to look into that 14:24:41 tetsuro: Thanks! 14:25:02 I don't know what is needed to trigger publishing, but we can figure that out as the content is being made ready. 14:25:08 edleafe: I agree, I mentioned in penultimate pupdate that we might want to restart the placement extraction etherpad to start from a clean slate and understanding of the now 14:25:12 but nobody said anything 14:25:20 implicit agreement ^ 14:25:34 didn't read it yet 14:25:35 keep the old one for posterity 14:25:41 Guilty. I remember reading that and thinking "Hey, we should definitely do that" 14:26:15 efried: have you been listening to me for the last few years? I don't do implicit, sirrah 14:26:58 cdent: I agree with the notion of starting a new extraction etherpad, while keeping the old for posterity. +1. Make it so. Do it, and let the English see you do it. 14:27:03 ^ explicit. 14:27:33 Oh, you mean "implicit agreement" which translate as "yeah, as long as the smeller is the feller, than it's cool"? 14:27:59 * cdent takes notes in his instruction manual 14:28:36 If I follow that policy all the time I will end up doing everything and I ain't gonna do that 14:28:52 but in this case I'll take that action 14:29:01 #action cdent to make a new extraction etherpad 14:29:48 oh, if we're using that tag... 14:29:48 #action tetsuro to de-nova-ify placement docs and make ready for publishing 14:30:46 okay, we done with extraction? 14:31:15 (silence <= implicit agreement) 14:31:17 #topic bugs 14:31:17 #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement 14:32:16 Any bugs worthy of discussion? 14:32:36 rgerganov has started backporting a fix for update running more than once in the resource tracker 14:32:54 the race condition it fixes is present back to queens (where it has presented a problem for the vmware product) 14:33:14 neat 14:33:15 #link update less in rt https://bugs.launchpad.net/nova/+bug/1729621 14:33:15 Launchpad bug 1729621 in OpenStack Compute (nova) pike "Inconsistent value for vcpu_used" [Undecided,In progress] - Assigned to Radoslav Gerganov (rgerganov) 14:33:40 it seems the race is more of a big deal if you have many hundreds of vms on the same nova compute 14:34:50 that would seem unsurprising 14:35:04 quite 14:36:44 other buggage? 14:36:49 my only concern about those backports 14:36:57 is the related 0.0 allocation fix that came later 14:37:06 which is in rocky but not queens or pike 14:37:29 well, that's not my only concern, but my biggest one 14:37:40 this https://github.com/openstack/nova/commit/2588af87c862cfd02d860f6b860381e907b279ff#diff-afb9c0c0ca5276c7eacd987bbf51d8e6 14:38:58 presumably this will come out in the review? 14:39:22 i'll leave something yes 14:40:26 #topic opens 14:40:41 Anyone? Bueller? 14:41:00 spec sprint tomorrow, yes? 14:41:44 yup 14:42:20 mentioned at :04:09 14:43:08 Anything else before we close? 14:43:47 Thanks y'all 14:43:47 #endmeeting