Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-08
15:43:48 efried mriedem: Can we get a quick merge on --^ to help us unwind the mess described therein?
15:54:40 openstackgerrit Matt Riedemann proposed openstack/nova master: Make _instances_cores_ram_count() be smart about cells https://review.openstack.org/569055
15:54:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Add DownCellFixture https://review.openstack.org/614810
15:54:41 openstackgerrit Matt Riedemann proposed openstack/nova master: [WIP] Add os_compute_api:servers:create:cell_down policy https://review.openstack.org/614783
15:54:42 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657
15:56:33 mriedem melwitt: dansmith: i think https://review.openstack.org/#/c/569055/ is good to go and something we can backport to rocky - that's the one that limits counting instances/cores/ram to only cells in which the tenant has instances
15:57:36 melwitt efried: ack
15:57:39 melwitt mriedem: ack
15:58:09 openstackgerrit Ivaylo Mitev proposed openstack/nova master: VMware: Attach volumes using adapter type from instance https://review.openstack.org/616599
16:07:49 dansmith mriedem: so on that.. is there any reason we need to or should limit that based on config?
16:08:20 dansmith mriedem: because it doesn't really make sense to look at cells we think aren't going to have anything
16:08:41 mriedem maybe not
16:09:22 pvc hi anyone uses cyborg here?
16:11:04 melwitt dansmith: tssurya did that to avoid a useless lookup in the single cell case, similar to instance list
16:11:34 dansmith melwitt: we can look at the cell cache and know whether or not we have any more than one non-zero cell right?
16:13:55 tssurya mriedem thanks
16:14:05 melwitt maybe. I don't remember the details around the config option to avoid a "by project" check to save extra unneeded lookups if an operator is running only a single cell deployment
16:14:30 melwitt we had been thinking this would be the same situation
16:15:03 tssurya dansmith: yea, we did the config for listing to avoid the lookup so thought of doing the same here,
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 by which I meant
16:19:40 efried f
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 openstackgerrit Merged openstack/nova stable/rocky: Add regression test for bug 1797580 https://review.openstack.org/611938
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: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

Earlier   Later