| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-18 | |||
| 15:41:30 | ildikov | amorin: efried: that should be ok for cherry-picking | |
| 15:41:36 | amorin | ildikov: this is the one I am trying to cherry-pick | |
| 15:41:48 | amorin | Cannot create new patch set of change 508640 because it is abandoned | |
| 15:41:51 | openstackgerrit | Merged openstack/nova master: placement: _get_trees_matching_all_resources() https://review.openstack.org/531512 | |
| 15:42:01 | openstackgerrit | Merged openstack/nova master: Fix openstackdocstheme options for api-ref https://review.openstack.org/534712 | |
| 15:42:02 | amorin | from web page | |
| 15:42:10 | ildikov | amorin: what I've just linked in that's merged | |
| 15:42:33 | ildikov | amorin: Change 430400 | |
| 15:43:12 | ildikov | amorin: you're trying with an already cherry-picked patch which landed on Ocata and got abandoned after Matt's comment that it should've been backported to Pike first | |
| 15:43:27 | amorin | yup | |
| 15:43:36 | amorin | but it's already in pike actually | |
| 15:43:52 | amorin | I think it was merged while pike was the master branch | |
| 15:44:52 | ildikov | I didn't check that | |
| 15:45:10 | ildikov | are you trying to get it landed on Ocata? | |
| 15:45:22 | amorin | yes, both Ocata and newton if possible | |
| 15:45:22 | gibi | amorin, ildikov: yeah it seems that it is in stable/pike according to gerrit | |
| 15:45:37 | ildikov | gibi: yeah, I've just checked | |
| 15:45:37 | amorin | reopen this https://review.openstack.org/#/c/508640/ | |
| 15:45:42 | amorin | and this | |
| 15:45:44 | amorin | https://review.openstack.org/#/c/508641/ | |
| 15:45:58 | ildikov | amorin: I think Newton is EOL now, but gibi should be smarter | |
| 15:46:03 | amorin | because the related but : https://bugs.launchpad.net/nova/+bug/1662626 | |
| 15:46:04 | openstack | Launchpad bug 1662626 in nova (Ubuntu Xenial) "live-migrate left in migrating as domain not found" [Medium,Triaged] | |
| 15:46:14 | ildikov | amorin: in both cases you only need to get the patch re-opened | |
| 15:46:15 | amorin | is supposed to be fixed | |
| 15:46:25 | ildikov | amorin: no more cherry-picking is needed | |
| 15:46:40 | amorin | ildikov: ok, so I need some core to reopen it right? | |
| 15:46:47 | ildikov | amorin: https://review.openstack.org/#/q/b706155888d740841d745c52aae543cf82fab0bc | |
| 15:46:58 | ildikov | amorin: yes, correct | |
| 15:47:13 | ildikov | amorin: gibi has the power for instance :) | |
| 15:47:15 | gibi | amorin: it seems you need a stable core to reopen the abandoned patches | |
| 15:47:21 | gibi | ildikov: it seems not :) | |
| 15:47:32 | ildikov | gibi: sadness :( | |
| 15:47:37 | amorin | :( | |
| 15:47:58 | gibi | I only have such power on master branch | |
| 15:48:38 | gibi | amorin: I think this group is the nova stable cores https://review.openstack.org/#/admin/groups/540,members | |
| 15:48:51 | amorin | thanks | |
| 15:50:25 | amorin | is there any official way to contact them without too much bothering? | |
| 15:51:59 | spotz | sean-k-mooney: I actually was able to do it and by just giving it an IP in the subnet range so I let the student know that method | |
| 15:52:25 | spotz | sean-k-mooney: plus specifiying the network | |
| 15:52:54 | gibi | bauzas: could you help amorin reopening these abandoned stable backports? https://review.openstack.org/#/q/I23ed9819061bfa436b12180110666c5b8c3e0f70 | |
| 15:53:03 | gibi | bauzas: I have no stable power | |
| 15:54:00 | gibi | dansmith, tonyb ^^ | |
| 15:55:29 | ameeda | what about this log ? undercloud.bootpc > gateway.bootps: BOOTP/DHCP, Request from 00:a7:b7:5c:d0:dd (oui Unknown), length 30 | |
| 15:55:33 | lyarwood | gibi: the stable/ocata change is open, newton is EOL so I'd rather not open it up | |
| 15:55:35 | bauzas | gibi: sure, doing it | |
| 15:55:54 | gibi | lyarwood: thanks. you are right netwon is EOL | |
| 15:56:07 | amorin | lyarwood: gibi thanks for ocata | |
| 15:56:19 | amorin | problem is that this bug is supposed to be fixed: | |
| 15:56:21 | amorin | https://review.openstack.org/#/q/b706155888d7408 | |
| 15:56:22 | bauzas | hah, jinxed by lya | |
| 15:56:25 | bauzas | lyarwood: | |
| 15:56:27 | amorin | but is not | |
| 15:56:40 | amorin | sorry good link : https://bugs.launchpad.net/nova/+bug/1662626 | |
| 15:56:41 | openstack | Launchpad bug 1662626 in nova (Ubuntu Xenial) "live-migrate left in migrating as domain not found" [Medium,Triaged] | |
| 15:56:41 | bauzas | and yeah, newton is EOL, so no for that one | |
| 15:57:06 | amorin | thanks | |
| 15:57:59 | amorin | I'll rebase the ocata one | |
| 15:59:56 | openstackgerrit | Arnaud Morin proposed openstack/nova stable/ocata: Stop _undefine_domain erroring if domain not found https://review.openstack.org/508640 | |
| 16:01:14 | ameeda | TheJuliaL what about this log ? undercloud.bootpc > gateway.bootps: BOOTP/DHCP, Request from 00:a7:b7:5c:d0:dd (oui Unknown), length 30 | |
| 16:06:25 | openstackgerrit | Merged openstack/nova master: trivial: Remove crud from 'conf.py' https://review.openstack.org/534713 | |
| 16:20:13 | Spazmotic | Mannnnnnnnnnnnnn laying there trying to sleep with resource providers moving through my brain | |
| 16:24:44 | Spazmotic | I understand what you were asking now about discovery and healing efried and I can agree it's something to consider. We already have local delete issues here in Nova but they intend to push this service externally. | |
| 16:25:20 | Spazmotic | Currently we could code around this in Cells or something to monitor the state of a compute node to clear out the placements..or some other solution.. but if we open this into an ew project to keep track of Cinder Volumes, those can possibly have the same issue. | |
| 16:25:46 | efried | Heh, "an ew project" - how apt. | |
| 16:25:48 | Spazmotic | or Kubernetes as well, etc.. | |
| 16:25:54 | Spazmotic | hehe | |
| 16:26:51 | Spazmotic | Seems like it should run almost as a service as how we have compute run to monitor its resource providers. Possibly with a column for them for Last_Checked(datetime) and task_state(varchar()) on the resource. | |
| 16:26:59 | Spazmotic | Allow a task state like "Draining" | |
| 16:27:18 | Spazmotic | To clear the providers in a data-loss event like that where a compute node or such doesn't ever intend to come back up, or will get a new headshot | |
| 16:27:19 | openstackgerrit | Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/535121 | |
| 16:27:31 | Spazmotic | err consumers rather. | |
| 16:27:46 | Spazmotic | But that's just from first blush of looking at the code and trying to fall asleep.. i may be a zombie. | |
| 16:34:11 | Spazmotic | But yeah.. currently that is far outside of the scope of the current project unfortunately. | |
| 16:55:29 | gibi | bauzas: Do you agree that this is not a problem? https://review.openstack.org/#/c/533642/4/nova/virt/libvirt/driver.py@555 | |
| 16:56:34 | bauzas | gibi: that's an excellent catch! | |
| 16:56:44 | bauzas | gibi: but yeah you're right, not impactful | |
| 16:57:16 | bauzas | gibi: because I'm just doing that for recreating mediated devices that are assigned to instances by the related guest XML | |
| 16:57:39 | bauzas | gibi: so, if after looking at all the instances, we destroy some of them, it will just leave some mediated devices "free" | |
| 16:58:19 | gibi | bauzas: and those mdevs will be used for the next VM boot that requests vgpus | |
| 16:59:10 | gibi | bauzas: as the code only create new mdevs if there is no existing is found | |
| 16:59:42 | bauzas | gibi: correct | |
| 17:00:00 | bauzas | gibi: I also added in a comment that it *could* be a problem when we begin supporting multiple types | |
| 17:00:41 | bauzas | gibi: but then, I plan to just verify all the mediated devices whether they're assigned or not once an instance is spawned to make sure we don't create more mdevs than needed | |
| 17:01:14 | gibi | bauzas: sounds good | |
| 17:01:37 | gibi | bauzas: hm, we actually leak the mdev uuid from the destroyed VM to the new VM and if the destroyed VM is one that was evacuated then we will have two VMs on two separate compute hosts with identical mdev uuids. But I guess it is not a problem | |
| 17:02:12 | bauzas | gibi: migrating a VM with vGPUs isn't tested yet | |
| 17:02:36 | bauzas | gibi: but I'd treat any possible problem with migrations as bugs | |
| 17:02:47 | gibi | bauzas: I agree | |
| 17:02:56 | gibi | bauzas: I'm +2 on this patch | |
| 17:03:00 | bauzas | cool thanks | |
| 17:03:04 | gibi | bauzas: thanks for the explanation | |
| 17:03:15 | bauzas | I still need to add a new patch for the suspend case | |
| 17:03:22 | bauzas | but I'll treat that patch as a bug | |
| 17:03:46 | bauzas | because that's not working because libvirt doesn't support suspending a guest with attached PCI or mediated devices | |
| 17:03:52 | bauzas | just FYI | |
| 17:04:17 | gibi | bauzas: seems like a bleading edge feature :P) | |
| 17:04:31 | gibi | s/bleading/bleeding/ | |
| 17:04:33 | bauzas | hah! | |
| 17:05:02 | bauzas | when I see how people plan to use vGPUs, I'd be surprised if they want to suspend | |