| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-02 | |||
| 16:50:16 | gibi | mriedem: fyi https://review.openstack.org/607314 | |
| 16:53:13 | cdent | sean-k-mooney: I was "less meetings is good" in reponse to gibi. My syntax very bad. | |
| 16:53:54 | sean-k-mooney | cdent: yes as a sane person that was my assumtion | |
| 16:55:16 | sean-k-mooney | cdent: actully since your about. we still block live migration with config drive to fail right | |
| 16:56:06 | gibi | cdent: :) | |
| 16:56:34 | cdent | sean-k-mooney: that is not an area of expertise for me, but a hazy memory suggests that's the case | |
| 16:57:10 | openstackgerrit | Merged openstack/nova stable/pike: Fix host validity check for live-migration https://review.openstack.org/590263 | |
| 16:57:18 | sean-k-mooney | cdent: oh ok i had a vague memory that you were invovled in adding config drive at some point | |
| 16:57:41 | sean-k-mooney | cdent: in either case it does which is what i was expecting | |
| 16:57:45 | cdent | not me, unless I blacked it out | |
| 16:58:24 | sean-k-mooney | cdent: yes that would be a sensable thing to do if you had worked on config drive :P | |
| 16:59:44 | sean-k-mooney | that abit unfiar to config drive as it actully works prettry in limited usescaes but live migration is not one of them | |
| 16:59:52 | openstackgerrit | Elod Illes proposed openstack/nova stable/ocata: Add check for invalid allocation amounts https://review.openstack.org/607320 | |
| 16:59:53 | openstackgerrit | Elod Illes proposed openstack/nova stable/ocata: Add check for invalid inventory amounts https://review.openstack.org/607321 | |
| 17:32:56 | cfriesen | So what's the process for getting a specless blueprint approved? One of my coworkers opened up https://blueprints.launchpad.net/nova/+spec/support-hpet-on-guest and there's code up as well. Should he be using the runway system once the blueprint is approved? It's just the one commit. | |
| 17:50:03 | melwitt | cfriesen: usually when seeking specless blueprint approval, you can add it to the Open Discussion section of the next nova meeting agenda | |
| 17:50:23 | cfriesen | melwitt: thanks, that works | |
| 17:50:30 | melwitt | using the runway system after approval is good for attracting review attention | |
| 17:51:51 | gryf | artom: unfortunately, I'm afk right now. Which time zone are you in? | |
| 17:57:19 | openstackgerrit | Eric Fried proposed openstack/nova master: Placement: Remove usage of get_legacy_facade() https://review.openstack.org/607336 | |
| 17:58:24 | efried | melwitt, cdent: ^ | |
| 18:43:07 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | |
| 18:48:50 | artom | gryf, GMT-4 (NA east coast) | |
| 18:48:54 | artom | gryf, email? | |
| 18:52:06 | dansmith | mriedem: https://review.openstack.org/#/c/607296 | |
| 18:55:44 | mriedem | done | |
| 19:07:48 | bauzas | dansmith: mriedem: a few other people interested in, I finally reworked the reshaper change https://review.openstack.org/599208 | |
| 19:07:55 | bauzas | I'll test it on a devstack | |
| 19:08:04 | bauzas | with a machine having pGPUs | |
| 19:10:17 | mriedem | :( this is all half-baked https://review.openstack.org/#/q/topic:bug/1384637+(status:open+OR+status:merged) | |
| 19:10:31 | mriedem | none of that plumbing was ever leveraged by the REST API | |
| 19:10:39 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Update blueprint name so spec matches launchpad https://review.openstack.org/607347 | |
| 19:15:58 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Dynamically find releases for move-implemented-specs https://review.openstack.org/592628 | |
| 19:15:59 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Add a script for counting blueprints https://review.openstack.org/581914 | |
| 19:17:26 | cfriesen | if anyone feels like a spec review, the updated emulated TPM spec is up at https://review.openstack.org/#/c/571111 There are no API changes, the spec is really to allow discussion of the concept. | |
| 19:19:19 | sean-k-mooney | cfriesen: i assume the only enduser fasing change would be an image property or flavor extra spec to enable/request teh vtpm | |
| 19:19:43 | cfriesen | sean-k-mooney: flavor extra spec, yes. the rest is virt driver backend stuff | |
| 19:28:59 | sean-k-mooney | ill review it in detail tomorow but initall feedback is i would proably expect 2 extra_spec argument one to specify the tpm verion and another for the backend type. other then that it would be nice to support this via the image metadata too but after 5 mins skiming it it seams resonable | |
| 19:29:55 | sean-k-mooney | i seam to recall form the PTG there were some live migration requirements too which i did not see explcitly in the spec. if so proabley a good idea to add them | |
| 19:33:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Fail count in API https://review.openstack.org/607352 | |
| 19:34:13 | artom | dansmith, mriedem, ^^ really easy spec about the fail count discussion earlier | |
| 19:35:05 | dansmith | hmm | |
| 19:35:16 | bauzas | artom: I thought we said to deprecate os-hypervisors API ? | |
| 19:35:22 | bauzas | at least not adding more to it | |
| 19:35:31 | artom | bauzas, seriously? I had no idea. | |
| 19:35:48 | artom | Nothing in the api-ref about it | |
| 19:35:51 | dansmith | and that fail count is an internal value that can change | |
| 19:36:05 | mriedem | artom wasn't at the ptg when os-hypervisors was discussed... | |
| 19:36:09 | artom | I mean, I'm not looking for +W fast track here :) | |
| 19:36:09 | dansmith | so I'm kinda meh about exposing it and having people make up beliefs about what it means | |
| 19:36:21 | artom | So if there are legit issues, destroy at will | |
| 19:36:50 | artom | We could find other ways of indicating the same information, if y'all agree the basic idea is worthwhile | |
| 19:37:09 | bauzas | can't we just emit a notification ? | |
| 19:37:21 | bauzas | stupid idea maybe | |
| 19:37:25 | artom | And if y'all don't, I'm cool as well, NUMA live migration is quite enough for me ;) | |
| 19:51:48 | cfriesen | sean-k-mooney: thanks. to allow it in the image we'd have to use the "trait" as specified in the alternatives section. I'd be fine with that too, I just went with a resource because Eric Fried suggested it. :) | |
| 19:54:46 | cfriesen | sean-k-mooney: live migration is fine, and cold migration is covered in the spec | |
| 19:55:01 | artom | bauzas, notifications I don't think are very useful, but logs would definitely work | |
| 19:55:16 | artom | To be honest, not sure why I didn't go there in the first place | |
| 19:56:11 | cfriesen | artom: probably cause mriedem was talking about the os-hypervisors API this morning | |
| 19:56:56 | artom | mriedem, see, totally your fault. | |
| 19:57:43 | bauzas | I wasn't looking at the IRC discussion this 'US' morning | |
| 19:57:53 | bauzas | what was the point ? | |
| 19:58:12 | artom | The hell, we already log weighed hosts | |
| 19:58:15 | sean-k-mooney | cfriesen: cool am i would have to read the spec properly to understand traits vs reousce comment but ill take your word for it. i had assumed we could have HW_VTPM_TYPE=emulated HW_VTPM_VERSION=2.0 image property pair and have nova construt the resouce request form that but perhaps there is a reason that would not work that i missed | |
| 19:59:16 | mriedem | "(11:27:58 AM) artom: Btw, this would be a think we should probably expose in the hypervisors API or something" | |
| 19:59:28 | artom | mriedem, sshh, let me have this | |
| 19:59:41 | sean-k-mooney | bauzas: the context was artom was trying to recreate the "vm spawns with multiples" issue and injected a fault which resulted in all his instances landing on a host he was not expecting | |
| 20:00:46 | openstackgerrit | Merged openstack/nova stable/ocata: Fix instance evacuation with PCI devices https://review.openstack.org/605881 | |
| 20:00:52 | openstackgerrit | Merged openstack/nova stable/ocata: Update nova network info when doing rebuild for evacuate operation https://review.openstack.org/605882 | |
| 20:00:53 | sean-k-mooney | bauzas: idea was to help debuging perhaps expose it via hyperviors api but i would guess a debug level weigher log might be better in this case | |
| 20:01:09 | artom | Ah, we just log the final sorted list, not the individual weights, nor the per-filter weights | |
| 20:01:15 | bauzas | could we just have alaski back here and just him and me +2/+W a change deprecating multiple-create API ? | |
| 20:01:55 | mriedem | oh god why would we allow attaching volumes to a resized server before it's confirmed/revert | |
| 20:01:57 | mriedem | *reverted | |
| 20:02:01 | mriedem | that's just asking for trouble | |
| 20:02:33 | sean-k-mooney | mriedem: because we did not think that is what we were allowing at the time the code merged ? | |
| 20:03:19 | melwitt | bauzas: users love the multi-create API | |
| 20:03:39 | sean-k-mooney | mriedem: i cound half of the issue with the multiple port bindingings thing by the way. ill file a bug and upload a patch tomorow | |
| 20:03:42 | mriedem | there is a forum session about the multi-create api | |
| 20:03:47 | sean-k-mooney | *found | |
| 20:03:57 | artom | mriedem, I feel like attaching anything to anything that isn't ACTIVE is asking for trouble | |
| 20:04:18 | artom | Like, we should wrap the instance decorator around any method that as 'attach' in its name. | |
| 20:04:28 | artom | *instance state decorator | |
| 20:04:49 | sean-k-mooney | melwitt: do the love the multi create api or multi create support in the client/sdk/osc | |
| 20:05:38 | sean-k-mooney | artom: i think the vm is active in this case on the dest | |
| 20:05:44 | melwitt | mriedem: is it under a more broad topic? I don't see it | |
| 20:05:45 | sean-k-mooney | artom: we just have not confimed it | |
| 20:06:02 | artom | sean-k-mooney, it's still in VERIFY_RESIZE in the API tho | |
| 20:06:07 | artom | I think is what mriedem means | |
| 20:06:10 | melwitt | sean-k-mooney: the API, I think. | |
| 20:06:17 | cfriesen | sean-k-mooney: I'd be open to something like that if people are looking for additional flexibility. making the version explicit would at least protect us if qemu ever supported a newer version | |
| 20:07:05 | sean-k-mooney | cfriesen: you can always default it to 2.0 initally so its optional | |
| 20:07:22 | mriedem | bauzas: melwitt: https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22840 | |
| 20:08:10 | bauzas | melwitt: I'm not against something elsewhere but not in the API :) | |
| 20:08:28 | bauzas | that said, now the ship has sailed... | |
| 20:08:44 | bauzas | I'm pretty sure we'd get lots of arguments if we deprecate it :) | |
| 20:08:52 | sean-k-mooney | mriedem: i would assume the answer to there first quest is ther is no sla followed by there is no test coverage for that usecase | |
| 20:09:32 | mriedem | i tested how you can kill the scheduler https://review.openstack.org/#/c/507918/ | |
| 20:09:34 | mriedem | if that helps | |