| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-19 | |||
| 14:07:42 | edmondsw | also think about dev on the cloud... I'm still developing this service and haven't setup HA yet, but I don't want you restarting it while I'm working | |
| 14:07:43 | kashyap | Where you update Compute-B, migrate all instances from Compute-A to B | |
| 14:07:46 | sean-k-mooney | cdent: well live migration cannot always be assumed to be available in a cloud and even if it is it my not be viable due to your perfromce constratints | |
| 14:07:46 | kashyap | And so forth | |
| 14:08:19 | kashyap | Yeah, random restarts that catch tenant users off-guard are completely undesirable | |
| 14:09:13 | kashyap | sean-k-mooney: Yeah, that's also why, as you pointed out, tenant users don't get to migrate instances. It is admins that drive it. | |
| 14:09:28 | cdent | Sounds like there could be a problem with "random restarts" that is orthogonal to everything else | |
| 14:09:37 | sean-k-mooney | i would generally say livemigration is more of an enterprise feature then telco as most nfv application cant tollerate the dataplane impact of a livemigration (latency,bandwith and packet loss) | |
| 14:10:07 | kashyap | True | |
| 14:11:09 | edmondsw | kashyap tenant users don't get to migrate instances because migration assumes knowledge of the infrastructure. If I don't have that knowledge, why would I try to move it :) | |
| 14:11:52 | sean-k-mooney | cdent: to your original question a cloud native application should not require livemigration to be avalible at all as it should be fault tolerant enough to cover a cold migration but most applications are not cloud native. | |
| 14:12:08 | kashyap | edmondsw: Yeah, indeed. | |
| 14:12:36 | cdent | I should probably have put some ™ in my original statement to make it clear that I was talking about over-idealized and over-hyped pictures. | |
| 14:13:11 | edmondsw | is there such a thing as over-idealized? ;) | |
| 14:13:23 | sean-k-mooney | edmondsw: that and allowing tennants to live migrate stuff is a great way to ddos you management network as that is what all the openstack installers configure to use by default. | |
| 14:14:00 | edmondsw | ++ | |
| 14:14:38 | edleafe | edmondsw: that's like being "more unique" | |
| 14:14:54 | edmondsw | but if there's no use case to allow tenants to live migrate (because they lack the necessary infra knowledge) all other concerns become secondary | |
| 14:15:19 | sean-k-mooney | edmondsw: i would say the existence of apple product in the world would be evedence of over-idealized design above fuction. | |
| 14:15:34 | edmondsw | sean-k-mooney touche! | |
| 14:15:44 | jaypipes | mriedem, dansmith, melwitt, bauzas, stephenfin: we've got pretty broad agreement on the approach in https://review.openstack.org/#/c/540111/. would be great to approve that and unblock the patch series implementing it. | |
| 14:16:09 | bauzas | jaypipes: stephenfin is on PTO this week | |
| 14:16:31 | bauzas | but I can review it for sure | |
| 14:16:40 | sean-k-mooney | oh by the way is master open for rocky and i assume not is a good time to repopose the feature based schduling spec form last cycle? | |
| 14:17:00 | edmondsw | sean-k-mooney master is open | |
| 14:17:35 | sean-k-mooney | edmondsw: cool i have some patches to rebase that missed code freeze | |
| 14:17:50 | edmondsw | join the club! | |
| 14:18:25 | jaypipes | sean-k-mooney: feature-based scheduling? | |
| 14:18:37 | jaypipes | sean-k-mooney: oh, the nic feature one? | |
| 14:18:44 | sean-k-mooney | jaypipes: ya rodolfos work | |
| 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 | 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:03:17 | efried | Placeed: Hmm, the bug doesn't sound like your issue: https://bugs.launchpad.net/nova/+bug/1404867 | |
| 15:05:04 | mriedem | efried: it's not, | |
| 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:07 | mriedem | it's likely https://bugs.launchpad.net/nova/+bug/1469179 | |
| 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 | 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:06:51 | Placeed | mriedem : it really sounds like https://bugs.launchpad.net/nova/+bug/1469179 | |
| 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 ? | |