| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-08 | |||
| 16:15:15 | tssurya | (sorry leaving office now..) | |
| 16:15:44 | dansmith | melwitt: tssurya yeah I was thinking the instance list thing had more distinction than just the "could be running one cell" | |
| 16:15:45 | dansmith | like, | |
| 16:16:00 | dansmith | if you have multiple cells but you don't keep people to a single cell, | |
| 16:16:09 | dansmith | then getting the mappings every time they do a list is pointless | |
| 16:16:23 | dansmith | I guess it's similar for quota | |
| 16:16:54 | dansmith | but quota would be a check on boot, which is less often than list, which could be getting hit really hard in a polling loop | |
| 16:16:57 | melwitt | oh, right, it was to save on pulling mappings | |
| 16:17:12 | dansmith | anyway, just struck me as less sane to have that be configurable for the quota one | |
| 16:19:22 | mriedem | efried: zuul failed | |
| 16:19:35 | efried | y | |
| 16:19:40 | efried | f | |
| 16:19:40 | efried | by which I meant | |
| 16:20:45 | efried | ahjeez. More chicken/egg. | |
| 16:27:43 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: [WIP] libvirt: Add a default Virtio RNG device to guests https://review.openstack.org/616603 | |
| 16:30:09 | efried | melwitt, mriedem: See https://review.openstack.org/616604 <== this will come first; then the nova cap (https://review.openstack.org/616591) then the u-c bumps (https://review.openstack.org/#/c/615676/ and/or https://review.openstack.org/#/c/616371/, but at least the latter) then melwitt's actual fix (https://review.openstack.org/#/c/615724/) | |
| 16:37:32 | openstackgerrit | Eric Fried proposed openstack/nova master: Cap oslo.service to 1.32.0 (temporarily) https://review.openstack.org/616591 | |
| 17:02:32 | efried | melwitt, mriedem: btw, we're discussing this in openstack-requirements if you're interested in following along. | |
| 17:05:36 | openstackgerrit | Eric Fried proposed openstack/nova master: Use SleepFixture instead of mocking _ThreadingEvent.wait https://review.openstack.org/615724 | |
| 17:07:28 | openstack | bug 1797580 in OpenStack Compute (nova) rocky "NoValidHost during live migration after cold migrating to a specified host" [High,In progress] https://launchpad.net/bugs/1797580 - Assigned to Matt Riedemann (mriedem) | |
| 17:07:28 | openstackgerrit | Merged openstack/nova stable/rocky: Add regression test for bug 1797580 https://review.openstack.org/611938 | |
| 17:08:31 | openstackgerrit | Eric Fried proposed openstack/nova master: Use SleepFixture instead of mocking _ThreadingEvent.wait https://review.openstack.org/615724 | |
| 17:10:28 | efried | ah, rats, forgot to remove the g-r exclusions... | |
| 17:56:29 | nicolasbock | Hi, when creating a server from an image with a flavor that has a disk of 50 GiB I am told that the the image size is too large. I am quoted the actual file size of the qcow2 file and not the size of the partition on that image. | |
| 17:56:44 | nicolasbock | Did I misunderstand the meaning of disk in flavor? | |
| 17:57:11 | nicolasbock | I assumed that it's referring to the disk size, i.e. that it should relate to the disk that's encoded in the qcow2. | |
| 17:57:17 | sean-k-mooney | nicolasbock: glance shows the actual file size | |
| 17:57:40 | nicolasbock | But isn't it Nova that's complaining? | |
| 17:57:50 | sean-k-mooney | glance has extra metadata to store the minium required disk space to unpack the image | |
| 17:58:12 | nicolasbock | So the qcow2 is unpacked? | |
| 17:58:24 | sean-k-mooney | nicolasbock: the nova flavor disk attribute is the size the qcow will be unpacked too | |
| 17:58:42 | sean-k-mooney | nicolasbock: if the qcow file system is bigger nova will complain | |
| 17:58:59 | sean-k-mooney | nova is allowed to expand the disk but not srink it | |
| 17:59:15 | nicolasbock | Ok, I get that sean-k-mooney (IRC) , but the error message is quoting the file size of the qcow2 image and not the size of the unpacked FS | |
| 17:59:45 | nicolasbock | sean-k-mooney (IRC): you are saying that the disksize inside the image should be <= the disk size of the flavor? | |
| 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? | |