Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-08
14:34:08 mriedem bauzas: you were +2 on this https://review.openstack.org/#/c/610034/ - if you still are I guess we should get that in so we can move the mirrored placement change forward
14:34:40 kashyap mriedem: About the 'virsh capabilities' ping you made last night, I see that's resolved as to what tssurya was looking for.
14:35:31 tssurya kashyap: hi, yes thanks we found out the code and as suspected it was adding the offline cpus as well
14:36:34 kashyap Hi; cool. (My "waking hours" are in the CET timezone)
14:48:36 frickler aarents: we are affected by https://bugs.launchpad.net/nova/+bug/1801702 and your patch works fine for us, too. just needed to find the correct location for that function in pike. do you want to submit it yourself to upstream? otherwise I'd push it and add you as co-author
14:48:36 openstack Launchpad bug 1801702 in OpenStack Compute (nova) "Spawn may fail when cache=none on block device with logical block size > 512" [Undecided,New]
14:49:18 frickler nova bug triagers: ^^ that bug is critical for us, please assign some importance
15:01:25 mriedem frickler: done
15:01:33 sean-k-mooney frickler: 4k sectore are becomming more common even when not using nvme so yes this should be fixed
15:01:56 mriedem i suggested trying in order from largest to smallest
15:02:13 mriedem could be a config option i guess....but that seems unnecessary
15:03:07 sean-k-mooney mriedem: perhaps that said i was under the impression there was a way to ask the device for its native alingment so we might be able to discover it
15:03:17 frickler 4096 should always work since it is a multiple of 512, but I'm not 100% sure about other possible regressions
15:04:42 sean-k-mooney frickler: alot of 512 driver these days are actully 4096 with 512 sector emulation
15:05:17 sean-k-mooney frickler: i do know that older windows versions ran slower/ had issue with 4k native boot media
15:12:02 openstackgerrit Jens Harbott (frickler) proposed openstack/nova master: Make supports_direct_io work on 4096b sector size https://review.openstack.org/616580
15:12:14 jroll kashyap: thanks!
15:14:46 mriedem alex_xu: replied to you in https://review.openstack.org/#/c/615341/ - i have a goal in what i'm cleaning up so i'm not sure how much we should pack into each change, versus me just doing follow ups
15:22:36 aspiers mriedem, gibi: I'm reasonably optimistic that https://review.openstack.org/#/c/609779/14 can be the final patchset :-)
15:28:35 gibi aspiers: I've opened your patch for rereview
15:32:44 mriedem aspiers: i just need to go over it again, been busy this week before the summit
15:35:43 aspiers thanks both! hopefully nothing controversial since your last reviews :)
15:38:37 mriedem i can't remember my last review on it
15:38:41 mriedem except concerns about move operations
15:39:01 aspiers according to Gerrit it was on patch set 7
15:41:12 mriedem tssurya: https://review.openstack.org/#/c/569055/ needs work - i can update it quick though
15:41:17 mriedem since the changes needed are pretty minor
15:42:50 openstackgerrit Martin Midolesov proposed openstack/nova master: VMware: Expose esx hosts to Openstack https://review.openstack.org/613626
15:42:51 openstackgerrit Martin Midolesov proposed openstack/nova master: [vmware] Cross vCenter live migration https://review.openstack.org/616590
15:43:23 openstackgerrit Eric Fried proposed openstack/nova master: Cap oslo.service to 1.32.0 (temporarily) https://review.openstack.org/616591
15:43:34 efried bnemec, melwitt: ^
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

Earlier   Later