Tuesday, 2019-06-04

*** nicolasbock has quit IRC00:01
*** frank_wang has quit IRC00:08
*** frankwang has joined #openstack-nova00:11
*** markvoelker has quit IRC00:24
*** takashin has joined #openstack-nova00:25
*** _erlon_ has quit IRC00:29
*** mriedem has quit IRC00:44
openstackgerritMatt Riedemann proposed openstack/nova master: Hide hypervisor id on windows guests  https://review.opendev.org/57989700:51
*** ttsiouts has joined #openstack-nova01:00
openstackgerritMatt Riedemann proposed openstack/nova stable/stein: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66289401:01
openstackgerritMatt Riedemann proposed openstack/nova stable/rocky: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66289501:03
*** brinzhang has joined #openstack-nova01:05
*** ttsiouts has quit IRC01:06
*** gyee has quit IRC01:19
openstackgerritBrin Zhang proposed openstack/nova master: Replace the invalid index of nova-rocky releasenote  https://review.opendev.org/66289701:32
*** brinzhang has quit IRC01:39
*** brinzhang has joined #openstack-nova01:39
*** _hemna has joined #openstack-nova01:53
*** Sundar has quit IRC02:08
openstackgerritzhaixiaojun proposed openstack/python-novaclient master: Bump openstackdocstheme to 1.30.0  https://review.opendev.org/66290502:10
*** hongbin has joined #openstack-nova02:17
*** _hemna has quit IRC02:17
*** BjoernT has joined #openstack-nova02:25
*** BjoernT_ has joined #openstack-nova02:29
*** BjoernT has quit IRC02:31
*** minmin has joined #openstack-nova02:50
*** _hemna has joined #openstack-nova02:52
openstackgerritzhaixiaojun proposed openstack/python-novaclient master: Blacklist python-cinderclient 4.0.0  https://review.opendev.org/66291202:53
*** whoami-rajat has joined #openstack-nova03:14
*** _hemna has quit IRC03:25
*** Kimmo_ has joined #openstack-nova03:35
*** igordc has quit IRC03:39
openstackgerritArtom Lifshitz proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type  https://review.opendev.org/66288703:45
*** guozijn has joined #openstack-nova03:52
*** frankwang has quit IRC04:02
*** igordc has joined #openstack-nova04:06
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP:Introduce scope_types in os-services  https://review.opendev.org/64542704:08
*** hongbin has quit IRC04:17
*** udesale has joined #openstack-nova04:25
*** ivve has quit IRC04:36
*** damien_r has joined #openstack-nova04:45
*** damien_r has quit IRC04:46
*** damien_r has joined #openstack-nova04:46
*** guozijn has quit IRC04:51
*** BjoernT_ has quit IRC05:00
*** lbragstad has quit IRC05:09
*** Sundar has joined #openstack-nova05:11
*** pcaruana has joined #openstack-nova05:12
*** _hemna has joined #openstack-nova05:22
*** pcaruana has quit IRC05:23
*** pcaruana has joined #openstack-nova05:28
*** ccamacho has quit IRC05:28
*** frankwang has joined #openstack-nova05:39
*** ivve has joined #openstack-nova05:42
*** belmoreira has joined #openstack-nova05:49
*** igordc has quit IRC05:51
openstackgerritMerged openstack/nova master: Follow up for counting quota usage from placement  https://review.opendev.org/66205605:54
*** _hemna has quit IRC05:55
*** guozijn has joined #openstack-nova06:03
*** Sundar has quit IRC06:06
*** damien_r has quit IRC06:07
*** lpetrut has joined #openstack-nova06:10
*** bbowen has joined #openstack-nova06:12
*** slaweq has joined #openstack-nova06:13
*** dpawlik has joined #openstack-nova06:13
*** bbowen_ has quit IRC06:14
*** dtantsur|afk is now known as dtantsur06:16
*** wwriverrat has joined #openstack-nova06:17
*** _hemna has joined #openstack-nova06:25
openstackgerritMerged openstack/nova stable/stein: xenapi/agent: Change openssl error handling  https://review.opendev.org/65630406:36
*** evrardjp_ is now known as evrardjp06:43
*** belmoreira has quit IRC06:43
*** damien_r has joined #openstack-nova06:44
*** damien_r has quit IRC06:44
*** brinzhang has quit IRC06:49
*** brinzhang has joined #openstack-nova06:49
*** maciejjozefczyk has joined #openstack-nova06:53
*** _hemna has quit IRC06:58
*** ccamacho has joined #openstack-nova07:04
*** ccamacho has quit IRC07:04
*** ccamacho has joined #openstack-nova07:04
*** damien_r has joined #openstack-nova07:08
*** luksky has joined #openstack-nova07:08
*** ttsiouts has joined #openstack-nova07:09
*** _hemna has joined #openstack-nova07:11
*** rpittau|afk is now known as rpittau07:15
*** _hemna has quit IRC07:16
*** slaweq has quit IRC07:16
*** tkajinam has quit IRC07:24
*** tkajinam has joined #openstack-nova07:24
*** zbr has joined #openstack-nova07:31
*** markvoelker has joined #openstack-nova07:32
*** ttsiouts has quit IRC07:34
*** ttsiouts has joined #openstack-nova07:35
openstackgerritGhanshyam Mann proposed openstack/nova master: Add new default roles and mapping in policy base class  https://review.opendev.org/64545207:35
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP:Introduce scope_types in os-services  https://review.opendev.org/64542707:39
openstackgerritBoxiang Zhu proposed openstack/nova master: Validate requested host/node during servers create  https://review.opendev.org/66123707:39
*** helenafm has joined #openstack-nova07:39
*** ttsiouts has quit IRC07:39
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP: Add new default roles in os-services API policies  https://review.opendev.org/64848007:40
*** slaweq has joined #openstack-nova07:40
*** threestrands has joined #openstack-nova07:44
*** tianhui has joined #openstack-nova07:45
*** xek has joined #openstack-nova07:52
*** tianhui has quit IRC07:55
*** boxiang has joined #openstack-nova07:56
*** minmin has quit IRC07:56
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP: Add new default roles in os-services API policies  https://review.opendev.org/64848007:57
kashyapefried: Indeed, it was not me (on "live resize").  But I've followed it on-and-off07:58
*** ttsiouts has joined #openstack-nova08:02
*** markvoelker has quit IRC08:05
openstackgerritBalazs Gibizer proposed openstack/nova stable/stein: Reset the stored logs at each notification test steps  https://review.opendev.org/66296508:06
*** tetsuro has joined #openstack-nova08:07
*** brinzhang has quit IRC08:07
*** brinzhang has joined #openstack-nova08:07
*** frankwang has quit IRC08:12
*** frankwang has joined #openstack-nova08:12
*** boxiang has quit IRC08:14
*** boxiang has joined #openstack-nova08:14
*** factor has joined #openstack-nova08:18
*** jaosorior has joined #openstack-nova08:21
*** maciejjozefczyk has quit IRC08:21
*** maciejjozefczyk has joined #openstack-nova08:22
*** priteau has joined #openstack-nova08:23
*** tkajinam has quit IRC08:24
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP:Introduce scope_types in servers API  https://review.opendev.org/66296808:24
johnthetubaguygmann: I couldn't get my unit test to do what I expected with this: https://review.opendev.org/#/c/657823/208:29
johnthetubaguyI am probably doing something dumb08:29
*** maciejjozefczyk_ has joined #openstack-nova08:30
*** takashin has left #openstack-nova08:30
gmannjohnthetubaguy: ok, i am updating the spec now with more mapping data. I will check your unit test thing after tnat08:31
johnthetubaguygmann: sweet, lets refresh the spec first for sure08:32
johnthetubaguythis is implementation detail08:32
*** maciejjozefczyk has quit IRC08:33
kashyapjohnthetubaguy: In your copious free time, mind having a look at the Secure Boot spec, please? -- https://review.openstack.org/#/c/506720/08:33
johnthetubaguyits spec review day, so totally will take a look at that08:34
kashyapBefore I respin to rephrase some text, just want to check if there's anything else anyone has.  Near as I see, I've addressed all the feedback08:34
kashyapjohnthetubaguy: Most excellent08:34
johnthetubaguythat and I have customers who will want this08:34
kashyapjohnthetubaguy: Cool!08:36
*** guozijn has quit IRC08:37
kashyapjohnthetubaguy: A good chunk of stuff is in Work Items08:37
kashyapjohnthetubaguy: The thid point, that shows the use 'UefiShell.iso' is info-only; no need for us to run any of that.08:38
kashyapBecause, all distributions that matter, ship OVMF "variables" (or "vars") files that have default UEFI keys enrolled.08:38
kashyapAnyway, it's a detail.  We'll get to it when you're reviewing.08:38
*** janki has joined #openstack-nova08:39
*** maciejjozefczyk has joined #openstack-nova08:39
*** maciejjozefczyk has quit IRC08:39
* kashyap is here to answer any questions08:39
*** tssurya has joined #openstack-nova08:40
openstackgerritGhanshyam Mann proposed openstack/nova master: WIP: Add new default roles in servers API policies  https://review.opendev.org/66297108:40
*** guozijn has joined #openstack-nova08:41
openstackgerritBalazs Gibizer proposed openstack/nova master: Change the default of notification_format to unversioned  https://review.opendev.org/60307908:42
*** derekh has joined #openstack-nova08:44
*** maciejjozefczyk_ is now known as maciejjozefczyk08:44
*** spsurya has joined #openstack-nova08:51
*** tesseract has joined #openstack-nova08:56
johnthetubaguykashyap: I see what you mean about the work items thing... its normally like three lines08:57
kashyap:D08:57
kashyapjohnthetubaguy: I wanted to remove some of the background stuff, to reduce text.  As most of the stuff is automated for us by libvirt's new interface08:57
kashyapAnd I've working with distributions to ensure they're shipping the variables files08:57
*** mvkr has joined #openstack-nova08:59
*** ttsiouts has quit IRC09:01
*** ttsiouts has joined #openstack-nova09:02
johnthetubaguykashyap: yeah, I think you could, finding it interesting, but don't feel qualified to review it09:05
kashyapjohnthetubaguy: Okido; I'll leave it as is.  I made sure to write clear sentences that add some value :D09:05
*** factor has quit IRC09:06
*** factor has joined #openstack-nova09:06
*** ttsiouts has quit IRC09:06
*** rcernin has quit IRC09:07
johnthetubaguykashyap: I am putting some comments on the bits I would trim, like that list of distro details, I think just two distros to illustrate the complexity would do09:07
*** factor has quit IRC09:07
kashyapjohnthetubaguy: Sure.  Comment away09:07
kashyapjohnthetubaguy: Aside: If you want to try a SecureBoot-enabled guest, here's an automated script I wrote for it: https://kashyapc.fedorapeople.org/Create-a-SecureBoot-enabled-VM.bash09:07
*** factor has joined #openstack-nova09:07
johnthetubaguythe ovmf loader paths in the xml... I thought libvirt did all that for us/09:08
*** factor has quit IRC09:08
kashyapjohnthetubaguy: Are you referring to point-2 in the Work Items section?09:08
kashyapjohnthetubaguy: Yes, the new libvirt does handle that for us.09:09
*** factor has joined #openstack-nova09:09
johnthetubaguyyeah, that is the bit09:09
kashyapI have a TODO to trim that second point to reflect that.09:09
*** factor has quit IRC09:10
*** factor has joined #openstack-nova09:10
*** factor has quit IRC09:11
*** factor has joined #openstack-nova09:12
*** _hemna has joined #openstack-nova09:12
*** threestrands has quit IRC09:14
*** factor has quit IRC09:15
*** rpittau is now known as rpittau|reboot09:17
johnthetubaguykashyap: so this sounds harsh... but I think you need to turn your spec upside down, given the new libvirt version, and I guess that is what you are thinking too09:19
kashyapjohnthetubaguy: Sorry, what do you mean upside down?09:19
kashyapjohnthetubaguy: You mean, push the content from Work Items a bit above?09:19
kashyapNoting clearly that the new libvirt (and QEMU, OVMF / EDK2) version handles most of the work for us?09:20
kashyap(All harsh feedback is welcome :-)  After spending so much time on my text, I need other eyes to help edit it.)09:20
kashyaps/other/others'/09:20
*** rpittau|reboot is now known as rpittau09:21
johnthetubaguykashyap: trying to work out how to describe what I am thinking :)09:21
kashyapjohnthetubaguy: Sure.  Whatever brings clarity.09:22
johnthetubaguyso overall I think we are largely there, libvirt does all the work, it clearly is something useful09:22
kashyap"No mind is ever willingly deprived of the truth" — Plato09:22
kashyapjohnthetubaguy: Yeah, indeed.09:22
johnthetubaguyso I think this spec was needed before libvirt did all the hard work09:23
johnthetubaguyand we still need a bunch of the detail for sure09:23
johnthetubaguyjust wondering first about what is missing09:23
johnthetubaguy... so the last two work items09:23
johnthetubaguyactually, that is back to front, maybe I just say what I think I was expecting... which doesn't make it the right or only way, its just a data point09:24
*** sapd1_x has joined #openstack-nova09:24
kashyapYeah, noted.09:25
kashyapAlso, it's not just the last two points, surely?09:25
kashyapAlso the point on making Nova use the firmware auto-selection feature?09:25
kashyap        <os firmware='efi'>09:25
kashyap          <loader secure='yes'/>09:25
kashyap        </os>09:25
johnthetubaguyyeah, totally09:25
johnthetubaguylets go through each bit of the spec quickly, I think its close09:26
kashyapCertainly.09:26
johnthetubaguyso problem and use cases, I think you could simplify it a little bit, line 51-52 and line 42-44 are good09:26
kashyapRight, I'll reword the "or other kernel code ..." thing, if you prefer.09:27
johnthetubaguywell, I mean those lines are vital... i.e. you need this for guests to protect against certain kinds of maleware, and by the way we already added this for hyper-v09:28
kashyap(It's just saying: either guest side malware or malware from kernel modules)09:28
johnthetubaguythe hypervisor kernel modules?09:28
kashyapjohnthetubaguy: Added what?  (The SecureBoot feature?  Sure)09:28
kashyapYes09:28
johnthetubaguyhmm, OK, I guess it does... :/ not sure09:28
johnthetubaguyanyways, the guest malware seems the key thing for the user09:29
* kashyap is taking summary notes based on this chat, so at the end I can work through that list.09:29
johnthetubaguysweet09:29
johnthetubaguythe proposed change thing: (1) copy hyper-v interface, (2) libvirt does all the work when we add the above XML, (3) scheduling to make sure we get on a capable host09:30
johnthetubaguyis there anything else from the "changes to nova" sense?09:30
kashyapjohnthetubaguy: For the (2) part, we need to expand that: introduce libvirt config classes, etc?09:31
kashyapjohnthetubaguy: No, from the list of three, I don't think there's any further, from "changes to Nova" sense.09:32
johnthetubaguyI would do the reverse, this is the magic we put in the XML... PS this is what that really means09:32
johnthetubaguyfrom the scheduling, I think in the comments it noted that the libvirt driver would add a secure_boot capability style trait if its capable09:33
kashyapRight, noted.09:33
johnthetubaguyI guess we need to ask libvirt if we can do that, once libvirt is the correct version?09:33
kashyapYes, we need to query via `capabilities`09:34
kashyapTo look if it supports the "secure" flag for 'efi'09:34
johnthetubaguycool09:34
johnthetubaguyso its "a little bit" like this: https://github.com/openstack/nova/blob/2ea6e6f8db9fc6cecf389cacdd0d82d8226b99fb/nova/virt/libvirt/driver.py#L33409:34
kashyaps/capabilities/getDomainCapabilities/09:35
johnthetubaguyin that its a conditional capability09:35
kashyapjohnthetubaguy: (Aside: While implementing, I could use some help on the scheduling bits, it's my weak area.)09:36
* kashyap clicks the URL09:36
johnthetubaguyso I fear the spec needs to cover the rough details of what is going to happen there09:36
johnthetubaguyhttps://github.com/openstack/nova/blob/2ea6e6f8db9fc6cecf389cacdd0d82d8226b99fb/nova/virt/libvirt/driver.py#L495909:36
johnthetubaguyI guess its an extension of that09:36
kashyapjohnthetubaguy: Yeah, indeed: Need to write: _has_uefi_secure_boot_support()09:37
johnthetubaguyhow to we schedule for uefi today... I don't rightly remember09:37
kashyapWe don't do any scheduling decisions for UEFI, IIRC09:37
*** panda is now known as panda|ruck09:38
kashyapjohnthetubaguy: Do you see anything contrary to what I say in the code?09:40
*** tesseract has quit IRC09:40
johnthetubaguykashyap: not so far... just re-reading the hyper-v spec09:41
*** jaosorior has quit IRC09:41
johnthetubaguydo we not need os_secure_boot_signature?09:42
johnthetubaguyref: https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/hyper-v-uefi-secureboot.html09:42
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Policy Default Refresh spec  https://review.opendev.org/54785009:42
kashyapjohnthetubaguy: I _think_ for the first iteration, it should be optional.09:44
kashyap`os_secure_boot_signature` allows specifying bootloader's signature09:45
kashyapI need to play a bit more to see how strongly we need it09:45
kashyapjohnthetubaguy: Because, the OVMF maintainer says: if you don't trust the default UEFI keys, then it is almost the same as you're not trusting the filesystem where your Compute node is running09:45
johnthetubaguyso you know... I think this was before the distros shipped trusted default keys09:46
kashyapYeah, very true.09:46
johnthetubaguylets just add in the spec that we only support using the default keys in the first implementation?09:46
*** _hemna has quit IRC09:46
kashyapjohnthetubaguy: Yes, very much worth it to spell it out09:46
*** owalsh_ has joined #openstack-nova09:48
*** owalsh has quit IRC09:49
*** phasespace has joined #openstack-nova09:51
*** mugsie_ is now known as mugsie09:52
johnthetubaguykashyap: so I just added an extra note to give a summary of what I was thinking for the proposed changes section09:54
johnthetubaguyI am tempted to say this first version follows UEFI and simple errors out if not supported?09:54
*** ociuhandu has joined #openstack-nova09:54
johnthetubaguythen in the alternatives but that in the future a request spec filter can be added similar to the existing image type filter09:55
johnthetubaguykashyap, the release note for hyper-v is quite nice: https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/releasenotes/notes/hyperv-uefi-secure-boot-a2a617ac2c313afd.yaml09:56
kashyapjohnthetubaguy: Looking...09:56
kashyapjohnthetubaguy: Meanwhile, just typed this up: http://kashyapc.fedorapeople.org/Feedback-to-address-SecureBoot-spec.txt09:57
kashyapjohnthetubaguy: Yes, we should error-out simply if there's no support09:57
kashyapjohnthetubaguy: Can you explain a bit more on the request spec filter alternative?09:57
johnthetubaguyyeah09:58
kashyapjohnthetubaguy: Yes, we'll write an equally good release note :-)09:58
johnthetubaguyso the code for the image one is here: https://github.com/openstack/nova/blob/0c9c422c878719bae5b97fd07cafe7cd933bf103/nova/scheduler/request_filter.py#L12409:58
johnthetubaguyfor secure boot, I think we look at the flavor and image to work out if secure_boot is required, and if it is we would request the trait the driver capabilties could advertise like SECURE_BOOT_CAPABLE or something like that10:00
*** claudiub has joined #openstack-nova10:00
* kashyap clicks10:00
kashyapAh-ha, noted.10:01
kashyapjohnthetubaguy: Thanks for the explanation.10:01
johnthetubaguyno worries10:01
johnthetubaguyso I attempted a summary comment here: https://review.opendev.org/#/c/506720/11/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@8210:01
kashyapjohnthetubaguy: Excellent, reading it already10:02
*** guozijn has quit IRC10:02
*** markvoelker has joined #openstack-nova10:02
kashyapjohnthetubaguy: Can you also compare my notes here, the 2nd point: http://kashyapc.fedorapeople.org/Feedback-to-address-SecureBoot-spec.txt10:03
kashyapThis week, I'm going to address that, plus other items you noted in the review.10:03
kashyapWill make it ready by end of this week, to keep the momentum, and not let it languish10:03
kashyapNot least because ... "One who delays his work is always wrestling with ruin."10:04
johnthetubaguyI may have changed my mind on some of the things in your notes...10:05
johnthetubaguyproblem description is good10:05
johnthetubaguyuse cases, I would just focus on the first one10:05
kashyapOkay, will adjust10:05
johnthetubaguy... I am tempted to focus only on the guest level protection10:05
johnthetubaguythen reference the other white paper for more details10:06
*** luksky has quit IRC10:06
johnthetubaguythat way its not our job to review it / keep it correct :)10:06
kashyapYes, indeed10:06
johnthetubaguythat hypervisor kernel protection... surely a bad hypervisor could spoof things to the guest, claiming its really a good little hypervisor?10:07
johnthetubaguyi.e. that is what folks want attestation and secure boot of the hypervisor... which is a different thing, and in some ways, an ironic level feature10:07
kashyapjohnthetubaguy: Hm, I'm not really sure, afraid.  Can ask Laszlo (OVMF maintainer) to comment10:07
johnthetubaguyso I think we should only claim the guest protection at this point10:08
kashyapjohnthetubaguy: BTW, we're only talking here about *guest*-level protection, indeed -- not baremetal, that's out of scope, as we know :-)10:08
johnthetubaguyfairly sure you need hypervisor secure boot for the other thing, along with active atestation10:08
johnthetubaguycool10:08
johnthetubaguylets just make that clear10:08
johnthetubaguyone extra comment, the enrolement of keys, and the context so you know what the means seems well worth explaining, probably under "other deployer impact", its kinda like a dependency of the system setup10:09
gmannjohnthetubaguy: this is ready for review, i have updated the mapping of new and old roles.  - https://review.opendev.org/#/c/547850/10:09
kashyapWe're only concerned about the case of: "If you don't trust what is inside the VM" -- that's what SB protects you from.10:09
gmannalso added fallback idea in Alternate section10:09
johnthetubaguyso basically, we need all the details you have put together in the spec, just prehaps they need to move around a little bit.10:10
gmanni will be here for another ~2 hours for updating it.10:10
kashyapjohnthetubaguy: Okay, will add a clarifying note that here, Secure Boot is only dealing with guest-level protection.10:10
johnthetubaguysweet, sounds good10:10
kashyapjohnthetubaguy: Yeah, I'll reorganize with a fresh mind early tommorrow.10:10
kashyapI need time to process all of this :-)10:10
johnthetubaguykashyap: great work on this though, its a nasty can of worms, which thanks to your spec, I think I understand much better now, let's not loose that in the reworking!10:11
kashyapjohnthetubaguy: Yeah, won't lose.  It's been more than a year ago, when I started this QEMU thread:10:11
kashyaphttps://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01978.html -- [RFC] Defining firmware (OVMF, et al) metadata format & file10:12
johnthetubaguyI remember discussion it (and getting confused) when we were snowed in10:12
kashyapjohnthetubaguy: Thanks a _ton_ for this focussed review time.  I find this approach very effective.10:12
johnthetubaguykashyap: me too, its much better than three weeks of back and forth10:12
johnthetubaguygmann: talking a look at yours now10:13
kashyapRight, a lot of complexity is reduced.  I'm glad there's someone like you, a "hypervisor person", who can see all the "can of worms"10:13
kashyapAlrightie, I've got enough to chisel away10:13
kashyapjohnthetubaguy++10:14
johnthetubaguykashyap: cool, looks really promising10:14
kashyapNow only the "small matter of programming" remaining :D10:14
*** shilpasd has joined #openstack-nova10:17
johnthetubaguygmann: line 90, I think we mean change the DB check from role:admin to scope:system?10:17
johnthetubaguyor rather, change from "role:admin" to "scope:system" when enforce_scope = True ?10:18
*** owalsh has joined #openstack-nova10:19
kashyapjohnthetubaguy: A quick typo thing: did you mean Chris, instead of Eric here: https://review.opendev.org/#/c/506720/11/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@9810:21
kashyap(Because there was no comment from Eric there :-))10:21
gmannjohnthetubaguy: second one, when enforce_scope is true then we will start checking system scope10:21
johnthetubaguykashyap: oops yes, I was thinking about the previous one clearly10:21
kashyapYeah, figured as much.10:21
kashyapThx.10:22
* johnthetubaguy face palm10:22
*** owalsh_ has quit IRC10:22
johnthetubaguygmann: yeah, the steps bit is a bit out of date now I think10:22
johnthetubaguygmann: I just added comments on the first 100 lines, going to keep going now10:24
gmannjohnthetubaguy: thanks, checking..10:24
*** damien_r has quit IRC10:26
*** damien_r has joined #openstack-nova10:27
*** cdent has joined #openstack-nova10:27
*** slaweq has quit IRC10:30
yaawangjohnthetubaguy: Hi, could you please taking a look at the auto-converge/post-copy spec? I have replied your commets. https://review.opendev.org/#/c/651681/10:32
johnthetubaguyyaawang: ah, I meant to follow up with your spec, will have a look10:33
yaawangjohnthetubaguy: Great10:34
*** markvoelker has quit IRC10:36
johnthetubaguyyaawang: sorry, I think I miss-understood your use case10:36
johnthetubaguyyaawang: could you describe to me why a workload prefers auto converge vs post copy?10:37
johnthetubaguyis it the slowing down of the guest it wants to avoid?10:37
johnthetubaguyor the pausing of the guest it want's to avoid10:37
gmannjohnthetubaguy: to be clear on DB check change. currently we check hard coded is_admin for few place which is going to be change to check if requested token is scoped to system.10:38
johnthetubaguygmann: but... is_admin is set via policy10:38
gmannjohnthetubaguy: yes, by checking is_context_admin which internally check admin role10:38
johnthetubaguygmann: I think thinking we can hardcode to context.system_scope == "all" for the DB check, probably needs a new name though10:39
yaawangjohnthetubaguy: Ok, please wait...10:39
*** nicolasbock has joined #openstack-nova10:40
johnthetubaguyyaawang: no problem10:40
* gmann https://github.com/openstack/nova/blob/1d1b0d573671add8630af41754e5521cb2bc5ae1/nova/context.py#L15110:40
gmannjohnthetubaguy: yeah. something like that and then set is_system or something on context like ^^10:40
gmannjohnthetubaguy: updated my local copy of spec with your comments till L100. waiting for next10:41
*** brinzhang has quit IRC10:43
*** brinzhang has joined #openstack-nova10:43
johnthetubaguygmann: yeah, I think so... the key bit in the ordering is to allow us to implement the System Reader role, without breaking the project_id protection. i.e. the role:admin no longer works for list servers in all projects10:44
johnthetubaguyreally just talking out loud to check my thinking there10:44
yaawangjohnthetubaguy: If the compute node enable auto-converge, it will slow down CPU and memory I/O to make it easy to live-migrate to other compute node.10:46
yaawangjohnthetubaguy: But it means all vms on the compute node will use auto-converge during live-migration even the vm can live-migrate to other compute node without auto-converge/post-copy.10:46
yaawangjohnthetubaguy: For some applications(such as scientific computing applications) is sensitive to performance reduce or memory I/O error, these vms do not want to use auto-converge/post-copy during live-migration.10:46
*** nicolasbock has quit IRC10:47
openstackgerritMerged openstack/os-traits master: Create trait for NUMA subtree affinity  https://review.opendev.org/65789810:47
*** bbowen has quit IRC10:49
*** guozijn has joined #openstack-nova10:49
gmannjohnthetubaguy: if deployment say scope enforcement and token is not scoped to system then yes role:admin will not be able to list all project's servers10:49
*** tbachman has quit IRC10:50
johnthetubaguyyaawang: makes sense to me, but why do you want to use auto-converge for the other workloads? Maybe you just want to disable auto-converge in your cloud?10:50
johnthetubaguyyaawang: also, have you seen this interesting look at live-migration, I am curious if you see the same things: https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/10:51
gmannwith system reader (because of system_scope:all in check_str) it will keep checking the system scope even enforce_scope if false. so we would not break project_id protection there10:51
johnthetubaguygmann: true, I might be worrying too much, anyways the role:admin check will break System Reader10:54
yaawangjohnthetubaguy: Some vms do not want to use auto-converge/post-copy, but the other can use these feature. Auto-converge/post-copy can help vm live-migrate more faster, it's good to vm which can accept the performance reduce. Disable auto-converge/post-copy means all vms can't use them, it's not a good idea to users.10:58
*** slaweq has joined #openstack-nova11:01
*** beagles has quit IRC11:03
johnthetubaguyyaawang: for the VMs that don't want post copy or auto-converge, what do they want instead? are they OK being paused for longer, so the performance is more predicable during the live-migration?11:05
*** jaosorior has joined #openstack-nova11:07
*** spatel has joined #openstack-nova11:09
*** dpawlik has quit IRC11:12
*** guozijn has quit IRC11:15
yaawangjohnthetubaguy: Just normal live-migration without any addition option, the main point is decrease the effort of source vm's performance. If the user call force-complete API, nova will pause the vm, it may not a good idea for now :(. But there are no more good idea.11:19
*** ttsiouts has joined #openstack-nova11:22
*** luksky has joined #openstack-nova11:25
openstackgerritLee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type  https://review.opendev.org/66288711:27
openstackgerritLee Yarwood proposed openstack/nova master: DNM/WIP blockinfo: Use SATA bus for cdrom devices when using q35  https://review.opendev.org/66301111:27
lyarwoodmdbooth / kashyap ^ q35 hackaround as discussed, tempest is passing locally using q35 again, I'll sort the unit tests out now.11:28
sean-k-mooneylyarwood: isnt that in a docs comment somewhere11:28
sean-k-mooneylyarwood: e.g. you have to use sata11:28
sean-k-mooneybecause ide is not supported11:28
sean-k-mooneyim pretty sure we discussed needing to do that months ago11:28
sean-k-mooneyim guessing your just adding it now :)11:28
lyarwoodnot that I can see11:28
lyarwoodit likely came up11:29
sean-k-mooneyi remember talking to kasabp about it during the stien cycle11:29
sean-k-mooneyi was going to say before chritmas but i think it was early january11:29
lyarwoodright, I think the action just slipped through the cracks and we missed the impact on config drive users11:29
sean-k-mooneyah ya makes sense11:30
sean-k-mooneythey could se hw_cdrom_bus11:30
sean-k-mooneythey could se hw_cdrom_bus=sata11:30
sean-k-mooneyas a workaourd11:30
sean-k-mooneybut ya11:30
*** janki has quit IRC11:30
kashyaplyarwood: Yeah, will look11:31
johnthetubaguyyaawang: so I want to support your use case, but I am really against "use post copy" and "use auto converge" as things we expose. I really want to have something that doesn't depend on how we implement it, I am adding some ideas / alternatives in the spec comments.11:32
kashyapjohnthetubaguy: Yeah, I see what you mean on that; me also needs to look at that spec11:32
*** ttsiouts has quit IRC11:33
*** markvoelker has joined #openstack-nova11:33
*** ttsiouts has joined #openstack-nova11:34
yaawangjohnthetubaguy: I've replied your comment about why not only use post-copy.11:34
johnthetubaguykashyap: yeah, I found something in google's APIs that I think expresses the user intent better11:34
kashyapI see; do provide a URL when you get around to it11:34
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Policy Default Refresh spec  https://review.opendev.org/54785011:34
*** cmart has quit IRC11:34
johnthetubaguyyaawang: ah... thank you, I forgot about the VM needing to reboot if you loose network connectivity with Post Copy11:35
gmannjohnthetubaguy: ^^ updated for current comments. i will check other review comments tomorrow.11:35
*** ttsiouts_ has joined #openstack-nova11:37
*** dave-mccowan has joined #openstack-nova11:37
johnthetubaguygmann: thanks, sorry for the delay, too much multi-tasking... and I need to get some lunch11:37
*** ttsiouts has quit IRC11:38
gmannjohnthetubaguy: i know, how many time you need to switch the context :)11:38
johnthetubaguygmann: I am wondering if we need to split the details into two...11:38
johnthetubaguygmann: maybe this should be two specs (...ducks)11:39
*** tetsuro has quit IRC11:39
johnthetubaguygmann: so first bit is admin_only and admin_or_owner with tests and better default check_str and scope_types11:40
gmannjohnthetubaguy: hummm you mean separate for scope and default roles ?11:40
gmannok11:40
johnthetubaguygmann: second spec is adding the Reader role support?11:40
johnthetubaguynow... I know the reader role support is why we are doing it really11:40
johnthetubaguyI just think we need to separate the two bits of work, as they have two different sets of thinking around how we keep it backwards compatible11:41
yaawangjohnthetubaguy: Pleasure, can you remove -1 on the gerrit? :)11:41
johnthetubaguyI think the Reader thing is easy, once you have the other stuff in place11:41
johnthetubaguyyaawang: I am still -1 the current approach though, because it talks about the specific implementation, we need to talk about what the workload needs in a way that is hypervisor agnostic... ideally that is.11:42
gmannjohnthetubaguy:  so in first bit we will keep all GET with system_admin or project_member etc and in second we change them to reader roles11:42
*** _hemna has joined #openstack-nova11:42
johnthetubaguyyaawang: I will come back with a better suggestion after I have had lunch11:42
*** dpawlik has joined #openstack-nova11:43
johnthetubaguygmann: yeah, I think that is what we agreed at the PTG in terms of splitting up the patches as we improve the coverage11:43
johnthetubaguygmann: the second reader roles spec is where we need the extra granular roles too, I guess11:43
gmannyeah, granular rules is needed mainly for reader capability11:44
*** frankwang has quit IRC11:44
johnthetubaguygmann: do you think that makes sense? I don't want to drag it out too much, but I think we need that split due to all test coverage and the change to the DB level check11:44
johnthetubaguygmann: so the DB level check would go with the reader change I think11:45
*** panda|ruck is now known as panda|ruck|eat11:45
*** ccamacho has quit IRC11:45
johnthetubaguynow the customers I have really want the reader role, they don't care about the other bits, they are "just a dependency" to make things work :(11:46
gmannbut DB check needs to adjust with scope_type right say when we will change current admin to system_admin11:46
johnthetubaguywell the DB check is only needed by the Reader rule11:46
johnthetubaguyI mean...11:46
gmanni am still thinking if split  can end  up with 2 upgrade impact for operator.11:46
gmannohk, yeah mostly GET thing11:47
johnthetubaguyso I think the reader role addition has no upgrade impact... unless you happen you use the role "reader" instead of "member"11:47
johnthetubaguywell, there granularity change is an impact I guess, but it only affects folks who have changed those policy rules, which should be quite a smaller number of folks11:48
johnthetubaguygmann: so maybe the best thing is keep it as one spec, but make that clear split in the spec description?11:49
gmannyeah that looks much better to me.11:49
gmanncurrent spec is split for scope_type and roles. i can make it to 1. admin, admin-or-owner -> system scope, project member 2. reader role and DB checks change11:50
*** panda|ruck|eat is now known as panda|ruck11:51
*** udesale has quit IRC11:52
*** bbowen has joined #openstack-nova11:52
gmannbasically first bit goes more for adding scope type only with adjusted check_str and second goes for adopting default roles. hummm11:52
*** udesale has joined #openstack-nova11:52
johnthetubaguygmann: I think the first does scope_types and check_str optionally checking for Member, and scope:project, etc11:53
*** cdent has quit IRC11:54
johnthetubaguygmann: I think the first does scope_types and check_str optionally checking for Member, and scope:project, etc11:54
johnthetubaguyhmm, maybe that's not right either11:55
johnthetubaguyso I really should get some food, my brain is failing me11:55
gmannit mainly separate the current admin from project operation. i mean current project admin would not be able to perform new system level admin operation unless token is scoped with system.11:58
gmannif deployment choose to enforce the scope_type11:58
gmanni still feel reader ability makes these changes more useful otherwise operator can still add project member with system scope and lie to nova/oslo.12:00
*** jaosorior has quit IRC12:00
*** b3nt_pin has joined #openstack-nova12:02
*** tbachman has joined #openstack-nova12:04
*** markvoelker has quit IRC12:05
johnthetubaguygmann: yeah, maybe we just do this in one shot... going to think on that over lunch12:06
johnthetubaguyyaawang: thank you for explaining your use case, I think if we rename the image properties and flavor extra specs slightly, I am happy.12:06
johnthetubaguyyaawang: I have added a suggestion on your spec12:07
gmannjohnthetubaguy: ok, will catch with you ( or on gerrit) tomorrow. thanks for review and detail discussion.12:07
yaawangjohnthetubaguy: Thanks, will look later...12:08
*** tbachman has quit IRC12:09
*** spatel has quit IRC12:12
*** _hemna has quit IRC12:17
*** tbachman has joined #openstack-nova12:17
*** mugsie is now known as mugsie_12:18
*** mugsie_ is now known as mugsie12:18
*** Sundar has joined #openstack-nova12:24
*** priteau has quit IRC12:34
*** BlackDex_ is now known as BlackDex12:35
*** panda|ruck is now known as panda|ruck|eat12:37
*** spsurya has quit IRC12:40
*** amyltsev has joined #openstack-nova12:44
*** stress_t has joined #openstack-nova12:45
*** cdent has joined #openstack-nova12:48
amyltsevHello, could someone advice, can I have name of volumes which were created during creation instances with volume creation, like the instance name?12:48
*** davidsha has joined #openstack-nova12:48
*** panda|ruck|eat is now known as panda|ruck12:51
*** priteau has joined #openstack-nova12:58
kashyapsean-k-mooney: On 'virtio-blk' vs. 'virtio-scsi', I'd say you got it the other way round: 'virtio-scsi' was designed to address the limitations of 'virtio-blk'12:59
*** Luzi has joined #openstack-nova13:00
sean-k-mooneykashyap: virtio-scsi is generally slower as it has to emulate a scsi contoller13:01
*** BjoernT has joined #openstack-nova13:01
kashyapsean-k-mooney: In _some_ workloads 'virtio-scsi' is slower, in others, it outperforms 'virtio-blk'13:01
yonglihesean-k-mooney: Hi13:02
sean-k-mooneyyonglihe: hi13:03
sean-k-mooneykashyap: in anycase we are defaulting to sata so its not really that relevent13:03
yongliheI'm finding you that NUMA stuff api spec13:03
sean-k-mooneykashyap: i normally only use virtio-scsi when im using ceph13:03
kashyapsean-k-mooney: Sure, but I wanted to point out that correction13:03
kashyapYep, noted13:04
kashyapsean-k-mooney: Also most new features are implemented on 'virtio-scsi'-only; due to the difficulty to extend 'virtio-blk'13:04
*** priteau has quit IRC13:04
yonglihesean-k-mooney:  Hope you have time ,thanks.  https://review.opendev.org/#/c/658716/   spec "show-server-numa-topology"13:05
sean-k-mooneykashyap: yes i know. i do follow the qemu/kvm development too not quite as closely as you but enought to know where to look this up when i need too13:05
kashyap(Nod)13:06
sean-k-mooneythe storage subsystem in qemu/kvm is one i have looked into a few times but its also the first thing i swap out of memory :)13:09
kashyapsean-k-mooney: Hehe, I spent far too much time following and playing with the Block Layer13:10
kashyapAnd _still_ I swap out routinely13:10
*** ttsiouts_ has quit IRC13:10
*** ttsiouts has joined #openstack-nova13:11
yonglihePaste "clean up orphan instances" here,  need review : https://review.opendev.org/#/c/627765/13:11
sean-k-mooneyyonglihe: i just responded to your question on v2 and ill review v4 after i grab a cup of coffee.13:12
lyarwoodkashyap: https://github.com/openstack/nova/blob/2ea6e6f8db9fc6cecf389cacdd0d82d8226b99fb/nova/conf/libvirt.py#L714 - Any idea why we don't set defaults for hw_machine_type?13:13
*** Luzi has quit IRC13:13
kashyaplyarwood: We set for AArch64 and s390x; but not for x86_6413:13
* kashyap clicks13:13
sean-k-mooneyyonglihe: claning up instance not listed in the db can be dangous in some cases13:13
sean-k-mooneyill try to review that also but how are you validiating that openstack created the instnce13:14
sean-k-mooneyare you checking for the metadata we add in the domian xml?13:14
yongliheI create a out of band vm13:14
kashyaplyarwood: We don't set for x86_64, because we don't have enough information for that.13:14
kashyaplyarwood: That's what this spec is supposed to handle: https://review.openstack.org/#/c/631154/ ("WIP: Gracefully handle QEMU machine types for guests")13:15
lyarwoodkashyap: I don't even see a default listed in that section13:15
sean-k-mooneyyonglihe: to be clear my concern is we allow people to run non openstack manged vms on openstack compute nodes. so your orpahn patch should not break that usecase13:15
lyarwoodkashyap: ah right13:15
kashyaplyarwood: We choose the defaults for non-x86_64 in the method you just moved: get_machine_type()13:15
*** ttsiouts has quit IRC13:15
kashyapI even added a NOTE there :-)13:15
kashyap        if caps.host.cpu.arch in (obj_fields.Architecture.ARMV7,13:15
kashyap                                  obj_fields.Architecture.AARCH64):13:15
kashyap            mach_type = "virt"13:15
kashyapLikewise, for s390x13:15
yonglihesean-k-mooney: if it's dangers in any way,  we should address that. for the none OS vms,  some ones need this to clean up and some one does not. the default action now is noop.13:16
lyarwoodkashyap: right sorry I'm specifically talking about the hw_machine_type option itself13:17
*** mriedem has joined #openstack-nova13:17
lyarwoodkashyap: and the fact that option doesn't actually have a default13:17
sean-k-mooneyyonglihe: right but what im suggesting is we shoudl chacke the domain xml to confim if it contains the metadata we add with the instacne uuid/flavor/image and other info were we say this vm was created by nova13:17
lyarwoodkashyap: I assumed it did and that caused loads of tests to fail as the final lookup would use that config option and return None13:17
sean-k-mooneyyonglihe: if that info is not present then we should not reap the vm as it was not create by nova13:18
kashyaplyarwood: Even for the config option *itself*, we don't set default as we don't have enough information about the guest OS13:18
yonglihesean-k-mooney: seems like a good point and we need that.13:18
*** b3nt_pin is now known as beagles13:19
lyarwoodkashyap: ack understood13:19
kashyaplyarwood: That's why we delegate setting default machine type to orchestrators.13:19
yonglihesean-k-mooney: you may want to comment this to the patch and i gonna address that.  -:)13:19
sean-k-mooneyyonglihe: that will driver dependent but i think it makes sense to have a call to the driver to retrun the set of possible ophean instances and then for the compute manager to ask the driver to reap them.13:20
sean-k-mooneysure ill add it to the review13:20
mriedemlyarwood: bauzas: dansmith: can we get these stein backports in so i can do a release? https://review.opendev.org/#/q/topic:bug/1830747+status:open+branch:stable/stein13:22
bauzasmriedem: ack I can take a look13:23
yonglihesean-k-mooney: driver specific is spitted out, there is 2 patches on set. find the orphan seems like logic belong to compute but checking the metadata is definitely driver's scope.13:23
sean-k-mooneyyonglihe: well i woudl expect the driver to be the thing that check what intances are running on the host and provide a kwarg to allow filtering to just vms it created.13:25
*** ttsiouts has joined #openstack-nova13:26
sean-k-mooneybut i wouuld expect the compute manager to be the thinkg that calls that and descided if it should reap or not based on the policy set in the config13:26
sean-k-mooneywell i guess its a periodic task but the point is i would expect the fucntion exectued by the periodic task to be driver independent13:27
dansmithmriedem: yes13:27
lyarwoodthanks dansmith13:29
*** brinzhang has quit IRC13:30
*** lbragstad has joined #openstack-nova13:32
*** spatel has joined #openstack-nova13:32
openstackgerritMatt Riedemann proposed openstack/nova stable/stein: Noop CantStartEngineError in targets_cell if API DB not configured  https://review.opendev.org/66303013:32
yonglihesean-k-mooney:  anyway there is a new  API need added to driver layer. and i agree it should decouple with driver in some way. now it's not the way you prefer. but it's driver's choice to  implement or not.13:34
*** spatel has quit IRC13:36
*** cdent has quit IRC13:38
*** luksky has quit IRC13:41
yaawangjohnthetubaguy: Hi, I've replied your suggestion, is it correct? https://review.opendev.org/#/c/65168113:41
*** cmart has joined #openstack-nova13:42
*** lpetrut has quit IRC13:43
openstackgerritDan Smith proposed openstack/nova master: Make nova-next archive using --before  https://review.opendev.org/66100213:45
openstackgerritMerged openstack/nova-specs master: Amend count-quota-usage-from-placement to reflect implementation  https://review.opendev.org/66213013:47
johnthetubaguyyaawang: opps, your question points out I explained my idea badly, I will reply in the review soon13:47
*** boxiang has quit IRC13:49
*** boxiang has joined #openstack-nova13:52
*** mlavalle has joined #openstack-nova13:53
*** liuyulong has joined #openstack-nova13:53
*** boxiang has quit IRC13:55
*** boxiang has joined #openstack-nova13:55
*** luksky has joined #openstack-nova14:00
*** eharney has joined #openstack-nova14:00
*** amorin has joined #openstack-nova14:01
*** cdent has joined #openstack-nova14:02
yaawangjohnthetubaguy: Thanks, I'll look it tomorrow because my timezone is UCT+8 :)14:03
johnthetubaguyyaawang: no problem, have a good evening/night!14:04
*** munimeha1 has joined #openstack-nova14:04
*** rpittau is now known as rpittau|afk14:05
sean-k-mooneygibi: mriedem forgot to push my comments but the reason the vgpu spec only provides soft affitnity curenly is that dansmith ask to reduce the scope to that case so yes part of it need to be updated but in v1 and v2 it proposed multiple affintiy polices14:07
sean-k-mooneygibi: mriedem which is why the oringal use case refer to enforcing numa affinity14:07
*** spatel has joined #openstack-nova14:08
mriedemsean-k-mooney: ok -1 to clean that up then to avoid confusion14:12
*** _hemna has joined #openstack-nova14:13
*** ivve has quit IRC14:13
* mriedem goes to the dentist, back in about 90 minutes14:14
*** mriedem is now known as mriedem_away14:14
*** amyltsev_ has joined #openstack-nova14:17
*** ivve has joined #openstack-nova14:19
*** amyltsev has quit IRC14:20
*** zbr has quit IRC14:21
*** amyltsev has joined #openstack-nova14:22
*** zbr has joined #openstack-nova14:23
*** BjoernT has quit IRC14:25
*** amyltsev_ has quit IRC14:26
*** amyltsev has quit IRC14:28
*** BjoernT has joined #openstack-nova14:41
openstackgerritMerged openstack/nova stable/stein: Add regression recreate test for bug 1830747  https://review.opendev.org/66257414:47
openstackbug 1830747 in OpenStack Compute (nova) stein "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem)14:47
*** aarents__ has quit IRC14:48
*** abhishekk has joined #openstack-nova14:49
*** owalsh has quit IRC14:49
openstackgerritMerged openstack/python-novaclient master: Bump openstackdocstheme to 1.30.0  https://review.opendev.org/66290514:52
*** BjoernT_ has joined #openstack-nova14:53
*** BjoernT has quit IRC14:56
*** owalsh has joined #openstack-nova14:56
*** lpetrut has joined #openstack-nova14:57
*** shilpasd has quit IRC14:58
*** itlinux has quit IRC14:58
*** cfriesen has joined #openstack-nova15:01
*** luksky has quit IRC15:04
*** ttsiouts has quit IRC15:04
*** ttsiouts has joined #openstack-nova15:05
*** dpawlik has quit IRC15:05
*** cfriesen has quit IRC15:06
*** ttsiouts has quit IRC15:09
*** cfriesen has joined #openstack-nova15:17
*** dpawlik has joined #openstack-nova15:18
*** _hemna has quit IRC15:18
*** dpawlik has quit IRC15:22
*** damien_r has quit IRC15:29
*** lpetrut has quit IRC15:29
*** gyee has joined #openstack-nova15:35
*** helenafm has quit IRC15:38
*** spsurya has joined #openstack-nova15:39
*** bnemec has quit IRC15:44
*** jistr is now known as jistr|call15:45
*** jistr|call is now known as jistr15:45
*** bnemec has joined #openstack-nova15:46
*** hamzy_ has quit IRC15:48
*** itlinux has joined #openstack-nova15:54
*** Sundar has quit IRC15:57
*** ccamacho has joined #openstack-nova15:57
*** itlinux has quit IRC15:59
*** damien_r has joined #openstack-nova16:02
*** davidsha has quit IRC16:02
*** abhishekk has quit IRC16:08
*** ivve has quit IRC16:08
yaawangjohnthetubaguy: Thanks for your commet.16:09
efriedkashyap: you and yaawang have been talking about cpu model list. Would you be okay if we restored the spec and let yaawang take over convincing the world it has legs?16:10
yaawangmriedem_away: Could you take a look at this spec, please. https://review.opendev.org/#/c/65168116:10
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using q35 machine type  https://review.opendev.org/66301116:10
openstackgerritLee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type  https://review.opendev.org/66288716:10
lyarwoodmdbooth / kashyap / artom ; ^ finally got through all of the tests, it's pretty horrific so if someone has a better way I'm all ears :)16:10
*** dtantsur is now known as dtantsur|afk16:11
*** itlinux has joined #openstack-nova16:11
*** spatel has quit IRC16:11
mdboothlyarwood: Looking now.16:11
mdboothOuch, test_driver.py!16:12
artomlyarwood, we'd want to backport this, right?16:13
*** damien_r has quit IRC16:13
lyarwoodyup16:13
artomThe thing is, it's hard to know if another approach would have less collateral damage without actually trying it16:14
artomBecause backporting this in its current form will be a pain, I suspect16:14
mdboothartom: I don't think we need to backport further than Stein though, right?16:14
artommdbooth, true16:14
lyarwoodit's actually clean at the moment16:14
lyarwoodto stable/stein16:14
* mdbooth would hope Stein isn't too hard right now16:14
artomWhoa...16:14
lyarwoodsomehow16:15
mdboothQuick, land it!16:15
lyarwoodhaha16:15
artomMy brain's kinda foggy, but yeah, if it backports clean, I suppose it's OK16:18
artomDon't really see a way around it16:18
lyarwoodkk, I'll sort out the missing tests now16:18
*** wwriverrat has quit IRC16:19
*** mriedem_away is now known as mriedem16:20
*** xek has quit IRC16:20
*** xek_ has joined #openstack-nova16:20
mriedemyaawang: you said you had to go to bed :)16:21
mriedemefried: sean-k-mooney: dansmith: gibi: more replies in the nova/cinder spec https://review.opendev.org/#/c/603955/ with my top two concerns listed when i left my latest comment (the latter is an implementation detail so not a huge deal),16:22
yaawangmriedem: haha :)16:22
sean-k-mooneymriedem: *nova/cyborg16:22
mriedembut in general how much debate has already happened about the API change to *always* have nova manage ARQ creation/lifecycle management vs just having the API accept a pre-created ARQ id like SR-IOV ports?16:22
mriedemsean-k-mooney: heh yeah16:22
mriedemmy ideal would be to have version 1 only accept pre-created ARQ ids and attach them rather than version 1 be nova as sole orchestrator16:23
mriedembut if this has already been debated for 2 years i don't want to wade into that pool16:23
sean-k-mooneymriedem: i dont know how much that has been debated in the current iteration. at present the spec has nova always create the ARQ16:23
sean-k-mooneybecause the request it via the flavor16:23
sean-k-mooneybut treating it like a netorn port also makes sense to me16:24
mriedemthe user wouldn't have to request it via the flavor if they just passed an ARQ id right?16:24
sean-k-mooneyeventrually i think we will want somethign like  "openstack server create --device ..."16:24
kashyapefried: Hi, I'm okay restoring.  But maybe at this point, a small PoC would already be better, if yaawang wants to tackle.16:24
dansmithmriedem: pretty sure every discussion we've had I've argued for the "make them be pre-created first"16:24
efriedkashyap: Okay, let's do that. <== yaawang16:25
mriedemdansmith: yeah...because over the years we've pushed back on nova orchestrating external resources, but this starts out with the total opposite end16:25
kashyaplyarwood: That diffstat...16:25
dansmithmriedem: I haven't really tracked the spec of late, but we had a three phase approach at the previous denver ptg, to not have nova do the creation in the first pass16:25
dansmithmriedem: yeah, well, that definitely sounds like not what I had suggested16:25
sean-k-mooneymriedem: well that is because in the second denver ptg we layed out a 3 phase aproch16:25
sean-k-mooneyfirst staticaly request via flavor16:26
mriedemthe thing that really concerns me is there is talk about hot plug support in the future where the compute API would grow support for passing the device profile directly which i'm against,16:26
*** damien_r has joined #openstack-nova16:26
mriedemrather than just pre-create the ARQ and hand it to nova to attach16:26
*** damien_r has quit IRC16:26
sean-k-mooneyseacond extend nova api to support precreated ports third i forget16:26
mriedemsean-k-mooney: so the opposite of what dansmith just said :)16:26
sean-k-mooneyor third was suppoort hot attach/detach16:26
kashyapefried: FWIW, I'd strongly prefer if they write a _clear_ functional test (even if manual) to clearly show the truth.16:26
sean-k-mooneymriedem: yes the opisite fo what dan just sain16:27
kashyapBecause ... "to show truth is to automatically persuade."16:27
dansmithsean-k-mooney: well, maybe we're confusing things16:27
dansmithmriedem: ^16:27
mriedemsean-k-mooney: do we know why that changed?16:27
*** lpetrut has joined #openstack-nova16:27
kashyap(s/write/wrote/)16:27
dansmithbecause the thing sean-k-mooney is describing is what I'm talking about16:27
*** jangutter has quit IRC16:27
sean-k-mooneyperhaps the reason its this way si to not require modificaiton of the nova api16:27
mriedemsean-k-mooney: that's what Sundar said in the spec as well,16:27
mriedemit's still a compute API change,16:27
mriedemit's just not a schema change16:27
mriedemtrojan horsing the device profile through the flavor is still an api change16:28
sean-k-mooneywell its actully jsut a flavor extraspec16:28
mriedemyeah i know16:28
sean-k-mooneybut ya technically16:28
bauzasfolks, fwiw I wasn't able to do spec reviews today, but I'll do it tomorrow16:28
mriedembut there is still a lot of stuff in the api/conductor that needs to change to create the arq16:28
mriedemand wire the request spec up for scheduling16:28
*** itlinux has quit IRC16:29
sean-k-mooneymriedem: yes alot of that would be reused in precreated case16:29
sean-k-mooneyat least passing it to the schduler16:29
dansmithmriedem: yeah reading your comments, I think what's being described _is_ what we discussed at the previous denver ptg16:29
*** cdent has quit IRC16:29
dansmithwhich *was* to have nova do the creation, but just based on some static profile listed in the flavor,16:29
dansmithtaking the nova api interaction part out16:30
dansmithbut that's akin to an attachment for cinder, which I think makes sense here16:30
dansmithor a binding for neutron16:30
mriedemwell, you mean nova creating a volume or a port right?16:30
*** itlinux has joined #openstack-nova16:30
mriedemon behalf of the user16:31
dansmithno16:31
dansmithbecause the complex configuration  bits are wrapped up in the profile, right?16:31
sean-k-mooneykind of16:31
dansmithit's not a direct correlation, but nova currently does its own attaching of ports and volumes to a host once it knows where it's going, even if the complex volume or port was created, configured, etc by the user16:32
dansmiththat's the analog I think I'm making here16:32
sean-k-mooneythe profile is just a string in the nova flavor extra spec and wehn we ask cyborg for the detail of the profile it gives us back a set of resource requests and traits16:32
dansmithright16:32
sean-k-mooneyand later when we bind the arq to a specifc host cyborge say "heres a pci device"16:32
sean-k-mooneyand we generagte the correct xml to pass it to the guest16:33
dansmithright, which to me is equivalent to a host binding or cinder attachment16:33
mriedemsure i get that,16:34
dansmithI really haven't read the spec in a while so I should probably keep my mouth shut,16:34
mriedemit's not really what i'm talking about though16:34
mriedemnova has to do the binding either way,16:34
sean-k-mooneyyes but the profile is more like a neutron network in that we told you i want an arq of this type "or a port on this network" and nova is creating an new arq instance like it create a neutron port16:34
openstackgerritSylvain Bauza proposed openstack/nova master: Pass allocations to virt drivers when resizing  https://review.opendev.org/58908516:34
mriedemi was just concerned about nova being responsible for creating the arq resource always rather than passing a pre-created arq id and just using that (which is already linked to a device profile)16:34
sean-k-mooneyi then binds that arq the same way it bind the prot16:34
mriedemsean-k-mooney: right that's what i'm getting at,16:35
mriedemand i worry that will get more complicated down the road (like SR-IOV ports) which requires the compute API to grow complexity to handle new types of devices16:35
dansmithI think the benefit of not letting them pass an ARQ in first is that it delays our commitment to the api user until after this kinda actually works16:35
sean-k-mooneymriedem: so in a way yes we are proxing the creation of the arq but we chose to do that to reduce the change in the api.16:35
mriedemwhereas for sriov ports we just said, nope, use the neutron api first if you want those16:36
openstackgerritJohn Garbutt proposed openstack/nova master: Add functional test for admin_actions  https://review.opendev.org/65769816:36
openstackgerritJohn Garbutt proposed openstack/nova master: WIP: add scope check, see tests catch the change  https://review.opendev.org/65782316:36
openstackgerritJohn Garbutt proposed openstack/nova master: Ensure we pass a target in admin actions  https://review.opendev.org/66309516:36
sean-k-mooneydansmith: ya i think that was the basis of your original argument for this approch in the ptg session16:36
mriedemsean-k-mooney: dansmith: ok, ack, i'll yield on that, and had said in my review that i'm sure this has been debated and discussed before and i'm just catching up on that, so don't want to block on it16:37
*** damien_r has joined #openstack-nova16:37
sean-k-mooneye.g. to defer the api change until this actully works16:37
dansmithsean-k-mooney: yep16:37
mriedembased on all that the spec is probably mostly ready to go after Sundar cleans it up a bit16:37
*** itlinux has quit IRC16:37
*** xek_ has quit IRC16:37
sean-k-mooneylong term i think have a --device option on the server create commandline and the appropriate api change makes the most sense and allow the precreation of ports16:38
mdboothlyarwood: Done.16:40
mriedemok thanks, linked to this discussion for Sundar and once he cleans up i'll probably +2 the spec16:40
*** itlinux has joined #openstack-nova16:42
mriedemdansmith: if there is one spec you review on this, the 3rd formal spec review sprint of the train release, it should be *my* spec for pre-filtering disabled computes https://review.opendev.org/#/c/657884/ :)16:49
dansmithorly?16:49
mriedemmostly b/c i have a quandary in there16:50
*** maciejjozefczyk has quit IRC16:51
*** sapd1_x has quit IRC16:53
openstackgerritMerged openstack/nova stable/stein: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66289416:53
*** sapd1_x has joined #openstack-nova16:53
sean-k-mooneymriedem: oh i thought your disabled nodes prefilter spec was already merged16:54
*** lpetrut has quit IRC16:55
*** damien_r has quit IRC17:01
*** derekh has quit IRC17:06
*** luksky has joined #openstack-nova17:08
*** hamzy has joined #openstack-nova17:10
openstackgerritJohn Garbutt proposed openstack/nova master: WIP: add scope check, see tests catch the change  https://review.opendev.org/65782317:11
dansmithmriedem: I'm super confused about this17:14
dansmiththis spec seems to confuse disabledness and down-ness17:14
dansmithI'm commenting17:14
*** _hemna has joined #openstack-nova17:14
*** sapd1_x has quit IRC17:17
openstackgerritStephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize  https://review.opendev.org/66252217:17
openstackgerritStephen Finucane proposed openstack/nova master: tests: Add '_setup_compute_services' helper  https://review.opendev.org/66310217:18
*** tbachman has quit IRC17:21
*** spatel has joined #openstack-nova17:21
spatelFolks, i am getting this error qemu-kvm: -object memory-backend-ram,id=ram-node0,size=12884901888,host-nodes=0,policy=bind: cannot set up guest memory 'ram-node0': Cannot allocate memory17:21
spatelI have 32G memory and hugemem is 25G17:21
spateli am trying to build VM with 24G and its throwing this error17:22
sean-k-mooneyspatel: do you have 24G of hugepages on a single numa node17:23
*** itlinux has quit IRC17:23
spatelno17:23
sean-k-mooneyby default the kernel will split it across all numa nodes  if you allcoate the hugepages on teh kernel commandline17:23
spatelHow do i tell my flavor to use both side of NUMA ?17:24
*** itlinux has joined #openstack-nova17:24
*** whoami-rajat has quit IRC17:24
sean-k-mooneyam you have to create a guest with multiple numa nodes which is done by setting hw:numa_nodes=217:24
*** luksky has quit IRC17:24
sean-k-mooneyin the flavor17:24
spatelI have that option already in flavor17:25
sean-k-mooneyor hw_numa_nodes=2 in the image metadat17:25
sean-k-mooneywell yes it requesting 12 Gof hugepages on numa 017:25
sean-k-mooneybut you may not have 12G free17:25
*** luksky has joined #openstack-nova17:26
spatelThis is i have currently hw:cpu_policy='dedicated', hw:mem_page_sizee='large', hw:numa_nodes='2'17:26
sean-k-mooneyyes so that will use hugepage,cpu pinning and create a vm with 2 numa nodes17:27
spatelI have 32G memory total ( 16G per numa)17:27
sean-k-mooneyif you check cat /sys/devices/system/node/node*/meminfo17:27
sean-k-mooneydo you have 12G of free hugepages per node17:28
*** ociuhandu has quit IRC17:28
stephenfinsean-k-mooney: Now with functional tests https://review.opendev.org/#/c/662522/17:29
spatelThis is i have in my grub hugepagesz=2M hugepages=1228817:29
stephenfinStill need to figure out how I can rollback the changes to the field in the event that the resize fails but that's tomorrow's problem17:29
sean-k-mooneystephenfin: cool i take it we never save the modifed request_spec?17:29
sean-k-mooneystephenfin: well first confirm ^17:30
sean-k-mooneyif we dont save it then your good17:30
stephenfinnot sure yet. I'll check that out first, yup17:30
*** tbachman has joined #openstack-nova17:30
spatelsean-k-mooney: 25723 MB total huge page17:30
spatelshould i assume its divided between two numa node (25/2 = 12.4G)17:31
sean-k-mooneyspatel: ya that should give you ~ 12.5G per numa node but what does "cat /sys/devices/system/node/node*/meminfo  | grep HugePages" show17:32
-spatel- [root@ostack-compute-sriov-196 ~]# cat /sys/devices/system/node/node*/meminfo | grep -i hugepage17:33
-spatel- Node 0 AnonHugePages: 0 kB17:33
-spatel- Node 0 HugePages_Total: 614417:33
-spatel- Node 0 HugePages_Free: 614417:34
-spatel- Node 0 HugePages_Surp: 017:34
-spatel- Node 1 AnonHugePages: 0 kB17:34
-spatel- Node 1 HugePages_Total: 614417:34
-spatel- Node 1 HugePages_Free: 614417:34
-spatel- Node 1 HugePages_Surp: 017:34
spateloh!!!17:34
spatel6G free17:34
sean-k-mooneyno17:34
sean-k-mooneyyou default hugepage size it 2m17:34
sean-k-mooneythat is reported in pages not MBs17:35
spateloh, ok17:35
sean-k-mooneyso you have exactly 12G of hugepage per numanode17:35
spatelshould i create flavor with 23G?17:35
sean-k-mooneyi susspect that that would work yes17:35
spatellet me try.. hold tight17:35
sean-k-mooneyi think we have an off by 1 issue when we woudl use it exactly17:36
sean-k-mooneyi know i have had issue wiht that in the past so i usally round up my allocation on the kernel slightly17:36
sean-k-mooneyso hugepagesz=2M hugepages=12300 in your case instead of hugepagesz=2M hugepages=1228817:37
*** tssurya has quit IRC17:38
*** ricolin has joined #openstack-nova17:38
*** ivve has joined #openstack-nova17:39
*** gyee has quit IRC17:41
sean-k-mooneyspatel: if 23G works then then you are likely hitting the isssue were we cant consume every hugepage page which has been a thing forever. i thought that was fixed litrally years ago but we could have regressed.17:42
spatelsean-k-mooney: it works!! instance is Up and running, I am in :)17:45
-spatel- total used free shared buff/cache available17:45
-spatel- Mem: 22394 526 21268 16 599 2149517:45
-spatel- Swap: 4095 0 409517:45
*** udesale has quit IRC17:46
sean-k-mooneyspatel: as a workaround i would just increase your group settings 12300 instead of 1228817:46
sean-k-mooney12288 is exactly 24G of hugepages17:46
spatelhmm!17:47
sean-k-mooneycan you file a bug so we have something to track fixing the case where we use every single page in 1 vm17:47
*** luksky has quit IRC17:48
spatelcan you explain me what went wrong in my case so it would be easy for me to open bug17:48
*** _hemna has quit IRC17:48
sean-k-mooneyso you had allocated 12288 2MB hugepages which is 24G exactly17:49
sean-k-mooneyand then you created a flavor that requested all 24G17:49
sean-k-mooneye.g. 12288 hugpages17:49
sean-k-mooneyin this case i belive we have an off by 1 error where we say it can't fit when it can fit exactly17:49
sean-k-mooneybasically i think we are doign a < so where where it shoudl be <=17:50
spatelopening bug now17:50
sean-k-mooneyi know this used to be a bug when we first intoduced hugepages back in like 2014 but its totally posibel that that bug has been reinotduce or that we just never got aroud to fixing it17:51
*** jdillaman has quit IRC17:55
sean-k-mooneythis should be correct https://github.com/openstack/nova/blob/master/nova/objects/numa.py#L140-L157 but that said the error came from qemu so perhaps this is a qemu issue17:55
*** luksky has joined #openstack-nova18:00
openstackgerritMerged openstack/nova master: db: Remove cell APIs  https://review.opendev.org/65130918:02
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66311018:04
*** brault has joined #openstack-nova18:05
spatelsean-k-mooney: https://bugs.launchpad.net/nova/+bug/183165218:06
openstackLaunchpad bug 1831652 in OpenStack Compute (nova) "fixing the case where we use every single page in 1 vm" [Undecided,New]18:06
spatelsean-k-mooney: Thank you for help :)18:06
sean-k-mooneyspatel: no worries as i said the error seams to be coming form qemu so its likely that we fixed the nova issue already and qemu also has a bug but at least we have something to track figuring that out18:08
*** brault has quit IRC18:09
*** luksky has quit IRC18:17
*** amodi has quit IRC18:23
*** spsurya has quit IRC18:24
*** whoami-rajat has joined #openstack-nova18:26
*** spatel has quit IRC18:29
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using q35 machine type  https://review.opendev.org/66301118:30
openstackgerritLee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type  https://review.opendev.org/66288718:30
*** tbachman has quit IRC18:30
*** itlinux has quit IRC18:30
*** itlinux has joined #openstack-nova18:31
*** spatel has joined #openstack-nova18:32
*** Sundar has joined #openstack-nova18:33
*** ociuhandu has joined #openstack-nova18:34
*** BjoernT_ has quit IRC18:38
*** itlinux has quit IRC18:39
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using q35 machine type  https://review.opendev.org/66301118:40
openstackgerritLee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type  https://review.opendev.org/66288718:40
*** itlinux has joined #openstack-nova18:43
*** burt has quit IRC18:43
*** ociuhandu has quit IRC18:43
*** burt has joined #openstack-nova18:45
mriedemdansmith: thanks replied on that pre-filter for disabled computes spec18:50
mriedemtl;dr it sounds like don't worry about down services18:51
*** maciejjozefczyk has joined #openstack-nova18:58
*** maciejjozefczyk has quit IRC19:03
dansmithmriedem: ack, replied, but yeah, that's MHO19:05
mriedemregarding old computes that won't be reporting the trait but they get disabled in the api, what are your thoughts on that? the api manages the trait until the compute is upgraded, or just ignore it until upgraded, or add a sync CLI?19:06
mriedemif we do'nt add a sync CLI for old computes that are already disabled, then i'd just ignore those requests in the API19:07
dansmithneither19:10
dansmithignore until upgrade19:10
dansmithwe set disabled=true on the compute record, let the computefilter continue to exclude those at great expense19:10
*** ricolin has quit IRC19:10
dansmithwhen the compute is upgraded and restarted, the u-p-t  sync will update placement19:10
mriedemupt won't set this trait19:11
dansmithwhy?19:11
mriedemwell, i hadn't planned on adding that - it was an alternative but not one i'd baked into the proposed change19:11
dansmithbut why not? it solves a lot right?19:11
mriedemsolves as in upgrades, dropped calls, out of sync, etc?19:12
dansmithit's kindof our "heal placement" loop as it is, so I don't see why we wouldn't19:12
dansmithyeah19:12
mriedemok. in my reply i said we could build that in, so i might as well i guess, i'll move that out of alternatives.19:13
*** cdent has joined #openstack-nova19:20
*** Sundar has quit IRC19:23
*** BjoernT has joined #openstack-nova19:26
*** tbachman has joined #openstack-nova19:28
efriedmelwitt: Is there a reason you're holding back from approving https://review.opendev.org/#/c/579897/ ?19:31
melwittefried: yeah, I hadn't reviewed deep into the change previously and don't know much about the context (the original feature). but since I had expressed a reno would be helpful, I reviewed the change and acked on that basis19:34
efriedokay, thanks.19:34
mriedemefried: dustinc: i'm marking https://review.opendev.org/#/c/662881/ as a WIP since it's clearly a WIP19:34
efriedNot sure who we're looking for to send it19:34
efriedack mriedem19:34
mriedemefried: just spin the roulette wheel of nova cores19:35
efriedmriedem: Tempted to send it myself, adding my almost+2 to the testament of people who tested it live19:36
mriedemprobably shouldn't,19:36
mriedemjust wait for stephenfin or johnthetubaguy to take a look i'd say19:36
efriedI didn't touch much of it. But yeah.19:36
mriedemhttps://www.youtube.com/watch?v=JGftIcp2SC0 ?19:37
dansmithrock on19:37
melwittlol, a song for every occasion19:37
*** bbowen has quit IRC19:38
*** imacdonn has quit IRC19:38
mriedembon was ahead of his time when it came to collaborative software development19:38
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Add regression recreate test for bug 1830747  https://review.opendev.org/66312419:39
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66312519:39
openstackbug 1830747 in OpenStack Compute (nova) rocky "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem)19:39
sean-k-mooneyefried: for what its worth i think the hypervior hiding chance makes sense the only reservation i have is nvida or other may work around this in the future so i tond want us to have to keep addign these workaround but for this specific case i think it makes sense19:40
*** altlogbot_2 has joined #openstack-nova19:40
*** slaweq has quit IRC19:43
dustincmriedem: thanks, I meant to put WIP in the title19:44
*** _hemna has joined #openstack-nova19:45
*** slaweq has joined #openstack-nova19:45
*** Sundar has joined #openstack-nova19:50
*** itlinux has quit IRC19:50
*** imacdonn has joined #openstack-nova19:53
*** itlinux has joined #openstack-nova19:54
*** dave-mccowan has quit IRC19:55
efrieddustinc: In case it's not clear, if it looks like I'm answering questions in the sdk spec, me (or anyone) answering in comments isn't the end of the road - the salient points should be included in the document itself.20:13
*** BjoernT has quit IRC20:17
*** _hemna has quit IRC20:19
dustincefried: very clear, thanks20:27
*** itlinux has quit IRC20:30
*** luksky has joined #openstack-nova20:31
*** hamzy has quit IRC20:31
*** itlinux has joined #openstack-nova20:32
mriedemi'm assuming i'm not alone in saying if we add support to pass an az to the unshelve api https://review.opendev.org/#/c/624689/ we should/would not support the zone:host:node format like on server create which bypasses the scheduler and forces the server onto the specified host and/or node20:40
mriedemfrom earlier review on the spec i think at least alex_xu agrees with me on ^20:41
*** eharney has quit IRC20:41
*** hoonetorg has quit IRC20:42
*** _hemna has joined #openstack-nova20:43
efriedmriedem: You appear to be alone in saying that, at least right now. But I wouldn't take that as dissent.20:44
mriedemhttps://review.opendev.org/#/c/624689/7/specs/train/approved/support-specifying-az-when-restore-shelved-server.rst@4920:44
melwittif it's "obvious" that the only utility for zone:host:node was getting a server into a specific az, then I would agree, but I don't feel sure that's the only reason people were using it20:46
melwitt*for unshelve20:46
*** dklyle has quit IRC20:49
*** dklyle has joined #openstack-nova20:49
*** bbowen has joined #openstack-nova20:52
*** whoami-rajat has quit IRC20:54
*** hoonetorg has joined #openstack-nova20:55
*** cdent has quit IRC20:55
mriedemi'm not sure what that means20:59
mriedemzone:host:node is used during server create to force the server on a specific host and/or node if you're an admin20:59
*** tbachman has quit IRC21:00
mriedemif you're non-admin you can only specify zone21:00
openstackgerritMatt Riedemann proposed openstack/nova stable/ocata: Add regression recreate test for bug 1830747  https://review.opendev.org/66314321:05
openstackbug 1830747 in OpenStack Compute (nova) rocky "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem)21:05
openstackgerritMatt Riedemann proposed openstack/nova stable/ocata: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66314421:05
melwittoh, sorry, I misunderstood what was happening in the spec. I thought that today zone:host:node is supported and that they wish to add specifying az (for non-admins) and that they were proposing removing zone:host:node as part of the change21:05
mriedemnope, just wanting to add az to unshelve21:06
melwittI see now that today there is no zone:host:node support and they want to add specification of az and they're proposing doing it via zone:host:node. I agree it should not be done that way because that's more than only adding the az, that's adding scheduler bypass, as you said21:06
mriedemyar21:06
* melwitt comments21:07
*** pcaruana has quit IRC21:07
mriedemthanks21:15
*** itlinux has quit IRC21:16
*** ivve has quit IRC21:16
*** ivve has joined #openstack-nova21:20
*** mriedem is now known as mriedem_away21:22
*** _hemna has quit IRC21:23
openstackgerritDustin Cowles proposed openstack/nova-specs master: WIP: Spec: Use OpenStack SDK in Nova  https://review.opendev.org/66288121:25
*** munimeha1 has quit IRC21:39
*** luksky has quit IRC21:41
*** spatel has quit IRC21:41
*** tbachman has joined #openstack-nova21:47
cfriesenwhen a nova-compute service is deleted in nova, is that supposed to also remove the relevent row in the resource_providers table?22:06
efriedcfriesen: If it's deleted through proper channels, I think so?22:07
efriedthat would seem to be a pretty obvious miss if not22:07
*** slaweq has quit IRC22:07
efriedYou're supposed to stop the service before you delete it22:08
efriedotherwise the compute will reassert its RP the next time periodics run.22:09
cfriesenI'm debugging a situation with Pike where deleting nova-compute and then adding it back with the same name ends up not updating the resource_providers row so it points at the deleted entry in compute_nodes.22:09
efriedoh, yeah, pretty sure there's been a bug or three about that.22:09
efriedmriedem_away would be able to recite the number off the top of his head.22:09
efriedFraid I gotta run. Good luck :)22:10
cfriesenthanks. :)22:10
*** cmart has quit IRC22:10
*** slaweq has joined #openstack-nova22:11
openstackgerritsean mooney proposed openstack/nova-specs master: add libvirt pqos spec  https://review.opendev.org/66226422:12
*** slaweq has quit IRC22:24
*** slaweq has joined #openstack-nova22:34
cfriesenefried: FYI, pretty sure I found the missing commits.  seems we weren't up-to-date with upstream stable/pike22:41
*** dave-mccowan has joined #openstack-nova22:44
*** slaweq has quit IRC22:47
*** artom has quit IRC22:50
*** tkajinam has joined #openstack-nova22:51
*** cmart has joined #openstack-nova22:53
*** dave-mccowan has quit IRC22:56
*** slaweq has joined #openstack-nova23:04
openstackgerritDustin Cowles proposed openstack/nova-specs master: WIP: Spec: Use OpenStack SDK in Nova  https://review.opendev.org/66288123:16
*** slaweq has quit IRC23:17
*** rcernin has joined #openstack-nova23:20
*** gyee has joined #openstack-nova23:29
*** mlavalle has quit IRC23:34
*** itlinux has joined #openstack-nova23:37
*** itlinux has quit IRC23:38
*** itlinux has joined #openstack-nova23:42
*** itlinux_ has joined #openstack-nova23:45
*** itlinux has quit IRC23:47
*** tbachman has quit IRC23:49
*** slaweq has joined #openstack-nova23:50
*** takashin has joined #openstack-nova23:54

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