| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-26 | |||
| 21:05:53 | imacdonn | sdague: Understood. It makes sense now. | |
| 21:10:07 | openstackgerrit | Eric Fried proposed openstack/nova master: doc: Upgrade placement first https://review.openstack.org/556631 | |
| 21:22:12 | cfriesen | does anyone know why we call driver.plug_vifs() in _init_instance() for a stopped instance? | |
| 21:22:19 | cfriesen | looks like that code has been there forever | |
| 21:23:03 | cfriesen | I'm wondering if it's a lowest-common-denominator virt driver thing | |
| 21:23:08 | kashyap | cfriesen: melwitt: dansmith: Since I'm awake, thinking a bit more on https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py: While I agree that failing at Nova start up is better it seems better to hard-fail _at_ instance start up, much like we do for 'mode' and 'model'? | |
| 21:23:33 | kashyap | If you see we're actually hard-failing for 'custom' and 'mode' just in the driver.py file | |
| 21:24:05 | cfriesen | kashyap: arguably we should hard-fail those at nova-compute startup too. | |
| 21:24:08 | kashyap | IMHO, it just is consistent (for better or worse) to raise exception.Invalid()fail for the closely related 'extra_flags' too. | |
| 21:24:13 | kashyap | cfriesen: Yes, exactly! | |
| 21:24:20 | kashyap | cfriesen: But that's a surgery for different day | |
| 21:24:32 | kashyap | I'm curious if anyone can poke holes in the above logic | |
| 21:24:37 | dansmith | cfriesen: mode is protected by choices | |
| 21:24:44 | dansmith | er, kashyap | |
| 21:24:56 | dansmith | kashyap: and model is defined in the libvirt cpu models xml, which can be custom-written | |
| 21:25:24 | kashyap | dansmith: Custom-writing models is a horrible thing to do | |
| 21:25:31 | dansmith | kashyap: that has nothing to do with it | |
| 21:25:37 | kashyap | (It'll just cause untold pain.) | |
| 21:25:51 | dansmith | kashyap: also, we've paved the way for you to be able to backport this with minimal change, so it'd be cool if we could just not argue over minutia | |
| 21:25:55 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.openstack.org/552924 | |
| 21:25:56 | dansmith | lots of people have opined at this point | |
| 21:25:59 | kashyap | dansmith: Sure, I'm not saying otherwise (on your earlier point). | |
| 21:26:11 | kashyap | dansmith: Oh, I actually _did_ make the LOG.warning thing | |
| 21:26:23 | kashyap | Locally | |
| 21:26:41 | kashyap | dansmith: But I'm just trying to discus in good spirit, as it seems to make logical sense given the existing structure | |
| 21:27:59 | dansmith | kashyap: one could argue that if we made you do it as a workaround flag this would be moot, | |
| 21:28:12 | dansmith | so arguing for it further might work against us here :) | |
| 21:28:31 | kashyap | dansmith: C'mon :-) | |
| 21:28:52 | kashyap | dansmith: I'm amenable to reason (contrary to what you seem to imply :P) | |
| 21:29:37 | kashyap | But we know that the 'workaround' is just needless work for the poor deployment folks. That's why you concurred w/ me on that | |
| 21:29:41 | kashyap | Anyway. | |
| 21:30:18 | melwitt | I thought we were restricting choices to 'pcid' through the config option choices anyway, no? why do we need this check? | |
| 21:30:31 | dansmith | melwitt: we can't via config | |
| 21:30:33 | kashyap | melwitt: We are restricting the choices, indeed. | |
| 21:30:34 | dansmith | for listopt | |
| 21:30:40 | kashyap | Ah, not via config, though. | |
| 21:30:42 | dansmith | that's the point of the thread | |
| 21:30:51 | melwitt | I replied to the ML with an example where we do. does that not work? | |
| 21:31:28 | kashyap | Sorry, haven't checked the thread yet. (It's late, and I'm slowly getting back to thinking in English, after 3-ish hours of straight Dutch.) | |
| 21:31:53 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option https://review.openstack.org/554688 | |
| 21:31:56 | dansmith | melwitt: ah I see now, I guess kashyap was confused? | |
| 21:32:19 | melwitt | okay, when you get a chance to check the thread, I'd try it out and see if it works. danpb used that technique to limit ListOpt choices for VNC auth_schemes for the console TLS stuff | |
| 21:33:07 | cfriesen | kashyap: I would suggest that it would make sense to do your check at LibvirtDriver.init_host(), then in a followup patch move the sanity checks from LibvirtDriver._get_guest_cpu_model_config() to init_host(). | |
| 21:33:28 | dansmith | cfriesen: looks to me like it will be checked early during config parsing now | |
| 21:33:30 | openstackgerrit | Eric Fried proposed openstack/nova master: Slugification utilities for placement names https://review.openstack.org/556628 | |
| 21:33:55 | dansmith | which is what we originally suggested | |
| 21:34:17 | cfriesen | sure, if we can restrict it via the config parsing for backport that'd be even better. | |
| 21:34:59 | kashyap | melwitt: Ah, this one: https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L226,232 | |
| 21:35:11 | melwitt | yes | |
| 21:35:12 | kashyap | melwitt: Interesting pointer; I'll give it a whirl and see what comes | |
| 21:35:43 | melwitt | cool, hope it works, else we have a bug in the vnc opts too :P | |
| 21:37:17 | kashyap | LOL | |
| 21:44:26 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Migrate tempest-dsvm-cells job to an in-tree job definition https://review.openstack.org/556656 | |
| 21:49:28 | mriedem | so uh, | |
| 21:49:46 | mriedem | sahid would likely explode if i mentioned this, but https://review.openstack.org/#/c/458820/ could arguably require a microversion right? | |
| 21:49:59 | mriedem | i.e. i create an sriov port in neutron with trusted=true, | |
| 21:50:22 | mriedem | and try to create a server with that port, but nova api isn't new enough to move that in the pci request for scheduling, | |
| 21:50:31 | mriedem | so i get a server without a trusted VF | |
| 21:51:36 | mriedem | thought about this because of the bandwidth-aware scheduling stuff that relies on the qos policy on the ports in neutron, which impacts scheduling behavior in nova | |
| 21:52:28 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472 | |
| 21:52:29 | openstackgerrit | Chris Dent proposed openstack/nova master: Support forbidden traits in allocation_candidates in db https://review.openstack.org/556660 | |
| 21:53:40 | cdent | edleafe, efried, jaypipes: that ^ batch of stuff is the initial db support for forbidden traits. most of the rest of the code is done too, but needs to be extracted from a lump of random stuff. I'm not super confident I've got enough tests yet. | |
| 21:54:18 | efried | ack | |
| 22:05:22 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement stable/queens: Do not depend on jenkins user in devstack gate https://review.openstack.org/556666 | |
| 22:05:36 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement stable/queens: Migrate legacy-osc-placement-dsvm-functional job in-tree https://review.openstack.org/556635 | |
| 22:19:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Handle agg generation conflict in report client https://review.openstack.org/556669 | |
| 22:20:02 | efried | dansmith, cdent, jaypipes, edleafe ^ | |
| 22:20:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Create/lookup API services in cell0 on WSGI app startup https://review.openstack.org/556670 | |
| 22:27:14 | mriedem | dansmith: i can't convince myself that there would be any upgrade impact with this ^ | |
| 22:27:28 | mriedem | even if you had mistakenly started up API services pointing at cell1 | |
| 22:29:05 | dansmith | well, you'd have some nova-api type services that will still list out of a service listing | |
| 22:29:06 | dansmith | from cell1 | |
| 22:29:16 | mriedem | service list filters out api services | |
| 22:29:19 | dansmith | we don't need this wsgi_app stuff for metadata? | |
| 22:29:21 | mriedem | https://github.com/openstack/nova/blob/88f6c3b7b892f2a05066ac6f0e3353f4ce80f6b0/nova/api/openstack/compute/services.py#L48 | |
| 22:29:50 | dansmith | hmm | |
| 22:30:07 | mriedem | is nova-metadata global or per-cell? | |
| 22:31:16 | melwitt | I think it's global | |
| 22:31:24 | dansmith | yeah, it hits api db | |
| 22:31:49 | dansmith | I really didn't think services would filter out api, that's kindof confusing to me | |
| 22:32:07 | mriedem | the os-services REST API is mostly biased to compute services | |
| 22:32:15 | mriedem | i.e. things you can enable/disable | |
| 22:32:21 | mriedem | and service group stuff | |
| 22:32:23 | dansmith | it shows scheduler | |
| 22:32:29 | mriedem | i know, but... | |
| 22:32:30 | dansmith | which is probably why I'm thinking that, | |
| 22:32:31 | dansmith | although,. | |
| 22:32:36 | dansmith | now that I think of it, | |
| 22:32:41 | mriedem | that all predates host mappings too | |
| 22:32:48 | dansmith | we didn't even have api service records until we needed it for SERVICE_VERSION | |
| 22:32:48 | mriedem | and this api relies on host mappings to do any actions on services | |
| 22:32:51 | dansmith | so that makes sense now | |
| 22:32:52 | mriedem | so it's restricted to compute | |
| 22:34:00 | mriedem | this is as close as we get to nova-metadata being global for cells v2 in our docs https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#neutron-metadata-api-proxy | |
| 22:34:04 | dansmith | so I guess no upgrade impact, through a weird set of reasons | |
| 22:34:28 | mriedem | alternatively to this, i could base it on if CONF.database.connection is None | |
| 22:34:31 | mriedem | but.. | |
| 22:35:05 | mriedem | but that just seems weird | |
| 22:35:54 | mriedem | anyway, there might be more fallout before https://review.openstack.org/#/c/555346/ is done | |
| 22:35:54 | dansmith | I guess I'm not sure why we should make this change | |