| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-11 | |||
| 18:25:18 | artom | dansmith, I mean, I'll take the "giant" as a compliment | |
| 18:25:35 | aspiers | melwitt: here it is finally ... https://blueprints.launchpad.net/nova/+spec/amd-sev-libvirt-support | |
| 18:26:03 | aspiers | my very first nova spec, so I'm prepared for the -3s to roll in | |
| 18:26:12 | dansmith | artom: heh | |
| 18:26:24 | aspiers | artom: ROFL | |
| 18:27:05 | aspiers | melwitt: one of the key questions is whether the built-in trait:HW_CPU_x86_SEV support should be included in this spec, or split off into a separate spec | |
| 18:27:13 | aspiers | melwitt: I'll gratefully take guidance on that | |
| 18:27:25 | melwitt | that's a jaypipes question | |
| 18:27:30 | aspiers | OK thanks | |
| 18:27:45 | melwitt | but I think in this spec would be fine | |
| 18:27:51 | aspiers | also, as a distinct nova newb, I've probably got the wrong end of the stick on a whole bunch of other stuff | |
| 18:28:04 | jaypipes | aspiers: I'll have a gander later today. | |
| 18:28:08 | aspiers | a lot of it is based on reading source code over the last few days | |
| 18:28:13 | aspiers | jaypipes: awesome, thanks! | |
| 18:29:09 | aspiers | intention is for me (and/or maybe colleagues) to do the heavy lifting, so we're not expecting anyone else to come in and do the hard work for us | |
| 18:29:12 | mriedem | dansmith: i left some replies in https://review.openstack.org/#/c/605573/15 | |
| 18:29:20 | aspiers | ... although of course we wouldn't object to that ;-) | |
| 18:30:40 | aspiers | oh crap, I forgot to finish the work items and dependencies sections | |
| 18:31:47 | imacdonn | -4 ? | |
| 18:32:13 | mriedem | ah traits, the new flavor extra spec | |
| 18:32:14 | aspiers | I'm OK with that if I get in the Guinness World Records for lowest Gerrit score | |
| 18:32:45 | mriedem | aspiers: have you read http://lists.openstack.org/pipermail/openstack-dev/2018-October/135446.html ? | |
| 18:32:52 | aspiers | almost certainly not | |
| 18:33:01 | mriedem | probably answers your trait questoin | |
| 18:33:03 | mriedem | *question | |
| 18:33:21 | aspiers | cool, thanks | |
| 18:34:40 | mriedem | tl;dr is we'll translate a flavor extra spec / image property to a trait for scheduling and the virt driver would use the extra spec/image property | |
| 18:34:41 | aspiers | mriedem: hooray, it seems my proposal accidentally aligns with upstream consensus on this | |
| 18:35:28 | aspiers | wait - doesn't that translation correspond to the first approach listed in that mail, rather than the second? | |
| 18:35:40 | openstackgerrit | Jim Rollenhagen proposed openstack/nova-specs master: Use conductor groups to partition nova-compute services for Ironic https://review.openstack.org/609709 | |
| 18:37:08 | mriedem | i guess | |
| 18:37:20 | mriedem | i don't remember being around for the decision | |
| 18:37:51 | aspiers | that mail says "Ultimately, the decision was made to go with the second approach." | |
| 18:38:35 | mriedem | yeah i just read it | |
| 18:38:50 | mriedem | hopefully that makes its way into developer docs somewhere at some point | |
| 18:38:58 | aspiers | +1 for that | |
| 18:39:13 | aspiers | but that's super-helpful - I'm gonna link it from the spec. thanks! | |
| 18:39:25 | melwitt | yeah, in the spec https://review.openstack.org/#/c/607989/1/specs/stein/approved/support-hpet-on-guest.rst it's the "explicit trait, implicit config" approach | |
| 18:42:44 | mriedem | dansmith: on that cache thing, can we do that in a follow up? | |
| 18:47:14 | dansmith | mriedem: I was even going to volunteer to do it as a follow-up, but then you hurt my feelings by calling it excessive | |
| 18:47:41 | mriedem | "all nova devs are giant dicks" | |
| 18:47:58 | mriedem | just trying to stay true to form... | |
| 18:48:14 | dansmith | I would like to appeal to our guidance counselor | |
| 18:49:40 | mriedem | is it still mnaser? | |
| 18:50:16 | mnaser | mriedem: you're on timeout | |
| 18:50:19 | mnaser | 4 hours of typo fixing | |
| 18:50:21 | dansmith | they're drawing new names out of a hat to ensure fairness I think | |
| 18:50:23 | mnaser | be nice >:( | |
| 18:51:07 | mnaser | also now that i've been highlighted | |
| 18:51:09 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779 | |
| 18:51:21 | mnaser | eyes on https://review.openstack.org/#/c/602384/ would be important/nice considering you can kinda snoop and listen to other vms traffic | |
| 18:51:31 | mnaser | which is kind of a big deal™ | |
| 18:51:50 | mriedem | sean-k-mooney was supposed to be working on backports | |
| 18:52:09 | mriedem | to see if older versions of libvirt had issues with that | |
| 18:53:03 | mnaser | "someone" i know has done extensive testing | |
| 18:53:13 | mnaser | and would be likely happy to do local testing | |
| 18:53:20 | mnaser | so i'll try to ask/get them here to help sean-k-mooney | |
| 18:53:50 | mriedem | mnaser: on https://review.openstack.org/#/c/609330/1/specs/stein/approved/remove-force-flag-from-live-migrate-and-evacuate.rst@93 you don't know of any operators that disable computes and then force live migrations to those hosts to rebalance or during rolling upgrades? | |
| 18:55:45 | mnaser | mriedem: we do a bit of the opposite. we disable the host being evacuated and then evacuate that one | |
| 18:55:57 | mnaser | that way the scheduler just distributes things the way they're suppoesd to be | |
| 18:56:20 | mnaser | i'll reply to the comment | |
| 18:59:28 | mnaser | mriedem: added my comment | |
| 18:59:28 | mriedem | mnaser: btw, you don't get "on" timeout, you get "in" timeout | |
| 18:59:36 | mriedem | unless on timeout is a canadian thing | |
| 18:59:45 | mriedem | it's like kid jail | |
| 18:59:53 | mnaser | sorry i haven't done the whole raising a kid/pet/thing | |
| 19:00:54 | mnaser | whats wrong with kids napping | |
| 19:02:41 | dansmith | mriedem: hmm, does the context we're passing to get_all_volume_types potentially limit the result to what you have available based on who you are? | |
| 19:02:51 | mriedem | dansmith: yes | |
| 19:02:57 | mriedem | so no caching | |
| 19:03:10 | mriedem | unless you use cinder admin config and list all volume types | |
| 19:03:19 | mriedem | which we have, but it's optional | |
| 19:04:18 | dansmith | I'll just stop trying to be smart | |
| 19:05:03 | mriedem | that's ok, i apparently don't understand json schema https://review.openstack.org/#/c/606398/10/nova/tests/unit/api/openstack/compute/test_serversV21.py | |
| 19:06:34 | melwitt | mriedem: doesn't "null" mean not present at all? I don't think it means None | |
| 19:07:09 | openstackgerrit | Florian Haas proposed openstack/nova master: Explain cpu_model_extra_flags and nested guest support https://review.openstack.org/609788 | |
| 19:07:16 | mriedem | the "required" entry in the schema should say if the field can be missing | |
| 19:07:24 | melwitt | although, what would None map to then? not string, apparently | |
| 19:07:32 | mriedem | so i'm confused as to what 'null' means here, because it's the same for the trusted cert id and description fields | |
| 19:07:43 | openstackgerrit | Florian Haas proposed openstack/nova stable/rocky: Explain cpu_model_extra_flags and nested guest support https://review.openstack.org/609789 | |
| 19:07:51 | melwitt | hm, ok. I guess I don't understand it either then. I had thought "null" meant that it could be omitted | |
| 19:08:19 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779 | |
| 19:08:35 | openstackgerrit | Florian Haas proposed openstack/nova stable/queens: Explain nested guest support https://review.openstack.org/609790 | |
| 19:10:28 | mriedem | i'm able to create a server with a null description: {"server": {"name": "test-null-desc", "description": null, "imageRef": "b9cdd407-14fc-42fb-beb9-d53988d866e3", "flavorRef": "1", "max_count": 1, "min_count": 1, "networks": "none"}} | |
| 19:14:47 | mriedem | hmm wtf | |
| 19:14:48 | mriedem | curl -g -i -X POST http://199.204.45.149/compute/v2.1/servers -H "Accept: application/json" -H "Content-Type: application/json" -H "OpenStack-API-Version: compute 2.67" -H "X-Auth-Token: $token" -H "X-OpenStack-Nova-API-Version: 2.67" -d '{"server": {"name": "bfv-server-null-vol-type", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", "uuid": "b9cdd407-14fc-42fb-beb9-d53988d866e3", "volume_size": "1", "volume_ty | |
| 19:14:48 | mriedem | null, "source_type": "image", "destination_type": "volume", "delete_on_termination": true}], "flavorRef": "1", "max_count": 1, "min_count": 1, "networks": "none"}}' | |
| 19:14:48 | mriedem | HTTP/1.1 202 Accepted | |
| 19:14:55 | mriedem | that's a null volume type | |
| 19:16:41 | melwitt | \:| | |
| 19:24:28 | mriedem | dansmith: you were right about that unset bdm.volume_type thing, wrote a test, will fix | |
| 19:24:46 | dansmith | finally. | |
| 19:33:22 | mriedem | i don't know how those functional api samples tests are passing without the cinder fixture either... | |
| 19:33:24 | mriedem | something smells in the tests | |
| 19:39:49 | artom | mriedem, a while ago I tried making the samples tests run with 2.latest, and realized I needed the CinderFixture (I think - might have been Neutron) | |
| 19:43:40 | artom | Hrmm, my old abandoned patches aren't telling me much. Anyways, it might be microversions, is what I'm saying. | |
| 20:11:39 | mriedem | well i think i know why the api samples are busted | |
| 20:12:23 | mriedem | https://github.com/openstack/nova/blob/7a5d7db7fc6ccfbd97508a1e8cd353ec25cf8ca2/nova/tests/functional/api_sample_tests/test_servers.py#L38 | |
| 20:12:32 | mriedem | it's not using the 2.67 request sample | |
| 20:15:23 | artom | Hey, I was right! Time to revive https://review.openstack.org/#/c/430352/ ? | |