| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-30 | |||
| 14:36:21 | cdent | I'm thinking that the positive way of looking at this is that the second _update has been masking a nasty bug for a long time | |
| 14:41:48 | mriedem | oh i'm not surprised that there would be a big pile of tight coupling tape holding this all together | |
| 14:42:05 | mriedem | and why i didn't want to merge that change before the GA | |
| 14:49:43 | bauzas | mriedem: again, the more I read, the more I think we possibly had the original problem once we had https://github.com/openstack/nova/commit/7b95b4d60726b6c8d0e0fe939c408a91ada79e0c | |
| 14:49:53 | bauzas | and .update() was just hiding it | |
| 14:50:12 | bauzas | mriedem: so, do you want me to modify the above and only set the values if not 0.0 ? | |
| 14:50:19 | bauzas | or are you working on this ? | |
| 14:52:34 | bauzas | disclaimer: looking at a long list of openstack-dev threads | |
| 15:00:27 | mriedem | Kevin_Zheng: yikun: you might be interested in https://review.openstack.org/#/c/591976/ | |
| 15:00:47 | mriedem | bauzas: i'm working it | |
| 15:00:59 | bauzas | okay | |
| 15:01:21 | Kevin_Zheng | Got it | |
| 15:02:31 | zigo | Nova 18.0.0 built, doing a recheck... | |
| 15:03:01 | openstackgerrit | Merged openstack/nova master: Fix soft deleting vm fails after "nova resize" vm https://review.openstack.org/546920 | |
| 15:04:36 | melwitt | . | |
| 15:16:00 | melwitt | stephenfin: on https://review.openstack.org/595592, if the bug is new for rocky, how did moshele run into it on OSP13 (queens)? | |
| 15:16:24 | stephenfin | melwitt: If he's using OSP, then it's because we backported it downstream | |
| 15:16:38 | stephenfin | Even if not, I'd imagine it's a feature backport | |
| 15:18:17 | melwitt | stephenfin: ohh, ok. I didn't think of that, backport of a feature | |
| 15:30:40 | mriedem | ? | |
| 15:30:40 | mriedem | efried: does any kind of nova/cyborg integration actually exist to do anything with servers in rocky/ | |
| 15:31:02 | mriedem | b/c https://docs.openstack.org/releasenotes/cyborg/rocky.html says it does | |
| 15:31:36 | mriedem | 1) rocky release notes talk about queens specs | |
| 15:31:47 | mriedem | 2) it sounds like "we completed specs" rather than "we have functioning code" | |
| 15:32:51 | Kevin_Zheng | mriedem: you made me laugh | |
| 15:33:43 | mriedem | i just don't want people showing up in -nova saying "hey why can't i attach fpgas to my vm?" | |
| 15:38:28 | efried | mriedem: No, cyborg has nothing in nova atm | |
| 15:38:46 | efried | oh, yeah, that's poorly worded. | |
| 15:41:16 | Kevin_Zheng | mriedem: we were talking today, about the batch when listing patch | |
| 15:42:24 | Kevin_Zheng | The batch size could vary depending on sort key and dir | |
| 15:42:44 | Kevin_Zheng | Like for sort with uuid | |
| 15:43:01 | Kevin_Zheng | It could be evenly distributed | |
| 15:43:24 | dansmith | Kevin_Zheng: you mean the *optimal* batch size? | |
| 15:43:40 | Kevin_Zheng | dansmith: yeah | |
| 15:44:40 | dansmith | Kevin_Zheng: obviously if you're sorting by uuid it should be fairly evenly distributes and sorting by other things could be massively less well-distributed, but I'm not sure how we could (efficiently) optimize that at runtime | |
| 15:44:45 | dansmith | Kevin_Zheng: do you have ideas? | |
| 15:45:00 | Kevin_Zheng | I was thinking a tool that analyzes dB data | |
| 15:45:16 | Kevin_Zheng | And feed to nova periodically | |
| 15:45:30 | Kevin_Zheng | But that seems to much :) | |
| 15:45:36 | dansmith | yeah :) | |
| 15:46:08 | dansmith | it likely varies by tenant, sort_key, cloud layout, scheduler weights, etc | |
| 15:46:17 | Kevin_Zheng | Just came up when we introduced the new approach to our product team | |
| 15:46:18 | dansmith | it'd be hard to pin that down except for a single-tenant cloud I think | |
| 15:46:55 | sean-k-mooney | mriedem: today i belive you can use cyborg to program a pci device and then you can use nova to pass it through via a pci passthrough flavor alisa but there is no way to force landing on the host with the device you just programed | |
| 15:46:57 | Kevin_Zheng | I’d say it is a powerful tool:) | |
| 15:47:33 | dansmith | Kevin_Zheng: if the goal is to get larger batches from cells likely to have many results, we could do things like scale up the batch size each time you hit a cell again | |
| 15:48:03 | dansmith | Kevin_Zheng: so that if your query is likely to get most results from one cell, we get $batch_size, then $batch_size*2, then $batch_size*4, etc | |
| 15:48:25 | dansmith | but I think I'd want to see a benchmark showing that as worthwhile before I approved it, | |
| 15:48:34 | Kevin_Zheng | Hmm | |
| 15:48:51 | Kevin_Zheng | That could be a good way | |
| 15:48:51 | dansmith | because I expect that since the db query time is so small compared to the processing time, I'm not sure it matters that much (even your hyper-optimized batch sizing tool :) | |
| 15:49:26 | Kevin_Zheng | Yeah, they are just guessing as always | |
| 15:49:49 | dansmith | Kevin_Zheng: yeah :D | |
| 15:50:27 | dansmith | Kevin_Zheng: it's common trap: One big optimization on batch size gives 60% improvement, so assume there are more 60% improvements to be gained through hyper-optimization :) | |
| 15:50:34 | openstackgerrit | Merged openstack/nova-specs master: VMware: add support for live migration https://review.openstack.org/598163 | |
| 15:59:27 | mriedem | leave some optimizations for the enterprise fellas | |
| 16:01:51 | mriedem | gibi: you were +2 on this before i robustified the test per mel's prodding https://review.openstack.org/#/c/588943/ | |
| 16:03:51 | Kevin_Zheng | maybe left some place for them to be able to do that, like a call to my powerful tool backend :P | |
| 16:04:53 | mriedem | is the toronto lab already working on that? | |
| 16:05:15 | mriedem | research people gotta get grant money somehow | |
| 16:05:37 | sean-k-mooney | mriedem: i will likely be fixing a few things in cyborg in the near future. do you want me to fix the releases note regarding nova inetgration | |
| 16:05:43 | mriedem | need i remind everybody https://www.openstack.org/videos/vancouver-2018/revisiting-scalability-and-applicability-of-openstack-placement-1 | |
| 16:05:58 | mriedem | sean-k-mooney: i guess? | |
| 16:06:05 | mriedem | revising release notes is sometimes a tricky business | |
| 16:06:47 | sean-k-mooney | well we update specs retroactivly i done really see release notes as any different | |
| 16:07:01 | mriedem | because release notes are built from git history | |
| 16:07:04 | mriedem | specs are not | |
| 16:07:17 | stephenfin | sean-k-mooney: Any reason we don't squash these? https://review.openstack.org/#/q/topic:bug/1759420+(status:open+OR+status:merged) | |
| 16:07:50 | sean-k-mooney | stephenfin: i wanted to specifcally demonstrate that the behavior was wrong | |
| 16:07:59 | sean-k-mooney | other then that no | |
| 16:08:05 | Kevin_Zheng | No, Xian lab can work on that:) | |
| 16:08:37 | stephenfin | sean-k-mooney: I'm guessing if we reverted the functional part then we'd see the test fail, right? Any chance you could squash them? | |
| 16:10:27 | sean-k-mooney | stephenfin: sure but i need to go get my car NCT tested so ill do it later this evening/tomorow | |
| 16:10:34 | stephenfin | sean-k-mooney: all good | |
| 16:10:41 | sean-k-mooney | anything else you want me to change while im doing it? | |
| 16:11:23 | sean-k-mooney | stephenfin: i might add mel's notes as comments too | |
| 16:11:47 | mriedem | mdbooth: are you ok with the wording here? https://review.openstack.org/#/c/596492/ | |
| 16:12:01 | sean-k-mooney | anyway got to run. | |
| 16:14:07 | cdent | sean-k-mooney: my MOT (which I guess is the same thing) is tomorrow and it's almost certainly going to fail | |
| 16:18:14 | stephenfin | sahid: I've still got open comments on https://review.openstack.org/#/c/532168/ | |
| 16:27:51 | stephenfin | lyarwood: Can I move this to MODIFIED too? I'm not sure what the process is for non-hotfixes as I didn't have to kick off any builds myself https://bugzilla.redhat.com/show_bug.cgi?id=1187945 | |
| 16:27:52 | openstack | bugzilla.redhat.com bug 1187945 in openstack-nova "[RFE] Take into account NUMA locality of physical NICs when plugging instance VIFS from Neutron networks" [Urgent,Post] - Assigned to sfinucan | |
| 16:29:06 | mnaser | so i never ended up doing the full clean up from the stale cell stuff | |
| 16:29:37 | mnaser | but if i have instances with an instance_mapping entry, no build_request, they don't exist in any cells (cell0 or anything else), i can just drop the instance_mapping entry to get rid of it from the listing? | |
| 16:29:58 | lyarwood | stephenfin: ^_^ | |
| 16:30:16 | dansmith | mnaser: yeah | |
| 16:30:17 | dansmith | mnaser: that should be the case for any instances you've deleted and then purged from the db | |
| 16:30:18 | dansmith | if you've done that | |
| 16:30:39 | mnaser | dansmith: yeah they're not even purged, cell_id = NULL too | |
| 16:30:39 | dansmith | recently archive started nuking the BR at least | |
| 16:30:41 | dansmith | not sure about the mapping | |
| 16:30:55 | dansmith | oh okay well, if they're really gone there's no need for the mapping | |
| 16:30:59 | stephenfin | lyarwood: 🙈 | |
| 16:31:11 | mnaser | this was a whole thing related to the adding entries into nova_api in a single transaction | |
| 16:31:27 | mnaser | which i think i put a patch that i *think* works but i dont know how to test that it works in a single transaction | |
| 16:32:23 | mnaser | https://review.openstack.org/#/c/586824/1 was supposed to be backportable interim solution to avoid listing stuff that shouldnt be there and https://review.openstack.org/#/c/586742/2 was the more fundamental fix but i havent had time to look over them more | |
| 16:42:17 | melwitt | sahid: your review would be appreciated on this bug fix for handling disk_bus for root disk https://review.openstack.org/584999 | |
| 16:42:45 | sahid | stephenfin: surprising that it I did not noticed them :) | |
| 16:43:26 | sahid | melwitt: sure i will do that | |
| 16:43:32 | melwitt | thanks | |