| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-17 | |||
| 19:08:58 | jroll | added a note to the detail=True parameter | |
| 19:29:28 | mriedem | so we're deprecating the force flag from the evacuate and live migration apis, | |
| 19:29:40 | mriedem | wouldn't it behoove us to deprecate that as an option from nova commands as well? | |
| 19:29:49 | mriedem | or at least doc it up real good that you shouldn't use it? | |
| 19:32:50 | artom | mriedem, wait, deprecate or remove? | |
| 19:33:01 | melwitt | dansmith: would appreciate your review on mah backport https://review.openstack.org/610673 | |
| 19:33:05 | artom | Because for removal the usual novaclient microversion stuff applies, no? | |
| 19:34:08 | mriedem | artom: if we don't want people using the force flag to live migrate or evacuate an instance, | |
| 19:34:17 | mriedem | so much so that we're deprecating the api parameter, | |
| 19:34:26 | mriedem | you could argue that we should not have it in the CLI either | |
| 19:34:31 | mriedem | like, at all | |
| 19:34:34 | mriedem | even for older microversions | |
| 19:34:43 | artom | mriedem, but it still exists for old microversions | |
| 19:34:45 | artom | In the API | |
| 19:34:47 | mriedem | yes i know | |
| 19:34:52 | artom | So, we have to keep client support | |
| 19:35:02 | mriedem | not really | |
| 19:35:03 | artom | So if they specifically --os-compute-version <old>, they have it | |
| 19:35:06 | artom | Otherwise, it's gone | |
| 19:35:36 | mriedem | once all allocations are nested, you won't be able to force at all | |
| 19:35:43 | mriedem | regardless of microversion | |
| 19:35:52 | mriedem | anyway, it was just a thought | |
| 19:36:05 | mriedem | should probably start by putting the big fat warnings in the API reference into the CLI option descriptions | |
| 19:36:52 | artom | mriedem, ah I see. Well we still have to keep the old API intact, no? Just now we'll return a 400 or something. | |
| 19:37:04 | artom | If they send a force flag | |
| 19:37:59 | mriedem | it'll be some kind of error | |
| 19:38:04 | mriedem | don't know if it's a 400 or 409 | |
| 19:38:07 | mriedem | it's in gibi's spec | |
| 19:40:11 | mriedem | aspiers: just a few hundred comments in your spec https://review.openstack.org/#/c/609779/ | |
| 19:43:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix typo in libvirt.hw_machine_type help https://review.openstack.org/611422 | |
| 19:48:58 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: High Precision Event Timer (HPET) on x86 guests https://review.openstack.org/607989 | |
| 19:51:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Document each libvirt.sysinfo_serial choice https://review.openstack.org/611426 | |
| 19:55:36 | artom | mriedem, you led me astray, I demand a refund: https://review.openstack.org/#/c/587439/4/nova/tests/unit/compute/test_compute_mgr.py@7439 | |
| 19:59:55 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Ensure attachment cleanup on failure in driver.pre_live_migration https://review.openstack.org/587439 | |
| 20:00:22 | mriedem | umm | |
| 20:00:27 | mriedem | what's the point of even asserting those then | |
| 20:01:08 | artom | I guess Matt was trying to make sure we call all of the things? But... in a for loop, because he didn't feel like writing out each individual method name? | |
| 20:01:49 | mriedem | ^O^ | |
| 20:01:56 | mriedem | that's me shrugging, not a bat | |
| 20:02:24 | artom | Or a yelling Asian person? | |
| 20:02:30 | artom | (Can I say that? Is that racist?) | |
| 20:02:54 | mriedem | it's very racist | |
| 20:03:16 | artom | Dammit. Hilter 2.0 right here, friends. | |
| 20:05:47 | openstackgerrit | Merged openstack/nova master: Merge used_limits extension response into limit view builder https://review.openstack.org/606031 | |
| 20:15:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix block_device_mapping_v2 mention in server create API reference https://review.openstack.org/611433 | |
| 20:34:34 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Recommend against using --force for evacuate/live migration https://review.openstack.org/611436 | |
| 21:15:09 | openstackgerrit | melanie witt proposed openstack/nova master: Add rolling upgrade info to enable_consoleauth workaround reno https://review.openstack.org/611218 | |
| 21:15:09 | openstackgerrit | melanie witt proposed openstack/nova master: Add nova-status upgrade check for consoles https://review.openstack.org/611214 | |
| 21:48:07 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Support initial allocation ratios https://review.openstack.org/552105 | |
| 21:51:20 | mriedem | holy fart i'm +2 on the initial allocation ratios spec https://review.openstack.org/#/c/552105/ | |
| 21:52:38 | melwitt | and the peasants rejoiced! | |
| 22:37:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add API ref guideline for examples https://review.openstack.org/604060 | |
| 23:19:44 | openstackgerrit | Merged openstack/nova stable/rocky: Handle volume API failure in _post_live_migration https://review.openstack.org/611083 | |
| 23:19:50 | openstackgerrit | Merged openstack/nova master: Ignore uuid if already set in ComputeNode.update_from_virt_driver https://review.openstack.org/611162 | |
| #openstack-nova - 2018-10-18 | |||
| 00:42:37 | openstack | bug 1798163 in OpenStack Compute (nova) rocky "Placement incomplete consumers online migration fails" [Critical,In progress] https://launchpad.net/bugs/1798163 - Assigned to Matt Riedemann (mriedem) | |
| 00:42:37 | openstackgerrit | Merged openstack/nova stable/rocky: Add recreate test for bug 1798163 https://review.openstack.org/611314 | |
| 01:34:46 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support vgpu resource provider create https://review.openstack.org/520313 | |
| 01:35:23 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations` https://review.openstack.org/521717 | |
| 01:36:14 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations` https://review.openstack.org/521717 | |
| 01:36:40 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update https://review.openstack.org/521041 | |
| 01:37:21 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): support compute node resource provider update https://review.openstack.org/521041 | |
| 01:37:47 | openstackgerrit | Naichuan Sun proposed openstack/nova master: os-xenapi(n-rp): add traits for vgpu n-rp https://review.openstack.org/604269 | |
| 01:59:35 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Merge image_size extension response into image view builder https://review.openstack.org/606845 | |
| 01:59:56 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the caching the resource on Request object https://review.openstack.org/609403 | |
| 02:00:17 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove more code related to extensions and testing https://review.openstack.org/607088 | |
| 02:01:04 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the extensions framework from wsgi.py https://review.openstack.org/607092 | |
| 02:01:42 | gmann | stephenfin: alex_xu ^^ rebased the series, need to +A again. | |
| 06:58:01 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova-specs master: Spec: Support filtering by forbidden aggregate https://review.openstack.org/603352 | |
| 08:12:03 | gibi | Kevin_Zheng: I've responded to you in https://review.openstack.org/#/c/605785 | |
| 08:13:13 | Kevin_Zheng | gibi, Oh, yes, I will check ASAP, I was busy on something else, these days, sorry for the late response | |
| 08:13:36 | gibi | Kevin_Zheng: no problem, take your time. :) | |
| 08:18:23 | bauzas | oh oops my manners | |
| 08:18:26 | bauzas | good morning Novaz | |
| 08:18:37 | gibi | bauzas: good morning | |
| 08:24:03 | Kevin_Zheng | gibi, I still don't get the reason for NoValidHost exception | |
| 08:25:11 | Kevin_Zheng | I got the point you illustrate in both case 1 and 2 | |
| 08:25:31 | gibi | Kevin_Zheng: bottom line, nova cannot always detect if the server would need complex allocation on the destination. When nova cannot detect that Nova cannot raise other than NoValidHost as that is the generic exception used when placement allocation fails | |
| 08:26:03 | gibi | Kevin_Zheng: so there will be always cases when nova raise NoValidHost because of complex allocation would be needed | |
| 08:27:27 | gibi | Kevin_Zheng: therefore I think it will be even more confusing to raise NoValidHost is some case and ComplexAllocationNotSupported exception in other cases when both situations has the same root casuse, the need for the complex allocation | |
| 08:28:59 | Kevin_Zheng | OK, I got your point | |
| 08:29:30 | gibi | Kevin_Zheng: I can inform the user properly in half of the cases :/ | |
| 08:30:47 | Kevin_Zheng | Hmm, but maybe it will still be miss leading, as an user, I can see that I still have resources in the cloud | |
| 08:30:56 | gibi | Kevin_Zheng: this is basically a chiken-and-egg problem. The need of complex allocation on the destination can only be detected in every case if placement a_c is called. But force flag is defined in a way that it forbids calling the scheduler and placement | |
| 08:30:58 | Kevin_Zheng | but you tell me that there is no valid host? | |
| 08:31:29 | gibi | Kevin_Zheng: only if you specify the force flag | |
| 08:31:39 | gibi | Kevin_Zheng: the root of the problem is the definition of the force flag | |
| 08:32:21 | gibi | Kevin_Zheng: it forces (sic) nova to decide without the scheduler. But when we introduced placement in the picture nova lost the possibility to decide without consulting placement | |
| 08:33:17 | Kevin_Zheng | Hmm, there is a log, but the logs may only be available for ``operators``, if we had ``admins`` that can use force flag, this might still be confusing? | |
| 08:34:14 | gibi | Kevin_Zheng: there is no specific log in case #2. In case #2 nova tries to blind copy the flat soruce allocation to the dest but on the dest the root RP does not have enough resources therefore it is a NoValidHost | |
| 08:35:05 | gibi | Kevin_Zheng: it is indistinguishable from the case when the dest would allow flat alloaction but we run out of resources on the dest | |
| 08:35:10 | Kevin_Zheng | Hmm, thats true | |
| 08:35:29 | Kevin_Zheng | Ok, I'm convienced | |
| 08:35:31 | Kevin_Zheng | :) | |
| 08:39:38 | gibi | Kevin_Zheng: I understand that it is not a good situation from the user perspective. But force flag cannot be supproted any more as it is defined today. This is why I proposed to remove that flag in the future | |
| 08:41:16 | Kevin_Zheng | yes, I understand, but I think it might be very widely used for admins, as you mentioned, it has already been discussed, and it is free to propose better solutions, I think I will try to dig deeper. | |
| 08:44:19 | gibi | Kevin_Zheng: in the ML post I tried to give alternatives http://lists.openstack.org/pipermail/openstack-dev/2018-October/135551.html | |
| 08:44:55 | gibi | Kevin_Zheng: option #D) would be one way out but that would be bad from other perspective (inconsisten resource allocation) | |
| 09:04:49 | sean-k-mooney | o/ | |
| 09:25:36 | jangutter | sean-k-mooney: in your absence, it was discovered that random failures in the gate uncovered a bug: https://review.openstack.org/#/c/611017 | |
| 09:31:41 | sean-k-mooney | jangutter: oh looking | |