*** dpawlik has quit IRC | 00:01 | |
openstackgerrit | Merged openstack/nova master: add caching to _build_regex_range https://review.openstack.org/599071 | 00:02 |
---|---|---|
*** brinzhang has joined #openstack-nova | 00:03 | |
*** openstackgerrit has quit IRC | 00:09 | |
*** brinzh has joined #openstack-nova | 00:09 | |
*** brinzh has quit IRC | 00:12 | |
*** tbachman has joined #openstack-nova | 00:37 | |
*** tbachman has quit IRC | 00:41 | |
*** tbachman has joined #openstack-nova | 00:47 | |
*** ircuser-1 has joined #openstack-nova | 00:53 | |
*** hongbin has joined #openstack-nova | 01:09 | |
*** openstackgerrit has joined #openstack-nova | 01:16 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add post-test hook for testing evacuate https://review.openstack.org/602174 | 01:16 |
*** mrsoul has quit IRC | 01:44 | |
openstackgerrit | Tao Li proposed openstack/python-novaclient master: Remove the unused instance-name https://review.openstack.org/602520 | 01:45 |
*** lbragstad has joined #openstack-nova | 02:07 | |
*** lbragstad has quit IRC | 02:36 | |
*** dave-mccowan has quit IRC | 02:37 | |
*** lbragstad has joined #openstack-nova | 02:41 | |
openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update https://review.openstack.org/521041 | 02:48 |
*** brinzh has joined #openstack-nova | 03:03 | |
*** brinzhang has quit IRC | 03:07 | |
*** vivsoni has joined #openstack-nova | 03:12 | |
*** trungnv has quit IRC | 03:33 | |
*** udesale has joined #openstack-nova | 03:34 | |
*** oanson has quit IRC | 03:44 | |
*** dpawlik has joined #openstack-nova | 03:57 | |
*** kevinbenton has quit IRC | 04:00 | |
*** kevinbenton has joined #openstack-nova | 04:00 | |
*** pooja_jadhav has joined #openstack-nova | 04:00 | |
*** dpawlik has quit IRC | 04:02 | |
*** udesale has quit IRC | 04:03 | |
*** udesale has joined #openstack-nova | 04:24 | |
*** udesale has quit IRC | 04:25 | |
*** udesale has joined #openstack-nova | 04:25 | |
*** eandersson has quit IRC | 04:36 | |
*** jiaopengju has quit IRC | 04:38 | |
*** jiaopengju has joined #openstack-nova | 04:39 | |
*** sapd1_ has quit IRC | 04:44 | |
*** sapd1__ has joined #openstack-nova | 04:44 | |
*** whoami-rajat has joined #openstack-nova | 05:07 | |
*** janki has joined #openstack-nova | 05:32 | |
*** sapd1__ has quit IRC | 05:50 | |
*** sapd1 has joined #openstack-nova | 05:51 | |
*** belmoreira has joined #openstack-nova | 05:55 | |
*** Luzi has joined #openstack-nova | 06:00 | |
*** hongbin has quit IRC | 06:00 | |
*** holser|ptg has joined #openstack-nova | 06:03 | |
*** holser|p_ has joined #openstack-nova | 06:05 | |
*** holser|ptg has quit IRC | 06:05 | |
*** dpawlik has joined #openstack-nova | 06:07 | |
*** rnoriega has quit IRC | 06:17 | |
*** rnoriega has joined #openstack-nova | 06:20 | |
*** adrianc has joined #openstack-nova | 06:23 | |
*** maciejjozefczyk has joined #openstack-nova | 06:29 | |
*** luksky has joined #openstack-nova | 06:34 | |
*** udesale has quit IRC | 06:38 | |
*** udesale has joined #openstack-nova | 06:40 | |
*** udesale has quit IRC | 06:45 | |
*** vivsoni has quit IRC | 06:48 | |
openstackgerrit | huanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state https://review.openstack.org/598084 | 06:59 |
*** slaweq has joined #openstack-nova | 07:00 | |
*** giblet is now known as gibi | 07:02 | |
gibi | good morning | 07:02 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/601047 | 07:04 |
*** luksky has quit IRC | 07:10 | |
*** rcernin has quit IRC | 07:11 | |
*** maciejjozefczyk has quit IRC | 07:19 | |
*** eandersson has joined #openstack-nova | 07:19 | |
*** holser|p_ is now known as holser_ | 07:24 | |
bauzas | good morning nova | 07:28 |
* bauzas yawns and streches | 07:28 | |
*** priteau has joined #openstack-nova | 07:30 | |
*** maciejjozefczyk has joined #openstack-nova | 07:31 | |
gibi | bauzas: good morning | 07:40 |
gibi | bauzas: I'm still working on the rebase of the nested allocation candidate patch series. I hope I can push it today | 07:40 |
bauzas | gibi: good morning, hope you're not too jetlaggued | 07:40 |
bauzas | gibi: no worries, I was doing the same | 07:41 |
gibi | bauzas: I'm pretty OK actually. Yesteday I slept 15 hours in a row | 07:41 |
bauzas | gibi: and I need to understand tetsuro's changes | 07:41 |
bauzas | wow | 07:41 |
bauzas | I'm happy for you | 07:41 |
bauzas | for me, I looked for 5 mins where my keys were in my car when going back from the school | 07:41 |
bauzas | but then I saw they were still on the door... | 07:42 |
gibi | :) jetlag is a nasty thing | 07:42 |
*** sambetts_ has quit IRC | 07:42 | |
bauzas | :) | 07:42 |
gibi | I had my moment yesterday too. I forget like 3 times that I left half of the grocery in the car | 07:43 |
gibi | the first day is always about survival :) | 07:44 |
bauzas | lol | 07:44 |
*** sambetts_ has joined #openstack-nova | 07:45 | |
*** luksky has joined #openstack-nova | 07:49 | |
*** jpena|off is now known as jpena | 07:50 | |
*** lpetrut has joined #openstack-nova | 07:52 | |
*** slaweq has quit IRC | 08:00 | |
*** slaweq has joined #openstack-nova | 08:03 | |
*** vivsoni has joined #openstack-nova | 08:03 | |
*** vivsoni_ has joined #openstack-nova | 08:03 | |
*** gameon has joined #openstack-nova | 08:08 | |
*** plestang has quit IRC | 08:08 | |
openstackgerrit | huanhongda proposed openstack/nova stable/pike: Fix bug case by none token context https://review.openstack.org/603044 | 08:15 |
*** rpittau has joined #openstack-nova | 08:23 | |
*** udesale has joined #openstack-nova | 08:25 | |
*** udesale has quit IRC | 08:27 | |
*** udesale has joined #openstack-nova | 08:28 | |
*** udesale has quit IRC | 08:29 | |
*** udesale has joined #openstack-nova | 08:29 | |
*** udesale has quit IRC | 08:29 | |
*** udesale has joined #openstack-nova | 08:30 | |
kashyap | Does this require a release note, because we're changing the default? https://review.openstack.org/#/c/602592/ ("libvirt: Use 'virt' as the default machine type for ARMv7") | 08:34 |
* bauzas looks | 08:37 | |
bauzas | kashyap: I'd tend to say yes, there is an upgrade impact AFAICS | 08:43 |
kashyap | bauzas: Yeah, let me add a note. But I have no clue how many (if at all) use ARMv7 | 08:44 |
kashyap | bauzas: Thanks for the view! | 08:44 |
bauzas | kashyap: existing guests wouldn't be changed tho, right? | 08:45 |
kashyap | bauzas: It will be *only* if: | 08:46 |
kashyap | (a) Upgrade Nova with this patch; (b) Start and stop the guest -- then, it will pick up this new machine type. | 08:46 |
bauzas | yeah of course | 08:46 |
bauzas | or rebuild | 08:46 |
kashyap | bauzas: So, it won't affect a running guest under its feet. | 08:46 |
kashyap | bauzas: Yep. | 08:46 |
*** udesale has quit IRC | 08:47 | |
bauzas | kashyap: I'm trying to put my feet into app developer shoes | 08:47 |
bauzas | kashyap: I imagine I would be surprised if my guest architecture would be different, hence the relnote | 08:47 |
kashyap | bauzas: Sure. So I'll add an upgrade note. Fine with you? | 08:48 |
bauzas | kashyap: yup | 08:48 |
kashyap | Thanks for looking. | 08:48 |
*** pvc has quit IRC | 08:49 | |
*** udesale has joined #openstack-nova | 08:55 | |
johnthetubaguy | +1 on the upgrade note, sounds like the correct call | 08:58 |
johnthetubaguy | kashyap: interesting questions came up at the PTG around SEV (https://libvirt.org/formatdomain.html#sev) | 09:00 |
johnthetubaguy | kashyap: I was wondering if you had plans around that already? | 09:00 |
kashyap | johnthetubaguy: Hi there, haven't seen you in a while | 09:00 |
*** udesale has quit IRC | 09:01 | |
johnthetubaguy | yeah, busy working with users these days, in a nice way | 09:01 |
kashyap | johnthetubaguy: I am peripherally aware of SEV, as I've seen those patches fly by on QEMU and libvirt lists | 09:01 |
kashyap | johnthetubaguy: Nice | 09:01 |
kashyap | johnthetubaguy: But I don't have plans for that, I'm afraid. My plate is just too full for the next two months. | 09:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations https://review.openstack.org/591597 | 09:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Consumer gen support for put allocations https://review.openstack.org/591647 | 09:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Consumer gen: remove_provider_from_instance_allocation https://review.openstack.org/591784 | 09:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: consumer gen: move_allocations https://review.openstack.org/591810 | 09:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: consumer gen: more tests for delete allocation cases https://review.openstack.org/591811 | 09:01 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: consumer gen: support claim_resources https://review.openstack.org/583667 | 09:01 |
kashyap | johnthetubaguy: Is there an Etherpad discusion about SEV at the PTG? | 09:02 |
*** mrsoul has joined #openstack-nova | 09:02 | |
gibi | bauzas: rebase for the consumer gen support is up ^^ | 09:03 |
johnthetubaguy | kashyap: nothing much of interest, its in the main etherpad, I think it was clear non of us really know how to expose it yet | 09:03 |
kashyap | johnthetubaguy: On this I presume? -- https://etherpad.openstack.org/p/nova-ptg-stein | 09:03 |
gibi | bauzas: I continue with the nested a_c support rebase | 09:03 |
johnthetubaguy | kashyap: yeah, thats the one | 09:03 |
kashyap | johnthetubaguy: Damned if I can find the relevant line (`grep`ed for "SEV", "secure") | 09:04 |
kashyap | Ah, it's line-848 | 09:04 |
kashyap | "Exposing encrypted virtualization to operators" | 09:04 |
bauzas | gibi: oh cool | 09:04 |
*** mschuppert has joined #openstack-nova | 09:04 | |
johnthetubaguy | kashyap: that sounds correct | 09:04 |
bauzas | gibi: don't worry with the a_c rebase | 09:04 |
bauzas | I'd like to upload it | 09:04 |
kashyap | johnthetubaguy: Is that aimed at "Stein" release? | 09:04 |
gibi | bauzas: I need the a_c rebase to rebase the bandwidht series top of it :) | 09:05 |
johnthetubaguy | well, only in the same way everything new is sort of aimed at stein | 09:05 |
gibi | bauzas: but if you working on that that is fine then I will wait | 09:05 |
johnthetubaguy | kashyap: is the intel SGX version going in soon, do you know? | 09:06 |
kashyap | johnthetubaguy: Afraid, I don't know. | 09:06 |
gibi | bauzas: just to be on the safe side. are you rebasing a_c on top of consumer gen support? | 09:07 |
kashyap | johnthetubaguy: I think what you're getting at is we need to take both Intel and AMD into consideration, obviously | 09:07 |
johnthetubaguy | kashyap: no worries, based on a blog I am reading, it sounds like SGX isn't that usable yet https://lwn.net/Articles/686808/ | 09:07 |
kashyap | johnthetubaguy: (Assuming Intel is going to come up w/ a similar thing 'soon') | 09:07 |
kashyap | Ah, the venerable LWN | 09:08 |
johnthetubaguy | kashyap: FWIW, our customer's medical data processing probably needs this at some point, although per host allocation works in the meantime | 09:08 |
kashyap | johnthetubaguy: Seems to be from 2 years ago; wonder what's the state today. But anyway, I don't see this merging anytime soon in Nova | 09:08 |
johnthetubaguy | kashyap: yeah, totally | 09:08 |
bauzas | gibi: I was indeed | 09:08 |
kashyap | Given the complexity of it, and the "head-wrapping" required | 09:08 |
johnthetubaguy | +1 | 09:08 |
bauzas | gibi: now I need to rebase on top of your last update, but that should be fine | 09:09 |
gibi | bauzas: cool | 09:09 |
bauzas | gibi: well, sorry I wasn't clear | 09:10 |
johnthetubaguy | kashyap: feels like it should work a bit like volume encryption, once its working correctly, but want to get my hands on it first, which is hard given my customer is an Intel only shop right now, this might change things I guess! | 09:10 |
johnthetubaguy | kashyap: will let you know if I hear any more | 09:10 |
bauzas | I was working on rebasing tetsuro's branch on top of master | 09:10 |
*** vivsoni_ has quit IRC | 09:10 | |
kashyap | johnthetubaguy: Sure. (And yeah, the use cases are definitely critical.) | 09:11 |
bauzas | gibi: most of the conflicts were due to the 1.30 microversion for reshapes | 09:11 |
gibi | bauzas: no problem. If nested a_c support ends up top of top of consumer_gen support then I'm OK. | 09:12 |
bauzas | gibi: yup, I just rebased the whole series | 09:13 |
gibi | bauzas: coolio | 09:13 |
bauzas | gibi: now, rebasing on top of your latest rev should be trivial hopefully | 09:13 |
bauzas | gibi: https://review.openstack.org/#/c/583667/ is the top patch of your series, right? | 09:14 |
openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'virt' as the default machine type for ARMv7 https://review.openstack.org/602592 | 09:14 |
kashyap | bauzas: ^ If you want to put it out of its misery :-) | 09:15 |
*** adrianc has quit IRC | 09:16 | |
*** owalsh_ is now known as owalsh | 09:18 | |
gibi | bauzas: yes, it is | 09:18 |
openstackgerrit | Sylvain Bauza proposed openstack/nova master: Enable nested allocation candidates in scheduler https://review.openstack.org/585672 | 09:21 |
*** tbachman_ has joined #openstack-nova | 09:21 | |
*** tbachman has quit IRC | 09:22 | |
*** tbachman_ is now known as tbachman | 09:22 | |
bauzas | gibi: ^ | 09:23 |
gibi | bauzas: awesome | 09:23 |
*** priteau has quit IRC | 09:23 | |
gibi | bauzas: shall I rebase the functional tests for the change or you will do that too? | 09:24 |
bauzas | gibi: I can try | 09:24 |
gibi | bauzas: if you haven't started yet, then I can continue with the functionals | 09:24 |
bauzas | gibi: fair enough | 09:24 |
*** priteau has joined #openstack-nova | 09:25 | |
bauzas | I'll have to bail out by 11:35 | 09:25 |
gibi | bauzas: then I will jump on the functionals | 09:25 |
bauzas | so I won't have time to fix this | 09:25 |
bauzas | wait a sec, I'll amend tetsuro's change based on your good commebnt | 09:25 |
bauzas | gibi: ^ | 09:25 |
gibi | bauzas: sure | 09:25 |
*** priteau has quit IRC | 09:30 | |
bauzas | gibi: good news is that I checked the unittests with the rebase and they're good | 09:30 |
kashyap | Lately, I've begun doing this when running `git-review`, others too? | 09:32 |
kashyap | $ git review -R --no-custom-script | 09:32 |
openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Remove the allocation ratios adjusting logic https://review.openstack.org/602805 | 09:32 |
openstackgerrit | Sylvain Bauza proposed openstack/nova master: Enable nested allocation candidates in scheduler https://review.openstack.org/585672 | 09:33 |
bauzas | gibi: updated change ^ | 09:33 |
bauzas | gibi: you can rebase functional tests on top of this | 09:33 |
gibi | bauzas: thanks, I will do that | 09:33 |
*** udesale has joined #openstack-nova | 09:38 | |
*** helenafm has joined #openstack-nova | 09:40 | |
*** priteau has joined #openstack-nova | 09:44 | |
openstackgerrit | Brin Zhang proposed openstack/nova master: Resource retrieving: add changes-before filter https://review.openstack.org/599276 | 09:47 |
*** tssurya has joined #openstack-nova | 09:58 | |
*** lpetrut has quit IRC | 09:59 | |
*** brinzh has quit IRC | 10:03 | |
*** oanson has joined #openstack-nova | 10:05 | |
bauzas | naichuans_: sorry, just saw your reply on the ML | 10:05 |
bauzas | naichuans_: I'm back but I'm off until 1140UTC | 10:06 |
bauzas | naichuans_: after that, I think you should be off too | 10:06 |
bauzas | naichuans_: so let's discuss tomorrow if you want | 10:06 |
*** alexchadin has joined #openstack-nova | 10:10 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Functional test for booting with nested resources https://review.openstack.org/527728 | 10:10 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Functional test for moving with nested resources https://review.openstack.org/587350 | 10:10 |
bauzas | gibi: just saw ^ | 10:12 |
bauzas | coolio, that will allow me to add a new functional test | 10:12 |
gibi | bauzas: functional tests passes, but I have to think about what we can consider as enough test coverage | 10:13 |
bauzas | gibi: we need allocation candidates for creating a new instance | 10:16 |
bauzas | needed* | 10:16 |
bauzas | anyway, me is off now | 10:16 |
*** ShilpaSD has joined #openstack-nova | 10:18 | |
*** dtantsur|afk is now known as dtantsur | 10:18 | |
*** belmoreira has quit IRC | 10:22 | |
*** finucannot is now known as stephenfin | 10:34 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add request_spec.RequestGroup versioned object https://review.openstack.org/568840 | 10:39 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267 | 10:39 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847 | 10:39 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | 10:39 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | 10:39 |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | 10:39 |
*** alexchadin has quit IRC | 10:43 | |
*** tbachman has quit IRC | 10:48 | |
*** alexchadin has joined #openstack-nova | 10:53 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deprecate the unversioned notifications https://review.openstack.org/603079 | 11:08 |
openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: Remove the allocation ratios adjusting logic https://review.openstack.org/602805 | 11:16 |
*** imacdonn has quit IRC | 11:18 | |
*** imacdonn has joined #openstack-nova | 11:19 | |
*** jpena is now known as jpena|lunch | 11:20 | |
*** belmoreira has joined #openstack-nova | 11:22 | |
*** jaypipes has joined #openstack-nova | 11:25 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor NeutronFixture https://review.openstack.org/588338 | 11:29 |
openstackgerrit | Merged openstack/nova master: Fix docs and add functional test for AggregateMultiTenancyIsolation https://review.openstack.org/601835 | 11:31 |
openstackgerrit | John Garbutt proposed openstack/nova master: Deprecate ComputeCapabilitiesFilter https://review.openstack.org/603102 | 11:31 |
*** erlon has quit IRC | 11:36 | |
*** psachin has joined #openstack-nova | 11:43 | |
openstackgerrit | huanhongda proposed openstack/nova stable/pike: Fix bug case by none token context https://review.openstack.org/603044 | 11:45 |
*** alexchadin has quit IRC | 11:48 | |
*** maciejjozefczyk has quit IRC | 11:52 | |
*** adrianc has joined #openstack-nova | 12:04 | |
*** alexchadin has joined #openstack-nova | 12:05 | |
*** alexchadin has quit IRC | 12:06 | |
*** alexchadin has joined #openstack-nova | 12:07 | |
*** tbachman has joined #openstack-nova | 12:18 | |
*** Roamer` has joined #openstack-nova | 12:19 | |
*** Sigyn has quit IRC | 12:19 | |
*** Sigyn has joined #openstack-nova | 12:20 | |
*** jpena|lunch is now known as jpena | 12:22 | |
Roamer` | hi, possibly stupid question incoming :) If a company has two different physical datacenters, and an OpenStack setup in each of them, how would it be best to make it possible to (cold-)migrate instances (with attached volumes) between them? Is there a way to migrate an instance between two regions of the same cluster? The two options I've found so far is "openstack server image create" (which | 12:23 |
Roamer` | creates a zero-byte image for a volume-backed instance, though maybe I've configured something wrong) and cinder backup/restore; are there other options? | 12:23 |
*** tbachman has quit IRC | 12:23 | |
*** tbachman_ has joined #openstack-nova | 12:23 | |
*** janki has quit IRC | 12:25 | |
*** erlon has joined #openstack-nova | 12:39 | |
bauzas | gibi: thanks for the updates | 12:45 |
gibi | bauzas: you are welcome | 12:46 |
gibi | bauzas: I think the series works as my bandwidth functional tests worked on top. But I wouldn't be surprised if migrate or evacuate would eventually be found broken | 12:47 |
bauzas | gibi: for migrate, we at least need to pass allocations | 12:47 |
bauzas | I have an uploaded change for it | 12:47 |
bauzas | to the drivers, I meant | 12:47 |
gibi | bauzas: for VGPU I guess | 12:47 |
bauzas | alas yes | 12:48 |
gibi | bauzas: yeah, that make sense. I also have to work on the bandwidth patch to see migrate works or not as-is. So fare I only have boot and delete tests there | 12:49 |
bauzas | yup, I just wanted to make sure you knew it | 12:50 |
gibi | VGPU and bandwidth differs in a sense that the physical use of the resource for VGPU happens in the virt driver (i.e. generating the proper xml) while for bandwidth it happens in neutron and os-vif. | 12:52 |
gibi | so at the moment I assumes that for bandwidth we don't need the allocations in the virt driver. But I very well be wrong in the SRIOV case due to the pci handling there | 12:53 |
*** udesale has quit IRC | 12:54 | |
bauzas | gibi: ah good point | 12:59 |
*** munimeha1_ has joined #openstack-nova | 13:14 | |
*** alexchadin has quit IRC | 13:14 | |
*** mriedem has joined #openstack-nova | 13:18 | |
*** Tomatosoup- has joined #openstack-nova | 13:23 | |
*** alexchadin has joined #openstack-nova | 13:29 | |
*** psachin has quit IRC | 13:29 | |
mriedem | got a clean run on the evacuate integration test https://review.openstack.org/#/c/602174/ | 13:29 |
mriedem | with no mdbooth around to celebrate | 13:30 |
*** burt has joined #openstack-nova | 13:30 | |
*** Tomatosoup- has quit IRC | 13:31 | |
*** Tomatosoup- has joined #openstack-nova | 13:32 | |
*** Luzi has quit IRC | 13:32 | |
*** belmorei_ has joined #openstack-nova | 13:33 | |
*** belmoreira has quit IRC | 13:33 | |
mriedem | we have something in a runway for stein now https://review.openstack.org/#/c/599276/ | 13:33 |
gibi | mriedem: I've just added the consumer generation support to the runway queue | 13:35 |
mriedem | is that a blueprint? | 13:36 |
mriedem | https://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates isn't approved | 13:36 |
gibi | it is part of bp/use-nested-allocation-candidates | 13:36 |
bauzas | do we started runways ? | 13:37 |
gibi | mriedem: true, then I remove the patches from the queue and bring up the bp on the Thursday meeting for approval | 13:37 |
bauzas | mriedem: FWIW https://review.openstack.org/#/c/527728/22/nova/tests/functional/test_servers.py should cover the boot case | 13:37 |
*** alexchadin has quit IRC | 13:38 | |
kashyap | Dear folks, I can't tell _why_ the 'neutron-grenade' job is failing here: https://review.openstack.org/#/c/602592/ | 13:42 |
kashyap | I'm looking at the "ara-report", but I can't find a log file. | 13:43 |
bauzas | kashyap: http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/job-output.txt.gz | 13:45 |
kashyap | bauzas: Ah, let me look | 13:45 |
bauzas | mmm, actually | 13:46 |
mriedem | http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/logs/devstack-gate-setup-workspace-old.txt | 13:46 |
mriedem | i've seen that in a couple of other jobs but don't know what's causing it | 13:47 |
*** alexchadin has joined #openstack-nova | 13:47 | |
* kashyap clicks | 13:47 | |
kashyap | http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/job-output.txt.gz#_2018-09-17_10_12_38_647361 | 13:47 |
bauzas | http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/job-output.txt.gz#_2018-09-17_11_27_33_877513 | 13:48 |
kashyap | 2018-09-17 10:12:38.647361 | primary | smoke installed: ----------------------------------------,Error when trying to get requirement for VCS system Command "git config --get-regexp remote\..*\.url" failed with error code 1 in /opt/stack/new/tempest, falling back to uneditable format,Could not determine repository location of /opt/stack | 13:48 |
mriedem | that's common | 13:48 |
mriedem | the failure is in http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/logs/devstack-gate-setup-workspace-old.txt | 13:48 |
mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22error%3A%20The%20following%20untracked%20working%20tree%20files%20would%20be%20overwritten%20by%20checkout%3A%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d | 13:48 |
kashyap | Ah, it's the untracked files | 13:49 |
bauzas | http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/logs/devstack-gate-setup-workspace-old.txt | 13:50 |
bauzas | dammit, I'm burned | 13:50 |
kashyap | bauzas: Thought you'll be refreshed after the PTG? | 13:50 |
* bauzas should wear sunglasses | 13:50 | |
kashyap | Ah, _that_ kind of a burn | 13:50 |
bauzas | I am | 13:50 |
bauzas | nah, burned because I'm too slow | 13:50 |
mriedem | someone want to backport this to stable/rocky? https://review.openstack.org/#/c/546920/ | 13:53 |
*** tetsuro has joined #openstack-nova | 13:53 | |
mriedem | someone not on the stable core team... | 13:54 |
*** alexchadin has quit IRC | 13:56 | |
* bauzas looks elsewhere | 13:58 | |
bauzas | stephenfin: ^ ? | 13:59 |
gibi | mriedem: elod is still in Denver but he is back on Wednesday so if nobody take this backport then I can encourage them to take it | 14:00 |
stephenfin | bauzas, mriedem: Sure | 14:00 |
*** awaugama has joined #openstack-nova | 14:00 | |
bauzas | do we have a scheduler meeting ? | 14:00 |
*** gbarros has quit IRC | 14:01 | |
*** alexchadin has joined #openstack-nova | 14:01 | |
mriedem | yes | 14:01 |
openstackgerrit | Stephen Finucane proposed openstack/nova stable/rocky: Fix soft deleting vm fails after "nova resize" vm https://review.openstack.org/603140 | 14:02 |
stephenfin | mriedem, bauzas: as requested ^ | 14:02 |
bauzas | ta | 14:03 |
mriedem | dansmith: if you're ok with what i've proposed for updates in https://review.openstack.org/#/c/579520/ (the volume type spec) then i'll just make those updates myself | 14:09 |
dansmith | looking | 14:09 |
dansmith | mriedem: the latest two small things? sure, but I should re-review the whole thing | 14:11 |
dansmith | if you do the update I'll do that once the caffeine starts hitting my bloodstream | 14:11 |
mriedem | ok, i might not get to that until after the placement meeting | 14:12 |
* dansmith nods | 14:13 | |
*** mlavalle has joined #openstack-nova | 14:23 | |
openstackgerrit | Vlad Gusev proposed openstack/nova stable/pike: [placement] Retry allocation writes server side https://review.openstack.org/590745 | 14:26 |
stephenfin | bauzas: Does this need a reno, actually? https://review.openstack.org/#/c/603140/ | 14:35 |
openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add support specify volume type when boot instance https://review.openstack.org/579520 | 14:42 |
*** belmorei_ has quit IRC | 14:43 | |
mriedem | dansmith: fleshed out the proposed change section and also the specific test scenarios i'd want to see at a minimum ^ | 14:43 |
dansmith | ack | 14:43 |
*** vivsoni has quit IRC | 14:44 | |
*** vivsoni has joined #openstack-nova | 14:44 | |
*** belmoreira has joined #openstack-nova | 14:45 | |
*** artom has joined #openstack-nova | 14:45 | |
mriedem | bauzas: as far as i can tell, the only change i need to make in the libvirt vgpu reshaper patch is the naming convention we discussed at the ptg correct? https://review.openstack.org/#/c/599208/ | 14:48 |
mriedem | <HYPERVISOR_HOSTNAME>_VGPU_<TYPE_NAME> | 14:48 |
dansmith | mriedem: yauntmeta fix up my grammar nits, or just stack something on top? | 14:50 |
mriedem | i'll fix them quick | 14:51 |
dansmith | aight | 14:52 |
*** _d34dh0r53_ is now known as d34dh0r53 | 14:54 | |
* jaypipes logs "yauntmeta" in IRC dictionary... | 14:57 | |
openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Add support specify volume type when boot instance https://review.openstack.org/579520 | 14:58 |
mriedem | dansmith: done | 14:58 |
*** janki has joined #openstack-nova | 14:58 | |
*** bnemec has joined #openstack-nova | 14:59 | |
dansmith | mriedem: also done | 15:00 |
dansmith | mriedem: heading to the twitters | 15:01 |
dansmith | https://twitter.com/get_offmylawn/status/1041703857460412419 | 15:02 |
mriedem | heh | 15:02 |
mriedem | oh chet | 15:02 |
*** betherly has quit IRC | 15:03 | |
*** tetsuro has quit IRC | 15:03 | |
*** tbachman_ has quit IRC | 15:06 | |
*** alexchadin has quit IRC | 15:08 | |
*** luksky has quit IRC | 15:08 | |
bauzas | mriedem: sorry missed your ping | 15:10 |
bauzas | mriedem: yup, I guess, lemme check notes on this | 15:10 |
bauzas | mriedem: there was an upgrade concern, but I feel this should only be written for the multiple types support | 15:11 |
bauzas | I feel => I'm sure | 15:11 |
mriedem | yes multiple gpu types can't be supported until the reshape is done | 15:11 |
bauzas | mriedem: I reproposed the spec FWIW | 15:12 |
bauzas | mriedem: https://review.openstack.org/#/c/602474/ | 15:12 |
bauzas | jaypipes: I know you had concerns on https://review.openstack.org/#/c/602474/ but you eventually got a +2 | 15:13 |
bauzas | jaypipes: my take on this is that I'm fine if someone writes something using YAML | 15:13 |
bauzas | jaypipes: I'll then just use it for multiple VGPU types | 15:13 |
bauzas | (I mean, speaking of the inventory) | 15:13 |
bauzas | if by Stein, nobody proposes it, then I could consider proposing myself for Train | 15:14 |
mriedem | resource provider name looks like it's just a string in the api schema, | 15:14 |
bauzas | for the YAML inventory recording | 15:14 |
mriedem | wonder if we should replace whitespaces with underscores just to be safe | 15:15 |
mriedem | or remove whitespaces | 15:15 |
bauzas | mriedem: I think we agreed on underscores, nope ? | 15:15 |
mriedem | the etherpad says <HYPERVISOR_HOSTNAME>_VGPU_<TYPE_NAME> | 15:15 |
mriedem | the conf docs show: | 15:15 |
mriedem | <HYPERVISOR_HOSTNAME>_VGPU_<TYPE_NAME> | 15:15 |
mriedem | oops | 15:15 |
mriedem | enabled_vgpu_types = GRID K100,Intel GVT-g,MxGPU.2,nvidia-11 | 15:15 |
bauzas | hah, that | 15:16 |
mriedem | so you could have foo.bar.something_VGPU_GRID K100 | 15:16 |
bauzas | for libvirt, there is (AFAIK) only "vendorshit-number" | 15:16 |
bauzas | the above example was for Xen | 15:16 |
bauzas | but yeah, we could try to replace | 15:17 |
bauzas | https://libvirt.org/drvnodedev.html#MDEVCap | 15:18 |
bauzas | "The element has one attribute id which holds an official vendor-supplied identifier for the type. Since 3.4.0" | 15:18 |
*** alexchadin has joined #openstack-nova | 15:18 | |
bauzas | I don't know what "official vendor-supplied ID" means :) | 15:18 |
bauzas | "official" and "vendor-supplied" seem opposite to me | 15:19 |
mriedem | i'm just going to pass the configured type through | 15:23 |
*** alexchadin has quit IRC | 15:23 | |
bauzas | mriedem: uh, I'm being told that this string is just passed thru by the vendor driver to the kernel, period | 15:23 |
bauzas | mriedem: so there is litterally no formatting | 15:23 |
mriedem | and i'm passing it through to placement | 15:23 |
bauzas | and passing to operators | 15:23 |
bauzas | that's awesome | 15:24 |
*** manjeets has joined #openstack-nova | 15:24 | |
mriedem | well the operator is the one that configures nova with the type | 15:24 |
mriedem | so yeah | 15:24 |
jaypipes | bauzas: done. | 15:26 |
jaypipes | bauzas: by "done", I mean I've re-reviewed the Stein vGPU types spec. | 15:26 |
bauzas | jaypipes: gotcha, and thanks | 15:28 |
bauzas | jaypipes: yeah, I think your comment is all good with me | 15:28 |
*** artom has quit IRC | 15:30 | |
bauzas | jaypipes: tbc, I think I can discover certain things like framebuffer size and what's described in https://docs.nvidia.com/grid/6.0/grid-vgpu-user-guide/index.html#vgpu-types-tesla-m60 and others | 15:30 |
bauzas | jaypipes: but GPU capabilities will have to be described by operators directly | 15:30 |
jaypipes | bauzas: what is the user asking for? I've only seen requests for things like "my application is built with CUDA library X and therefore can take advantage of NVIDIA Compute Capability Y hardware, so make sure I get on a GPU that has that Compute Capability". | 15:31 |
bauzas | yeah probably | 15:32 |
bauzas | jaypipes: that's where your idea of an YAML inventory could help | 15:32 |
bauzas | but for the moment, I'm not happy with nova supporting vendor-specific features by code | 15:33 |
bauzas | anyway, speaking of code is better with code | 15:33 |
*** sean-k-mooney has joined #openstack-nova | 15:36 | |
openstackgerrit | Merged openstack/nova-specs master: Add support specify volume type when boot instance https://review.openstack.org/579520 | 15:36 |
mriedem | libvirt reshaper patch updated | 15:38 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | 15:38 |
mriedem | i'm pondering how useful a pre-upgrade check could be for this | 15:38 |
mriedem | as in, i'm not sure how useful it would be since it's not something you can run offline | 15:38 |
mriedem | a pre-upgrade check would mostly be for reporting - yes you have x number of providers of these things and you're going to need to upgrade those via reshaper | 15:39 |
*** alexchadin has joined #openstack-nova | 15:40 | |
mriedem | although...why can't we run this offline? if the vgpu inventory is already on the root compute node provider and has allocations, we can call the reshaper API - the only thing we'd need is the gpu type and we can get that from config | 15:40 |
mriedem | lyarwood: dansmith: ^ | 15:40 |
dansmith | each compute node can have different types, right? | 15:40 |
dansmith | we need the quantity from the virt driver at least | 15:41 |
dansmith | we know which types, but not how many of each | 15:41 |
mriedem | you'd have to run the data migration per compute yes | 15:41 |
dansmith | right now we expose N of one type, IIRC | 15:41 |
mriedem | like the ironic instance flavor one | 15:41 |
dansmith | but you still need data from the compute, not just the types the compute is going to use, AFAIK | 15:41 |
mriedem | isn't that already in placement? | 15:41 |
mriedem | via the inventory record? | 15:41 |
dansmith | for one type, but not the others | 15:42 |
dansmith | bauzas: right? | 15:42 |
mriedem | we don't support multiple types yet | 15:42 |
mriedem | so one vgpu inventory record at most per compute node provider | 15:42 |
dansmith | right, but this is to get us there right? | 15:42 |
mriedem | yes | 15:42 |
dansmith | or your idea is to reshape just the one inventory, | 15:42 |
*** tssurya has quit IRC | 15:42 | |
mriedem | yes | 15:42 |
mriedem | that's what my patch above does | 15:43 |
dansmith | and then let the compute fill it itn? | 15:43 |
dansmith | so, that might work, | 15:43 |
sean-k-mooney | dansmith: one of the issues with vgpus is that while you can have multilpel vgpus on the same pcpu like vm flavors dependng on what you have already created you may not be able to create others since they all share the same resouces | 15:43 |
dansmith | yeah, | 15:43 |
dansmith | so can't we have created some vgpus for guests on different cards that now need to be represented separately but weren't before? | 15:44 |
dansmith | and without a view of the virt driver, that might not be doable | 15:44 |
*** alexchadin has quit IRC | 15:44 | |
* bauzas scrolling back | 15:44 | |
sean-k-mooney | dansmith: perhaps i belive today bauzas has confied the compute agent to only createing 1 vgpu type per host so it might not be be an issue | 15:45 |
bauzas | dansmith: you can get the supported type by looking up the conf optionj | 15:45 |
dansmith | type per host | 15:45 |
bauzas | sean-k-mooney: that's correct, we only support one type | 15:45 |
mriedem | if you changed the configured support vgpu type after creating some inventory/allocations but before reshaping, then we'd have a problem | 15:45 |
bauzas | mriedem: yeah that's a limitation | 15:46 |
dansmith | bauzas: one type per host, but potentially across multiple cards right? | 15:46 |
bauzas | dansmith: correct | 15:46 |
bauzas | libvirt only gives the total | 15:46 |
mriedem | isn't the multiple cards just the total? | 15:46 |
mriedem | yeah | 15:46 |
sean-k-mooney | bauzas: you are proposing a whitelist model where the operator figures out what are compatible ahead of time rather then dynamicaly handeling this in nova/cyborg. that is deffinetly a step forward but may not cover all usecases well | 15:46 |
dansmith | so can we know externally which instance should go to which new (separate) card provider? | 15:46 |
bauzas | it can be sharded across cards | 15:46 |
mriedem | tbc, | 15:46 |
dansmith | presumably post-reshape, each allocation is against a single card for affinity reasons, right? | 15:46 |
mriedem | my patch isn't creating multiple vgpu providers | 15:46 |
dansmith | since they will eventually be tied to numa nodes | 15:47 |
bauzas | dansmith: that's right | 15:47 |
bauzas | dansmith: in my spec, I'm proposing the PCI ID as a way to know which card is for which type | 15:47 |
mriedem | so we're going to have 1 vgpu child provider per card with a total inventory of 1? | 15:47 |
bauzas | dansmith: what is uncovered in my spec is how an user can ask a certain type | 15:48 |
dansmith | mriedem: no, | 15:48 |
dansmith | mriedem: one card with however many vgpus it can support, right? | 15:48 |
dansmith | one card per provider I mean | 15:48 |
bauzas | mriedem: dansmith: no, it will create N children inventories, one per type | 15:48 |
sean-k-mooney | dansmith: well even with out numa restictions that would be required as the shader units cannot pysically acess the ram on another card. at least not without an explictit direct dma | 15:48 |
mriedem | i guess i just need someone to tell me if https://review.openstack.org/599208 is the correct direction or not | 15:48 |
dansmith | bauzas: right, N inventories per M providers for M cards, yes? | 15:48 |
bauzas | where the total of that inventory being the aggregated amount of capacity for each card | 15:48 |
mriedem | for existing inventory/allocations | 15:48 |
bauzas | dansmith: one PCI ID only supporting one type | 15:49 |
*** dklyle has quit IRC | 15:49 | |
dansmith | sean-k-mooney: ack yeah, and the allocations are not fungible.. | 15:49 |
dansmith | bauzas: I think you're confusing what I'm asking | 15:49 |
bauzas | probably | 15:50 |
bauzas | :) | 15:50 |
dansmith | sean-k-mooney: btw, my inventory of 4 crunchie bars has been 75% allocated, with 25% now free | 15:50 |
*** dklyle has joined #openstack-nova | 15:50 | |
bauzas | dansmith: lemme try to clarify my spec for multiple types | 15:50 |
sean-k-mooney | dansmith: haha next time ill have to bring a larger consignment | 15:50 |
bauzas | dansmith: the operator defines which types he wants | 15:51 |
dansmith | sean-k-mooney: get your importer license | 15:51 |
dansmith | bauzas: I don't think we're talking about your spec | 15:51 |
bauzas | dansmith: for each type, he has to mention which PCI IDs will be supported | 15:51 |
bauzas | oh | 15:51 |
bauzas | then I'm confused :) | 15:51 |
dansmith | I think we're talking about how to reshape from the controller (or not) | 15:51 |
bauzas | mriedem's patch ? | 15:51 |
bauzas | it's simple in my mind | 15:51 |
bauzas | we only support one type | 15:51 |
bauzas | reshaping will just create a child with the exact same inventory | 15:52 |
bauzas | and move allocations against it | 15:52 |
sean-k-mooney | bauzas: do we today supprot 2+ pgpus on a host | 15:52 |
bauzas | sean-k-mooney: yup, but they are hidden for libvirt | 15:52 |
mriedem | bauzas: and that's what i've implemented | 15:53 |
bauzas | mriedem: I know | 15:53 |
bauzas | hence my +1 | 15:53 |
bauzas | so i don't get the concerns | 15:53 |
bauzas | having multiple cards isn't a problem | 15:53 |
bauzas | or I'm missing a crucial point | 15:53 |
bauzas | I mean, I can be wrong but I don't get the problem | 15:53 |
dansmith | bauzas: presumably we want to reshape inventories onto providers that represent actual cards, right? | 15:54 |
bauzas | dansmith: no | 15:54 |
sean-k-mooney | bauzas: i would have assumed that as part of reshaper we would have had to devide that compinded inventory across the pGPUs no ? | 15:54 |
dansmith | not just reshape onto a provider that matches the one type we support today? | 15:54 |
dansmith | bauzas: why not? | 15:54 |
bauzas | dansmith: no, because once we support multiple types, they will still hide the fact that each type can be supported on N possible pGPUs | 15:54 |
dansmith | how is that helpful? | 15:55 |
dansmith | meaning, | 15:55 |
*** belmoreira has quit IRC | 15:55 | |
dansmith | how does that help us represent the physical numa affinity? | 15:55 |
sean-k-mooney | bauzas: you can hide that but you can also get the info via libvirt and expose it | 15:55 |
dansmith | and, presumably a guest that wants 4 vgpus won't (presumably) be happy with 2 from 2 separate cards? | 15:55 |
sean-k-mooney | dansmith: actully i think 4vgpus form 2 cards should be ok | 15:56 |
bauzas | dansmith: ah shit, for NUMA affinity, topology is important | 15:56 |
dansmith | sean-k-mooney: not if they look to be on the same NUMA node but aren't, right? | 15:56 |
*** icey has quit IRC | 15:56 | |
bauzas | shit shit shit | 15:56 |
dansmith | ... | 15:56 |
dansmith | isn't this the whole discussion we had in denver? | 15:56 |
sean-k-mooney | dansmith: right if they are split across numa nodes that would be bad | 15:56 |
dansmith | sean-k-mooney: right | 15:56 |
dansmith | I'm confused about why we had that discussion and are now having it again :) | 15:57 |
sean-k-mooney | dansmith: but in general they will appear to be 4 different cards to the guest driver so it wont be able to tell the difference bar numa effects | 15:57 |
*** icey has joined #openstack-nova | 15:57 | |
dansmith | but I have to jump on a call in a few minutes | 15:57 |
dansmith | sean-k-mooney: sure | 15:57 |
*** helenafm has quit IRC | 15:57 | |
bauzas | dansmith: in https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/add-support-for-vgpu.html#proposed-change we always thought on GPU types | 15:57 |
bauzas | dansmith: yes we barely discussed on NUMA affinity for GPUs | 15:58 |
dansmith | barely/ | 15:58 |
bauzas | dansmith: but in my mind, those were GPU types, and not cards | 15:58 |
dansmith | what was the whole reason to talk about the reshape happening on the compute node, AFAIK :) | 15:58 |
dansmith | anyway, /me -> call | 15:58 |
johnthetubaguy | +1 | 15:59 |
bauzas | mriedem: I just feel I'll necessarly have to help you on the reshaper patch | 15:59 |
bauzas | but I first need to consider whether a child being a pGPU and not a GPU type would change | 16:00 |
sean-k-mooney | bauzas: i think the pGPUs would be childeren of the numa nodes with inventoies of vgpu(types) | 16:02 |
sean-k-mooney | bauzas: we might also want to group pgpus into nvlink aggretates at some point but not now | 16:02 |
bauzas | sean-k-mooney: shhhhhhhhhhhht | 16:03 |
mriedem | bauzas: clearly. i only shat this out b/c it seemed trivial. i never made the link between the numa node stuff in the vgpu reshaper discussions. | 16:04 |
bauzas | sean-k-mooney: some customer could hear us and ask for this feature | 16:04 |
bauzas | mriedem: and my brain fucked on it, I'm sorry | 16:04 |
bauzas | that's where I think it's crucial to see the topology now and in the future | 16:05 |
bauzas | in order to prevent reshapes | 16:05 |
bauzas | we could implement chidren as GPU types and do reshapes later | 16:05 |
bauzas | or we could reshape it now and do the necessary work now | 16:05 |
*** tbachman has joined #openstack-nova | 16:05 | |
bauzas | I think given FFU pain, the less reshapes we have, the better it will be | 16:05 |
bauzas | mriedem: permission to play with your change ? | 16:06 |
mriedem | bauzas: sure | 16:06 |
sean-k-mooney | bauzas: /window splitv | 16:06 |
sean-k-mooney | ... ignore that | 16:06 |
bauzas | call me vim | 16:07 |
sean-k-mooney | bauzas: can you do that in vim? i was setting back up my irc client "weechat" | 16:08 |
bauzas | you can split for sure | 16:08 |
bauzas | mriedem: I'm just afraid of Xen having different RP structure | 16:10 |
bauzas | I know we said the drivers are responsible, but that makes us differ | 16:11 |
sean-k-mooney | bauzas: well im sure hyperv and powervm will likely have different stutures too | 16:11 |
*** gyee has joined #openstack-nova | 16:12 | |
sean-k-mooney | bauzas: is your consern that you would not know the numa affinty of xen. xen report and supports numa affinity and cpu pinning via libvirt. we just dnot have the supprot in the nova driver | 16:13 |
*** holser_ has quit IRC | 16:14 | |
bauzas | sean-k-mooney: no, I'm talking of XenServer driver not reporting GPUs like libvirt | 16:15 |
sean-k-mooney | bauzas: ah ok. i think that is ok provided that does not require use to change the flaovr in some way | 16:15 |
bauzas | right | 16:16 |
bauzas | anyway, now /me has to figure out the best way to lookup which GPU is attached to each running instance | 16:16 |
*** artom has joined #openstack-nova | 16:20 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: implement reshaper for vgpu https://review.openstack.org/599208 | 16:22 |
*** psachin has joined #openstack-nova | 16:28 | |
openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.openstack.org/602201 | 16:36 |
openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.openstack.org/602201 | 16:41 |
*** psachin has quit IRC | 16:43 | |
johnthetubaguy | melwitt alex_xu I have attempted to capture the unified limits discussion here in here, still not complete, but getting closer: https://review.openstack.org/602201 | 16:43 |
*** psachin has joined #openstack-nova | 16:48 | |
bauzas | mriedem: thanks for the last update on libvirt reshape, I now see your TODO(sbauza) and the direction it goes | 16:50 |
bauzas | mriedem: starting from now, I'll test this by changing to create a child per pGPU | 16:50 |
* bauzas goes AWOL but will probably be around tonight | 16:52 | |
*** dtantsur is now known as dtantsur|afk | 16:54 | |
*** cfriesen has joined #openstack-nova | 16:56 | |
*** artom has quit IRC | 17:04 | |
*** artom has joined #openstack-nova | 17:05 | |
*** efried has joined #openstack-nova | 17:08 | |
*** jpena is now known as jpena|off | 17:11 | |
*** efried is now known as efried_off | 17:12 | |
*** artom has quit IRC | 17:15 | |
*** med_ has joined #openstack-nova | 17:24 | |
*** devananda has joined #openstack-nova | 17:28 | |
*** luksky has joined #openstack-nova | 17:35 | |
*** psachin has quit IRC | 17:40 | |
cfriesen | sean-k-mooney: bauzas: curious what you think of https://bugs.launchpad.net/nova/+bug/1792985. Huge bug write-up for what would be a small code change. | 17:46 |
openstack | Launchpad bug 1792985 in OpenStack Compute (nova) "strict NUMA memory allocation for 4K pages leads to OOM-killer" [Undecided,New] | 17:46 |
sean-k-mooney | cfriesen: we have spoken about that in the past | 17:53 |
sean-k-mooney | cfriesen: its because the reserved memory is global not per numa node | 17:53 |
cfriesen | sean-k-mooney: I'm talking about actual instance memory, so reserved shouldn't be involved | 17:54 |
*** david-lyle has joined #openstack-nova | 17:54 | |
cfriesen | sean-k-mooney: for a floating instance, it can allocate memory from any numa node | 17:54 |
sean-k-mooney | cfriesen: reserved should because it will prevent schduing to that node so we dont exaust the memory on one numa node | 17:54 |
*** priteau has quit IRC | 17:55 | |
sean-k-mooney | cfriesen: when you set a mem page size it created a numa node of 1 | 17:55 |
cfriesen | sean-k-mooney: if you don't specify a page size, there is no instance numa_topology | 17:55 |
sean-k-mooney | cfriesen: so its now confied to float over one numa node | 17:55 |
sean-k-mooney | yes but if you dont specify a page size of 4 k we dont set the numa tune element at all unless you specify some else that created the numa topologyy | 17:56 |
cfriesen | sean-k-mooney: the scenario is this: one floating instance that can allocate from any numa node. one instance (with pci device maybe) that is pinned to a single numa node and can't allocate because the other instance consumed all the memory from that node. | 17:57 |
*** dklyle has quit IRC | 17:57 | |
sean-k-mooney | cfriesen: this xml | 17:57 |
sean-k-mooney | <numatune> | 17:57 |
sean-k-mooney | <memory mode='strict' nodeset='0'/> | 17:57 |
sean-k-mooney | <memnode cellid='0' mode='strict' nodeset='0'/> | 17:57 |
sean-k-mooney | </numatune> | 17:57 |
sean-k-mooney | will not be genergated unless the guest has a numa toployt of 1 either implictly or implcitly | 17:58 |
sean-k-mooney | *explictly | 17:58 |
cfriesen | sean-k-mooney: yes, that's the one with the pci device | 17:58 |
cfriesen | which is pinned to a numa node | 17:58 |
sean-k-mooney | right so the behavor is correct | 17:58 |
cfriesen | no, because the "floating" instance may have consumed all the memory from that node | 17:59 |
sean-k-mooney | the issue is we do not have a per numa reserved memory so we can exaust one numa node and trigger oom | 17:59 |
cfriesen | so either we restrict floating instances to a single numa node, or else we can't use "strict" for the "memory mode" line | 17:59 |
sean-k-mooney | cfriesen: we already no you cannot mix numa affined instances with non numa instances on a singel host for this exact reason | 18:00 |
cfriesen | sean-k-mooney: but you can, because you can specify a pci device which implicitly makes it numa-affined | 18:00 |
sean-k-mooney | cfriesen: we could fix this but we tell operators that this is not ok and use host aggreate to seperate these flavors today | 18:00 |
sean-k-mooney | cfriesen: you mean by neutron sriov ports | 18:01 |
sean-k-mooney | cfriesen: that is true | 18:01 |
sean-k-mooney | cfriesen: i would be ok with introduceing the hw:numa_mem_policy extra spec that was originally proposed for hyper v to allowchanging the mode but it messes up our accounting in placement if we do | 18:02 |
*** janki has quit IRC | 18:04 | |
sean-k-mooney | that said another way to resolve this would be to allways specify a page size so your floating instances would be hw:mem_page_size=small or 4k | 18:04 |
cfriesen | sean-k-mooney: I was thinking we could literally just remove the "memory mode=strict" line. That would make us use the linux default, which is local allocation. | 18:04 |
sean-k-mooney | cfriesen: if we remove it for 4k why would we not allow it for any page size | 18:05 |
cfriesen | sean-k-mooney: explicitly specifying page size would limit them to a single numa node, which we had before but removed. | 18:05 |
cfriesen | sean-k-mooney: adding hugepages explicitly results in a numa-topology and being restricted to a single node. | 18:05 |
sean-k-mooney | cfriesen: in nova yes but qemu does not require that | 18:06 |
cfriesen | sean-k-mooney: I suspect that people using hugepages care about performance, while people using the default pagesize and floating instances don't. :) | 18:06 |
*** artom has joined #openstack-nova | 18:06 | |
sean-k-mooney | cfriesen: so the defautl is stict and you opt out | 18:07 |
*** artom has quit IRC | 18:07 | |
sean-k-mooney | cfriesen: that argument will never win with me because i argued that none of the implit behavior should have existied for the start | 18:07 |
*** artom has joined #openstack-nova | 18:07 | |
cfriesen | sean-k-mooney: I'd rather have the default be something that doesn't lead to the OOM-killer. Then if you've engineered the cluster to avoid the problem you can opt-in to "strict" | 18:09 |
sean-k-mooney | cfriesen: prefer will break us one memory is reported in placement as we will nologer no where the memory was consumed form | 18:10 |
*** openstackgerrit has quit IRC | 18:10 | |
cfriesen | sean-k-mooney: we already don't know where it's consumed from. we just think we do. :) | 18:10 |
cfriesen | for the floating instances, at least | 18:10 |
sean-k-mooney | cfriesen: we know when we explcitly state a page size | 18:10 |
cfriesen | sean-k-mooney: yes | 18:10 |
sean-k-mooney | for floating instance we dont touch the numa toplogy blob. | 18:11 |
*** jiapei has joined #openstack-nova | 18:11 | |
sean-k-mooney | so its fine | 18:11 |
sean-k-mooney | the numa toplogy blob heals based on the periodic task | 18:11 |
cfriesen | sean-k-mooney: sure, each is fine in isolation. but as soon as you have numa-affined and non-numa-affined instances on the same numa node all bets are off. | 18:11 |
cfriesen | (with "strict" at least) | 18:12 |
sean-k-mooney | cfriesen: yes so perhaps we should use a filter to prevent that | 18:12 |
*** adrianc has quit IRC | 18:13 | |
cfriesen | worth considering. anyways, gotta run. thanks for the feedback | 18:13 |
sean-k-mooney | :) sorry it was not more positve | 18:13 |
*** harlowja has joined #openstack-nova | 18:24 | |
*** openstackgerrit has joined #openstack-nova | 18:27 | |
openstackgerrit | Merged openstack/nova stable/rocky: Fix soft deleting vm fails after "nova resize" vm https://review.openstack.org/603140 | 18:27 |
mriedem | johnthetubaguy: you asked why remove the old warts from the compute API in a microversion? i have one answer: because i have to always lookup those stupid "OS-EXT-SRV-ATTR" prefixes when writing client side code for the server response | 18:53 |
mriedem | i know the host is in the response when showing server details as admin, but i can never remember the stupid prefix on the response field | 18:53 |
mriedem | mordred: can i get an amen?! ^ | 18:54 |
*** hemna_ has quit IRC | 18:55 | |
*** hemna_ has joined #openstack-nova | 18:57 | |
*** alexchadin has joined #openstack-nova | 18:59 | |
mriedem | gmann: alex_xu: i've left some comments on https://review.openstack.org/#/c/599276/ but we should probably discuss when we can change additionalProperties=False in the GET /servers(/detail) APIs | 19:19 |
mriedem | i'll send something to the ML | 19:19 |
*** alexchadin has quit IRC | 19:32 | |
mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-September/134748.html | 19:32 |
*** tbachman has quit IRC | 19:54 | |
*** tbachman has joined #openstack-nova | 19:54 | |
*** tbachman has quit IRC | 19:54 | |
*** med_ has quit IRC | 20:01 | |
*** diablo_rojo has joined #openstack-nova | 20:03 | |
mordred | mriedem: amen | 20:13 |
*** lbragstad has quit IRC | 20:26 | |
*** lbragstad has joined #openstack-nova | 20:27 | |
*** tbachman has joined #openstack-nova | 20:37 | |
*** tbachman has quit IRC | 20:41 | |
*** tbachman has joined #openstack-nova | 20:46 | |
*** artom has quit IRC | 20:48 | |
*** med_ has joined #openstack-nova | 20:49 | |
*** med_ has quit IRC | 20:50 | |
*** tbachman has quit IRC | 21:02 | |
*** awaugama has quit IRC | 21:05 | |
*** erlon has quit IRC | 21:18 | |
jaypipes | mriedem: do you want code reviews on https://review.openstack.org/#/c/599208/ or not? | 21:18 |
mriedem | jaypipes: no | 21:18 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge security groups extension response into server view builder https://review.openstack.org/585475 | 21:19 |
mriedem | sounds like it's going to need more work from bauzas | 21:19 |
*** tbachman has joined #openstack-nova | 21:26 | |
*** munimeha1_ has quit IRC | 21:27 | |
jaypipes | mriedem: ack | 21:27 |
*** tbachman has quit IRC | 21:30 | |
*** diablo_rojo has left #openstack-nova | 21:35 | |
*** takashin has joined #openstack-nova | 21:43 | |
alex_xu | johnthetubaguy: thanks a lot, will review it | 21:47 |
*** hemna_ has quit IRC | 21:51 | |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | 22:00 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106 | 22:00 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110 | 22:00 |
*** luksky has quit IRC | 22:02 | |
*** rcernin has joined #openstack-nova | 22:08 | |
*** slaweq has quit IRC | 22:09 | |
*** slaweq has joined #openstack-nova | 22:11 | |
*** mlavalle has quit IRC | 22:14 | |
*** slaweq has quit IRC | 22:15 | |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | 22:23 |
mriedem | when your house is full of the sounds of screaming 7 year old girls and "metal militia" by metallica comes on, | 22:42 |
mriedem | one must drown out the screaming | 22:42 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add scatter-gather-single-cell utility https://review.openstack.org/594947 | 22:46 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge extended_volumes extension response into server view builder https://review.openstack.org/596285 | 22:46 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6) https://review.openstack.org/574113 | 22:51 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7) https://review.openstack.org/574974 | 22:51 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8) https://review.openstack.org/575311 | 22:51 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Making instance/migration listing skipping down cells configurable https://review.openstack.org/592428 | 22:54 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9) https://review.openstack.org/575581 | 22:57 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10) https://review.openstack.org/576017 | 22:57 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11) https://review.openstack.org/576018 | 22:58 |
openstackgerrit | Matt Riedemann proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList https://review.openstack.org/591656 | 23:09 |
*** slaweq has joined #openstack-nova | 23:11 | |
*** devananda has quit IRC | 23:13 | |
mriedem | gmann: there is one open change left in the extension merge series https://review.openstack.org/#/q/topic:bp/api-extensions-merge-stein+(status:open+OR+status:merged) - if you're feeling up to it the extended_volumes one needs to be fixed for the same kind of performance issue as the security groups one | 23:14 |
mriedem | i.e. call it with the list of servers to batch the results rather than one per server in the detail() Case | 23:14 |
*** slaweq has quit IRC | 23:16 | |
*** mriedem is now known as mriedem_away | 23:23 | |
*** jiapei has quit IRC | 23:30 | |
*** tbachman has joined #openstack-nova | 23:43 | |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12) https://review.openstack.org/576019 | 23:44 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13) https://review.openstack.org/576020 | 23:44 |
openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14) https://review.openstack.org/576027 | 23:45 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!