Thursday, 2019-09-05

*** BjoernT has quit IRC00:00
*** BjoernT_ has joined #openstack-nova00:00
*** BjoernT_ has quit IRC00:01
*** BjoernT has joined #openstack-nova00:01
*** BjoernT has quit IRC00:02
*** BjoernT_ has joined #openstack-nova00:02
*** trident has joined #openstack-nova00:03
*** ozzzo has quit IRC00:04
*** BjoernT_ has quit IRC00:06
*** macz has joined #openstack-nova00:10
*** ozzzo has joined #openstack-nova00:10
*** macz has quit IRC00:37
*** gyee has quit IRC00:39
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460600:40
openstackgerritArtom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration  https://review.opendev.org/64002100:40
openstackgerritArtom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration  https://review.opendev.org/67259500:40
openstackgerritDustin Cowles proposed openstack/nova master: Provider Config File: YAML file loading and schema validation  https://review.opendev.org/67334100:57
openstackgerritDustin Cowles proposed openstack/nova master: WIP: Provider Config File: Function to further validate and retrieve configs  https://review.opendev.org/67602900:57
openstackgerritDustin Cowles proposed openstack/nova master: WIP: Provider Config File: Merge provider configs to provider tree  https://review.opendev.org/67652200:57
*** tetsuro has joined #openstack-nova00:58
*** markvoelker has joined #openstack-nova01:00
*** markvoelker has quit IRC01:05
*** slaweq has joined #openstack-nova01:11
*** slaweq has quit IRC01:15
*** kaliya has quit IRC01:19
*** rabel has quit IRC01:28
*** kaliya has joined #openstack-nova01:29
*** rabel has joined #openstack-nova01:29
*** markvoelker has joined #openstack-nova02:01
*** markvoelker has quit IRC02:05
*** tetsuro has quit IRC02:18
*** tetsuro has joined #openstack-nova02:20
*** kaliya has quit IRC02:22
*** rabel has quit IRC02:24
*** rabel has joined #openstack-nova02:25
*** mkrai has joined #openstack-nova02:27
openstackgerritBrin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API  https://review.opendev.org/67348502:28
alex_xudansmith: Luyao defined a field type for resource_class https://review.opendev.org/#/c/678448/13/nova/objects/fields.py@94, but I doubt validate the standard rc is right thing.02:49
*** nicolasbock has quit IRC02:49
alex_xudansmith: if we are in the middle of upgrade, like Live migraiton, there will be have object transfer between new and old node. so for old node, it may have old os-resource-class lib, so it may not know the new RC, then the deserilzier will blowup. So if we want the validation, I think we only need a copy of generic RC pattern02:51
alex_xuhttps://github.com/openstack/placement/blob/master/placement/schemas/common.py#L19, let me know if it is right02:51
*** cfriesen has quit IRC02:54
*** mdbooth has quit IRC02:58
*** bbowen_ has quit IRC02:59
*** bbowen_ has joined #openstack-nova02:59
openstackgerritMerged openstack/nova master: Use microversion in put allocations in test_report_client  https://review.opendev.org/67962203:01
*** slaweq has joined #openstack-nova03:11
*** slaweq has quit IRC03:15
*** tetsuro has quit IRC03:24
*** mdbooth has joined #openstack-nova03:25
openstackgerritBrin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API  https://review.opendev.org/67348503:30
*** markvoelker has joined #openstack-nova03:31
*** markvoelker has quit IRC03:41
*** tetsuro has joined #openstack-nova03:42
*** ricolin has joined #openstack-nova03:49
*** mvkr has joined #openstack-nova03:51
*** etp has joined #openstack-nova04:12
gmannmelwitt: johnthetubaguy alex_xu looking for review/feedback on this first set of policy-defaults-refresh changes.  This one and all its base patches  - https://review.opendev.org/#/c/648480/04:14
alex_xugmann: got it04:15
gmannalex_xu: thanks. and this nit followup change in spec - https://review.opendev.org/#/c/669196/04:16
gmannalex_xu: this is review guide i sent on ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.html04:17
alex_xugmann: got it, I will give it try, let see if i have enough bandwidth04:17
gmannalex_xu: thx again , kenichi has +2 on most of them i think04:18
*** markvoelker has joined #openstack-nova04:30
*** markvoelker has quit IRC04:35
*** larainema has joined #openstack-nova04:48
*** tetsuro has quit IRC04:50
*** tetsuro has joined #openstack-nova04:52
openstackgerritAkira KAMIO proposed openstack/nova master: VMware: disk_io_limits settings are not reflected when resize  https://review.opendev.org/68029604:53
*** Luzi has joined #openstack-nova04:55
*** hoonetorg has quit IRC04:56
*** udesale has joined #openstack-nova05:02
*** artom has quit IRC05:09
*** artom has joined #openstack-nova05:09
*** slaweq has joined #openstack-nova05:11
*** adriant has quit IRC05:11
*** adriant has joined #openstack-nova05:12
*** hoonetorg has joined #openstack-nova05:13
*** slaweq has quit IRC05:15
*** ratailor has joined #openstack-nova05:19
*** markvoelker has joined #openstack-nova05:30
*** ccamacho has quit IRC05:32
*** avolkov has joined #openstack-nova05:34
*** etp has quit IRC05:34
*** etp has joined #openstack-nova05:34
*** markvoelker has quit IRC05:35
*** psachin has joined #openstack-nova05:37
openstackgerritSundar Nadathur proposed openstack/nova master: ksa auth conf and client for Cyborg access  https://review.opendev.org/63124205:40
openstackgerritSundar Nadathur proposed openstack/nova master: Add Cyborg device profile groups to request spec.  https://review.opendev.org/63124305:41
openstackgerritSundar Nadathur proposed openstack/nova master: Create and bind Cyborg ARQs.  https://review.opendev.org/63124405:41
openstackgerritSundar Nadathur proposed openstack/nova master: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML.  https://review.opendev.org/63124505:41
openstackgerritSundar Nadathur proposed openstack/nova master: Delete ARQs for an instance when the instance is deleted.  https://review.opendev.org/67373505:41
*** mdbooth has quit IRC05:45
openstackgerritBrin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API  https://review.opendev.org/67348505:53
*** mdbooth has joined #openstack-nova05:54
*** mdbooth has quit IRC06:18
*** mdbooth has joined #openstack-nova06:20
*** tetsuro has quit IRC06:22
*** slaweq has joined #openstack-nova06:23
*** ccamacho has joined #openstack-nova06:27
*** slaweq has quit IRC06:28
*** psachin has quit IRC06:31
*** mmethot_ has joined #openstack-nova06:43
*** etp has quit IRC06:44
*** etp has joined #openstack-nova06:44
*** mmethot has quit IRC06:45
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces  https://review.opendev.org/67964006:46
openstackgerritLuyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory  https://review.opendev.org/67847006:46
openstackgerritLuyao Zhong proposed openstack/nova master: doc: attaching virtual persistent memory to guests  https://review.opendev.org/68030006:46
*** cfriesen has joined #openstack-nova06:50
*** openstackgerrit has quit IRC06:51
*** slaweq has joined #openstack-nova06:52
*** damien_r has joined #openstack-nova06:54
*** tetsuro has joined #openstack-nova06:55
*** luksky has joined #openstack-nova06:56
*** udesale has quit IRC06:56
*** janki has joined #openstack-nova06:58
*** tetsuro has quit IRC06:59
*** mkrai has quit IRC07:00
brinzhanggmann: takashin: https://review.opendev.org/#/c/673133/15/api-ref/source/os-volume-attachments.inc@46, replace the response of the `GET os-volume_attachments`` or ``SHOW os-volume_attachments`` response body by latest version.07:02
brinzhanggmann: takashin: I am not sure is it appropriate. If the microversion less than 2.78, the delete_on_termination field will not contained in the response.07:02
brinzhanggmann: takashin:In PS12 I also add the v2.78 response example to that palce, but mriedem let me removed it and just add the os-volume_attachments response to the POST API. https://review.opendev.org/#/c/673133/12/api-ref/source/os-volume-attachments.inc@5407:02
*** maciejjozefczyk has joined #openstack-nova07:02
*** mkrai has joined #openstack-nova07:06
*** markvoelker has joined #openstack-nova07:06
*** yan0s has joined #openstack-nova07:07
takashinbrinzhang: If the microversion less than 2.78, the delete_on_termination field will not contained in the response. But it is not problem because the parameter description says delete_on_termination has been added since microversion 2.78.07:09
*** markvoelker has quit IRC07:10
*** sapd1_x has quit IRC07:10
brinzhangtakashin: thanks, I will replace it by follow-up.07:14
*** tesseract has joined #openstack-nova07:15
*** trident has quit IRC07:21
*** cfriesen has quit IRC07:22
*** ivve has joined #openstack-nova07:27
*** trident has joined #openstack-nova07:29
*** threestrands has quit IRC07:32
*** rcernin has quit IRC07:33
*** trident has quit IRC07:34
*** takashin has left #openstack-nova07:34
*** takashin has joined #openstack-nova07:37
*** trident has joined #openstack-nova07:43
*** openstackgerrit has joined #openstack-nova07:47
openstackgerritBoxiang Zhu proposed openstack/nova master: Preserve UEFI NVRAM variable store  https://review.opendev.org/62164607:47
*** brault has joined #openstack-nova07:50
openstackgerritBoxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule  https://review.opendev.org/64996307:58
openstackgerritBoxiang Zhu proposed openstack/nova master: Fix live migration break group policy simultaneously  https://review.opendev.org/65196907:58
*** takashin has left #openstack-nova08:00
*** tkajinam has quit IRC08:05
*** etp has quit IRC08:07
*** etp has joined #openstack-nova08:07
openstackgerritBrin Zhang proposed openstack/python-novaclient master: Microversion 2.78: Add delete_on_termination to volume-attach API  https://review.opendev.org/67348508:07
*** brault has quit IRC08:13
*** ralonsoh has joined #openstack-nova08:20
*** cdent has joined #openstack-nova08:21
*** etp has quit IRC08:30
*** etp has joined #openstack-nova08:30
*** derekh has joined #openstack-nova08:31
*** cdent has quit IRC08:31
*** cdent has joined #openstack-nova08:32
openstackgerritYongli He proposed openstack/nova master: Clean up orphan instances virt driver  https://review.opendev.org/64891208:34
openstackgerritYongli He proposed openstack/nova master: clean up orphan instances  https://review.opendev.org/62776508:34
*** dtantsur|afk is now known as dtantsur08:38
kashyapaspiers: This is from OpenSUSE, see the maddenning number of OVMF binaries :-( -- http://paste.openstack.org/show/693648/08:41
kashyapaspiers: An impressive 3508:41
kashyapaspiers: Anyway, can you get the same output from SLES?  (`rpm -ql qemu-ovmf-x86_64`)08:42
kashyapaspiers: But my educated guess is that, these two are the recommended ones for Secure Boot:08:44
kashyap/usr/share/qemu/ovmf-x86_64-ms-4m-code.bin08:44
kashyap/usr/share/qemu/ovmf-x86_64-ms-4m-vars.bin08:44
kashyap(The above are from OpenSUSE.  Hopefully they're similarly named on SLES.)08:44
kashyapaspiers: In short, for SB, you want the 'ms'-variant '-code.bin' (and its corresponding '-vars.bin')08:45
*** markvoelker has joined #openstack-nova08:45
aspierskashyap: it's not 35, you're counting text files and directories in that08:46
aspierskashyap: but still agree that it's way too many08:46
kashyapaspiers: Yeah, sorry, exaggerated; do rake me on coals08:46
aspiersXD08:46
aspiersIt's the same on SLES08:47
*** markvoelker has quit IRC08:50
dr_gogeta86good morning08:52
dr_gogeta86any hitachi guys here ?08:52
kashyapaspiers: Okay, then.  Do you have the recorded notes from your previous successful Secure Boot?08:58
kashyapaspiers: If so, I'd bet they are the ms-variant binaries.08:58
aspierskashyap: No it was -suse-code08:58
kashyapaspiers: Ah, okay.  So they are the MS-enrolled ones for SLES08:59
aspierskashyap: But the problem is I'm trying to boot an unreleased test kernel09:00
aspiersso it doesn't have the official signature09:00
kashyapNod; for this unrelease kernel, either you just go into the Tianocore BIOS and disable SB09:01
*** trident has quit IRC09:01
aspierskashyap: https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel has been suggested09:01
kashyapYep, those are the steps the Secure Boot / BIOS dev I know recommended too09:01
kashyapYou have to do a lot of manual muckery, generate certs, run 'mokutil', etc09:02
aspierskashyap: do BIOS definitions get persisted to the VARS file? is that what https://review.opendev.org/#/c/621646/ is about?09:03
aspierskashyap: I'm confused by that commit, because even without it I *already* see the vars files persisting in /var/lib/libvirt/qemu/nvram09:04
kashyapaspiers: The VARS file contains anything a user configures.09:04
aspiersOh, that's the bug09:04
kashyapaspiers: The context is: just like traditional BIOS, UEFI has menus (just more of them), and needs to store them somewher09:04
aspiers"Anything" meaning what though? BIOS settings? anything else?09:04
kashyapSo, if a user customizes something, it goes into the "VARS" file09:05
kashyapaspiers: One of the things it stores is the UEFI keys09:06
kashyapaspiers: Yeah, the bug is reinitializing a VARS from the default template, which is is undesirable.09:07
aspiersright09:08
aspiersso e.g. SB would have to be disabled every boot09:09
aspiersthere should really also be some way to change the default template09:09
aspierseven per image09:09
*** trident has joined #openstack-nova09:09
kashyapaspiers: In what else way do you want to "change the default (VARS) template"?09:10
aspierse.g. disabling SB09:10
aspiersor any other BIOS tweak you can imagine09:10
kashyapYou don't want to mess with the default template itself, but rather do what libvirt does -- copy it per guest, in the "domain private path", and _then_ do what you want09:11
kashyapaspiers: If you _don't_ want SB, then simply use the un-enrolled VARS file.09:12
aspiersHow?09:12
aspiersI guess I didn't explain the use case clearly enough09:12
aspiersLet's say I want to boot 100 VMs with SB, and another 100 without SB09:12
aspiersHow do I do that?09:12
kashyapThis way:09:12
kashyap- For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is built with SB/SMM (i.e. suse-code.bin)09:13
kashyap- For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is *not* with SB/SMM (i.e. suse.bin -- or whatever it's called)09:14
aspiersBut as an unprivileged non-admin how do I choose which OVMF binary gets used?09:14
kashyap(Both the above is for UEFI boot, though.)09:15
kashyapaspiers: So for a non-admin uesr:09:15
kashyapYou simply _don't_ set the 'uefi' image property09:15
aspiersNo, because then SEV breaks09:15
*** swamireddy has quit IRC09:15
kashyapAh!  We're talking in SEV context09:16
aspiersOf course :)09:16
aspiersWell, just as an example09:16
kashyapForgot the world spins around SEV for a sec :D09:16
aspiersIt's one example of a more general issue09:16
aspiersWhat if I want to boot 100 VMs with some UEFI option tweaked and 100 with it not tweaked? It's not always going to be the case that there's a binary offering exactly what I want; there should be an option to create custom VARS templates, and to choose which VARS template to start from09:16
kashyapaspiers: Now the question is: why would you want SEV *without* SB?09:17
aspiersWell I already gave yesterday's example: testing new unsigned kernels09:17
aspiersbut please don't get hung up on the SEV part, that's just one example09:17
kashyapSure, sure.09:18
aspiersIt seems entirely reasonable to assume that at some point hardly anyone will want to boot non-UEFI09:18
kashyapaspiers: For enrolling your own VARS files, the process is not "simple" :-(09:18
aspiersand even though maybe most people will want SB and other default UEFI options most of the time, I'm sure they will want non-defaults at other times09:18
kashyapE.g. to enroll _default_ UEFI (MS) keys (which most distros ship now), we wrote this tool: https://github.com/puiterwijk/qemu-ovmf-secureboot09:19
aspiersand at those other times, it will *not* be acceptable to manually go into the console of every single VM at boot-time and press Escape and manually customise things09:19
aspiersThis is entirely analogous to the need for datacentre operators to tweak legacy BIOS settings over 1000s of machines09:19
aspiersAt some point around 2002, people got really tired and fed up of having to do that09:20
aspiersso the h/w vendors gradually introduced ways of programmatically tweaking the BIOS settings09:20
aspiersWhat we are talking about here is just the 2019 equivalent of that problem09:20
kashyapaspiers: Yeah, I completely agree that manually tweaking BIOS settings at boot-time is fugly09:20
kashyap(And undesirable)09:20
aspiersOK, so do you now see why customisable VARS templates are useful?09:20
aspiersor am I missing another way to achieve the same?09:21
kashyapaspiers: I see the rationale for customizable VARS templates --09:21
kashyapbut for most majority use cases won't need it09:22
kashyapaspiers: On any other way -- we can ask Laszlo (OVMF maint) on email09:22
aspiersWhy would most use cases need it any less than people needed to tweak BIOS settings in 2002?09:23
*** ociuhandu has joined #openstack-nova09:23
aspiersI would expect more need if anything, since surely UEFI is way more tweakable09:23
aspiersalthough granted I know very little about UEFI09:23
kashyapYeah, I don't claim to be an expert either.09:24
aspiersAnyway, that's thinking ahead. So for now it sounds like there is no way to cater for use case #1 - i.e. choosing per SEV image whether to use SB or not09:26
kashyapaspiers: Talking to a BIOS dev:09:26
aspiersso that makes my life a little harder09:26
kashyap11:24 <kashyap> Do you know of any other way to create customizable VARS files?09:26
kashyap11:24 <puiterwijk> There's no way, just boot and enter the tianocore bios setup09:26
aspierskashyap: Sure, *creation* is the easy part. It's the *reuse* which I'm talking about.09:27
aspiersCreation of a VARS template only has to be done once, so manual is fine09:27
aspiersReuse across 500 VMs is different, however09:27
aspiersEventually I could imagine uploading VARS template files to (say) glance, and choosing which to use at boot-time via the nova API09:28
aspiersMaybe my use case (testing SEV+SB with stable *and* bleeding edge kernels) is the only use case the world will ever encounter, but that seems unlikely to me.09:29
*** puiterwijk has joined #openstack-nova09:29
aspiersWell, the "SEV" component can be dropped from that immediately and the use case is still clearly relevant for kernel devs who care about UEFI and SB09:30
kashyapaspiers: 1 sec09:30
kashyapaspiers: I invited the expert to this channel, Patrick (puiterwijk) -- thanks for joining09:31
aspiersHi puiterwijk :)09:31
puiterwijkaspiers: hi09:31
puiterwijkthe problem is that the VARS file format is internal to TianoCore itself, and there's (to my knowledge) no API guarantee on it, nor an external library to manipulate them. That is also why the enroll script I hacked together just boots an EFI binary that enrolls the keys. And the other one I wrote literally just automates stepping through the BIOS menus09:32
aspierspuiterwijk: If you want you can quickly catch up via the bottom of http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-05.log.html09:32
* puiterwijk goes read that09:32
aspierspuiterwijk: Creation of template VARS files is not the hard part here, since that only needs to be done once per template, so doing it manually is fine.09:33
aspiersReuse across 500 VMs is different, however.09:33
puiterwijkAh, so what you want is a way to tell nova to use a different vars file template?09:33
aspiersYes09:33
aspiersMaybe I'm way off here (since I don't know much about UEFI in general) but I would expect that to be useful in the future as use of UEFI gets more sophisticated. What do you think?09:34
puiterwijkAhhh, I see. Okay, then I retract my comments on how that's hard to automate :). And I think that, based on the questions I got from kashyap, he might also have misunderstood that that was an option09:34
puiterwijkSo, the one question I'd have is which BIOS settings you want to tweak regularly?09:35
aspiersIn the legacy BIOS world, there are loads09:35
puiterwijkSince based on the settings available in tianocore, I don't think there's that many that are interesting that you can't tweak from external.09:35
kashyap(Hmm, in the scrollback I did mention that using different VARS files _should_ be possible...)09:35
puiterwijkkashyap: ah, okay, sorry. I did not read the full backlog yet.09:36
aspiersLet me look at tianocore settings quickly09:36
kashyapNo problem; don't expect you to read everything I ramble :D09:36
aspiersI've never looked at them before09:36
puiterwijkaspiers: so, the ones I'd think are most often changed would be the secureboot settings, and the boot order. And the latter you can tweak directly from qemu09:36
puiterwijk(but sure, there's a bunch of other settings, and there's probably ones I'm just not thinking of right now)09:37
kashyapaspiers: puiterwijk: Oh, something interesting here: https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json09:40
puiterwijkSo, I do wnat to make one clarification though that I do see from skimming the backlog: I think we'd always want to use the OVMF *binarY* that has secureboot capabilities compiled in, but that we'd want to change the OVMF *template* (i.e. settings)09:40
aspiersmakes sense09:40
kashyapaspiers: So in the firmware descriptor files, there's also an "amd-sev" feature represented:09:40
kashyap 112 # @amd-sev: The firmware supports running under AMD Secure Encrypted09:41
kashyap 113 #           Virtualization, as specified in the AMD64 Architecture09:41
kashyap 114 #           Programmer's Manual. QEMU command line options related to09:41
kashyap 115 #           this feature are documented in09:41
kashyap 116 #           "docs/amd-memory-encryption.txt".09:41
kashyap(And libvirt parses this, IIRC)09:41
* kashyap --> tea; bbiab09:42
*** etp has quit IRC09:45
puiterwijkSo, on the multiple vars files: yes, I agree that it would probably be useful to be able to ask nova for a specific vars file to be used. But maybe do require that vars file to be put in place and registered by an admin.09:45
*** etp has joined #openstack-nova09:45
aspiersright09:45
puiterwijkBecause even if you only have the secureboot settings, you might want a vars file that has your own custom keys enrolled09:45
aspiersexactly09:45
aspiersit could be an extra spec on the flavor09:45
aspiershw_uefi_vars or something09:46
puiterwijkYeah, agreed that that sounds decent09:46
aspierskashyap: is it worth adding this to http://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html ?09:47
puiterwijk(do note that I'm not too deeply integrated into how Openstack (Nova) do things, other than mostly operational and fixing my own bugs, so it might be that this is not in line iwth their design goals)09:47
aspierspuiterwijk: Yeah I'm not sure about this either but I think it's worth suggesting at least09:47
puiterwijkYep, agreed.09:47
aspiersOK I just managed to fix my broken devstack so maybe I can finally look inside tiano09:49
kashyappuiterwijk: aspiers: Hmm, 'hw_uefi_vars' idea does sound reasonable -- but would need to tackle that _after_ adding initial SB support in the spec09:49
aspierskashyap: sure09:49
puiterwijkSure, that sounds fine09:49
*** mdbooth has quit IRC09:49
kashyapaspiers: And yeah, it does belong to that spec.  Should we "extend" the spec later?  Or have an additional BP for this?09:50
*** mdbooth has joined #openstack-nova09:51
aspierskashyap: Very good questions...09:51
kashyapProbably something additional on top will be simpler process-wise.09:52
puiterwijkThe problem with adding it on top is: how do the two work together then?09:52
puiterwijki.e. if I request secureboot per the current blueprint, and then in the later one I ask for another firmware that doesn't have secureboot?09:52
kashyapHeh09:53
puiterwijk(My suggestion would be "if the requested vars isn't secureboot, and secureboot is asked, return error due to invalid config")09:53
puiterwijkor invalid request*09:53
kashyappuiterwijk: I mean, they're _related_ topics, and will be designed to work together09:53
aspierskashyap: I think it might work as a flavor extra spec09:54
aspiersso the admin controls exactly which templates are available09:54
puiterwijkkashyap: sure. I'm just thinking of what would need to be thought about if talking about a new BP :)09:54
kashyappuiterwijk: Ah, nod.09:54
aspiersHow do I get into the TianoCore settings? Escape doesn't work, goes straight to asking for the encrypted disk password09:54
puiterwijkaspiers: boot without working boot options09:55
puiterwijki.e. detach the disk09:55
aspiersErm, not sure I can do that in nova09:55
puiterwijkOh, inside nova...09:55
aspiersIt's not a volume09:55
puiterwijkYeah, I'm not sure either.09:55
aspiersI guess maybe boot from volume09:55
aspierskashyap: ideas?09:55
puiterwijkaspiers: so... I know that in the Fedora grub, we have an option to "go to system setup"09:56
puiterwijk(because "go to setup" is available as an UEFI call)09:56
aspiersI can get to the grub commandline09:56
aspiersand I can do chainloader (hd0,gpt2)/efi/...09:56
puiterwijkI don't know the grub cmdline for that option right now, let me see in my config09:56
aspiersI managed to get into mokmanager that way09:57
aspiersor whatever it's called09:57
puiterwijkOh09:57
puiterwijk"fwsetup"09:57
puiterwijkthat's the grub command09:57
puiterwijkmenuentry 'System setup' $menuentry_id_option 'uefi-firmware' {09:57
puiterwijk        fwsetup09:57
puiterwijk}09:57
stephenfinmelwitt: Heh, sorry. That auto-topic thing was killing me downstream and like mriedem I always do 'git checkout -b bug/NNN' (or 'bp/foo') manually first. Also, it was broken with storyboard09:57
aspiersIRC is awesome for apparent non-sequiturs09:58
stephenfinmelwitt: mordred reviewed it though so if you _really_ want to blame someone, I suggest blaming him. Everyone else does it :P09:58
aspiersmorning stephenfin09:58
aspiers;-p09:58
stephenfinyo09:58
aspierspuiterwijk: fwsetup is accepted but does nothing09:58
* stephenfin is in Dublin today, where the amount of cranes and general building sites has reached insane levels09:59
kashyapaspiers: So you got into Grub command-line...09:59
stephenfinI can see four new towers going up just from our window09:59
aspierskashyap: yes09:59
aspiersstephenfin: try London for a bit09:59
stephenfinonce that legislation is passed, sure :)10:00
aspiersI get "error: you need to load the kernel first."10:00
stephenfintil then, I'll stay where food supplies aren't a concern10:00
aspiers:'(10:00
aspiersentirely understandable10:01
* aspiers got his Irish passport recently just in case10:01
aspierswell, more on principle10:01
aspiersno a-hole is going to take away my EU membership10:01
*** tetsuro has joined #openstack-nova10:04
*** tetsuro has quit IRC10:08
*** luksky has quit IRC10:10
sean-k-mooneyi think its funny that they keep talking about people in northerin ireland losing ther eu citizenship give that almost everyone born there is entitled to irish citizen ship grantign them full eu citizenship too10:11
aspiersYeah they have other things to worry about but not that10:12
sean-k-mooneywell not funny in the convnetional sense more tragic that politions in london dont know thats a thing10:12
aspiershalf our politicians are totally clueless10:12
aspierslet's not drag this channel down that rathole though10:13
sean-k-mooneyquite so10:13
cdenthalf?10:13
sean-k-mooneyits stressful enough watching the news10:13
aspierscdent: probably more, I was being generous off the back of yesterday10:14
cdentsomebody else was trying to tell me that yesterday was a spark of hope, but I'm not sure. But I agree, turning an openstack channel into the brexit-therapy-network is probably a misuse10:15
aspiersit's definitely a spark of hope10:15
aspiersnot sure how big but we'll see10:15
openstackgerritsean mooney proposed openstack/nova master: multi numa nfv testing job  https://review.opendev.org/67965610:19
*** udesale has joined #openstack-nova10:20
aspierskashyap, sean-k-mooney: turns out that my new q35 patch introduced a circular import loop https://review.opendev.org/#/c/680065/10:24
aspiersso I'm trying to figure out the best way of moving code around10:24
kashyapaspiers: Did it?  Will look in a bit; buried in untangling something :-(10:24
*** tetsuro has joined #openstack-nova10:24
aspierssee discussion with efried last night http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-04.log.html#t2019-09-04T20:57:1410:25
sean-k-mooneyaspiers: between what10:25
aspiersbetween virt.hardware and libvirt.utils10:25
aspiersand also libvirt.driver in between which imports libvirt.utils10:25
sean-k-mooneyright virt.hardware cant call the libvirt code10:25
aspiersso there are some options for how to fix this10:26
aspiershmm, need a cloud-based sequence diagram editor now to help discuss this10:26
sean-k-mooneyi see what your importing10:27
aspierssean-k-mooney: it affects the next apply-config patch too10:27
aspiersone option is to move sev_enabled from utils to hardware10:27
sean-k-mooneyactully libvit.utils does not use teh hardware module10:28
sean-k-mooneyso you shoudl be able to import that form hardware.py10:28
*** udesale has quit IRC10:28
sean-k-mooneyaspiers: well they should be in hardware.py anyway10:28
aspierssean-k-mooney: https://review.opendev.org/#/c/644565/51/nova/virt/libvirt/utils.py@3810:28
*** udesale has joined #openstack-nova10:29
sean-k-mooney oh you adding it in another patch10:29
aspiersanother option is a new machine_types.py10:29
aspiersa third option efried suggested is a new virt.libvirt.hardware10:29
openstackgerritLuyao Zhong proposed openstack/nova master: object: Introduce Resource and ResourceList objs  https://review.opendev.org/67844810:30
openstackgerritLuyao Zhong proposed openstack/nova master: Add resources dict into _Provider  https://review.opendev.org/67844910:30
openstackgerritLuyao Zhong proposed openstack/nova master: Retrieve the allocations early  https://review.opendev.org/67845010:30
openstackgerritLuyao Zhong proposed openstack/nova master: Claim resources in resource tracker  https://review.opendev.org/67845210:30
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver discovering PMEM namespaces  https://review.opendev.org/67845310:30
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: report VPMEM resources by provider tree  https://review.opendev.org/67845410:30
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup  https://review.opendev.org/67845510:30
openstackgerritLuyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec  https://review.opendev.org/67845610:30
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces  https://review.opendev.org/67964010:30
openstackgerritLuyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory  https://review.opendev.org/67847010:30
openstackgerritLuyao Zhong proposed openstack/nova master: doc: attaching virtual persistent memory to guests  https://review.opendev.org/68030010:30
aspiersbut I was struggling to figure out whether SEV is libvirt specific. At least machine types are QEMU-specific10:30
sean-k-mooneysev is tecnically not10:30
sean-k-mooneybut the way you are checking for it is10:30
kashyapaspiers: SEV is hardware-specific; machine types indeed are not "libvirt10:30
kashyap... -specific"10:31
kashyapAs you discovered (read the chat).10:31
kashyapBut they're typically handled by libvirt for Nova.10:31
aspiersRight10:31
aspiersThe problem is that get_mem_encryption_constraint() and its helpers are tied to virt.hardware10:32
sean-k-mooneyaspiers: move sev_enabled out of utils into the driver10:33
aspiersbecause they rely on _get_flavor_image_meta() in that file, and so do other functions there10:33
aspierssean-k-mooney: originally sev_enabled had to be outside driver.py10:34
aspiersso it could be called from vif.py10:34
*** mdbooth has quit IRC10:34
aspiersbut now I moved the iommu stuff into designer.py10:34
aspiersso maybe I could move it back10:34
*** mdbooth has joined #openstack-nova10:34
sean-k-mooneyall calls from vif.py are form the driver10:34
sean-k-mooneyso you can pass it in a flag if its needed10:34
aspiersthat wasn't easily doable before10:34
sean-k-mooneybut we dont pas the libvirt host object to any other funciton in utils10:35
aspiersbut now it's not needed anyway10:35
sean-k-mooneythe utils dont actully talk to libvirt as far as i can see10:35
aspiersright10:35
sean-k-mooneyso the sev_enabled check does not fit with the rest of the module10:35
sean-k-mooneyso ya simple fix is just make it a member funciton of the driver then you can do self.host and just pass in the flavor and image10:36
aspiersI don't think this is sufficient10:37
aspiershow would https://review.opendev.org/#/c/644565/51/nova/virt/libvirt/utils.py@38 change?10:37
aspiersoh sorry10:37
sean-k-mooneyi will remove the only use of hardware.py form the utils10:37
aspierswrong link10:37
aspiershow would https://review.opendev.org/#/c/680065/4/nova/virt/hardware.py change?10:38
sean-k-mooneythat would not10:38
aspiersbut that already causes a cycle10:38
sean-k-mooneyyour only calling  libvirt_utils.get_machine_type(image_meta)10:38
*** mdbooth has quit IRC10:38
sean-k-mooneyhow10:38
aspierslook at the CI failures :)10:38
sean-k-mooneyhardware.py will import utils but utils wont import it10:39
sean-k-mooneyso if you remove the change in https://review.opendev.org/#/c/644565/51/nova/virt/libvirt/utils.py@3810:39
sean-k-mooneyits not an issue right10:39
aspiersohhh OK those CI failures on the first patch are something else10:40
*** mdbooth has joined #openstack-nova10:40
aspiersI thought I saw circular import errors in both patches but I was wrong10:40
aspierscool10:40
*** nicolasbock has joined #openstack-nova10:41
sean-k-mooneythere is another way to break circual dependcies in python but moveing htat function is the simplest10:42
aspierswhich one?10:42
aspierssev_enabled?10:42
sean-k-mooneyyes10:42
sean-k-mooneymoving it to the driver10:42
aspiersyou mentioned another function in utils you are gonna move?10:42
aspierswhich one?10:42
sean-k-mooneyno you dont need to move anything else10:42
aspiersoh that's the only one OK cool10:43
sean-k-mooneyjust the new funtion your intoducing10:43
aspiersso move that to libvirt/driver.py10:43
aspierswhere it was originally :)10:43
sean-k-mooneyya10:43
aspierscool10:43
aspiersusing designer.py made everything a lot cleaner10:43
aspiersthis is another example of that10:43
aspiersthanks a lot!10:43
sean-k-mooneywe want to kill desigenr.py10:43
yonglihesean-k-mooney, stephenfin: good morning, guys.10:43
aspiersmy brain was hurting from thinking about this10:43
sean-k-mooneyor at least we did10:43
aspierssean-k-mooney: there should be a list of tech debt goals somewhere public10:44
sean-k-mooneyyonglihe: hi10:44
aspierssean-k-mooney: e.g. storyboard10:44
aspiersmaybe it's on an etherpad somewhere10:44
sean-k-mooneyaspiers: i was going to say etherpad would be good.10:44
aspiersWFM too10:44
aspiersOK, gonna take a break10:44
sean-k-mooneyaspiers: the designer.py was intoduced by danpb to breakout some fo the code out of the driver but it was started and never finish and became techdebt10:45
sean-k-mooneyreally we shoudl merge it into the config.py10:45
aspiersI disagree10:45
*** bbowen_ has quit IRC10:45
sean-k-mooneyits basically doing the same thing10:45
aspiersI think the scoping text at the top of config.py is good10:46
*** sapd1_x has joined #openstack-nova10:46
sean-k-mooneywell i gues10:46
aspiersit's good to keep logic out of config,py10:46
sean-k-mooneyconfig.py is giving you the datamodels10:46
aspiersjust keep it parsing/generating XML only10:46
sean-k-mooneyand serialistaion code10:46
sean-k-mooneyand the designer is wiring up the elements10:46
*** markvoelker has joined #openstack-nova10:46
sean-k-mooneybut the problem is so is the driver.py10:46
sean-k-mooneyso without moveing more of the xml logic out of the dirver and into the desinger among other things its kind of messey to have it in two places10:47
sean-k-mooneyyonglihe:  o/10:47
*** tbachman has quit IRC10:49
sean-k-mooneyyonglihe: i see stephenfin has +2'd the toplogy api seires. it should merge soon10:50
sean-k-mooneyyonglihe: that just leaves your orpahn vm series right10:50
openstackgerritAdam Spiers proposed openstack/nova master: Ensure q35 machine type is used when booting with SEV  https://review.opendev.org/68006510:51
openstackgerritAdam Spiers proposed openstack/nova master: Ensure q35 machine type is used when booting with SEV  https://review.opendev.org/68006510:51
*** markvoelker has quit IRC10:52
yonglihesure, i notice that.  thank you guys.  That orphan is real orphan now. -:)10:52
sean-k-mooneyill try and check it out again this week.10:52
yongliheThat's great !10:53
yonglihePile of patches recently.10:53
sean-k-mooneywell code freeze is in a week so it always gets hechtic at this time10:54
yonglihedeja vu10:55
*** luksky has joined #openstack-nova10:58
*** sapd1_x has quit IRC11:07
*** tetsuro has quit IRC11:07
stephenfinyaawang, alex_xu: I'm going to address my nits in the docs for https://review.opendev.org/#/c/670298/ and then fast approve, if that's okay. I'd like to see a follow-up for the non-doc fixes though11:12
aspierssean-k-mooney: https://review.opendev.org/#/c/680065/6/nova/virt/hardware.py@30 still doesn't work because that imports libvirt.driver which imports virt.hardware11:15
aspierskashyap: ^^^11:15
kashyapHmm11:16
openstackgerritwangfengsheng proposed openstack/nova master: test  https://review.opendev.org/68037211:16
kashyapaspiers: Is it simpler if you just put it in utils?11:16
aspierskashyap: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-05.log.html#t2019-09-05T10:32:4111:20
*** Sundar has joined #openstack-nova11:20
kashyapAh, "The problem is that get_mem_encryption_constraint() and its helpers are tied to virt.hardware"11:21
aspiersyes, keep reading11:21
*** mdbooth has quit IRC11:21
*** mdbooth has joined #openstack-nova11:22
* kashyap does11:22
alex_xustephenfin: cool11:23
*** ociuhandu has quit IRC11:23
cdentaspiers, sean-k-mooney : https://twitter.com/richard_parris/status/116941419009362739211:24
aspierscdent: heh that's good11:25
* kashyap 's head is spinning with all these circular deps11:26
*** lpetrut has joined #openstack-nova11:27
aspiersmine too11:28
aspiersargh11:28
SundarHi gibi, I resubmitted the Cyborg interaction patch series [1] with the updated notification structure. Please review it when you can. [1] https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-cyborg-interaction11:28
* sean-k-mooney im glad i was not drinking coffee when i clicked that11:29
aspierssean-k-mooney: :)11:30
kashyapaspiers: Sorry for no bright ideas yet; I'm mired in mutliple tasks (multitasking--); now for lunch11:33
artomaspiers, so ideally you'd want to fail early at the compute API level, around the same place _validate_flavor_image_mem_encryption() is called11:33
artomThe problem is that we don't want to have driver-specific calls in there (libvirt_utils.get_machine_type)11:34
Sundarsean-k-mooney: How are you?11:34
aspiersartom: That's already happening; the challenge is getting import dependencies right11:34
aspiersartom: Yeah that's a good point, maybe the crux of the problem11:34
artomaspiers, right, sorry, you're calling your thing from get_mem_encryption_constraint11:34
aspiersWell you're right that we're calling driver-specific stuff from the API level11:35
artomBut if we move to fail within libvirt, which is where the machine type stuff belongs, it's super late (around https://review.opendev.org/#/c/644565/51/nova/virt/libvirt/driver.py@4931 presumably)11:35
sean-k-mooneySundar: hi. im ok i did not sleef last night but other then that im good11:35
sean-k-mooneySundar: how is the cyborg integration comming11:36
aspiersartom: exactly11:36
aspiersartom: so how to achieve https://review.opendev.org/#/c/680065/6//COMMIT_MSG ?11:36
artomaspiers, I don't want to over design, but maybe drivers need a validate_image_props() or something11:36
aspiersurgh11:36
artomI know :(11:37
aspiersa cloud suddenly passed over the chances of landing SEV before feature freeze :-(11:37
Sundarsean-k-mooney: The integ is progressing. When you tried to deploy Cyborg, perhaps you may have grappled with which patch series to deploy. Many of them have merged now. If you have the time, I can explain further.11:37
artomThat's what we get for exposing driver-specific stuff in what's essentially our API11:37
aspiersartom: you referring to stuff like hw_machine_type extra spec?11:38
aspiersI don't see how that could be avoided11:38
Sundarsean-k-mooney: Hope Cyborg is not what's keeping you up ;)11:38
sean-k-mooneySundar: i ended up spending the last few days teting artoms numa live migration patch.11:38
SundarAh, I see11:38
sean-k-mooneySundar: no i set up a clean vm to test cyborg in with centos 7 as you suggeted11:38
sean-k-mooneybut i did not get time to actully execute devstack and deploy it11:39
openstackgerritLuyao Zhong proposed openstack/nova master: object: Introduce Resource and ResourceList objs  https://review.opendev.org/67844811:39
openstackgerritLuyao Zhong proposed openstack/nova master: Add resources dict into _Provider  https://review.opendev.org/67844911:39
artomaspiers, yes to both points :P11:39
openstackgerritLuyao Zhong proposed openstack/nova master: Retrieve the allocations early  https://review.opendev.org/67845011:39
openstackgerritLuyao Zhong proposed openstack/nova master: Claim resources in resource tracker  https://review.opendev.org/67845211:39
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver discovering PMEM namespaces  https://review.opendev.org/67845311:39
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: report VPMEM resources by provider tree  https://review.opendev.org/67845411:39
*** ociuhandu has joined #openstack-nova11:39
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup  https://review.opendev.org/67845511:39
openstackgerritLuyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec  https://review.opendev.org/67845611:39
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces  https://review.opendev.org/67964011:39
openstackgerritLuyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory  https://review.opendev.org/67847011:39
openstackgerritLuyao Zhong proposed openstack/nova master: doc: attaching virtual persistent memory to guests  https://review.opendev.org/68030011:39
aspiersartom: well it wouldn't be too hard to add validate_flavor_image() or whatever to the driver interface I guess?11:40
Sundarsean-k-mooney: There was an issue that Cyborg's notificaiton event would come too soon before the n-cpu has begun to wait, so the event was getting dropped. I believe I have fixed it now. The crux of it is to do it in _build_resources, and to launch the wait before calling Cyborg for the bind, so that there is no window in between.11:40
aspiersartom: it could just be a nop in the base class11:40
*** ociuhandu has quit IRC11:40
aspiersartom: or even individual noops in each driver except libvirt11:40
Sundarsean-k-mooney: In the patch series https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-cyborg-interaction, the notification is in 'Create/bind ARQs' patch https://review.opendev.org/63124411:41
aspiersefried: seems there is a substantial flaw in our idea of checking for hw_machine_type=q35 at API-level, since it's driver-specific ...11:41
*** ociuhandu has joined #openstack-nova11:41
*** ociuhandu has quit IRC11:41
aspiersefried: see above discussion with artom ^^^11:41
SundarThe lvirt driver merely queries Cyborg to get the ARQs, relyung upon _build_resources to have done the wait.11:41
aspiersartom: can you think of any other way around this?11:42
stephenfinyaawang, alex_xu: Actually, there's an issue with the second patch in the series so I'll leave the release note rework to yaawang :)11:42
*** ociuhandu has joined #openstack-nova11:42
aspiersartom: the alternative would be to not check at API-level and then it would try and fail on every compute host, right?11:42
sean-k-mooneySundar: ok11:42
alex_xustephenfin: hah11:42
sean-k-mooneySundar: we treat missign the event as fatal uncondtionally correct11:43
artomaspiers, or just move get_machine_type out of libvirt utils11:43
artomWell11:43
*** ociuhandu has quit IRC11:43
artomNo, because it depends on the default machine type if nothing is set11:43
artomI'll drive my kids to school/daycare and think about it11:44
aspiersartom: previous version did not check for q35 when SEV is enabled but instead overrode the default to q3511:44
sean-k-mooneySundar: i dont see any depends on links in teh nova patches to point to cyborg11:44
aspiersartom: it also overrode machine type even if it was set on the image11:44
*** ociuhandu has joined #openstack-nova11:44
sean-k-mooneySundar: has all the cyborg code merged?11:44
sean-k-mooneySundar: if not we should add it to the first patch that calls cyborg directly11:45
sean-k-mooneySundar: which i think would be https://review.opendev.org/#/c/631244/3811:45
sean-k-mooneySundar: by the way can we abandon https://review.opendev.org/#/q/topic:bp/nova-cyborg-interaction+(status:open+OR+status:merged)+project:opendev/sandbox11:47
Sundarsean-k-mooney: Good point, I'll add the dependencies. Some Cyborg patches are close to merging, but the patches together are testable. The tempest scenarios are possible with one exception of device profile deletion in some circumstances. But that doesn't affect VM launch.11:48
artomaspiers, overriding isn't cool either11:48
sean-k-mooneySundar: ok it would be good to ad a testing patch that runs the tempst job on nova11:48
artomaspiers, validate_flavor_image() can't be in the driver itself because we don't want to call to the individual driver instance11:48
artomWhich is why get_machine_type is in libvirt_utils11:49
sean-k-mooneySundar: do you mind if i abandon the two patches against the sandbox repo to clean up the gerrit topic11:49
artomBecause it's libvirt'y, but doesn't depend on a specific host11:49
artomaspiers, if you can find a way to abstract that ^^ for all drivers, I think it'd be the best solution11:49
*** ociuhandu has quit IRC11:50
sean-k-mooneyartom: the validate flavor stuff belongs in hardware.py11:50
Sundarsean-k-mooney: I wasn;t even aware of these patches! They seem very preliminary. I don't know the author. But, IMHO, they can be abandoned.11:50
sean-k-mooneySundar: the sandbox repo is the one for teaching people how to use gerrit11:50
sean-k-mooneyso they are not but they have the topic which is confusing11:51
sean-k-mooneyill close them so11:51
Sundarsean-k-mooney: Re. "testing patch that runs the tempst job on nova", I believe that would be https://review.opendev.org/#/c/670999/11:51
sean-k-mooneygiven they are 6 mohts old11:51
artomsean-k-mooney, yeah but aspiers has a problem with circular dependencies11:51
sean-k-mooneyartom: not any more11:51
aspiersartom, sean-k-mooney: so the suggestion is a common validation interface across all drivers?11:51
aspierssean-k-mooney: no I do11:51
aspierssean-k-mooney: I was wrong (again)11:51
aspierssean-k-mooney: https://review.opendev.org/#/c/680065/ has circular dependencies even before sev_enabled is added11:52
sean-k-mooneyhardware specifc tratit valdiation lives in hardare.py11:52
luyaostephenfin: comments addressed , and thanks for your review.  https://review.opendev.org/#/q/topic:bp/virtual-persistent-memory+(status:open)11:52
aspierssean-k-mooney, artom: http://paste.openstack.org/show/771288/11:53
aspierssean-k-mooney: so unfortunately your suggestion wasn't enough to solve it11:53
sean-k-mooneys/triatis/flavor and image/ its where all the numa, pinning, hugepages and pci checks live11:53
aspierssean-k-mooney: right but until now it never cared about machine types11:54
aspiersmaybe moving get_machine_type to a separate class is the only way11:54
aspierss/class/file/11:54
sean-k-mooneyno that wont work11:55
aspiersright it won't11:55
aspierswell, not unless it is moved outside nova.virt.libvirt11:55
sean-k-mooneyit because importing nova/virt/libvirt/__init__.py has sideffects11:55
aspiersyes11:55
sean-k-mooneywe should remove this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/__init__.py#L1711:55
aspiersthat sounds good11:55
aspierswhy is it even there?11:56
sean-k-mooneywe proably moved things and that was a quick hack11:56
aspiersOK so first I have to get rid of that11:56
aspierssigh11:56
sean-k-mooneyremind me why you need to call the fucntion to get the machine type11:58
sean-k-mooneyi know its for suspend and live migate11:58
aspiersno11:58
aspiersit's to check for q3511:58
sean-k-mooneyyes11:58
aspiershttps://review.opendev.org/#/c/680065/6//COMMIT_MSG11:58
aspiersSEV doesn't work without q3511:59
sean-k-mooneyaspiers: where is that check going to be called form11:59
sean-k-mooneyit wont be used in the api11:59
aspiersyes in the API was the idea11:59
sean-k-mooneyand it can only be known on the compute node11:59
sean-k-mooneybut what api11:59
sean-k-mooneylive migrate and suspend?11:59
aspiersno, launch11:59
sean-k-mooneyit cant be known at lauch12:00
sean-k-mooneywe have not selected the host12:00
sean-k-mooneyand the machine type can be set in the hsot config12:00
aspiersright, this is the crux of the problem12:00
sean-k-mooneyright so you cant check for q35 in the api12:00
aspiersbut we can at least check the image12:00
sean-k-mooneyat lest not the create server api12:00
aspiersno we can check for hw_machine_type in the image12:01
aspierswe already require hw_firmware_type=uefi12:01
sean-k-mooneycheckign the image does not require calling get default machine tyhpe12:01
sean-k-mooneyor whathever12:01
sean-k-mooneyif we are jsut checking the image then just check the metadata directly12:01
aspiersthat's what I was originally doing https://review.opendev.org/#/c/644565/49/nova/virt/libvirt/utils.py@53812:02
*** HagunKim has quit IRC12:02
sean-k-mooneythat check should be in hardware.py direclty12:02
*** markvoelker has joined #openstack-nova12:02
aspiershttps://review.opendev.org/#/c/644565/49/nova/virt/libvirt/driver.py@509712:02
aspiersI was originally only checking the image12:02
sean-k-mooneyyou can have a second check for the machine type on the host12:02
sean-k-mooneyaspiers: for the fast fail on create server i think that is all you can do12:03
aspiershang on12:03
sean-k-mooneythen you can do the late check in the dirver12:03
aspierseither we *require* hw_machine_type=q35 image property or we make it optional12:03
aspierswhich are you suggesting?12:03
aspiersI mean in the SEV case12:03
sean-k-mooneywe will not require it12:04
sean-k-mooneyor should not12:04
aspiersOK so then what's the point of an API check?12:04
sean-k-mooneywe can check if hw_machine_type is set12:04
sean-k-mooneyand if its not q35 reject12:04
aspiersOK yeah12:04
aspiersthen if not set, it will fail later12:04
sean-k-mooneybut the api check was not for create it was for live migrate and suspend originaly12:04
aspiersperhaps horribly on multiple compute hosts12:04
sean-k-mooneyyep12:04
aspiersno live migrate/suspend is a different topic12:05
aspiersthat's not related to machine type12:05
aspiersthat relies on checking for hw_mem_encryption12:05
sean-k-mooneywe could maybe report machine types as traits in the future12:05
sean-k-mooneybut that is not ideal12:05
aspiersthat's this one https://review.opendev.org/#/c/680158/312:05
aspierskashyap: didn't we talk about that?12:05
*** tbachman has joined #openstack-nova12:05
aspierskashyap: about machine types as traits?12:05
aspiersthought I vaguely remembered some discussion on that12:06
aspiersmaybe not12:06
sean-k-mooneyi think that is leaking too much info personally12:06
*** brault has joined #openstack-nova12:06
aspiersI don't see a security risk but different rathole12:06
aspiersmaybe you're right but let's not go there now12:06
sean-k-mooneyno that is not what i ment12:06
sean-k-mooneywe could advertise that the host has q35 support12:07
aspiersOK so to summarise, the plan is this:12:07
aspiershw_machine_type=q35 image prop is optional for SEV12:07
aspierswe have an API check enforcing that if it's there, it has to be q35 family12:07
aspiersbut if it's not there then we just hope the scheduler picks a machine with nova.conf defaulting x86_64 to q3512:08
aspiersif it doesn't it will fail and try other compute hosts12:08
sean-k-mooneyand check it in the driver12:08
sean-k-mooneybut yes12:08
sean-k-mooneyit will fail and rescdule12:08
sean-k-mooneyand you can use host aggreates ectra if you want too to reduce the chance of that happening12:09
aspiersso the operator should configure CONF.libvirt.machine_type to x86_64=q35 on all SEV hosts12:09
sean-k-mooneyif you dont want to set q35 in the image or the config12:09
sean-k-mooneyyes i think that is what we shoudl recommend12:09
aspiersOK12:10
aspiersBUT12:10
aspiersdoes that fix the import cycle?12:10
aspiersit means there are two types of q35 check12:10
aspiersone image-only, and one including nova.conf12:10
sean-k-mooneyyes in hardware.py you dont need to import the utils funciton anymore12:10
sean-k-mooneyhardware.py just does the image check12:10
*** bbowen has joined #openstack-nova12:11
sean-k-mooneyand the driver just does the final machine type check using the image+config12:11
aspiersI don't follow12:11
sean-k-mooneyso no import of libvirt.utils is need in hardware.py12:11
sean-k-mooneyill comment on the patch12:11
aspierswait12:11
aspierswhich one of the two types of q35 check are you suggesting happens in hardware.py?12:12
aspiersthe API one or the driver one?12:12
aspiersthe driver one *does* need libvirt.utils12:12
aspiersto read the config12:12
aspierssean-k-mooney: ^^ (in case you are already commenting on the patch)12:12
sean-k-mooneythe api one should happen in hardware.py and it should only check the image12:13
aspiersOK so where does the driver one happen?12:13
aspiersin driver.py?12:13
sean-k-mooneyyes in driver.py12:13
aspiershmm12:13
sean-k-mooneyit can call the hardware.py if it wans ill type up som sudo code.12:14
*** bbowen_ has joined #openstack-nova12:14
aspiersyeah OK I think that might work12:14
aspiersartom: I think sean-k-mooney's proposal should work ^^^12:16
aspierskashyap too, in case you are interested12:16
aspiersefried: you might just want to wait for the new patch sets rather than wade through this conversation ...12:16
aspiersOK gotta go12:16
*** bbowen has quit IRC12:16
aspierslunch12:17
brinzhanggmann: Would you prefer https://review.opendev.org/#/c/673133/15/nova/tests/unit/api/openstack/compute/test_volumes.py@1036 ?12:18
Sundarsean-k-mooney: Re. "testing patch that runs the tempst job on nova", I believe that would be https://review.opendev.org/#/c/670999/12:18
brinzhanggmann: I think this test already test pre 2.78 microversion, and the 'delete_on_termination' field not in the response body.12:18
gmannbrinzhang: yeah that is good test and same we need for list and show API operation12:19
gmannbrinzhang: that is for POST and same we should test for other modified API also.12:19
brinzhanggmann: got it, I will update it, beacause it will be conflict, https://review.opendev.org/#/c/621476/ this patch will be merged first12:20
brinzhanggmann: no need a follow-up patch.12:20
gmannbrinzhang: ok but we cna check how matt prefer. it will be easy for him to re+2 if you only rebase on microverison and do other changes in followup.12:21
gmanni am ok either way12:22
brinzhanggmann: thanks.12:22
sean-k-mooneyaspiers: when you get back see if that makes sense. https://review.opendev.org/#/c/680065/6/nova/virt/hardware.py12:24
*** ociuhandu has joined #openstack-nova12:27
sean-k-mooneySundar: yes alther when i ran it 3 weeks ago it failed12:27
sean-k-mooneyill recheck it12:27
sean-k-mooneySundar: actully that patch does not pull in the nova integration code unless the cyborge cod is12:28
sean-k-mooneySundar: so no that is propsoed agains nova but it does not run any of the nova cyborge integration code12:29
Sundarsean-k-mooney: The dependencies need to be fixed there too. Will follow up. Thanks.12:29
sean-k-mooneythat should jsut be rebased on top of the final cyborg patch12:30
SundarOk, I will ask thr author or do it myself12:31
Sundar*the12:31
sean-k-mooneyi think we can do that in the gerrit ui12:32
sean-k-mooneywant me too try12:32
*** ociuhandu has quit IRC12:32
sean-k-mooneythis is the final patch in teh series right https://review.opendev.org/#/c/673735/12:32
openstackgerritsean mooney proposed openstack/nova master: [WIP] add cyborg tempest job  https://review.opendev.org/67099912:33
Sundarsean-k-mooney: Yes, 67373512:33
sean-k-mooneyok its rebased and i updated the topic12:33
SundarThank you12:34
sean-k-mooneyand i kicked off an experimental build so we should get results in an hour or so12:34
SundarIt will probably fail because the Cyborg code dependencies are not set yet?12:35
sean-k-mooneythey are12:35
sean-k-mooneywell they coudl be wrong12:35
sean-k-mooneyit has12:36
sean-k-mooney Depends-On: https://review.opendev.org/#/c/667231/ Depends-On: https://review.opendev.org/#/c/665318/12:36
sean-k-mooneyso that is the fake driver and the tempest plugin12:36
*** jmlowe has quit IRC12:36
SundarYea, those are offbase. Should be 670470 and 67452012:37
sean-k-mooneythe cyborg one might need to be updated if there is other stuff pending12:37
sean-k-mooneyah ok ill let it to them or you to update12:37
kashyapaspiers: Was AFK; reading now12:40
*** etp has quit IRC12:40
*** eharney has joined #openstack-nova12:41
kashyapaspiers: We might've discussed (on machine types as traits) ... although I'm fuzzy on what we talked, though12:41
*** ratailor has quit IRC12:42
*** nweinber has joined #openstack-nova12:43
openstackgerritBalazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate  https://review.opendev.org/65642212:44
openstackgerritBalazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth  https://review.opendev.org/65510912:44
openstackgerritBalazs Gibizer proposed openstack/nova master: Func test for migrate server with ports having resource request  https://review.opendev.org/65511312:44
openstackgerritBalazs Gibizer proposed openstack/nova master: Add min service level check for migrate with bandwidth  https://review.opendev.org/68039412:44
openstackgerritBalazs Gibizer proposed openstack/nova master: Add bandwidth min service level check of source compute  https://review.opendev.org/68039512:44
openstackgerritBalazs Gibizer proposed openstack/nova master: Add bandwidth min service level check of source compute  https://review.opendev.org/68039612:44
*** nweinber_ has joined #openstack-nova12:46
*** nweinber has quit IRC12:48
kashyapaspiers: Glad if you worked out a way to resolve the imports impasse.  /me back to duking around with SB code12:50
openstackgerritMerged openstack/nova master: Add server sub-resource topology API  https://review.opendev.org/62147612:51
sean-k-mooneykashyap: i think we have. and we discovered a 7 year old bit of tech debt to go clean up eventually.12:51
kashyapsean-k-mooney: :D  Which is?  Also I saw in passing, that you wanted to "kill off designer.py"12:52
kashyapIIRC, it was introduced with a purpose back in the day.12:52
sean-k-mooneyit was but we never finished it12:52
kashyap(For making "policy" decisions.)12:53
sean-k-mooneybut that is not what i was refering too12:53
openstackgerritBalazs Gibizer proposed openstack/nova master: Make _rever_allocation nested allocation aware  https://review.opendev.org/67613812:53
sean-k-mooneykashyap: i was refering to removing this12:54
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/__init__.py#L15-L1712:54
sean-k-mooneybecause of that when you import anythin in nova.virt.libvit.*12:54
sean-k-mooneyit pulls in the dirver which pulls in half of nova12:54
sean-k-mooneywell not really but importin nova.virt.libvirt.utils12:55
sean-k-mooneyshoudl not have that silent side effect12:55
kashyapsean-k-mooney: Ah, okay; I see what you mean12:55
kashyapThanks for the context12:55
sean-k-mooneyso we shoudl remove that at somepoint12:55
sean-k-mooneybut its been that way for 7 years+12:56
openstackgerritBalazs Gibizer proposed openstack/nova master: Support reverting migration / resize with bandwidth  https://review.opendev.org/67614012:56
openstackgerritBalazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth  https://review.opendev.org/67697212:56
artomaspiers, so the API-level check boils down to essentially "if 'q35' in machine_type"?12:56
artomAnd actually yeah, we can't do anything else12:57
artomIt just dawned on me that calling libvirt_utils on anything other than the compute host doesn't make sense12:57
artomSince it checks the CONF12:57
artomFor the machine type, which may not even be set on a controller12:58
openstackgerritBrin Zhang proposed openstack/nova master: Add delete_on_termination to volume-attach API  https://review.opendev.org/67313312:59
sean-k-mooneyartom: yep12:59
*** jmlowe has joined #openstack-nova12:59
sean-k-mooneyartom: even if it was set on the contoler i t would be wrong12:59
artomsean-k-mooney, yep13:00
sean-k-mooneythe main api check we care about is for live migrate and suspend13:01
sean-k-mooneythe create server one is fine too but its not the main one13:01
openstackgerritBalazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth  https://review.opendev.org/67698013:02
openstackgerritBalazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request  https://review.opendev.org/67149713:02
aspiersartom: exactly13:04
* sean-k-mooney goes for foods.13:05
*** jchhatbar has joined #openstack-nova13:05
* aspiers goes out for an hour or two13:06
*** takashin has joined #openstack-nova13:06
*** janki has quit IRC13:06
*** mriedem has joined #openstack-nova13:07
openstackgerritBalazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize  https://review.opendev.org/67882713:07
*** jchhatba_ has joined #openstack-nova13:08
brinzhangmriedem: Beacause of https://review.opendev.org/#/c/621476/ hit the microversion 2.78, I was rebased it. Can you review https://review.opendev.org/#/c/673133/16 again?13:09
mriedembrinzhang: yes13:09
mriedemyonglihe: will you be working on adding support for microversion 2.78 to openstackclient as well?13:10
brinzhangmriedem: About your comment in PS14, I update https://review.opendev.org/#/c/674243/20/nova/tests/functional/api_sample_tests/test_migrations.py@424, could you please review this again, and I will update it tomorrow.13:10
*** pcaruana has quit IRC13:10
*** jchhatbar has quit IRC13:11
brinzhangmriedem: Alex already leaving comments on https://review.opendev.org/#/c/67424313:12
gmannmriedem: i asked few more test to add in 673133 and in followup as it was +2 by you. as he need to rebase you want to fix those in followup or same commit? what ever is easy to get your +2 :)13:12
openstackgerritBalazs Gibizer proposed openstack/nova master: Allow resizing server with port resource request  https://review.opendev.org/67901913:13
*** mkrai has quit IRC13:14
*** tbachman has quit IRC13:14
mriedemgmann: you asked for a test that already exists13:15
mriedemtest_attach_volume_pre_v27813:15
gmannmriedem: that is for POST API only i asked to test the same for GET (list and show)13:15
mriedemok13:16
brinzhangmriedem: gmann: thanks13:16
luyaodansmith: Hi, Dan, comments addressed, https://review.opendev.org/#/c/678447/ and https://review.opendev.org/#/c/678448/. Could you help confirm if it is right?13:17
*** brault has quit IRC13:18
*** tbachman has joined #openstack-nova13:18
*** ociuhandu has joined #openstack-nova13:18
mriedembrinzhang: https://review.opendev.org/#/c/674243/20 is in merge conflict13:19
brinzhangmriedem: yeah, beacause of https://review.opendev.org/#/c/621476/ hit the microversion 2.7813:21
openstackgerritBalazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate  https://review.opendev.org/65642213:22
*** spatel has joined #openstack-nova13:22
brinzhangmriedem: I will update it by tomorrow, and need your suggestion in https://review.opendev.org/#/c/674243/20/nova/tests/functional/api_sample_tests/test_migrations.py13:23
*** mkrai has joined #openstack-nova13:23
yonglihemriedem: the client code is under reviewing now.13:24
openstackgerritBalazs Gibizer proposed openstack/nova master: Add min service level check for migrate with bandwidth  https://review.opendev.org/68039413:24
openstackgerritBalazs Gibizer proposed openstack/nova master: Add bandwidth min service level check of source compute  https://review.opendev.org/68039513:24
mriedembrinzhang: i'm likely not going to get to the migrations API change today13:26
mriedemlots of other stuff to review13:26
mriedemyonglihe: novaclient is, but what about openstackclient?13:26
mriedemyonglihe: see: https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc - we don't want to add more gaps to osc13:27
bauzasgibi: can I start looking at your updated change ? ^13:27
yongliheo, i like to do that also.13:27
gibibauzas: the first 3 patches are ready13:27
bauzasgibi: cool13:28
mriedemyonglihe: the osc change likely won't land until ussuri but you can start on it,13:28
mriedemmaybe after we get closer on the novaclient change13:28
brinzhangmriedem: Ok, tomorrow I will update it, and then wait for your time :)13:28
yonglihemriedem: Sure, i definitely need few days to do that.13:28
gibimriedem: I replied in https://review.opendev.org/#/c/656422/18/nova/compute/manager.py@2122 I diverged from your original suggestion a bit13:29
openstackgerritBalazs Gibizer proposed openstack/nova master: Add bandwidth min service level check of source compute  https://review.opendev.org/68039613:30
sean-k-mooneydonnyd: i seam to be getting node failures when i use multi-numa-ubuntu-bionic-expanded and multi-numa-ubuntu-bionic13:31
yonglihemriedem: I take it as my task,  for sure.  thanks your remind.13:31
sean-k-mooneydonnyd: based on https://github.com/openstack/project-config/blob/master/nodepool/nl02.openstack.org.yaml#L348-L357 they shoudl be the correct lables13:31
openstackgerritBalazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth  https://review.opendev.org/65510913:33
openstackgerritBalazs Gibizer proposed openstack/nova master: Func test for migrate server with ports having resource request  https://review.opendev.org/65511313:36
stephenfinmriedem: Mind taking a look at that patch to validate CPU config options again today? https://review.opendev.org/#/c/680107/13:37
*** tbachman has quit IRC13:37
openstackgerritBalazs Gibizer proposed openstack/nova master: Make _rever_allocation nested allocation aware  https://review.opendev.org/67613813:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Support reverting migration / resize with bandwidth  https://review.opendev.org/67614013:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth  https://review.opendev.org/67697213:39
*** pcaruana has joined #openstack-nova13:39
stephenfinbauzas: I split that "Differentiate between shared and dedicated CPUs" patch into two patches, btw :) https://review.opendev.org/#/c/680108/ and https://review.opendev.org/#/c/671800/13:40
* bauzas needs to sharpen his pen then13:41
*** spatel has quit IRC13:41
stephenfinwhat kind of monster sharpens a _pen_?13:41
* stephenfin notes bauzas has probably spent time in the slammer13:41
stephenfinmust be where you got the tattoos13:41
mriedemgibi: sure that works13:42
*** tbachman has joined #openstack-nova13:42
gibimriedem: phee, I was a it worried13:42
sean-k-mooneydonnyd: actully it seams to be running now13:42
gibibauzas, mriedem: I think comments are fixed up until the first functional test. I'm working on that now13:43
bauzasstephenfin: the OpenStack CLA doesn't require you to provide your filings13:43
bauzasso I let you imagine whatever you want13:43
efriedsean-k-mooney: Can I please ask you to vet the libvirt xml stuff for vpmem here? https://review.opendev.org/#/c/678455/13:43
bauzasgibi: cool, later today if time allows me13:43
gibibauzas: thanks13:44
*** jchhatba_ has quit IRC13:44
bauzasmriedem: gibi: just one thing, hardly working on the placement audit command, are we hit by feature freeze or not ?13:46
bauzasefried: ^13:46
*** Luzi has quit IRC13:46
gibibauzas: ff is next week13:46
bauzasI know13:46
bauzastalking of https://bugs.launchpad.net/nova/+bug/179356913:47
openstackLaunchpad bug 1793569 in OpenStack Compute (nova) "Add placement audit commands" [Wishlist,In progress] - Assigned to sean mooney (sean-k-mooney)13:47
bauzasit's wishlist13:47
mriedemgibi: a bit confusing that the commit message title is the same for these https://review.opendev.org/#/c/680395/2 https://review.opendev.org/#/c/680396/213:47
gibimriedem: noted, I will add some creativity to those13:48
openstackgerritChris Dent proposed openstack/nova master: single pass instance info fetch in host manager  https://review.opendev.org/62355813:48
*** bnemec has quit IRC13:48
openstackgerritBalazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth  https://review.opendev.org/67698013:48
*** bnemec has joined #openstack-nova13:48
gibibauzas: do you mean ff affects the work on that bug?13:48
efriedbauzas: If work isn't already well underway for that, it seems unlikely to make Train.13:48
donnydsean-k-mooney:  those labels got put in the pool with the rest of everything else.. so you will likely have to wait a little longer13:49
bauzasefried: I'm targeting to upload a last rev by tomorrow13:49
efriedbauzas: who's on the hook to review it?13:49
bauzasefried: good question13:49
efriedWhat do you consider the importance/priority versus other things we're behind on?13:49
bauzasefried: https://review.opendev.org/#/c/670112/13:49
bauzasefried: I don't disagree with your statement13:50
*** brault has joined #openstack-nova13:50
efriedI haven't made statements, just questions :)13:50
efriedoh, the "unlikely" one perhaps13:50
openstackgerritBalazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request  https://review.opendev.org/67149713:51
mriedembauzas: it's not going to make train13:51
bauzasefried: well, nevermind my question then, you know what, we'll see what's left13:51
cdentefried: i put some unit tests on that host manager change of jays, above. it was as painful as I feared it would be, but I think it got it. at least cover says so13:51
dansmithmriedem: so you think you can take a trip through the numa lm set this morning?13:51
mriedemdansmith: it's on the todo list13:52
dansmithmriedem: thanks13:52
efrieddansmith: can you run through the vpmem obj patches again please?13:52
mriedemso,13:53
mriedemefried: dansmith: besides numa lm,13:53
dansmithefried: I just dropped a -1.9 on one13:53
mriedemit seems the two other series that dansmith was reviewing was the forbidden aggregates stuff and sort of the vpmem stuff, right?13:53
mriedemwouldn't it be a better use of dan's time to focus on forbidden aggregates if he's going to review one of those?13:53
dansmithum..13:54
openstackgerritBalazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize  https://review.opendev.org/67882713:54
mriedemnot that i'm picking what dan should work on in the next week,13:54
dansmithapparently you are :)13:54
mriedembut forbidden aggregates isn't merged yet right?13:54
mriedemit was all +2ed at some point13:54
*** BjoernT has joined #openstack-nova13:54
dansmithI haven't looked at that set in a while, but I can circle back13:55
efriedugh, forbidden aggregates slid down my list and out of sight at some point.13:55
mriedemmy point is if you're going to ask dan to review something he's reviewed before, maybe make it the forbidden aggs one13:55
efriedyeah, same13:55
dansmithmriedem: well, I had gone back and forth on the vpmems bottom patches already recently13:56
mriedemthe vpmems series seeems way too risky to me at this point13:56
efriedmriedem: for me, vpmem is higher priority, and also more reliant on dansmith's expertise. If we needed to finish up forbidden aggs without him, it would be possible. vpmems (clearly) not so much.13:56
mriedemsure, but do we expect to land that whole series in the next week?13:56
mriedemw/o regression?13:56
dansmithefried: the vpmem series has a -1 on the fourth patch and is really large above that, is that really going to land?13:57
openstackgerritBalazs Gibizer proposed openstack/nova master: Allow resizing server with port resource request  https://review.opendev.org/67901913:57
dansmithefried: because if not, we shouldn't merge the db and object stuff, IMHO13:57
efrieddansmith: it has been pretty close for a while13:57
dansmithmriedem: yeah, I dunno about that, I was just looking to see what was above the two they were asking me to look at and ... it looks like a lot13:57
efriedmriedem: there should be no regression on that, it's code that isn't hit unless you activate it. I don't think it's risky from that perspective.13:57
mriedemif dan hasn't been in the 2nd half of the series i wouldn't call it close13:57
efriedmriedem: we don't need Dan for the second half. We have three cores on it already13:57
efriedspecialized review for ovo stuff13:58
efriedis where we need dan.13:58
*** brault has quit IRC13:58
dansmithjust skimming the top,13:58
dansmithit seems like there's plenty of room for regression in this stuff13:58
dansmithdespite being turned on only if you use it, it touches a lot of places13:58
efriedwell, it's not like this is brand new, it's been through many rounds of review13:59
dansmithlike, changes the order and timing of talking to placement from the compute manager13:59
dansmiththat's not gated on this feature, that's fun for everyone13:59
mriedemanything that deals with the RT flow is non-trivial14:01
mriedemand prone to regression14:01
mriedemi'm still fixing RT regressions since ocata14:01
efriedmeeting now14:01
*** Sundar has quit IRC14:02
efriedIf you like, we can discuss there why we're trying to freeze a feature a week before feature freeze14:02
dansmithnarrowing focus to get some things through the door instead of spreading focus among everything and getting nothing through the door?14:03
*** ociuhandu has quit IRC14:04
*** lpetrut has quit IRC14:05
*** takashin has quit IRC14:05
*** takashin has joined #openstack-nova14:06
mriedemgibi: comments in https://review.opendev.org/#/c/656422/2114:06
mriedemlet me know if we should just defer to a follow up14:06
*** brault has joined #openstack-nova14:08
*** BjoernT_ has joined #openstack-nova14:08
*** BjoernT has quit IRC14:09
gibimriedem: ack. I think I will defer to follow up there to ease the rebase pain14:09
mriedemgibi: ok +214:11
gibimriedem: thx14:11
*** pcaruana has quit IRC14:12
*** luksky has quit IRC14:19
*** ociuhandu has joined #openstack-nova14:20
openstackgerritBrin Zhang proposed openstack/nova master: Add user_id and project_id colume to Migration  https://review.opendev.org/67399014:22
openstackgerritBrin Zhang proposed openstack/nova master: Add operator user_id/project_id to the migrations  https://review.opendev.org/67941314:22
openstackgerritBrin Zhang proposed openstack/nova master: Filter migrations by user_id/project_id  https://review.opendev.org/67424314:22
*** ociuhandu has quit IRC14:25
brinzhangmriedem: https://review.opendev.org/#/c/674243/21 has bean resolved the merge conflict.14:28
*** lpetrut has joined #openstack-nova14:29
*** mlavalle has joined #openstack-nova14:38
*** udesale has quit IRC14:46
*** lpetrut has quit IRC14:47
*** udesale has joined #openstack-nova14:47
*** gyee has joined #openstack-nova14:50
sean-k-mooneydonnyd: it looks like its not completing and going to node_failure fairly consitently.14:51
donnydhrm14:52
donnydI will try to give that flavor a spin and make  sure it actually works14:52
*** cfriesen has joined #openstack-nova14:54
*** shilpasd has joined #openstack-nova14:55
donnydWell I didn't have any issues getting it to spin up, so I guess we dig a little deeper14:57
donnydsean-k-mooney: do you have a log file handy?14:57
sean-k-mooneydonnyd: node_failure means that nodepool was not able to provision a node for the zuul job14:58
sean-k-mooneyso it failed before starting the job14:59
sean-k-mooneythere would be a log entry in nodepool but not in what is uploaded14:59
donnydhttp://grafana.openstack.org/d/3Bwpi5SZk/nodepool-fortnebula?orgId=114:59
donnydI only see 3 failures from the last 6 hours14:59
sean-k-mooneyif you search for 679656 in https://zuul.opendev.org/t/openstack/status you wil see the latest one15:00
sean-k-mooneythis can happen if zuul is jsut at capastity for the provider15:01
sean-k-mooneyand it timed out waiting15:01
sean-k-mooneyi was seeing some node faiures before you update the lables too15:01
*** cdent has quit IRC15:01
sean-k-mooneyso maybe its just worse due to the shared pool15:02
*** takashin has left #openstack-nova15:02
sean-k-mooneyit was about 1 in 2 or 1 in 3 that failed previously15:02
donnydsean-k-mooney: I am not sure where I am supposed to be looking15:03
donnydthat is a pretty high failure rate no matter what15:03
donnydshouldn't be failing that often15:03
donnydmaybe someone in infra can give us some insights. I just provisioned 10 without a single failure15:04
sean-k-mooneywell as i said it was a node failutre meaning noodpool could not provide a node to zuul to run the job on. that can happen due to hitting quota15:04
efriedkashyap: can we talk about https://blueprints.launchpad.net/nova/+spec/allow-secure-boot-for-qemu-kvm-guests ?15:04
kashyapefried: Saddled with calls; but do ask away15:04
kashyapefried: Actively working on it...15:04
sean-k-mooneydonnyd: FN is proably fine this could be on infras side.15:04
donnydsean-k-mooney: let me up the quota and see if that is helpful15:04
efriedkashyap: do you hope to land it in the next week or should I defer to ussuri?15:04
sean-k-mooneyi need to jump on a call but for now ill wait and check the jobs later when the load drops a bit15:05
donnydok15:05
openstackgerritKobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found  https://review.opendev.org/67924715:05
sean-k-mooneywe intend to run this job nightly at 6am with ocational manual triggering so it should not generally be a proablem15:06
*** yan0s has quit IRC15:09
donnydsean-k-mooney: infra said they were hitting quota issues, so i just oversubscribed it for instances by 30% and pulled the rest of the quota entirely15:10
donnydopenstack.exceptions.HttpException: HttpException: 403: Client Error for url: https://openstack.fortnebula.com:13774/v2.1/e8fd161dc34c421a979a9e6421f823e9/servers, Quota exceeded for instances: Requested 1, but already used 70 of 70 instances15:10
donnydsean-k-mooney: that issue should be solved15:11
openstackgerritBalazs Gibizer proposed openstack/nova master: migrate: Add bw min service level check of source compute  https://review.opendev.org/68039515:11
openstackgerritBalazs Gibizer proposed openstack/nova master: resize: Add bw min service level check of source compute  https://review.opendev.org/68039615:11
openstackgerritStephen Finucane proposed openstack/nova master: Validate CPU config options against running instances  https://review.opendev.org/68010715:13
openstackgerritStephen Finucane proposed openstack/nova master: trivial: Use sane indent  https://review.opendev.org/68022915:13
openstackgerritStephen Finucane proposed openstack/nova master: objects: Add 'NUMACell.pcpuset' field  https://review.opendev.org/68010815:13
openstackgerritStephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs  https://review.opendev.org/67180015:13
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait  https://review.opendev.org/67557115:13
openstackgerritStephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta  https://review.opendev.org/67180115:13
openstackgerritStephen Finucane proposed openstack/nova master: Add reshaper for PCPU  https://review.opendev.org/67489515:13
openstackgerritBalazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth  https://review.opendev.org/65510915:14
artomdansmith, just want to make sure you saw my updates to the NUMA LM patch last night15:14
dansmithartom: I did, but Imma wait until mriedem has a go through it15:15
artomdansmith, ack15:15
efrieddustinc: I'd like to defer provider-config-file to ussuri given it has only had one reviewer (me) looking at it so far. Please let me know if you have reason to believe it can land in the next week.15:16
*** mkrai has quit IRC15:17
openstackgerritBalazs Gibizer proposed openstack/nova master: Func test for migrate server with ports having resource request  https://review.opendev.org/65511315:20
openstackgerritBalazs Gibizer proposed openstack/nova master: Make _rever_allocation nested allocation aware  https://review.opendev.org/67613815:20
kashyapefried: Don't defer it yet, please.  But I'll keep you posted.15:20
efriedkashyap: ack15:21
kashyapefried: I'll also be using that exception from Adam's InvalidMachineType patch; so there's a small dep there15:21
efriedkashyap: unclear whether SEV will make it too fyi15:21
kashyapefried: Hmm, understandable; review bandwidth, topic complexity, etc...15:22
kashyapBut to state the obvious, I don't want to rush anything, though.15:23
efriedstephenfin: how are you feeling about cpu-resources?15:23
stephenfinefried: I'm happy with it, but I need someone to take the hit on https://review.opendev.org/#/c/671800/ I've simplified it as much as I can at this point, I think15:24
stephenfinI've been bugging bauzas for that :)15:24
efriedstephenfin: what I mean is: do you reasonably expect it can land by next Thursday?15:25
stephenfinYeah, I think so15:25
efriedokay15:25
bauzasefried: I feel it's a reasonable target if someone else but me does reviews as well15:25
bauzashint : could be you15:25
efriedbauzas: I've been doing what I can, but much of it is beyond my ken.15:25
bauzascool15:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Support reverting migration / resize with bandwidth  https://review.opendev.org/67614015:26
*** ccamacho has quit IRC15:26
stephenfinefried: tbh, it's probably beyond most people that aren't called me and sean-k-mooney (and maybe cfriesen)15:27
stephenfinso I think we're going to have to rely on the fact that there are lot of functional tests there, and ask me all the questions if necessary15:27
stephenfin(and I mean, a _lot_ of functional tests)15:27
efriedOkay, sean-k-mooney if you've got room, it would be helpful if you could ack that stuff.15:28
efriedI think between bauzas, alex_xu, sean-k-mooney, and me, we should be able to scrape together the expertise. It's more a question of bandwidth.15:28
openstackgerritBalazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth  https://review.opendev.org/67697215:29
*** ociuhandu has joined #openstack-nova15:31
openstackgerritBalazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth  https://review.opendev.org/67698015:32
openstackgerritBalazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request  https://review.opendev.org/67149715:32
sean-k-mooneyefried: sorry was on a call15:35
sean-k-mooneywhat was the context15:35
efriedsean-k-mooney: The cpu-resources series15:35
bauzassean-k-mooney: the point was whether we have reasonable amount of eyes for cpu-resources15:36
efriedsean-k-mooney: it would increase confidence if it had your ack15:36
efrieddansmith: regarding isolated vs forbidden, this is a Nova UX vs Placement API thing.15:36
sean-k-mooneyi can dedicate the next few days to testing it like i was toing with artoms stuff15:36
dansmithefried: yeah I called that out15:36
*** ociuhandu has quit IRC15:36
efriedFrom the Nova perspective, we're isolating aggregates. Internally we're using placement's forbidden aggregates feature.15:36
sean-k-mooneyi think the numa migration is more or less in a good place so i can review the cpu serieis and start testing15:37
dansmithefried: did you see my comment on the later patch?15:37
sean-k-mooneyefried: while i hate to do this to my own seires we could punt https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/image-metadata-prefiltering if required to help to U. its ready to go but the sev and cpu series conflict with it15:38
sean-k-mooneyso untill they are landed its going to keep gong into merge conflict15:38
openstackgerritBalazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize  https://review.opendev.org/67882715:38
efriedsean-k-mooney: thanks, that's helpful15:39
sean-k-mooneyefried: stephen created https://etherpad.openstack.org/p/nova-cpu-resources as a set of test he wanted me to try.15:40
*** brault has quit IRC15:40
sean-k-mooneyi can start on them today/tomorrow but if anything else woudl help i could try that.15:40
sean-k-mooneyi can if need also try and create a temp ci job15:41
efrieddansmith: seeing it now. Sorry, I'm spread in a number of directions at the moment.15:41
openstackgerritBalazs Gibizer proposed openstack/nova master: Allow resizing server with port resource request  https://review.opendev.org/67901915:41
dansmithefried: let me circle back and explain more about why I think the seam needs to move up a step15:41
efrieddansmith: From my perspective, everything on the nova side should be called isolated, and we should only call placement-isms forbidden15:41
dansmithefried: cool, I shall tailor my response to indicate why that's a problem15:42
efrieddansmith: It's a little bit like where we (should) draw the line between 'member_of' and 'aggregate'.15:42
dansmithefried: yep15:43
efried'member_of' should really only start appearing in the thing we're using to construct the placement querystring.15:43
efriedRequestGroup, I think it's called.15:43
*** mdbooth_ has joined #openstack-nova15:45
dustincefried: I’d really like to get it landed in train and am working towards that. I hope to get it reviewable again by eod today.15:45
efrieddustinc: I would like that too, but unfortunately I don't feel like it's close enough given how much other stuff we're trying to cram in in the next week.15:46
*** jmlowe has quit IRC15:47
efrieddustinc: not because you did anything wrong, just because there has been more to review than reviewers have been able to keep up with, and this is one that slid off the bottom.15:48
*** mdbooth has quit IRC15:48
dansmithefried: https://review.opendev.org/#/c/671072/11/nova/scheduler/utils.py15:48
efrieddansmith: ack. You da boss. shilpasd ^15:49
dansmithefried: you just saw a wall of text and gave in without reading didn't you?15:49
efriedno, I read it. I don't agree, but it's more important to you than to me and I want to see it move forward. So let's do that.15:50
dansmithwell, that's constructive15:50
efrieddansmith: tbc, what you want to see is the field in Destination named forbidden_aggregates rather than isolated_aggregates. Everything else is okay?15:50
dustincefried: I understand. I will keep working on it anyway but if the review bandwidth isn’t there then go ahead and punt it to U. Thanks for your time spent reviewing it so far.15:52
dansmithefried: I think the set is kinda upside down, which I assume you also saw from the later ones, but what I'm gathering is that by asking me to review, you wanted me to either just approve or only look shallow for things that physically won't work instead of things that might bite us in the future15:52
dansmithefried: so maybe I should just drop my -1 and you find someone looking to do _that_ kind of review?15:53
efrieddansmith: Again, multitasking heavily right now, so I haven't read all of whatever reviews have been done today. I don't want you to rage quit. If there are other nontrivial issues you've called out, then those should be addressed.15:55
*** jmlowe has joined #openstack-nova16:00
*** altlogbot_1 has quit IRC16:01
*** altlogbot_3 has joined #openstack-nova16:02
*** irclogbot_3 has quit IRC16:03
*** irclogbot_2 has joined #openstack-nova16:05
*** artom has quit IRC16:06
*** damien_r has quit IRC16:06
*** irclogbot_2 has quit IRC16:07
*** irclogbot_2 has joined #openstack-nova16:08
*** artom has joined #openstack-nova16:14
*** cdent has joined #openstack-nova16:15
*** ivve has quit IRC16:19
mriedemgibi: so close https://review.opendev.org/#/c/680394/2 but there are missing tests for the new _reschedule condition16:24
*** tbachman has quit IRC16:28
*** sapd1_x has joined #openstack-nova16:34
*** maciejjozefczyk has quit IRC16:38
*** zigo has quit IRC16:43
*** spsurya has quit IRC16:48
*** sapd1_x has quit IRC16:48
*** igordc has joined #openstack-nova16:49
*** jaosorior has quit IRC16:51
mriedemgibi: a few easy things to address on the 2 after that as well16:52
*** ganso has left #openstack-nova16:53
openstackgerritraphael.glon proposed openstack/nova master: Ironic driver: fix when entering rebuild while already in error  https://review.opendev.org/68046816:56
*** ociuhandu has joined #openstack-nova17:01
*** tbachman has joined #openstack-nova17:03
*** markvoelker has quit IRC17:04
*** igordc has quit IRC17:04
openstackgerritDustin Cowles proposed openstack/nova-specs master: Spec: Provider config YAML file  https://review.opendev.org/68047117:04
*** tesseract has quit IRC17:06
mriedemIronic driver: fix when entering rebuild while already in error  https://review.opendev.org/680468 is another duplicate of https://review.opendev.org/#/c/523559/ which is pretty old so maybe we should get that in?17:06
mriedemmelwitt: ^?17:07
melwittmriedem: thanks for the reminder, I was thinking about that the other day. I do want to review that. been dreading re-loading of context on that one17:08
mriedemi think given the amount of time, the review it's had, the duplicates, and the fact it was proposed by an operator of an ironic deployment and this fixes their issue, and it's so narrow in focus, it's pretty low risk to just pull the trigger17:10
mriedemlike a mfing renegad17:10
mriedem*renegade17:10
*** zigo has joined #openstack-nova17:11
mriedemartom: dansmith: just got done going through that bw provider migration series again, now lunch and then i swear on my sweet lucy cat's whiskers that i'll review that numa live migration series17:11
artommriedem, appreciated :)17:12
*** markvoelker has joined #openstack-nova17:13
*** igordc has joined #openstack-nova17:15
efriedI think I've deferred all the obvious deferrals at this point. https://blueprints.launchpad.net/nova/train17:16
efriedA couple on there still that don't seem likely, but aren't obvious so I'm letting them slide off and will punt them next week.17:16
*** udesale has quit IRC17:18
*** maciejjozefczyk has joined #openstack-nova17:19
dansmithmriedem: thanks17:21
*** jaosorior has joined #openstack-nova17:22
dansmithmriedem: I'm sure you'll find some stuff, so just want to make sure there's time to address it17:22
*** larainema has quit IRC17:22
*** maciejjozefczyk has quit IRC17:24
*** igordc has quit IRC17:26
*** shilpasd has quit IRC17:27
*** ociuhandu_ has joined #openstack-nova17:32
donnydmelwitt: dansmith for the record today I have only thrown 4 errors from image related tasks... usually it is about 5x that17:33
donnydthanks for sticking with me on it17:33
melwittmriedem: noted17:33
dansmithdonnyd: cool17:34
melwittdonnyd: \o/17:34
*** ricolin has quit IRC17:35
*** ociuhandu has quit IRC17:36
*** ociuhandu_ has quit IRC17:36
melwittmriedem: +217:41
*** gbarros has quit IRC17:48
*** cdent has quit IRC17:50
mriedemartom: you could have probably asked in irc or commented without a vote on https://review.opendev.org/#/c/656594/17:51
mriedembut i've replied17:51
mriedemi see you've gone hunting for my changes...17:51
dansmithah yes, "I plan to backport this" is always a good reason :D17:57
mriedemdon't get me wrong, i appreciate the reviews17:57
mriedemand lord knows artom is heavily in debt in this regard :P17:57
dansmithartom: protip: tell him you'll +1 if he queues up a patch behind to do the right thing that needn't be backported :P17:58
mriedemi still won't do what he's suggesting, but he can do that17:58
dansmithhaha17:58
dansmithwell, probably still a good thought anyway.. at least he's thinking of front-loading api-related stuff in the api, so I'll give him credit17:59
mriedemnot to incur debt myself, but if there are any dan's around looking for reviews that is the bug fix for the multi-cell floating IP disassociate issue i found in denver...17:59
mriedemi agree it's not crazy17:59
dansmithassuming you're moving onto the numa lm patches I could probably look for a reason to -1 your fix18:00
mriedemwhen i don't see lee around much i need to move onto someone else to jab18:00
mriedemyeah yeah i'm on it18:00
mriedembtw, assuming anyone else is watching zuul, looks like it's taking around at least 5 hours to get a node18:01
*** gbarros has joined #openstack-nova18:01
mriedem(679473,1) Handle VirtDriverNotReady in _cleanup_running_deleted_instances (17h46m/18:02
*** luksky has joined #openstack-nova18:02
mriedemthat seems...less than good18:02
*** brault has joined #openstack-nova18:05
*** brault has quit IRC18:09
dansmithcrikey, yeah it's backed wayy up18:21
openstackgerritAdam Spiers proposed openstack/nova master: Ensure non-q35 machine type is not used when booting with SEV  https://review.opendev.org/68006518:22
aspierssean-k-mooney, kashyap, efried: I think this one should be good now ^^^ Reworking the other few on top now ...18:23
efrieddansmith: Can you help me understand under what circumstances a Destination gets persisted and then also reused later to influence a scheduling decision?18:23
dansmithefried: it's serialized inside the reqspec yeah?18:24
efrieddansmith: because if we're not reinvoking the scheduler with filters to recalculate isolated aggregates on a move operation, then I agree that's a problem.18:24
efriedso we calculate a reqspec once for an instance and then reuse it for move operations from that point on without reworking the stuff inside it??18:25
efriedSurely that's only the case for a non-resize-y move18:25
dansmithwe recalculate some of it, and what we recalculate has drifted a LOT over time18:25
dansmithwhich is my point,18:25
efriedmm, "some of it".18:26
dansmitheven if we blow it away currently,18:26
dansmithwe're storing the values as "isolated aggregates" and not "isolated (at the time of boot which was six months ago) aggregates"18:26
*** mvkr has quit IRC18:26
dansmith"forbidden" doesn't imply a reason18:26
dansmiththey were forbidden, they may no longer be forbidden for reasons related to this request or config, etc18:26
efriedI understand the issue now, thanks. Though I still fail to see how the word choice 'forbidden' vs 'isolated' has any power to clarify. Seems like a distinction without a difference, certainly not one that gives any hint about this persistence-vs-not issue.18:27
efriednot recalculating aggregate isolation would be a bug for sure, regardless of what we called it.18:28
dansmithforbidden implies what we're going to do with it... exclude those aggregates18:28
efriedI would possibly even go so far as to say that not recalculating *any* request filter would be a bug.18:28
dansmithisolated implies *why they are forbidden, which is based on a point-in-time configuration18:28
*** gbarros has quit IRC18:29
efriedI'm normally the pedantic, specific-word-choice guy, but I don't see it, sorry. So I'm sticking with my earlier story: if it makes the difference to you, it's fine with me.18:29
dansmithin other news, while looking for a reference for you, I realize that we now exclude destination from the reqspec when serializing, so it won't get persisted18:30
dansmithgood thing we had a discussion instead of you just pushing until I agree to something eh?18:30
efriedoh, that's nice :)18:30
efrieddude, that was never happening, you're making that part up.18:30
dansmithshall I quote you?18:30
efriedplease do18:30
dansmithI mean seriously18:30
efriedI am serious18:30
dansmith*eyeroll*18:31
efriedI at no time asked or even implied that you should roll over and approve something you disagreed with.18:31
dansmithno, that's not what I said18:31
*** mriedem has quit IRC18:31
dansmithI said *you* were just going to ask for the change so I'd agree to it without discussion18:31
dansmithwhich you said a few minutes ago, and earlier this morning18:31
efriedoh, yeah, true story, I was avoiding what I saw as a bikeshed over a name choice18:32
dansmithwhich is not the point of review and of course not the reason I'd ask for a change, just to be appeased18:32
dansmithso, here's my other reason for still thinking this is the wrong name for it18:33
efriedbecause I didn't (and still don't) see how 'isolated' and 'forbidden' mean different things in this context *other* than nova ux vs placement api terminology.18:33
*** mriedem has joined #openstack-nova18:33
dansmithpresumably we're going to need to forbid aggregates for other reasons in the future, for other nova features unrelated to aggregate isolation right?18:33
mriedemefried: dansmith: i dropped and maybe you already talked about this, or maybe it doesn't matter, but request spec's requested_destination isn't persisted18:33
dansmithheh18:34
dansmithyes, we've covered that already :)18:34
mriedemit used to be in the long ago and caused all sorts of problems18:34
dansmithyup18:34
* mriedem slinks back to hole18:34
dansmiththe destination object is all about what requests we're making to the scheduler and placement downstream of it, and since it's rpc, putting something in there means that's the interface and changing it later requires a version bump18:35
efrieddansmith: that's an interesting point, yes. I'm not fully swapped in on the code still, but I would think that would be a good reason to have the Destination field have 'isolated_aggregates', so that we can add 'frobnicated_aggregates' later and merge all of those into 'forbidden_aggregates' for the placement call.18:35
dansmithso if we ever think conductor may ask to forbid an aggregate for any other reason, we'd have to shove it into "isolated_aggregates" to make that happen, or add another field with the same purpose18:35
efriedthe latter, yes, IMO18:36
efriedno?18:36
dansmithefried: why? the scheduler doesn't need to know why to exclude aggregates, it just needs to know that it should18:36
*** dtantsur is now known as dtantsur|afk18:36
efriedwell18:36
*** igordc has joined #openstack-nova18:36
dansmithAZs are aggregates, what if I were to ask next cycle for a "disabled" flag on AZs? all we would need to do is tell scheduler (and thus placement) that AZ aggregate $uuid should be forbidden18:37
efriedgimme a sec to make sure I'm thinking of the right object hierarchy here...18:37
dansmithit's not isolated in the notion that nova's new isolated aggregate feature means, it's something else18:37
efried...so IMO what we want to be working toward is to have the placement-isms represented all and only in the RequestSpec.requested_resources field.18:38
efriedand in that case, since those are RequestGroup, absolutely we would have already funneled everything forbidden_aggregates into forbidden_aggregates.18:39
artommriedem, yep, shamelessly reviewing your bugfixes to quary favour18:39
dansmithyup, agree there18:39
efriedThe fact that anything that still needs to be translated to placement-ese lives in Destination (or elsewhere) is, to my way of thinking, tech debt.18:39
mriedemfavoUr?!18:39
artommriedem, *shrug* I changed it to a +1, didn't I? Given what dansmith said afterwards, looks like my concern was valid18:39
artommriedem, yes, the Queen's spelling18:40
dansmithefried: because the words "forbidden" and "aggregates" in that order are forever trademarked by placement?18:40
dansmithefried: call them excluded_aggregates in the Destination object and that'd also be fine18:40
dansmithartom: here and I was all ready to defend you, but I can't get behind the queen and her broke-ass spelling18:41
artomdansmith, thank you, you know you're my favourite18:44
dansmithgrr.18:45
efrieddansmith: but for the sake of shilpasd taking action, which will happen while we sleep, Destination.forbidden_aggregates will work for you, yes?18:45
dansmithefried: I think I've already said it would18:46
efriedIt's worth clarifying18:46
efriedmeasure twice, cut once18:46
dansmithif this wasn't codified in our object schema until version 2.0, you could totally claim that arguing over naming is not worth the trouble18:47
dansmithbut this stuff will stick with us for a long time18:47
dansmithso while you try to make it sound like I'm being unreasonably pedantic about the naming, I think I have a lot of version bumping battle scars (which nobody else has, btw) to back up my reasoning18:47
dansmith(*object version bumping scars.)18:48
efrieddooood18:48
efriedI'm not trying to make it sound like you're being unreasonable18:48
efriedall I've said is I don't see the difference18:49
efriedand I'm happy to defer to your judgment.18:49
efriedwhich is why I ask you for reviews on object/RPC/etc stuff18:49
aspiersefried: quick question, I want to reuse most of the fixture in test_config_kvm() https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/test_config.py#L2511 in new test I'm adding to test_designer.py - should I move it to fake_libvirt_data.py in a separate commit before reusing it, or move it as part of the commit adding the new test?18:50
aspiersartom: BTW this is how our discussion with sean-k-mooney turned out if you're curious https://review.opendev.org/#/c/680065/18:51
efriedaspiers: is the patch you're adding just a test?18:51
aspiersefried: no, it's the whole "apply SEV config" patch18:51
efriedyar. Then do it separately.18:52
aspiersOK thanks!18:52
* efried ==> next chauffeur errand18:52
*** efried is now known as efried_afk18:52
artomaspiers, yep, logic looks good18:53
aspiersartom: cool, thanks18:53
aspiersartom: fairly close to having the follow-on commit ready which adds the machine type check to the driver18:53
aspiersI'm using sean-k-mooney's nice idea of having the machine_type parameter in hardware.py optional, so the checking code can be reusedin both scenarios18:54
aspierstook several redesigns but I think we're finally there18:54
*** bbowen_ has quit IRC18:56
*** gbarros has joined #openstack-nova19:00
*** trident has quit IRC19:09
*** efried_afk is now known as efried19:13
efrieddansmith: moving up, the current ordering is my fault: I thought it was worse to first expose a conf opt that doesn't do anything, followed by the code that does the thing; than to introduce and unit test all the code, followed by a "master switch" that exposes it to the user in one go.19:15
efriedand thus the latter is the approach I've been advocating to *all* the series I've been reviewing this cycle.19:15
dansmithefried: it is, I'm not suggesting to put the conf toggle first, of course19:16
dansmithI'm suggesting you get all the plumbing that is in the last patch in front, and then land the filter and its knob together last19:16
* efried looks...19:16
efrieddansmith: that would effectively be combining the last two patches afaict. Which last-patch plumbing do you mean? Add the filter to the list but put an `if True: return` at the top of the filter method, and then s/True/CONF..../ in the last patch?19:18
dansmithefried: nova-status, scheduler/report.py, utils.py and associated tests can all be done ahead of time19:19
dansmithfrom the last patch19:19
dansmiththen you can add the filter and the knob,19:19
dansmithand docs could be in there or in a following patch19:19
dansmiththe last patch is a jumble of things19:19
dansmithsome of which are like rebase noise or something19:19
efriedYes, actually, utils.py looks like it should have been earlier regardless. client/report could just be flattened. I think the only reason these are split is to make the review smaller.19:20
efriedreviews19:20
dansmithit's likyes19:20
*** trident has joined #openstack-nova19:20
efriedwhich is probably also my fault.19:20
dansmithit's like the "uh, add the conf knob and all the other shit I forgot about" patch19:21
efriedif it was just the former, it would be okay IMO19:21
dansmiththere's no reason to land the filter and the knob separately19:22
dansmiththere is reason to land the plumbing separate from the filter/knob19:22
dansmithand it's fine to add the docs in a separate patch, which could slip past FF even19:22
efriedyeah, I just don't actually see any "plumbing" to speak of in that last patch19:22
dansmithwell, like you said, it's stuff that should have been earlier19:22
dansmiththe utils change, the placement version requirement bump, etc19:23
*** ralonsoh has quit IRC19:23
efriedokay, so again for the sake of being able to give shilpa a clear message, would it be acceptable to move the .py bits (including conf knob) of the last patch into the second-last patch, and leave the last patch for docs/reno?19:23
efriedbecause rn I don't think she understands that there's an action to be taken, based on her response.19:24
dansmithI think that the sorted change in utils is probably its own patch, with tests so that it's easy to validate which test is confirming that, then yes the filter, knob,19:25
dansmithisn't the report client bit actually already late?19:26
dansmithmeaning we already have code landed to put the not-member-of stuff in the qparams, we just won't ever run that code nor ask for the right version?19:26
efrieddansmith: it's not necessary until there's code that can hit the placement request with forbidden agg syntax19:26
dansmithif so, that would also be a "whoopsie" pre-patch, IMHO19:26
dansmithefried: mixing that up is not great to me.. if there's code that, if called, could generate a query that needs a newer version but it won't be provided,19:27
dansmiththat was a mistake19:27
dansmithbut whatever19:27
efriedyeah, could be perceived as "we can't hit this code so it doesn't matter" regardless of the reason we can't hit it, but I see your point.19:27
dansmithanyone else could land a patch right now that calls that code in such a way that it won't generate a sensible placement request19:28
dansmithand since it's kinda library/client code, it should be landed in a way that makes it work if called, IMHO19:28
efriedack19:28
dansmithso, to summarize,19:28
dansmithif it were me, I would ask for:19:28
dansmith1. A patch to fix up all the "oops I forgot" stuff in the placement client section, which is a chunk of the last patch currently19:29
dansmith2. A patch to add the filter and its knob19:29
*** gbarros has quit IRC19:29
dansmith3. Docs (and reno) at the end, which is the remaining bit of the last patchI think (if you subtract some of the random changes that are in there like renaming a test)19:29
*** gbarros has joined #openstack-nova19:30
mriedemartom: some comments/questions on patches 2 and 3, onto the big one https://review.opendev.org/#/c/634606/19:30
artommriedem, cheers! I have to pick up kids from school in 15, so my responses will have to wait later tonight, and probably into tomorrow morning19:31
*** jmlowe has quit IRC19:32
efrieddansmith: okay. I think I could probably do that shuffle and still +2 without losing sleep.19:32
dansmithefried: agree19:32
mriedemartom: yeah nothing major so far, just +1 with "i'm still going, but answer before i +2"19:35
dansmithmriedem: presume you've seen the CI job logs that shows this working too.. it's handy to trawl that looking for things to line up19:37
dansmithand also, sean-k-mooney did some manual testing yesterday that was meaningful to me, with edge cases and such19:37
artom"+1 I'm still going" is all we can hope from life19:38
mriedemdansmith: yes i was https://zuul.opendev.org/t/openstack/build/d51f91efa937411a9179b930eff3ab08/log/controller/logs/screen-n-cpu.txt.gz#219919:43
* dansmith nods19:44
efriedrebase only...19:44
openstackgerritEric Fried proposed openstack/nova master: Nova object changes for forbidden aggregates request filter  https://review.opendev.org/67107219:44
openstackgerritEric Fried proposed openstack/nova master: DB API changes to get non-matching aggregates from metadata  https://review.opendev.org/67107419:44
openstackgerritEric Fried proposed openstack/nova master: Add a new request filter to isolate aggregates  https://review.opendev.org/67107519:44
openstackgerritEric Fried proposed openstack/nova master: Enable request filter isolate_aggregates  https://review.opendev.org/66795219:44
* artom -> away19:45
mriedemdansmith: there is no up-call in this https://review.opendev.org/#/c/656594/19:47
mriedemthat code is only ever called from the api19:47
dansmithmriedem: is it?19:47
dansmithI thought we called down to the compute which did this19:48
mriedemno19:48
mriedemmaybe nova-net, idk about that, nor really care about nova-net19:48
mriedemthis is just a proxy call from nova-api to neutron19:49
dansmithsure, I just thought we still had to do FIP associate on the compute, like for LB or something19:49
mriedemhttp://codesearch.openstack.org/?q=network_api%5C.associate_floating_ip&i=nope&files=&repos=19:49
mriedemi guess mogan cares19:49
dansmithokay, well, I did say I hadn't chased all the plumbing19:50
*** jmlowe has joined #openstack-nova19:50
dansmithI think the thing that led me there, aside from artom's comment,19:51
dansmithwas that you're saying "if we don't have access to the API DB" which can't happen without nothing else working, if it's just in the api19:51
dansmithand the log message to that effect19:52
dansmiththe other change you reference was to handle calling code that could be either api-level or inside the cell19:52
dansmithbut if this is only ever at the API, then I don't think there's any need to catch that situation19:52
dansmithand if you do,19:53
dansmithit's not info-level, it's error-level,19:53
dansmithalong with all the other tracebacks the api would be throwing if you even got that far :)19:53
*** nweinber_ has quit IRC19:54
mriedemok, like i said, the CantStartEngineError thing came up in denver i think, but it's not written down so i can't remember the details for sure - i don't need it, and agree it shouldn't happen - and if it does, we're more f'ed than just this, so i'm happy to remove that in a follow up when i fix that comment in the test19:56
mriedemor, if i'm backporting, just nack it and i can remove that now19:57
dansmithack, commenting19:57
dansmithmriedem: done. left my +2, you can decide to fix or fup19:58
dansmithfor backport, I'd think it's worth fixing before it lands, since it's like 24 hours away :)19:59
*** eharney has quit IRC20:01
mriedemto be clear,20:04
mriedem"So, if you're going to catch it and log, I'd say do so at error and then  re-raise the exception like all the other API code would."20:04
mriedemyou're OK with just removing that catch right?20:04
dansmithyes, better to just remove it, imho20:05
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Find instance in another cell during floating IP re-association  https://review.opendev.org/65659420:05
dansmithmriedem: you doing it now? I'll stand by to fast approve if so20:06
mriedemno, still going through this big numa lm patch20:07
mriedemjust got through the commit message...20:07
openstackgerritEric Fried proposed openstack/nova master: Nova object changes for forbidden aggregates request filter  https://review.opendev.org/67107220:08
openstackgerritEric Fried proposed openstack/nova master: DB API changes to get non-matching aggregates from metadata  https://review.opendev.org/67107420:08
openstackgerritEric Fried proposed openstack/nova master: Add a new request filter to isolate aggregates  https://review.opendev.org/67107520:08
openstackgerritEric Fried proposed openstack/nova master: Docs for isolated aggregates request filter  https://review.opendev.org/66795220:08
efrieddansmith: gotta go on next chauffeur run, but I think that's what we were shooting for ^20:09
efriedbasically half of the .py changes needed to be in the first patch, the other half in the third.20:10
efriedguess I should have done that field rename while I was in there, sec...20:11
openstackgerritEric Fried proposed openstack/nova master: Nova object changes for forbidden aggregates request filter  https://review.opendev.org/67107220:15
openstackgerritEric Fried proposed openstack/nova master: DB API changes to get non-matching aggregates from metadata  https://review.opendev.org/67107420:15
openstackgerritEric Fried proposed openstack/nova master: Add a new request filter to isolate aggregates  https://review.opendev.org/67107520:15
openstackgerritEric Fried proposed openstack/nova master: Docs for isolated aggregates request filter  https://review.opendev.org/66795220:15
mriedemtotally unrelated to the numa live migration stuff, but can this fail the 'claim' for sriov pci devices on the dest host? https://github.com/openstack/nova/blob/f7f5e1846c7b19aa05817df7f3c4345819db413f/nova/compute/manager.py#L649120:16
mriedemand if so, how does it fail?20:16
*** efried is now known as efried_afk20:16
mriedembecause there is a very specific set of exceptions that will trigger a reschedule to an alternate host https://github.com/openstack/nova/blob/f7f5e1846c7b19aa05817df7f3c4345819db413f/nova/conductor/tasks/live_migrate.py#L48220:17
mriedemso if that stuff doesn't result in MigrationPreCheckError we'll fail the live migratoin b/c the first host claim failed20:17
mriedemsean-k-mooney: ^20:17
openstackgerritDan Smith proposed openstack/nova master: Find instance in another cell during floating IP re-association  https://review.opendev.org/65659420:18
mriedemtrying to follow that pci claim code is going down a rabbit hole20:18
dansmithmriedem: ^20:18
mriedemwant to hit that test comment while you're updating?20:20
*** bbowen_ has joined #openstack-nova20:21
*** lpetrut has joined #openstack-nova20:34
*** lpetrut has quit IRC20:38
*** ociuhandu has joined #openstack-nova20:39
openstackgerritMerged openstack/nova master: neutron: refactor nw info cache refresh out of associate_floating_ip  https://review.opendev.org/67830020:43
*** ociuhandu has quit IRC20:45
*** ociuhandu has joined #openstack-nova20:46
*** gbarros has quit IRC20:50
*** ociuhandu has quit IRC20:50
mriedemoooo https://github.com/openstack/nova/blob/f7f5e1846c7b19aa05817df7f3c4345819db413f/nova/scheduler/filter_scheduler.py#L173-L187 - if it weren't for USES_ALLOCATION_CANDIDATES we could burn all of that queens compat code out of the filter scheduler20:56
mriedemartom: dansmith: ok comments in the big one https://review.opendev.org/#/c/634606/7520:57
*** gbarros has joined #openstack-nova21:00
*** markvoelker has quit IRC21:05
openstackgerritMatt Riedemann proposed openstack/nova master: Find instance in another cell during floating IP re-association  https://review.opendev.org/65659421:05
dansmithmriedem:  cool thanks21:05
mriedemok i think that multi-cell floating ip thing is ready21:05
artommriedem, thanks! It's supper time now, will work a bit after, then gym, so tomorrow morning21:06
artomHaven't been to gym in, like, a week, not cool21:06
openstackgerritMerged openstack/nova master: Trap and log errors from _update_inst_info_cache_for_disassociated_fip  https://review.opendev.org/67830121:08
*** markvoelker has joined #openstack-nova21:11
mriedemgerrit is down anyway21:13
-openstackstatus- NOTICE: Gerrit is being restarted to pick up configuration changes. Should be quick. Sorry for the interruption.21:14
*** markvoelker has quit IRC21:15
*** gbarros has quit IRC21:18
openstackgerritMatt Riedemann proposed openstack/nova master: Remove old comments about caching scheduler compat  https://review.opendev.org/68052121:21
openstackgerritEric Fried proposed openstack/nova master: Add a new request filter to isolate aggregates  https://review.opendev.org/67107521:36
openstackgerritEric Fried proposed openstack/nova master: Docs for isolated aggregates request filter  https://review.opendev.org/66795221:36
mriedemalex_xu: can you take a look at the api change to attach a volume (and list/show vol attachments) with delete_on_termination? https://review.opendev.org/#/c/673133/ - it's probably going to be 2.79; i'm +2 on it21:37
*** mdbooth_ has quit IRC21:41
openstackgerritAdam Spiers proposed openstack/nova master: Ensure non-q35 machine type is not used when booting with SEV  https://review.opendev.org/68006521:42
openstackgerritAdam Spiers proposed openstack/nova master: Extract fake KVM guest fixture for reuse  https://review.opendev.org/68052621:43
openstackgerritAdam Spiers proposed openstack/nova master: Move get_machine_type() test to test_utils.py  https://review.opendev.org/68052721:44
efried_afkdansmith: vpmem json blob => hyp-specific ovo (https://review.opendev.org/#/c/678448/), you said to follow the example of LiveMigrateData.21:57
efried_afkSo I think that means they should make a base class (e.g. ResourceMetadata) and make LibvirtPMEMDevice (https://review.opendev.org/#/c/678453/19/nova/objects/resource.py) a subclass thereof.21:57
efried_afkI can't see where LiveMigrateData is a field in another ovo, though; is it kosher to make Resource.metadata of type ResourceMetadata even though IRL it will always be a *subclass*?21:57
openstackgerritMatt Riedemann proposed openstack/nova master: Rename Claims resources to compute_node  https://review.opendev.org/67947021:57
dansmithyeah, although you might have to register the base to make that work, which I don't think was required for the MD case because we always sent the child and not the parent, IIRC, but it's been a whiel21:58
efried_afkwhat does "register the base" mean?21:58
*** efried_afk is now known as efried21:58
mriedem@obj_base.NovaObjectRegistry.register21:59
mriedemnote that the base LiveMigrateData is not registered22:00
mriedemhttps://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L11222:00
mriedemb/c everything uses the subclasses22:00
dansmithright that ^22:00
dansmithefried: ovo requires a shared registry of the schemas on either side to ensure proper versioning22:00
efriedeverything will use the subclass in this case too... unless you mean that the Resource object will "use" the base class?22:00
mriedemso i can't do something like this in my driver: migrate_data = objects.LiveMigrateData(all_my_cool_shenanigans={...})22:00
dansmithefried: the difference is the inclusion in a field, which has to specify an object in the registry, IIRC22:01
dansmithwhich is why it's by name and not by reference22:01
efriedokay, cool.22:01
*** slaweq has quit IRC22:03
efrieddansmith, mriedem: Did I say it right? https://review.opendev.org/#/c/678448/15/nova/objects/resource.py@3622:03
mriedemi don't know that the chinese are going to understand the south park underpants gnomes reference22:05
efriedI've never actually even seen that thing22:05
efriedindirect meme reference culture22:05
* mriedem resists the urge to youtube22:05
dansmithefried: commented22:05
efriedI could find it if I wanted22:05
*** luksky has quit IRC22:06
efrieddansmith: thanks. I think nullable because not all ResourceZ are going to have metadata.22:06
mriedemthen don't set the field22:06
dansmithefried: yeah, that's the wrong answer22:06
efriedah22:06
efriedunset vs value of None vs object with no fields initialized vs object with fields set to None vs .....22:07
dansmithI thought I already commented about this in this patch, but maybe I was overwhelmed by the larger sin of using a string here and it didn't come through22:07
mriedemi need to make dan a shirt that has nullable=True on some object field with the circle bar banned icon on it22:07
dansmithI'd wear it22:07
*** claudiub has joined #openstack-nova22:08
dansmithefried: I suspect the right thing there is to always have a metadata object in that field (hence never None), with either fields set appropriately empty or whatever else,22:08
dansmithbut it's hard to tell what the right thing is because it's not defined there22:08
dansmiththat's probably why I didn't comment, because I don't know WHAT that is, other than a dumping ground for blobs22:08
mriedemit's this thing i think https://review.opendev.org/#/c/678453/19/nova/objects/resource.py22:10
efriedit's for hypervisor-specific, resource-specific metadata for a Resource. And not all ResourceZ are going to have any. It would seem like a lot of work to a) make sure to set the value b) to an empty object, meaning c) you have to make sure the object type can be "empty", whatever that means, etc.22:10
mriedemused here https://review.opendev.org/#/c/678454/19/nova/virt/libvirt/driver.py@693422:10
mriedemefried: not empty, just don't set the field22:10
efriedso does "nullable=False" just mean you're not allowed to set it to None?22:10
mriedemcorrect22:10
efriedand that's the default behavior.22:10
mriedemyeah22:11
dansmithcorrect22:11
efriedand you check with22:11
efriedif 'metadata' in res_obj:22:11
efried?22:11
*** slaweq has joined #openstack-nova22:11
dansmithif there's really a reason to have it =None then it _should_ be nullable,22:11
dansmithbut for something like this, the presence of the metadata object isn't the thing you want, it's what is inside22:11
mriedemefried: yup22:11
dansmithso if you always make these things nullable=True, then you always have to check first22:12
dansmithlike, if that was what it was intended to be in the first place, you'd have to do:22:12
dansmithif foo.metadata: if parse(foo.metadata): do_something(foo.metadata)22:12
dansmithwhen really you want to just be able to do something like22:12
dansmithif foo in resources.metadata22:13
dansmithor something like that22:13
dansmithtake a degree of freedom out of the thing by always making it present22:13
mriedemif you like mega conditionals https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L76022:13
efriedegads22:13
mriedemRequestSpec is i think the king of "if a and b and c and not d"22:13
dansmithbecause later when you have two versions out there, ambiguity is the enemy22:13
efriedcool, thanks for the primer. This was easier than having 12h between each call & response.22:15
dansmithnot for me22:15
mriedemtime to start a versioned objects FAQs doc22:15
dansmitheasier to ignore with 12h latency22:16
dansmithon my blog, which is apparently the canonical source for nova RPC information22:16
openstackgerritAdam Spiers proposed openstack/nova master: Apply SEV-specific guest config when SEV is required  https://review.opendev.org/64456522:16
mriedemheh, you know it22:16
mriedempulling stuff from slides 5-8 here (which is a lot based on the blog) into nova docs might be good to start https://docs.google.com/presentation/d/1YeXlL1EPaZTRkbJDywJKBrugXz-Amri3fIQk2ctOugs/edit?usp=sharing22:17
efrieddustinc: you around?22:18
mriedemnote slide 11 :)22:18
dustincefried: yeah what’s up?22:18
efrieddustinc: I think node.list patch has a regression -- did you see https://review.opendev.org/#/c/656027/29/nova/virt/ironic/driver.py@69022:18
dansmithmriedem: lol22:19
openstackgerritAdam Spiers proposed openstack/nova master: Reject live migration and suspend on SEV guests  https://review.opendev.org/68015822:19
efrieddustinc: if that's the case, it means we're missing test coverage in the CI job and we should add it.22:19
dustincefried: haven’t really been paying attention to those last two with the providers.yaml work. I will check it out.22:20
efrieddustinc: this is one already merged, so it takes priority over feature work.22:20
efrieddustinc: on inspection, it makes sense I think, because we're asking the API for the instance_id field instead of the instance_uuid field.22:21
*** slaweq has quit IRC22:21
efriedthis is a pain point with the sdk translation of uuid->id everywhere.22:21
efriedmordred: fyi22:21
dustincefried oh I see, on it now22:22
efriedso basically, queries *into* the API need to say uuid, but processing the results on the way out need to say id.22:22
efriedI think.22:22
efrieddustinc: You may want to ask for help in -ironic to add coverage to that CI job. Unless you already have it wired. I wouldn't know where to begin.22:22
openstackgerritAdam Spiers proposed openstack/nova master: Enable booting of libvirt guests with AMD SEV memory encryption  https://review.opendev.org/66661622:22
aspiersefried: OK, I'm done for the last time ... until next time ^^^22:23
aspierscouple of very simple new patches in there22:23
aspiersand more thorough tests than ever22:24
efrieddustinc: looks like it may be just tempest with configs to set up the ironic driver; which would mean that tempest in general doesn't exercise list_instances...22:27
*** bbowen_ has quit IRC22:33
*** BjoernT_ has quit IRC22:35
*** kaisers has quit IRC22:37
*** kaisers has joined #openstack-nova22:38
openstackgerritMatt Riedemann proposed openstack/nova master: doc: cleanup references to conductor doc  https://review.opendev.org/68053522:39
*** igordc has quit IRC22:48
*** mriedem has quit IRC22:50
*** tkajinam has joined #openstack-nova23:02
*** slaweq has joined #openstack-nova23:11
*** slaweq has quit IRC23:16
openstackgerritEric Fried proposed openstack/nova master: Bump min for oslo.service & .privsep to fix SIGHUP  https://review.opendev.org/67997423:17
*** rcernin has joined #openstack-nova23:23
*** macz has joined #openstack-nova23:24
*** macz has quit IRC23:26
*** macz has joined #openstack-nova23:27
aspiersIs it possible to configure zuul to fail early if certain jobs fail?23:28
aspiersFor example 680296,1 has already failed openstack-tox-pep8 but all the other jobs are still running, taking up valuable CI resources23:28
*** macz has quit IRC23:29
aspiersIn fact there's a large CI backlog which would probably vanish quickly if this were possible23:29
*** threestrands has joined #openstack-nova23:30
aspiersHmm, seems to be possible via pipeline.failure23:31
openstackgerritNathan Kinder proposed openstack/nova master: Allow TLS ciphers/protocols to be configurable for console proxies  https://review.opendev.org/67950223:36
dustincefried: You still online?23:45
openstackgerritDustin Cowles proposed openstack/nova master: Use fields="instance_uuid" when calling Ironic API  https://review.opendev.org/68054223:51
openstackgerritDustin Cowles proposed openstack/nova master: Use fields="instance_uuid" when calling Ironic API  https://review.opendev.org/68054223:52
*** rcernin is now known as rcernin|brb23:52
*** bbowen has joined #openstack-nova23:58

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