| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-08 | |||
| 17:59:52 | sean-k-mooney | nicolasbock: can you paste a copy of the error to paste.openstack.org | |
| 18:00:00 | sean-k-mooney | nicolasbock: yes | |
| 18:00:51 | sean-k-mooney | nicolasbock: nova enforces that the virtual size the disk could grow too is <= the disk in the flavor | |
| 18:01:01 | nicolasbock | sean-k-mooney (IRC): http://paste.openstack.org/show/734437/ | |
| 18:01:51 | sean-k-mooney | ya so in that case the image seams to be larger then the flavor allows | |
| 18:02:44 | sean-k-mooney | nicolasbock: it looks like you tried to boot a 65GiB image on a 50GiB flavor | |
| 18:03:05 | nicolasbock | The partition inside the image is 80GiB large though | |
| 18:03:22 | nicolasbock | I mean not that I am arguing with Nova here I am just saying that the error message was confusing to me :) | |
| 18:04:34 | sean-k-mooney | strang well the error is clearly showing the glance value it might check both | |
| 18:05:12 | nicolasbock | Ok, as long is this is expected behavior I am good. I was just expecting something else :) | |
| 18:05:39 | sean-k-mooney | the behavior looks correct to me. out of interest what were you expecting | |
| 18:05:55 | sean-k-mooney | was it 80GiB is lager then 50GiB | |
| 18:06:02 | nicolasbock | I was expecting the size of the unpacked disk | |
| 18:06:31 | efried | mriedem: Does deleting the compute service today delete the provider in placement? | |
| 18:06:47 | sean-k-mooney | i would guess we have an optimization that checks the glance size first sice we already have that before actully checking the size of the file which would require downloading it | |
| 18:07:30 | sean-k-mooney | nicolasbock: the glance vs flavor check can happen at the api level the actual size can only happen on the compute nodes | |
| 18:07:58 | nicolasbock | Ok that's a good point | |
| 18:08:10 | nicolasbock | I am going to resize the FS and the disk of that qcow2 | |
| 18:08:52 | nicolasbock | sean-k-mooney (IRC): Thanks for the help! | |
| 18:08:56 | sean-k-mooney | nicolasbock: if you flavor allowsed 70Gib then it would likely pass the api check and hit the compute node check | |
| 18:09:10 | sean-k-mooney | nicolasbock: no worries | |
| 18:09:16 | nicolasbock | But it would blow up then, no? | |
| 18:09:24 | sean-k-mooney | yes just much later | |
| 18:09:26 | nicolasbock | There is another check on the compute node? | |
| 18:09:29 | nicolasbock | Ok | |
| 18:09:37 | nicolasbock | Thanks! | |
| 18:22:10 | openstackgerrit | Merged openstack/nova stable/rocky: Don't persist RequestSpec.requested_destination https://review.openstack.org/611939 | |
| 19:05:23 | melwitt | mriedem: should we remove use-nested-allocation-candidates from the runway now? I noticed that it seemed to morph into bandwidth-resource-provider | |
| 19:45:34 | jmlowe | Has anybody had problems with instances getting multiple placement allocations? | |
| 19:59:44 | mriedem | efried: yes the api attempts to delete the resource provider when a compute service is deleted | |
| 20:00:33 | mriedem | melwitt: idk about that use-nested-alloc-candidates bp, or what's left, probably need to ask gibi/tetsuro | |
| 20:01:44 | melwitt | mriedem: yeah, I'll ask gibi. thanks | |
| 20:15:15 | mriedem | efried: is https://review.openstack.org/#/c/616371/ expected to be failing? | |
| 20:18:17 | mriedem | yay https://review.openstack.org/#/c/614489/ - hopefully we don't have to do the same dance in stable/rocky, but we probably will if the requirements team ever wants to increase the upper-constraint on oslo.service in rocky | |
| 20:21:30 | mriedem | efried: melwitt: ok i'm +2 on those two nova changes | |
| 20:22:21 | melwitt | thank ya | |
| 20:22:35 | mriedem | i'm not sure why https://review.openstack.org/#/c/616371/ is failing though | |
| 20:22:49 | mriedem | oh i see, | |
| 20:22:51 | mriedem | it needs https://review.openstack.org/#/c/615724/ | |
| 20:22:58 | mriedem | but that depeneds on 616731 | |
| 20:23:02 | mriedem | *371 | |
| 20:23:07 | mriedem | so we just need to land the nova changes | |
| 20:23:18 | mriedem | well... | |
| 20:23:39 | mriedem | but the top nova change can't land w/o that requirements dependency, which is failing b/c the code is still mocking the removed thing | |
| 20:24:12 | melwitt | yeah :/ | |
| 20:24:16 | melwitt | efried halp | |
| 20:24:54 | efried | melwitt: o/ Sorry, was getting a CT of my face. Took an elbow yesterday. (Don't worry, I'm sure it'll still be rainbow-colored next week for ya) | |
| 20:25:18 | melwitt | damn, sorry to hear that | |
| 20:25:23 | melwitt | hope you are ok | |
| 20:26:00 | efried | I'll know more in an hour. Hopefully no orbital/sinus fractures. | |
| 20:26:07 | efried | so, that bizarre requirements chain... | |
| 20:26:09 | efried | checking... | |
| 20:29:05 | efried | Three out of four are passing zuul, but https://review.openstack.org/#/c/616371/ isn't, and it's the cross-nova check that's being pooty... | |
| 20:29:56 | efried | melwitt, mriedem: Heading back to the requirements channel to pick this up... | |
| 20:46:15 | mriedem | dansmith: replied in https://review.openstack.org/#/c/569055/ for a case in which i think it makes sense to only ever count quota for cells in which the project has instances | |
| 20:46:58 | openstackgerrit | Merged openstack/nova master: Fix support matrix for VMware UEFI support https://review.openstack.org/615870 | |
| 20:47:38 | dansmith | mriedem: yeah, that's what I was saying | |
| 20:48:01 | dansmith | mriedem: we could still ignore the failed cell 5 in your example and let the create continue, but we'd have sat around waiting for it for no reason | |
| 20:50:25 | mriedem | in order to ignore it though, we'd have to determine if the project has instances in that cell, right? which means doing the instance mapping by project_id lookup anyway | |
| 20:50:29 | melwitt | nova meeting in 10 min | |
| 20:50:34 | dansmith | mriedem: yep | |
| 20:50:42 | mriedem | so we might as well just always do that | |
| 20:50:48 | dansmith | mriedem: this is my point | |
| 20:51:16 | melwitt | yeah, I think I got confused by the other instance list check where we could save on pruning cells if there's only one cell | |
| 20:51:16 | mriedem | in the case of a cloud that's not multi-cell, do we care about optimizing this? | |
| 20:51:49 | dansmith | mriedem: yeah you could filter out cell0 from the cache and if the result is only one avoid the lookup | |
| 20:51:49 | melwitt | I had thought there was a config option for avoiding that for single cell. and confused it with the quota situation | |
| 20:52:08 | mriedem | instances in cell0 still count against your quota though | |
| 20:52:11 | mriedem | i'm pretty sure | |
| 20:52:13 | melwitt | yeah they do | |
| 20:52:19 | melwitt | error instances, for example | |
| 20:52:32 | dansmith | yeah, I know, | |
| 20:52:35 | melwitt | oh, but you're saying don't count cell0 | |
| 20:52:36 | melwitt | yeah | |
| 20:52:53 | dansmith | so you could also just say len(cache)==2, but.. checking that there is only one non-cell0 cell seems like a better assertion | |
| 20:53:34 | mriedem | wfm | |
| 20:53:41 | dansmith | other things would be wrong if those weren't the same, for sure, it just seems more of a positive thing | |
| 20:53:42 | dansmith | but that's just a detail, either way that optimization is easy | |
| 20:53:55 | melwitt | yeah. we could have a "is_single_cell" method. though I wonder how that works before the cache has been populated. I guess we know it has been before quota checks happen? | |
| 20:54:21 | dansmith | if the cache isn't populated then we have to populate it before we look at the cache | |
| 20:54:25 | dansmith | that's how all that code works | |
| 20:54:37 | melwitt | ok | |
| 20:54:43 | dansmith | so is_single_cell() makes a _load_cells() call first | |
| 21:05:24 | artom | This is weird, why is conductor failing with 'CantStartEngineError: No sql_connection parameter is established' | |
| 21:06:34 | mriedem | artom: it's trying to hit the API DB | |
| 21:06:36 | mriedem | and not configured for it | |
| 21:06:39 | mriedem | if you're using devstack | |
| 21:06:45 | mriedem | the cell conductor that is | |
| 21:06:54 | artom | mriedem, that's exactly it, it's almost creey ;) | |
| 21:07:12 | mriedem | e.g. resize fails on compute1, casts back to cell conductor which looks up the instance mapping and kablamo | |
| 21:07:14 | mriedem | known issue | |
| 21:07:19 | artom | It's a reschedule, the (presumably cell) conductor is trying to get the AZ | |
| 21:07:33 | mriedem | yup, i know the bug | |
| 21:07:35 | mriedem | sec | |
| 21:08:02 | mriedem | artom: linked from https://blueprints.launchpad.net/nova/+spec/fix-reschedule-up-calls | |
| 21:08:14 | mriedem | i have a fix for one of those | |
| 21:08:17 | mriedem | discussed at the ptg | |
| 21:08:17 | artom | Thanks :) | |
| 21:08:25 | openstackgerrit | Jack Ding proposed openstack/nova master: Add cache=none option for qemu-img convert https://review.openstack.org/616692 | |
| 21:08:31 | mriedem | the other, the one you're hitting, is a bigger change b/c we have to pass the azs down to the cell | |