Monday, 2018-09-17

*** dpawlik has quit IRC00:01
openstackgerritMerged openstack/nova master: add caching to _build_regex_range  https://review.openstack.org/59907100:02
*** brinzhang has joined #openstack-nova00:03
*** openstackgerrit has quit IRC00:09
*** brinzh has joined #openstack-nova00:09
*** brinzh has quit IRC00:12
*** tbachman has joined #openstack-nova00:37
*** tbachman has quit IRC00:41
*** tbachman has joined #openstack-nova00:47
*** ircuser-1 has joined #openstack-nova00:53
*** hongbin has joined #openstack-nova01:09
*** openstackgerrit has joined #openstack-nova01:16
openstackgerritMatt Riedemann proposed openstack/nova master: Add post-test hook for testing evacuate  https://review.openstack.org/60217401:16
*** mrsoul has quit IRC01:44
openstackgerritTao Li proposed openstack/python-novaclient master: Remove the unused instance-name  https://review.openstack.org/60252001:45
*** lbragstad has joined #openstack-nova02:07
*** lbragstad has quit IRC02:36
*** dave-mccowan has quit IRC02:37
*** lbragstad has joined #openstack-nova02:41
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update  https://review.openstack.org/52104102:48
*** brinzh has joined #openstack-nova03:03
*** brinzhang has quit IRC03:07
*** vivsoni has joined #openstack-nova03:12
*** trungnv has quit IRC03:33
*** udesale has joined #openstack-nova03:34
*** oanson has quit IRC03:44
*** dpawlik has joined #openstack-nova03:57
*** kevinbenton has quit IRC04:00
*** kevinbenton has joined #openstack-nova04:00
*** pooja_jadhav has joined #openstack-nova04:00
*** dpawlik has quit IRC04:02
*** udesale has quit IRC04:03
*** udesale has joined #openstack-nova04:24
*** udesale has quit IRC04:25
*** udesale has joined #openstack-nova04:25
*** eandersson has quit IRC04:36
*** jiaopengju has quit IRC04:38
*** jiaopengju has joined #openstack-nova04:39
*** sapd1_ has quit IRC04:44
*** sapd1__ has joined #openstack-nova04:44
*** whoami-rajat has joined #openstack-nova05:07
*** janki has joined #openstack-nova05:32
*** sapd1__ has quit IRC05:50
*** sapd1 has joined #openstack-nova05:51
*** belmoreira has joined #openstack-nova05:55
*** Luzi has joined #openstack-nova06:00
*** hongbin has quit IRC06:00
*** holser|ptg has joined #openstack-nova06:03
*** holser|p_ has joined #openstack-nova06:05
*** holser|ptg has quit IRC06:05
*** dpawlik has joined #openstack-nova06:07
*** rnoriega has quit IRC06:17
*** rnoriega has joined #openstack-nova06:20
*** adrianc has joined #openstack-nova06:23
*** maciejjozefczyk has joined #openstack-nova06:29
*** luksky has joined #openstack-nova06:34
*** udesale has quit IRC06:38
*** udesale has joined #openstack-nova06:40
*** udesale has quit IRC06:45
*** vivsoni has quit IRC06:48
openstackgerrithuanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state  https://review.openstack.org/59808406:59
*** slaweq has joined #openstack-nova07:00
*** giblet is now known as gibi07:02
gibigood morning07:02
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/60104707:04
*** luksky has quit IRC07:10
*** rcernin has quit IRC07:11
*** maciejjozefczyk has quit IRC07:19
*** eandersson has joined #openstack-nova07:19
*** holser|p_ is now known as holser_07:24
bauzasgood morning nova07:28
* bauzas yawns and streches07:28
*** priteau has joined #openstack-nova07:30
*** maciejjozefczyk has joined #openstack-nova07:31
gibibauzas: good morning07:40
gibibauzas: I'm still working on the rebase of the nested allocation candidate patch series. I hope I can push it today07:40
bauzasgibi: good morning, hope you're not too jetlaggued07:40
bauzasgibi: no worries, I was doing the same07:41
gibibauzas: I'm pretty OK actually. Yesteday I slept 15 hours in a row07:41
bauzasgibi: and I need to understand tetsuro's changes07:41
bauzaswow07:41
bauzasI'm happy for you07:41
bauzasfor me, I looked for 5 mins where my keys were in my car when going back from the school07:41
bauzasbut then I saw they were still on the door...07:42
gibi:) jetlag is a nasty thing07:42
*** sambetts_ has quit IRC07:42
bauzas:)07:42
gibiI had my moment yesterday too. I forget like 3 times that I left half of the grocery in the car07:43
gibithe first day is always about survival :)07:44
bauzaslol07:44
*** sambetts_ has joined #openstack-nova07:45
*** luksky has joined #openstack-nova07:49
*** jpena|off is now known as jpena07:50
*** lpetrut has joined #openstack-nova07:52
*** slaweq has quit IRC08:00
*** slaweq has joined #openstack-nova08:03
*** vivsoni has joined #openstack-nova08:03
*** vivsoni_ has joined #openstack-nova08:03
*** gameon has joined #openstack-nova08:08
*** plestang has quit IRC08:08
openstackgerrithuanhongda proposed openstack/nova stable/pike: Fix bug case by none token context  https://review.openstack.org/60304408:15
*** rpittau has joined #openstack-nova08:23
*** udesale has joined #openstack-nova08:25
*** udesale has quit IRC08:27
*** udesale has joined #openstack-nova08:28
*** udesale has quit IRC08:29
*** udesale has joined #openstack-nova08:29
*** udesale has quit IRC08:29
*** udesale has joined #openstack-nova08:30
kashyapDoes 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 looks08:37
bauzaskashyap: I'd tend to say yes, there is an upgrade impact AFAICS08:43
kashyapbauzas: Yeah, let me add a note.  But I have no clue how many (if at all) use ARMv708:44
kashyapbauzas: Thanks for the view!08:44
bauzaskashyap: existing guests wouldn't be changed tho, right?08:45
kashyapbauzas: 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
bauzasyeah of course08:46
bauzasor rebuild08:46
kashyapbauzas: So, it won't affect a running guest under its feet.08:46
kashyapbauzas: Yep.08:46
*** udesale has quit IRC08:47
bauzaskashyap: I'm trying to put my feet into app developer shoes08:47
bauzaskashyap: I imagine I would be surprised if my guest architecture would be different, hence the relnote08:47
kashyapbauzas: Sure.  So I'll add an upgrade note.  Fine with you?08:48
bauzaskashyap: yup08:48
kashyapThanks for looking.08:48
*** pvc has quit IRC08:49
*** udesale has joined #openstack-nova08:55
johnthetubaguy+1 on the upgrade note, sounds like the correct call08:58
johnthetubaguykashyap: interesting questions came up at the PTG around SEV (https://libvirt.org/formatdomain.html#sev)09:00
johnthetubaguykashyap: I was wondering if you had plans around that already?09:00
kashyapjohnthetubaguy: Hi there, haven't seen you in a while09:00
*** udesale has quit IRC09:01
johnthetubaguyyeah, busy working with users these days, in a nice way09:01
kashyapjohnthetubaguy: I am peripherally aware of SEV, as I've seen those patches fly by on QEMU and libvirt lists09:01
kashyapjohnthetubaguy: Nice09:01
kashyapjohnthetubaguy: But I don't have plans for that, I'm afraid.  My plate is just too full for the next two months.09:01
openstackgerritBalazs Gibizer proposed openstack/nova master: Consumer gen support for delete instance allocations  https://review.openstack.org/59159709:01
openstackgerritBalazs Gibizer proposed openstack/nova master: Consumer gen support for put allocations  https://review.openstack.org/59164709:01
openstackgerritBalazs Gibizer proposed openstack/nova master: Consumer gen: remove_provider_from_instance_allocation  https://review.openstack.org/59178409:01
openstackgerritBalazs Gibizer proposed openstack/nova master: consumer gen: move_allocations  https://review.openstack.org/59181009:01
openstackgerritBalazs Gibizer proposed openstack/nova master: consumer gen: more tests for delete allocation cases  https://review.openstack.org/59181109:01
openstackgerritBalazs Gibizer proposed openstack/nova master: consumer gen: support claim_resources  https://review.openstack.org/58366709:01
kashyapjohnthetubaguy: Is there an Etherpad discusion about SEV at the PTG?09:02
*** mrsoul has joined #openstack-nova09:02
gibibauzas: rebase for the consumer gen support is up ^^09:03
johnthetubaguykashyap: nothing much of interest, its in the main etherpad, I think it was clear non of us really know how to expose it yet09:03
kashyapjohnthetubaguy: On this I presume? -- https://etherpad.openstack.org/p/nova-ptg-stein09:03
gibibauzas: I continue with the nested a_c support rebase09:03
johnthetubaguykashyap: yeah, thats the one09:03
kashyapjohnthetubaguy: Damned if I can find the relevant line (`grep`ed for "SEV", "secure")09:04
kashyapAh, it's line-84809:04
kashyap"Exposing encrypted virtualization to operators"09:04
bauzasgibi: oh cool09:04
*** mschuppert has joined #openstack-nova09:04
johnthetubaguykashyap: that sounds correct09:04
bauzasgibi: don't worry with the a_c rebase09:04
bauzasI'd like to upload it09:04
kashyapjohnthetubaguy: Is that aimed at "Stein" release?09:04
gibibauzas: I need the a_c rebase to rebase the bandwidht series top of it :)09:05
johnthetubaguywell, only in the same way everything new is sort of aimed at stein09:05
gibibauzas: but if you working on that that is fine then I will wait09:05
johnthetubaguykashyap: is the intel SGX version going in soon, do you know?09:06
kashyapjohnthetubaguy: Afraid, I don't know.09:06
gibibauzas: just to be on the safe side.  are you rebasing a_c on top of consumer gen support?09:07
kashyapjohnthetubaguy: I think what you're getting at is we need to take both Intel and AMD into consideration, obviously09:07
johnthetubaguykashyap: 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
kashyapjohnthetubaguy: (Assuming Intel is going to come up w/ a similar thing 'soon')09:07
kashyapAh, the venerable LWN09:08
johnthetubaguykashyap: FWIW, our customer's medical data processing probably needs this at some point, although per host allocation works in the meantime09:08
kashyapjohnthetubaguy: Seems to be from 2 years ago; wonder what's the state today.  But anyway, I don't see this merging anytime soon in Nova09:08
johnthetubaguykashyap: yeah, totally09:08
bauzasgibi: I was indeed09:08
kashyapGiven the complexity of it, and the "head-wrapping" required09:08
johnthetubaguy+109:08
bauzasgibi: now I need to rebase on top of your last update, but that should be fine09:09
gibibauzas: cool09:09
bauzasgibi: well, sorry I wasn't clear09:10
johnthetubaguykashyap: 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
johnthetubaguykashyap: will let you know if I hear any more09:10
bauzasI was working on rebasing tetsuro's branch on top of master09:10
*** vivsoni_ has quit IRC09:10
kashyapjohnthetubaguy: Sure.  (And yeah, the use cases are definitely critical.)09:11
bauzasgibi: most of the conflicts were due to the 1.30 microversion for reshapes09:11
gibibauzas: no problem. If nested a_c support ends up top of top of consumer_gen support then I'm OK.09:12
bauzasgibi: yup, I just rebased the whole series09:13
gibibauzas: coolio09:13
bauzasgibi: now, rebasing on top of your latest rev should be trivial hopefully09:13
bauzasgibi: https://review.openstack.org/#/c/583667/ is the top patch of your series, right?09:14
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Use 'virt' as the default machine type for ARMv7  https://review.openstack.org/60259209:14
kashyapbauzas: ^ If you want to put it out of its misery :-)09:15
*** adrianc has quit IRC09:16
*** owalsh_ is now known as owalsh09:18
gibibauzas: yes, it is09:18
openstackgerritSylvain Bauza proposed openstack/nova master: Enable nested allocation candidates in scheduler  https://review.openstack.org/58567209:21
*** tbachman_ has joined #openstack-nova09:21
*** tbachman has quit IRC09:22
*** tbachman_ is now known as tbachman09:22
bauzasgibi: ^09:23
gibibauzas: awesome09:23
*** priteau has quit IRC09:23
gibibauzas: shall I rebase the functional tests for the change or you will do that too?09:24
bauzasgibi: I can try09:24
gibibauzas: if you haven't started yet, then I can continue with the functionals09:24
bauzasgibi: fair enough09:24
*** priteau has joined #openstack-nova09:25
bauzasI'll have to bail out by 11:3509:25
gibibauzas: then I will jump on the functionals09:25
bauzasso I won't have time to fix this09:25
bauzaswait a sec, I'll amend tetsuro's change based on your good commebnt09:25
bauzasgibi: ^09:25
gibibauzas: sure09:25
*** priteau has quit IRC09:30
bauzasgibi: good news is that I checked the unittests with the rebase and they're good09:30
kashyapLately, I've begun doing this when running `git-review`, others too?09:32
kashyap    $ git review -R --no-custom-script09:32
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Remove the allocation ratios adjusting logic  https://review.openstack.org/60280509:32
openstackgerritSylvain Bauza proposed openstack/nova master: Enable nested allocation candidates in scheduler  https://review.openstack.org/58567209:33
bauzasgibi: updated change ^09:33
bauzasgibi: you can rebase functional tests on top of this09:33
gibibauzas: thanks, I will do that09:33
*** udesale has joined #openstack-nova09:38
*** helenafm has joined #openstack-nova09:40
*** priteau has joined #openstack-nova09:44
openstackgerritBrin Zhang proposed openstack/nova master: Resource retrieving: add changes-before filter  https://review.openstack.org/59927609:47
*** tssurya has joined #openstack-nova09:58
*** lpetrut has quit IRC09:59
*** brinzh has quit IRC10:03
*** oanson has joined #openstack-nova10:05
bauzasnaichuans_: sorry, just saw your reply on the ML10:05
bauzasnaichuans_: I'm back but I'm off until 1140UTC10:06
bauzasnaichuans_: after that, I think you should be off too10:06
bauzasnaichuans_: so let's discuss tomorrow if you want10:06
*** alexchadin has joined #openstack-nova10:10
openstackgerritBalazs Gibizer proposed openstack/nova master: Functional test for booting with nested resources  https://review.openstack.org/52772810:10
openstackgerritBalazs Gibizer proposed openstack/nova master: Functional test for moving with nested resources  https://review.openstack.org/58735010:10
bauzasgibi: just saw ^10:12
bauzascoolio, that will allow me to add a new functional test10:12
gibibauzas: functional tests passes, but I have to think about what we can consider as enough test coverage10:13
bauzasgibi: we need allocation candidates for creating a new instance10:16
bauzasneeded*10:16
bauzasanyway, me is off now10:16
*** ShilpaSD has joined #openstack-nova10:18
*** dtantsur|afk is now known as dtantsur10:18
*** belmoreira has quit IRC10:22
*** finucannot is now known as stephenfin10:34
openstackgerritBalazs Gibizer proposed openstack/nova master: Add request_spec.RequestGroup versioned object  https://review.openstack.org/56884010:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec  https://review.openstack.org/56726710:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes  https://review.openstack.org/57084710:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler  https://review.openstack.org/56726810:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding  https://review.openstack.org/56945910:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request  https://review.openstack.org/57331710:39
*** alexchadin has quit IRC10:43
*** tbachman has quit IRC10:48
*** alexchadin has joined #openstack-nova10:53
openstackgerritBalazs Gibizer proposed openstack/nova master: Deprecate the unversioned notifications  https://review.openstack.org/60307911:08
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Remove the allocation ratios adjusting logic  https://review.openstack.org/60280511:16
*** imacdonn has quit IRC11:18
*** imacdonn has joined #openstack-nova11:19
*** jpena is now known as jpena|lunch11:20
*** belmoreira has joined #openstack-nova11:22
*** jaypipes has joined #openstack-nova11:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor NeutronFixture  https://review.openstack.org/58833811:29
openstackgerritMerged openstack/nova master: Fix docs and add functional test for AggregateMultiTenancyIsolation  https://review.openstack.org/60183511:31
openstackgerritJohn Garbutt proposed openstack/nova master: Deprecate ComputeCapabilitiesFilter  https://review.openstack.org/60310211:31
*** erlon has quit IRC11:36
*** psachin has joined #openstack-nova11:43
openstackgerrithuanhongda proposed openstack/nova stable/pike: Fix bug case by none token context  https://review.openstack.org/60304411:45
*** alexchadin has quit IRC11:48
*** maciejjozefczyk has quit IRC11:52
*** adrianc has joined #openstack-nova12:04
*** alexchadin has joined #openstack-nova12:05
*** alexchadin has quit IRC12:06
*** alexchadin has joined #openstack-nova12:07
*** tbachman has joined #openstack-nova12:18
*** Roamer` has joined #openstack-nova12:19
*** Sigyn has quit IRC12:19
*** Sigyn has joined #openstack-nova12:20
*** jpena|lunch is now known as jpena12: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" (which12: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 IRC12:23
*** tbachman_ has joined #openstack-nova12:23
*** janki has quit IRC12:25
*** erlon has joined #openstack-nova12:39
bauzasgibi: thanks for the updates12:45
gibibauzas: you are welcome12:46
gibibauzas: 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 broken12:47
bauzasgibi: for migrate, we at least need to pass allocations12:47
bauzasI have an uploaded change for it12:47
bauzasto the drivers, I meant12:47
gibibauzas: for VGPU I guess12:47
bauzasalas yes12:48
gibibauzas: 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 there12:49
bauzasyup, I just wanted to make sure you knew it12:50
gibiVGPU 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
gibiso 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 there12:53
*** udesale has quit IRC12:54
bauzasgibi: ah good point12:59
*** munimeha1_ has joined #openstack-nova13:14
*** alexchadin has quit IRC13:14
*** mriedem has joined #openstack-nova13:18
*** Tomatosoup- has joined #openstack-nova13:23
*** alexchadin has joined #openstack-nova13:29
*** psachin has quit IRC13:29
mriedemgot a clean run on the evacuate integration test https://review.openstack.org/#/c/602174/13:29
mriedemwith no mdbooth around to celebrate13:30
*** burt has joined #openstack-nova13:30
*** Tomatosoup- has quit IRC13:31
*** Tomatosoup- has joined #openstack-nova13:32
*** Luzi has quit IRC13:32
*** belmorei_ has joined #openstack-nova13:33
*** belmoreira has quit IRC13:33
mriedemwe have something in a runway for stein now https://review.openstack.org/#/c/599276/13:33
gibimriedem: I've just added the consumer generation support to the runway queue13:35
mriedemis that a blueprint?13:36
mriedemhttps://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates isn't approved13:36
gibiit is part of bp/use-nested-allocation-candidates13:36
bauzasdo we started runways ?13:37
gibimriedem: true, then I remove the patches from the queue and bring up the bp on the Thursday meeting for approval13:37
bauzasmriedem: FWIW https://review.openstack.org/#/c/527728/22/nova/tests/functional/test_servers.py should cover the boot case13:37
*** alexchadin has quit IRC13:38
kashyapDear folks, I can't tell _why_ the 'neutron-grenade' job is failing here: https://review.openstack.org/#/c/602592/13:42
kashyapI'm looking at the "ara-report", but I can't find a log file.13:43
bauzaskashyap: http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/job-output.txt.gz13:45
kashyapbauzas: Ah, let me look13:45
bauzasmmm, actually13:46
mriedemhttp://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/logs/devstack-gate-setup-workspace-old.txt13:46
mriedemi've seen that in a couple of other jobs but don't know what's causing it13:47
*** alexchadin has joined #openstack-nova13:47
* kashyap clicks13:47
kashyaphttp://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/job-output.txt.gz#_2018-09-17_10_12_38_64736113:47
bauzashttp://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/job-output.txt.gz#_2018-09-17_11_27_33_87751313:48
kashyap2018-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/stack13:48
mriedemthat's common13:48
mriedemthe failure is in http://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/logs/devstack-gate-setup-workspace-old.txt13:48
mriedemhttp://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=7d13:48
kashyapAh, it's the untracked files13:49
bauzashttp://logs.openstack.org/92/602592/3/check/neutron-grenade/bfeb3e6/logs/devstack-gate-setup-workspace-old.txt13:50
bauzasdammit, I'm burned13:50
kashyapbauzas: Thought you'll be refreshed after the PTG?13:50
* bauzas should wear sunglasses13:50
kashyapAh, _that_ kind of a burn13:50
bauzasI am13:50
bauzasnah, burned because I'm too slow13:50
mriedemsomeone want to backport this to stable/rocky? https://review.openstack.org/#/c/546920/13:53
*** tetsuro has joined #openstack-nova13:53
mriedemsomeone not on the stable core team...13:54
*** alexchadin has quit IRC13:56
* bauzas looks elsewhere13:58
bauzasstephenfin: ^ ?13:59
gibimriedem: elod is still in Denver but he is back on Wednesday so if nobody take this backport then I can encourage them to take it14:00
stephenfinbauzas, mriedem: Sure14:00
*** awaugama has joined #openstack-nova14:00
bauzasdo we have a scheduler meeting ?14:00
*** gbarros has quit IRC14:01
*** alexchadin has joined #openstack-nova14:01
mriedemyes14:01
openstackgerritStephen Finucane proposed openstack/nova stable/rocky: Fix soft deleting vm fails after "nova resize" vm  https://review.openstack.org/60314014:02
stephenfinmriedem, bauzas: as requested ^14:02
bauzasta14:03
mriedemdansmith: 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 myself14:09
dansmithlooking14:09
dansmithmriedem: the latest two small things? sure, but I should re-review the whole thing14:11
dansmithif you do the update I'll do that once the caffeine starts hitting my bloodstream14:11
mriedemok, i might not get to that until after the placement meeting14:12
* dansmith nods14:13
*** mlavalle has joined #openstack-nova14:23
openstackgerritVlad Gusev proposed openstack/nova stable/pike: [placement] Retry allocation writes server side  https://review.openstack.org/59074514:26
stephenfinbauzas: Does this need a reno, actually? https://review.openstack.org/#/c/603140/14:35
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Add support specify volume type when boot instance  https://review.openstack.org/57952014:42
*** belmorei_ has quit IRC14:43
mriedemdansmith: fleshed out the proposed change section and also the specific test scenarios i'd want to see at a minimum ^14:43
dansmithack14:43
*** vivsoni has quit IRC14:44
*** vivsoni has joined #openstack-nova14:44
*** belmoreira has joined #openstack-nova14:45
*** artom has joined #openstack-nova14:45
mriedembauzas: 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
dansmithmriedem: yauntmeta fix up my grammar nits, or just stack something on top?14:50
mriedemi'll fix them quick14:51
dansmithaight14:52
*** _d34dh0r53_ is now known as d34dh0r5314:54
* jaypipes logs "yauntmeta" in IRC dictionary...14:57
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Add support specify volume type when boot instance  https://review.openstack.org/57952014:58
mriedemdansmith: done14:58
*** janki has joined #openstack-nova14:58
*** bnemec has joined #openstack-nova14:59
dansmithmriedem: also done15:00
dansmithmriedem: heading to the twitters15:01
dansmithhttps://twitter.com/get_offmylawn/status/104170385746041241915:02
mriedemheh15:02
mriedemoh chet15:02
*** betherly has quit IRC15:03
*** tetsuro has quit IRC15:03
*** tbachman_ has quit IRC15:06
*** alexchadin has quit IRC15:08
*** luksky has quit IRC15:08
bauzasmriedem: sorry missed your ping15:10
bauzasmriedem: yup, I guess, lemme check notes on this15:10
bauzasmriedem: there was an upgrade concern, but I feel this should only be written for the multiple types support15:11
bauzasI feel => I'm sure15:11
mriedemyes multiple gpu types can't be supported until the reshape is done15:11
bauzasmriedem: I reproposed the spec FWIW15:12
bauzasmriedem: https://review.openstack.org/#/c/602474/15:12
bauzasjaypipes: I know you had concerns on https://review.openstack.org/#/c/602474/ but you eventually got a +215:13
bauzasjaypipes: my take on this is that I'm fine if someone writes something using YAML15:13
bauzasjaypipes: I'll then just use it for multiple VGPU types15:13
bauzas(I mean, speaking of the inventory)15:13
bauzasif by Stein, nobody proposes it, then I could consider proposing myself for Train15:14
mriedemresource provider name looks like it's just a string in the api schema,15:14
bauzasfor the YAML inventory recording15:14
mriedemwonder if we should replace whitespaces with underscores just to be safe15:15
mriedemor remove whitespaces15:15
bauzasmriedem: I think we agreed on underscores, nope ?15:15
mriedemthe etherpad says <HYPERVISOR_HOSTNAME>_VGPU_<TYPE_NAME>15:15
mriedemthe conf docs show:15:15
mriedem<HYPERVISOR_HOSTNAME>_VGPU_<TYPE_NAME>15:15
mriedemoops15:15
mriedemenabled_vgpu_types = GRID K100,Intel GVT-g,MxGPU.2,nvidia-1115:15
bauzashah, that15:16
mriedemso you could have foo.bar.something_VGPU_GRID K10015:16
bauzasfor libvirt, there is (AFAIK) only "vendorshit-number"15:16
bauzasthe above example was for Xen15:16
bauzasbut yeah, we could try to replace15:17
bauzashttps://libvirt.org/drvnodedev.html#MDEVCap15: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-nova15:18
bauzasI don't know what "official vendor-supplied ID" means :)15:18
bauzas"official" and "vendor-supplied" seem opposite to me15:19
mriedemi'm just going to pass the configured type through15:23
*** alexchadin has quit IRC15:23
bauzasmriedem: uh, I'm being told that this string is just passed thru by the vendor driver to the kernel, period15:23
bauzasmriedem: so there is litterally no formatting15:23
mriedemand i'm passing it through to placement15:23
bauzasand passing to operators15:23
bauzasthat's awesome15:24
*** manjeets has joined #openstack-nova15:24
mriedemwell the operator is the one that configures nova with the type15:24
mriedemso yeah15:24
jaypipesbauzas: done.15:26
jaypipesbauzas: by "done", I mean I've re-reviewed the Stein vGPU types spec.15:26
bauzasjaypipes: gotcha, and thanks15:28
bauzasjaypipes: yeah, I think your comment is all good with me15:28
*** artom has quit IRC15:30
bauzasjaypipes: 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 others15:30
bauzasjaypipes: but GPU capabilities will have to be described by operators directly15:30
jaypipesbauzas: 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
bauzasyeah probably15:32
bauzasjaypipes: that's where your idea of an YAML inventory could help15:32
bauzasbut for the moment, I'm not happy with nova supporting vendor-specific features by code15:33
bauzasanyway, speaking of code is better with code15:33
*** sean-k-mooney has joined #openstack-nova15:36
openstackgerritMerged openstack/nova-specs master: Add support specify volume type when boot instance  https://review.openstack.org/57952015:36
mriedemlibvirt reshaper patch updated15:38
openstackgerritMatt Riedemann proposed openstack/nova master: libvirt: implement reshaper for vgpu  https://review.openstack.org/59920815:38
mriedemi'm pondering how useful a pre-upgrade check could be for this15:38
mriedemas in, i'm not sure how useful it would be since it's not something you can run offline15:38
mriedema 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 reshaper15:39
*** alexchadin has joined #openstack-nova15:40
mriedemalthough...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 config15:40
mriedemlyarwood: dansmith: ^15:40
dansmitheach compute node can have different types, right?15:40
dansmithwe need the quantity from the virt driver at least15:41
dansmithwe know which types, but not how many of each15:41
mriedemyou'd have to run the data migration per compute yes15:41
dansmithright now we expose N of one type, IIRC15:41
mriedemlike the ironic instance flavor one15:41
dansmithbut you still need data from the compute, not just the types the compute is going to use, AFAIK15:41
mriedemisn't that already in placement?15:41
mriedemvia the inventory record?15:41
dansmithfor one type, but not the others15:42
dansmithbauzas: right?15:42
mriedemwe don't support multiple types yet15:42
mriedemso one vgpu inventory record at most per compute node provider15:42
dansmithright, but this is to get us there right?15:42
mriedemyes15:42
dansmithor your idea is to reshape just the one inventory,15:42
*** tssurya has quit IRC15:42
mriedemyes15:42
mriedemthat's what my patch above does15:43
dansmithand then let the compute fill it itn?15:43
dansmithso, that might work,15:43
sean-k-mooneydansmith: 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 resouces15:43
dansmithyeah,15:43
dansmithso 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
dansmithand without a view of the virt driver, that might not be doable15:44
*** alexchadin has quit IRC15:44
* bauzas scrolling back15:44
sean-k-mooneydansmith: 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 issue15:45
bauzasdansmith: you can get the supported type by looking up the conf optionj15:45
dansmithtype per host15:45
bauzassean-k-mooney: that's correct, we only support one type15:45
mriedemif you changed the configured support vgpu type after creating some inventory/allocations but before reshaping, then we'd have a problem15:45
bauzasmriedem: yeah that's a limitation15:46
dansmithbauzas: one type per host, but potentially across multiple cards right?15:46
bauzasdansmith: correct15:46
bauzaslibvirt only gives the total15:46
mriedemisn't the multiple cards just the total?15:46
mriedemyeah15:46
sean-k-mooneybauzas: 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 well15:46
dansmithso can we know externally which instance should go to which new (separate) card provider?15:46
bauzasit can be sharded across cards15:46
mriedemtbc,15:46
dansmithpresumably post-reshape, each allocation is against a single card for affinity reasons, right?15:46
mriedemmy patch isn't creating multiple vgpu providers15:46
dansmithsince they will eventually be tied to numa nodes15:47
bauzasdansmith: that's right15:47
bauzasdansmith: in my spec, I'm proposing the PCI ID as a way to know which card is for which type15:47
mriedemso we're going to have 1 vgpu child provider per card with a total inventory of 1?15:47
bauzasdansmith: what is uncovered in my spec is how an user can ask a certain type15:48
dansmithmriedem: no,15:48
dansmithmriedem: one card with however many vgpus it can support, right?15:48
dansmithone card per provider I mean15:48
bauzasmriedem: dansmith: no, it will create N children inventories, one per type15:48
sean-k-mooneydansmith: 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 dma15:48
mriedemi guess i just need someone to tell me if https://review.openstack.org/599208 is the correct direction or not15:48
dansmithbauzas: right, N inventories per M providers for M cards, yes?15:48
bauzaswhere the total of that inventory being the aggregated amount of capacity for each card15:48
mriedemfor existing inventory/allocations15:48
bauzasdansmith: one PCI ID only supporting one type15:49
*** dklyle has quit IRC15:49
dansmithsean-k-mooney: ack yeah, and the allocations are not fungible..15:49
dansmithbauzas: I think you're confusing what I'm asking15:49
bauzasprobably15:50
bauzas:)15:50
dansmithsean-k-mooney: btw, my inventory of 4 crunchie bars has been 75% allocated, with 25% now free15:50
*** dklyle has joined #openstack-nova15:50
bauzasdansmith: lemme try to clarify my spec for multiple types15:50
sean-k-mooneydansmith: haha next time ill have to bring a larger consignment15:50
bauzasdansmith: the operator defines which types he wants15:51
dansmithsean-k-mooney: get your importer license15:51
dansmithbauzas: I don't think we're talking about your spec15:51
bauzasdansmith: for each type, he has to mention which PCI IDs will be supported15:51
bauzasoh15:51
bauzasthen I'm confused :)15:51
dansmithI think we're talking about how to reshape from the controller (or not)15:51
bauzasmriedem's patch ?15:51
bauzasit's simple in my mind15:51
bauzaswe only support one type15:51
bauzasreshaping will just create a child with the exact same inventory15:52
bauzasand move allocations against it15:52
sean-k-mooneybauzas: do we today supprot 2+ pgpus on a host15:52
bauzassean-k-mooney: yup, but they are hidden for libvirt15:52
mriedembauzas: and that's what i've implemented15:53
bauzasmriedem: I know15:53
bauzashence my +115:53
bauzasso i don't get the concerns15:53
bauzashaving multiple cards isn't a problem15:53
bauzasor I'm missing a crucial point15:53
bauzasI mean, I can be wrong but I don't get the problem15:53
dansmithbauzas: presumably we want to reshape inventories onto providers that represent actual cards, right?15:54
bauzasdansmith: no15:54
sean-k-mooneybauzas: i would have assumed that as part of reshaper we would have had to devide that compinded inventory across the pGPUs no ?15:54
dansmithnot just reshape onto a provider that matches the one type we support today?15:54
dansmithbauzas: why not?15:54
bauzasdansmith: no, because once we support multiple types, they will still hide the fact that each type can be supported on N possible pGPUs15:54
dansmithhow is that helpful?15:55
dansmithmeaning,15:55
*** belmoreira has quit IRC15:55
dansmithhow does that help us represent the physical numa affinity?15:55
sean-k-mooneybauzas: you can hide that but you can also get the info via libvirt and expose it15:55
dansmithand, presumably a guest that wants 4 vgpus won't (presumably) be happy with 2 from 2 separate cards?15:55
sean-k-mooneydansmith: actully i think 4vgpus form 2 cards should be ok15:56
bauzasdansmith: ah shit, for NUMA affinity, topology is important15:56
dansmithsean-k-mooney: not if they look to be on the same NUMA node but aren't, right?15:56
*** icey has quit IRC15:56
bauzasshit shit shit15:56
dansmith...15:56
dansmithisn't this the whole discussion we had in denver?15:56
sean-k-mooneydansmith: right if they are split across numa nodes that would be bad15:56
dansmithsean-k-mooney: right15:56
dansmithI'm confused about why we had that discussion and are now having it again :)15:57
sean-k-mooneydansmith: 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 effects15:57
*** icey has joined #openstack-nova15:57
dansmithbut I have to jump on a call in a few minutes15:57
dansmithsean-k-mooney: sure15:57
*** helenafm has quit IRC15:57
bauzasdansmith: in https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/add-support-for-vgpu.html#proposed-change we always thought on GPU types15:57
bauzasdansmith: yes we barely discussed on NUMA affinity for GPUs15:58
dansmithbarely/15:58
bauzasdansmith: but in my mind, those were GPU types, and not cards15:58
dansmithwhat was the whole reason to talk about the reshape happening on the compute node, AFAIK :)15:58
dansmithanyway, /me -> call15:58
johnthetubaguy+115:59
bauzasmriedem: I just feel I'll necessarly have to help you on the reshaper patch15:59
bauzasbut I first need to consider whether a child being a pGPU and not a GPU type would change16:00
sean-k-mooneybauzas: i think the pGPUs would be childeren of the numa nodes with inventoies of vgpu(types)16:02
sean-k-mooneybauzas: we might also want to group pgpus into nvlink aggretates at some point but  not now16:02
bauzassean-k-mooney: shhhhhhhhhhhht16:03
mriedembauzas: 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
bauzassean-k-mooney: some customer could hear us and ask for this feature16:04
bauzasmriedem: and my brain fucked on it, I'm sorry16:04
bauzasthat's where I think it's crucial to see the topology now and in the future16:05
bauzasin order to prevent reshapes16:05
bauzaswe could implement chidren as GPU types and do reshapes later16:05
bauzasor we could reshape it now and do the necessary work now16:05
*** tbachman has joined #openstack-nova16:05
bauzasI think given FFU pain, the less reshapes we have, the better it will be16:05
bauzasmriedem: permission to play with your change ?16:06
mriedembauzas: sure16:06
sean-k-mooneybauzas: /window splitv16:06
sean-k-mooney... ignore that16:06
bauzascall me vim16:07
sean-k-mooneybauzas: can you do that in vim? i was setting back up my irc client "weechat"16:08
bauzasyou can split for sure16:08
bauzasmriedem: I'm just afraid of Xen having different RP structure16:10
bauzasI know we said the drivers are responsible, but that makes us differ16:11
sean-k-mooneybauzas: well im sure hyperv and powervm will likely have different stutures too16:11
*** gyee has joined #openstack-nova16:12
sean-k-mooneybauzas: 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 driver16:13
*** holser_ has quit IRC16:14
bauzassean-k-mooney: no, I'm talking of XenServer driver not reporting GPUs like libvirt16:15
sean-k-mooneybauzas: ah ok. i think that is ok provided that does not require use to change the flaovr in some way16:15
bauzasright16:16
bauzasanyway, now /me has to figure out the best way to lookup which GPU is attached to each running instance16:16
*** artom has joined #openstack-nova16:20
openstackgerritMatt Riedemann proposed openstack/nova master: libvirt: implement reshaper for vgpu  https://review.openstack.org/59920816:22
*** psachin has joined #openstack-nova16:28
openstackgerritJohn Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec  https://review.openstack.org/60220116:36
openstackgerritJohn Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec  https://review.openstack.org/60220116:41
*** psachin has quit IRC16:43
johnthetubaguymelwitt alex_xu I have attempted to capture the unified limits discussion here in here, still not complete, but getting closer: https://review.openstack.org/60220116:43
*** psachin has joined #openstack-nova16:48
bauzasmriedem: thanks for the last update on libvirt reshape, I now see your TODO(sbauza) and the direction it goes16:50
bauzasmriedem: starting from now, I'll test this by changing to create a child per pGPU16:50
* bauzas goes AWOL but will probably be around tonight16:52
*** dtantsur is now known as dtantsur|afk16:54
*** cfriesen has joined #openstack-nova16:56
*** artom has quit IRC17:04
*** artom has joined #openstack-nova17:05
*** efried has joined #openstack-nova17:08
*** jpena is now known as jpena|off17:11
*** efried is now known as efried_off17:12
*** artom has quit IRC17:15
*** med_ has joined #openstack-nova17:24
*** devananda has joined #openstack-nova17:28
*** luksky has joined #openstack-nova17:35
*** psachin has quit IRC17:40
cfriesensean-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
openstackLaunchpad bug 1792985 in OpenStack Compute (nova) "strict NUMA memory allocation for 4K pages leads to OOM-killer" [Undecided,New]17:46
sean-k-mooneycfriesen: we have spoken about that in the past17:53
sean-k-mooneycfriesen: its because the reserved memory is global not per numa node17:53
cfriesensean-k-mooney: I'm talking about actual instance memory, so reserved shouldn't be involved17:54
*** david-lyle has joined #openstack-nova17:54
cfriesensean-k-mooney: for a floating instance, it can allocate memory from any numa node17:54
sean-k-mooneycfriesen: reserved should because it will prevent schduing to that node so we dont exaust the memory on one numa node17:54
*** priteau has quit IRC17:55
sean-k-mooneycfriesen: when you set a mem page size it created a numa node of 117:55
cfriesensean-k-mooney: if you don't specify a page size, there is no instance numa_topology17:55
sean-k-mooneycfriesen: so its now confied to float over one numa node17:55
sean-k-mooneyyes 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 topologyy17:56
cfriesensean-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 IRC17:57
sean-k-mooneycfriesen: this xml17: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-mooneywill not be genergated unless the guest has a numa toployt of 1 either implictly or implcitly17:58
sean-k-mooney*explictly17:58
cfriesensean-k-mooney: yes, that's the one with the pci device17:58
cfriesenwhich is pinned to a numa node17:58
sean-k-mooneyright so the behavor is correct17:58
cfriesenno, because the "floating" instance may have consumed all the memory from that node17:59
sean-k-mooneythe issue is we do not have a per numa reserved memory so we can exaust one numa node and trigger oom17:59
cfriesenso either we restrict floating instances to a single numa node, or else we can't use "strict" for the "memory mode" line17:59
sean-k-mooneycfriesen: we already no you cannot mix numa affined instances with non numa instances on a singel host for this exact reason18:00
cfriesensean-k-mooney: but you can, because you can specify a pci device which implicitly makes it numa-affined18:00
sean-k-mooneycfriesen: we could fix this but we tell operators that this is not ok and use host aggreate to seperate these flavors today18:00
sean-k-mooneycfriesen: you mean by neutron sriov ports18:01
sean-k-mooneycfriesen: that is true18:01
sean-k-mooneycfriesen: 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 do18:02
*** janki has quit IRC18:04
sean-k-mooneythat 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 4k18:04
cfriesensean-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-mooneycfriesen: if we remove it for 4k why would we not allow it for any page size18:05
cfriesensean-k-mooney: explicitly specifying page size would limit them to a single numa node, which we had before but removed.18:05
cfriesensean-k-mooney: adding hugepages explicitly results in a numa-topology and being restricted to a single node.18:05
sean-k-mooneycfriesen: in nova yes but qemu does not require that18:06
cfriesensean-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-nova18:06
sean-k-mooneycfriesen: so the defautl is stict and you opt out18:07
*** artom has quit IRC18:07
sean-k-mooneycfriesen: that argument will never win with me because i argued that none of the implit behavior should have existied for the start18:07
*** artom has joined #openstack-nova18:07
cfriesensean-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-mooneycfriesen: prefer will break us one memory is reported in placement as we will nologer no where the memory was consumed form18:10
*** openstackgerrit has quit IRC18:10
cfriesensean-k-mooney: we already don't know where it's consumed from.  we just think we do. :)18:10
cfriesenfor the floating instances, at least18:10
sean-k-mooneycfriesen: we know when we explcitly state a page size18:10
cfriesensean-k-mooney: yes18:10
sean-k-mooneyfor floating instance we dont touch the numa toplogy blob.18:11
*** jiapei has joined #openstack-nova18:11
sean-k-mooneyso its fine18:11
sean-k-mooneythe numa toplogy blob heals based on the periodic task18:11
cfriesensean-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-mooneycfriesen: yes so perhaps we should use a filter to prevent that18:12
*** adrianc has quit IRC18:13
cfriesenworth considering.  anyways, gotta run.  thanks for the feedback18:13
sean-k-mooney:) sorry it was not more positve18:13
*** harlowja has joined #openstack-nova18:24
*** openstackgerrit has joined #openstack-nova18:27
openstackgerritMerged openstack/nova stable/rocky: Fix soft deleting vm fails after "nova resize" vm  https://review.openstack.org/60314018:27
mriedemjohnthetubaguy: 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 response18:53
mriedemi know the host is in the response when showing server details as admin, but i can never remember the stupid prefix on the response field18:53
mriedemmordred: can i get an amen?! ^18:54
*** hemna_ has quit IRC18:55
*** hemna_ has joined #openstack-nova18:57
*** alexchadin has joined #openstack-nova18:59
mriedemgmann: 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) APIs19:19
mriedemi'll send something to the ML19:19
*** alexchadin has quit IRC19:32
mriedemhttp://lists.openstack.org/pipermail/openstack-dev/2018-September/134748.html19:32
*** tbachman has quit IRC19:54
*** tbachman has joined #openstack-nova19:54
*** tbachman has quit IRC19:54
*** med_ has quit IRC20:01
*** diablo_rojo has joined #openstack-nova20:03
mordredmriedem: amen20:13
*** lbragstad has quit IRC20:26
*** lbragstad has joined #openstack-nova20:27
*** tbachman has joined #openstack-nova20:37
*** tbachman has quit IRC20:41
*** tbachman has joined #openstack-nova20:46
*** artom has quit IRC20:48
*** med_ has joined #openstack-nova20:49
*** med_ has quit IRC20:50
*** tbachman has quit IRC21:02
*** awaugama has quit IRC21:05
*** erlon has quit IRC21:18
jaypipesmriedem: do you want code reviews on https://review.openstack.org/#/c/599208/ or not?21:18
mriedemjaypipes: no21:18
openstackgerritMatt Riedemann proposed openstack/nova master: Merge security groups extension response into server view builder  https://review.openstack.org/58547521:19
mriedemsounds like it's going to need more work from bauzas21:19
*** tbachman has joined #openstack-nova21:26
*** munimeha1_ has quit IRC21:27
jaypipesmriedem: ack21:27
*** tbachman has quit IRC21:30
*** diablo_rojo has left #openstack-nova21:35
*** takashin has joined #openstack-nova21:43
alex_xujohnthetubaguy: thanks a lot, will review it21:47
*** hemna_ has quit IRC21:51
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3)  https://review.openstack.org/57410422:00
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4)  https://review.openstack.org/57410622:00
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5)  https://review.openstack.org/57411022:00
*** luksky has quit IRC22:02
*** rcernin has joined #openstack-nova22:08
*** slaweq has quit IRC22:09
*** slaweq has joined #openstack-nova22:11
*** mlavalle has quit IRC22:14
*** slaweq has quit IRC22:15
openstackgerritMatt Riedemann proposed openstack/nova master: Merge extended_status extension response into server view builder  https://review.openstack.org/59209222:23
mriedemwhen your house is full of the sounds of screaming 7 year old girls and "metal militia" by metallica comes on,22:42
mriedemone must drown out the screaming22:42
openstackgerritMatt Riedemann proposed openstack/nova master: Add scatter-gather-single-cell utility  https://review.openstack.org/59494722:46
openstackgerritMatt Riedemann proposed openstack/nova master: Merge extended_volumes extension response into server view builder  https://review.openstack.org/59628522:46
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6)  https://review.openstack.org/57411322:51
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7)  https://review.openstack.org/57497422:51
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.openstack.org/57531122:51
openstackgerritMatt Riedemann proposed openstack/nova master: Making instance/migration listing skipping down cells configurable  https://review.openstack.org/59242822:54
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.openstack.org/57558122:57
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10)  https://review.openstack.org/57601722:57
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11)  https://review.openstack.org/57601822:58
openstackgerritMatt Riedemann proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList  https://review.openstack.org/59165623:09
*** slaweq has joined #openstack-nova23:11
*** devananda has quit IRC23:13
mriedemgmann: 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 one23:14
mriedemi.e. call it with the list of servers to batch the results rather than one per server in the detail() Case23:14
*** slaweq has quit IRC23:16
*** mriedem is now known as mriedem_away23:23
*** jiapei has quit IRC23:30
*** tbachman has joined #openstack-nova23:43
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12)  https://review.openstack.org/57601923:44
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13)  https://review.openstack.org/57602023:44
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14)  https://review.openstack.org/57602723:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!