| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-30 | |||
| 19:17:27 | mgagne | mriedem: what I meant is: once implementation is done, why should you rely on the spec? they can get out of sync easily | |
| 19:17:39 | mriedem | if some major part of a design point in a spec changed during implementation, or something was added, then we amend specs | |
| 19:17:57 | mriedem | lots of reasons - the problem statement, the original design ideas, etc | |
| 19:17:59 | mriedem | it's an archive | |
| 19:18:11 | mgagne | mriedem: that's not my experience so far as a spec reader | |
| 19:18:41 | mriedem | first, i'm not saying you should have to rely on a spec as a usage doc, it's not meant to be that | |
| 19:18:42 | mgagne | mriedem: ok, maybe not literally deleted but a end user shouldn't rely on that kind of documents | |
| 19:18:47 | openstackgerrit | Merged openstack/nova master: Bumping functional test job timeouts https://review.openstack.org/537933 | |
| 19:18:58 | mriedem | if we're missing usage docs, that's a bug | |
| 19:18:59 | mgagne | mriedem: ok, we agree on that point | |
| 19:23:45 | mgagne | mriedem: tyvm for your work btw =) | |
| 19:27:21 | openstackgerrit | Merged openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961 | |
| 19:27:31 | openstackgerrit | Merged openstack/nova master: Collapse duplicate error handling in rebuild_instance https://review.openstack.org/539001 | |
| 19:32:19 | openstackgerrit | Merged openstack/nova stable/pike: Fix false positive server group functional tests https://review.openstack.org/536981 | |
| 19:33:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 19:33:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 19:33:45 | openstackgerrit | Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517 | |
| 19:33:56 | efried | jaypipes: Fixed those tests; should all be ready to go now ^ | |
| 19:34:10 | efried | whoah, stuff is merging, neat. | |
| 19:36:21 | mgagne | mriedem: thanks for nova-caching-scheduler job, we do heavily rely on that driver. glad to see it won't get broken by accident before its removal. | |
| 19:36:45 | mriedem | mgagne: huawei public cloud is using it as well | |
| 19:36:53 | mriedem | so yeah i have to care about that one :) | |
| 19:36:59 | mgagne | mriedem: wasn't it them that made a presentation at the summit about it? | |
| 19:37:21 | mriedem | i don't remember one, but which summit? | |
| 19:37:29 | mriedem | it was added by rax | |
| 19:37:44 | mgagne | austin | |
| 19:37:59 | mgagne | was Intel | |
| 19:38:00 | mgagne | https://www.openstack.org/videos/austin-2016/dive-into-nova-scheduler-performance-where-is-the-bottleneck | |
| 19:38:06 | mriedem | yeah i remember that one | |
| 19:38:15 | mriedem | that was about a proposal for a different scheduler | |
| 19:38:57 | mgagne | difference of performance is like day and night (filter vs caching) | |
| 19:38:58 | mriedem | placement was pretty new still around that time so a lot of the outcome of that session (there was also a related design summit session) was "placement should handle a lot of these same issues" | |
| 19:39:40 | mriedem | i'm mostly interested, right now, in filter scheduler + placement vs caching | |
| 19:39:48 | mriedem | to see if that gap is much smaller | |
| 19:40:29 | mgagne | yes... because if placement is not as fast or close to be as fast, I would be like: "what's the point?" =) | |
| 19:41:46 | prometheanfire | mriedem: it's getting to the point where we'll need an FFE for https://review.openstack.org/538070 (if horizon doesn't merge that dependant patch) | |
| 19:42:47 | efried | jaypipes, mriedem: The final parts of update_provider_tree going to Rocky presents an opportunity to write that design up as a separate blueprint/spec. It was never outlined in any of the placement/NRP specs (right Jay?) and it really ought to be. If you agree, I can get started on that. | |
| 19:43:33 | efried | (If you don't agree, I'm going to write it anyway, for my own use, and you don't get to see it.) | |
| 19:44:30 | mriedem | prometheanfire: i'm not sure how much i want to pursue that this late given the impact it also has to some CLIs in OSC: http://lists.openstack.org/pipermail/openstack-dev/2018-January/126741.html | |
| 19:45:40 | prometheanfire | mriedem: that's kinda what I thought | |
| 19:47:38 | mriedem | we'll just pick it up in rocky | |
| 19:47:47 | mriedem | nothing requires novaclient>=10.0.0 in queens | |
| 19:48:50 | prometheanfire | k | |
| 19:56:40 | prometheanfire | mriedem: k, gonna -2-W that for freeze then | |
| 19:58:00 | mriedem | prometheanfire: ok i left a comment in there that i'm cool with it | |
| 20:01:30 | openstackgerrit | Merged openstack/nova stable/pike: Set server status to ERROR if rebuild failed https://review.openstack.org/536897 | |
| 20:06:25 | melwitt | more people are asking about https://review.openstack.org/340614 again, I've rewritten the commit message and added code comments to make it easier to review | |
| 20:08:16 | mriedem | i saw you dropped the revert history of shame | |
| 20:08:34 | mriedem | also, "people are talking" is a classic fox news tactic | |
| 20:08:41 | mriedem | name your sources mel | |
| 20:09:08 | prometheanfire | top | |
| 20:09:09 | prometheanfire | men | |
| 20:09:19 | melwitt | yeah, I had thought the history was important but I got the feeling no one could understand the point of the patch because of it | |
| 20:09:38 | melwitt | even I was getting confused between merge conflicts | |
| 20:09:39 | prometheanfire | https://www.reactiongifs.us/wp-content/uploads/2013/10/top_men_indiana_jones.gif | |
| 20:10:44 | melwitt | ayoung is asking about it today in #openstack-cinder | |
| 20:26:07 | mriedem | https://review.openstack.org/#/c/537933/ is finally merged, patches should flow much better through the gate now | |
| 20:27:45 | prometheanfire | mriedem: please have a piece of wood glued to your head :P | |
| 20:28:00 | cfriesen | melwitt: in the case of https://review.openstack.org/340614 why doesn't nova-compute do a more complete job of cleaning up at the time it sets the instance.host to None? | |
| 20:28:24 | mriedem | prometheanfire: ? | |
| 20:28:29 | prometheanfire | patches should flow much better through the gate now | |
| 20:28:53 | mriedem | cfriesen: like this? https://review.openstack.org/#/c/528385/ | |
| 20:29:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional tests for traits-based scheduling https://review.openstack.org/539310 | |
| 20:29:35 | mriedem | alex_xu: efried: ^ | |
| 20:29:41 | mriedem | turned out it was pretty simple to write those | |
| 20:30:30 | cfriesen | mriedem: yep, and something similar for ports I guess. | |
| 20:34:56 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: remove unnecessary conf imports https://review.openstack.org/539314 | |
| 20:35:27 | melwitt | cfriesen: good question. looks like it tries to do something to cleanup volumes but it only does a volume delete if 'delete_on_termination' and doesn't do anything like detach volumes | |
| 20:35:51 | melwitt | so it seems like a better fix would be to properly handle cleanup in compute | |
| 20:37:21 | mriedem | melwitt: that's what ameeda's patch is trying to do | |
| 20:38:05 | mriedem | we do call _cleanup_allocated_networks when a build fails on the compute | |
| 20:38:10 | mriedem | which should cleanup ports | |
| 20:38:48 | melwitt | right | |
| 20:39:12 | mriedem | there could possibly be a bug there if we're using a stale network info cache | |
| 20:39:31 | mriedem | the _cleanup_volumes thing is definitely a gap in the compute cleanup code | |
| 20:39:34 | mriedem | if the volume is attached | |
| 20:39:48 | melwitt | yeah, seeing that | |
| 20:40:29 | melwitt | we're also missing a volume cleanup call for the InstanceNotFound block | |
| 20:40:44 | mriedem | well, | |
| 20:40:50 | mriedem | that means the instance was deleted concurrently | |
| 20:40:51 | mriedem | yeah? | |
| 20:41:03 | mriedem | which should go through the local delete in the API, or _shutdown_instance in the compute | |
| 20:41:51 | melwitt | yeah, concurrent | |
| 20:42:09 | melwitt | okay, just saw there's a cleanup ports call in there but no volumes call | |
| 20:42:58 | openstackgerrit | Merged openstack/nova stable/pike: Make sure that functional test triggered on sample changes https://review.openstack.org/536934 | |
| 20:43:07 | openstackgerrit | Merged openstack/nova master: Fix a comment in a notification functional test https://review.openstack.org/536262 | |
| 20:49:43 | mriedem | woot ^ should be able to start rechecking pike changes now too | |
| 20:50:25 | efried | jaypipes: All other things being equal, is there a reason you prefer a DELETE API over PUT {} ? | |
| 20:50:55 | melwitt | mriedem: how? did that resolve the libvirt keepalive timeout fails? | |
| 20:51:08 | mriedem | no | |
| 20:51:27 | mriedem | melwitt: you're right - it doesn't, need to backport the functional job timeout bump patch | |
| 20:51:29 | mriedem | want to propose that? | |
| 20:52:03 | melwitt | I can, but I was referring to the permafail of the cells v1 job on pike and ocata because of the libvirt keepalive timeout issue | |
| 20:52:38 | mriedem | melwitt: remember i removed the cellsv1 job from stable? | |
| 20:52:41 | melwitt | AFAIK we're still blocked on pike and ocata because of that | |
| 20:52:49 | melwitt | oh, I didn't know that. nevermind | |
| 20:52:58 | mriedem | https://review.openstack.org/#/c/538619/ | |
| 20:53:34 | mriedem | if we want that job back, i think we have to define it in-tree per-branch and make it non-voting on stable | |
| 20:53:55 | melwitt | cool ... wish we knew what the root cause was, but there were no real leads | |
| 20:54:53 | openstackgerrit | sean mooney proposed openstack/nova master: Change 'InstancePCIRequest' spec field https://review.openstack.org/449257 | |