Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-19
14:18:50 jaypipes gotcha
14:19:27 sean-k-mooney he is full time on yardstick in opnfv now so im pickup all his patches at least to the end of Q1 /early Q2
14:21:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Provide a hint when performing a server action can't find the method https://review.openstack.org/545382
14:23:04 mriedem the bug fix series starting here needs review https://review.openstack.org/#/c/539758/ - +2 on all changes; fixes a problem going back to at least newton, if not since bfv was added forever ago
14:28:54 mriedem jaypipes: i'll go through that spec later this morning if someone else hasn't gotten to it first
14:29:02 mriedem i know dan has been through it before
14:29:06 jaypipes mriedem: I'll go through that patch series for the bug.
14:30:02 efried kumbaya
14:30:10 sean-k-mooney jaypipes: mriedem by the way the intel nfv ci should be operational again. can ye see any logs here http://http//52.27.155.124//portland/2018-02-19/540073/4/check/tempest-dsvm-intel-nfv-xenial/b045a8e
14:31:05 sean-k-mooney oh i see whats wrong they are not generating the url correctly.. ill let them know
14:50:41 Placeed Hi all, I have a problem with ressource_tracker.py on my compute instance. This script return a disk usage of 90% to nova so I can't run new instances. The problem is on the calculation ... Actually I use Cinder with NFS backend on /var/lib/nova/mnt with few tera avaiable. I don't run ephemeral vm's. It sounds like the script sum all disk usage of vm running and check only the local disk space of the compute server.
14:50:49 Placeed Someone can help me ?
14:53:40 Placeed As you can see there : https://paste.ofcode.org/SGqTUpeuWMErjfUwmHwQN2 The node think he have only 270Go available but in reality he have few tera through NFS
14:55:20 efried Placeed: Is this a boot-from-volume setup?
14:56:49 Placeed efried : Yes, In user point of view, I create a new instance based on image and it will create a cinder volume for the root disk of the instance
14:57:14 Placeed But it failed to find a host acceptable because of this "bug"
14:58:17 kashyap bauzas: I'm not sure a spec is required in this case https://review.openstack.org/#/c/545034/ ("Allow to configure amount of PCIe ports")
14:58:47 bauzas kashyap: sure, I discussed with hrw about the process
14:59:03 bauzas he created a BP, and asked for a specless approval for the next nova meeting
14:59:18 kashyap Ah-ha
14:59:27 kashyap hrw: The above change should also mention something about its usefulness in context of Nova coping with Q35 machine types
14:59:33 kashyap (Recall the discussion from #virt, OFTC)
14:59:59 kashyap At some point distributions will default to the Q35, and Nova should be ready to gracefully handle it.
15:00:20 kashyap So your change helps with that; so it's worth mentioning.
15:00:23 kashyap I'll add a note in the review
15:02:08 efried Placeed: I know mriedem has been looking at bfv stuff lately, though I don't know the details. I think he has recently put up a series of fixes - but again, no idea if the bug is related to this. Looking...
15:02:38 efried Placeed: Here's the code series: https://review.openstack.org/#/c/539758/
15:02:48 openstackgerrit Hamdy Khader proposed openstack/nova master: Adding NVMEoF for libvirt driver https://review.openstack.org/482640
15:03:17 efried Placeed: Hmm, the bug doesn't sound like your issue: https://bugs.launchpad.net/nova/+bug/1404867
15:03:17 openstack Launchpad bug 1404867 in OpenStack Compute (nova) "Volume remains in-use status, if instance booted from volume is deleted in error state" [Medium,In progress] - Assigned to melanie witt (melwitt)
15:05:04 mriedem efried: it's not,
15:05:07 mriedem it's likely https://bugs.launchpad.net/nova/+bug/1469179
15:05:07 openstack Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] - Assigned to melanie witt (melwitt)
15:05:11 mriedem https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged)
15:05:55 mriedem which has been continually deferred until we have sharing disk_gb provider support, which continually gets deferred
15:06:31 efried mriedem: "sharing disk_gb provider support" as in placement?
15:06:37 mriedem yeah
15:06:41 efried okay.
15:06:46 mriedem having the computes / RT be aware of shared storage pools
15:06:51 Placeed mriedem : it really sounds like https://bugs.launchpad.net/nova/+bug/1469179
15:06:51 openstack Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] - Assigned to melanie witt (melwitt)
15:07:00 mriedem Placeed: yes it's an old old bug
15:07:35 sean-k-mooney kashyap: i responded to your question regarding numa aware vswitches
15:07:55 Placeed mriedem : It mean there is a fix actually ? I'm running SUSE Official Openstack, maybe they run an old version ?
15:08:12 efried Placeed: There's not a fix yet.
15:08:18 mriedem Placeed: not unless suse patched it in their distro
15:08:19 kashyap sean-k-mooney: Thanks; will read
15:08:20 sean-k-mooney kashyap: the patch you linked is not quite what we need but i have added the details to the spec for what we would need to allow numa aware pcie virtualisation within the guest
15:08:40 efried Placeed: The shared provider support mriedem is talking about is feature work that's been in progress for several releases now.
15:08:48 Placeed mriedem : Could you help me to identify which fix it is ? I can ask them
15:08:55 mriedem Placeed: there is no fix upstream yet
15:09:00 kashyap sean-k-mooney: Ah; right. For PCIe, we'd also mention the need for Q35 machine type — as that's mandatory for PCIe
15:09:08 kashyap (I'd guess you already know that.)
15:09:15 mriedem Placeed: there is https://review.openstack.org/#/q/topic:fix-bfv-boot-resources+(status:open+OR+status:merged) but there is not agreement on merging those changes
15:09:20 mriedem as they would introduce some technical debt
15:09:25 sean-k-mooney kashyap: well i dont think it acutlly is
15:09:34 mriedem Placeed: you could take those, rebase them, and patch them into your env as a workaround
15:09:39 sean-k-mooney kashyap: can you show me where that is stated?
15:09:40 kashyap sean-k-mooney: Let me double-check on my comment w/ the Virt folks
15:09:53 kashyap Because, pretty sure I was told so by a QEMU dev
15:09:55 efried Placeed: For the "real fix", a lot of the groundwork has been laid at this point, and it's just possible we'll put it on the slate for Rocky. We'll be talking about that at the PTG next week.
15:09:58 mriedem Placeed: but if those patches never land, you're left with the fork
15:10:05 Placeed mriedem : But it mean actually everybody who is using NFS / CInder have the same issue on openstack right ?
15:10:22 Placeed Or it's only me on my suse distribution
15:10:31 mnaser good morning everyone, just going to drop https://review.openstack.org/#/q/status:open+topic:bug/1404867 here if someone feels like going through these patches, they're ready for final review (afaik)
15:10:51 sean-k-mooney kashyap: based on https://github.com/qemu/qemu/blob/master/docs/pcie.txt it does seam to be related to Q35 but not sure its a hard dependecy
15:11:09 mriedem Placeed: it's not just you
15:11:31 hrw kashyap: thx
15:11:36 sean-k-mooney kashyap: using the Q35 chipset is likely a good idea anyway
15:11:45 Placeed mriedem : So another workaround would be to have a local disk as big as all my vm's root disk running on that server right ?
15:12:04 hrw kashyap: BP mentions q35 but right, commit can describe it more too
15:13:16 hrw kashyap: release note describes x86/q35 and aarch64/virt
15:14:48 kashyap sean-k-mooney: Okay, I double-confirmed, and indeed Q35 is a hard dep for PCIe.
15:14:55 kashyap sean-k-mooney: That doc you linked to should be updated; I'll update it
15:14:56 mriedem Placeed: i'm not sure about that
15:15:16 kashyap sean-k-mooney: But, look here (the URL from the doc you mentioned), on slide-13: https://wiki.qemu.org/images/4/4e/Q35.pdf
15:15:25 kashyap sean-k-mooney: It says: "Q35-only features: PCIe goodies [...]"
15:15:38 hrw sean-k-mooney: q35 is hard dep for pcie.
15:15:46 Placeed mriedem : What could be a workaround while i wait the official patch ?
15:16:10 sean-k-mooney kashyap: yes but the feature i was memtioning is not listed in that slide and qemu had limited pcie support before the uese of q35
15:16:11 hrw sean-k-mooney: qemu has 3 x86 platforms: isa-pc (no one uses), i440fx (pci based), q35 (pcie based)
15:16:29 mriedem Placeed: i'm not intimately familiar with the bug nor the fix - melwitt has carried the patch for a long time, so she might be able to help once she's around
15:16:31 sean-k-mooney hrw: really i taught i440fx supported pcie
15:16:42 hrw sean-k-mooney: i440fx is older than pcie ;D
15:17:13 mriedem Placeed: you could also ask about that bug in the #openstack-operators channel and ask if anyone has patched it out of tree and if so, how?
15:17:17 kashyap sean-k-mooney: Yeah, first I'll read your full comment before talking further. And yes, Q35 does have the limitation you note.
15:17:38 mriedem Placeed: i know SAP is probably doing something for it
15:17:47 mriedem they use NFS for everything, and are i think suse customers
15:18:11 Placeed mriedem : Ok thank you very very much for your help. I will also check with SUSE Guys.
15:18:58 kashyap sean-k-mooney: My second sentence in my previous message was misphrased. Correct: Q35 _solves_ that limitation of older QEMUs PCIe support.
15:19:32 hrw would be nice to see some future qemu dropping <q35 ;D
15:19:48 hrw but that's not gonna happen
15:19:56 bauzas stupid question but we get network information from the compute right ? https://bugs.launchpad.net/nova/+bug/1740241
15:19:56 openstack Launchpad bug 1740241 in OpenStack Compute (nova) "Network info not always displayed for a created instance" [Undecided,New]
15:20:06 bauzas at least until we do that from the conductor
15:21:43 mriedem efried: questoin here https://review.openstack.org/#/c/540111/5/specs/rocky/approved/update-provider-tree.rst@73
15:21:44 bauzas nevermind, got the line
15:23:43 mriedem lyarwood: are you around this week? i want to flush some ocata patches since ocata eol is supposedly next week
15:24:33 kashyap hrw: Yes, that won't happen. Majority still use the 'i440fx', as you can guess.
15:25:11 hrw yep

Earlier   Later