Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-08
13:27:59 bauzas pbd'ing
13:29:30 sean-k-mooney bauzas: my understanding was we relied on the filters to check the host did not already have a member of the server group on the host in that case so the late check is not need however i belive there is a race when doing multiple live migration or booting more instnaces into the server group that was not handeled correct
13:32:13 bauzas sean-k-mooney: no, it's not a concurrent issue
13:32:31 bauzas sean-k-mooney: I guess the problem is about the persisted RequestGroup
13:32:44 bauzas oops s/RequestGroup/RequestSpec
13:33:01 bauzas AFAICS, the instancegroup.members is wrong
13:33:07 bauzas anyway
13:33:13 bauzas I'll continue to look
13:33:14 sean-k-mooney bauzas: do you have a functional test that can reporduce?
13:34:05 sean-k-mooney i have a couple of small patches i need to work on but i can try and help later once i get them written/pushed
13:34:51 sean-k-mooney i have other stuff i need to work on but i could also do with a break/context switch for a few hours so if i can help let me know.
13:35:27 bauzas I also have to go in a garage
13:35:31 bauzas see you in 1h
13:35:59 sean-k-mooney o/
13:47:55 jroll kashyap: when you have a few minutes, curious your thoughts on this: https://review.openstack.org/#/c/616405/
13:48:02 kashyap jroll: Hi
13:48:16 jroll hi :)
13:48:51 kashyap Let me check w/ the libvirt upstream folks
13:50:21 kashyap jroll: I'd expect the reporter to also note what precise failure they're seeing
13:50:24 kashyap Let me ask on the change
13:51:38 jroll kashyap: good point
13:52:11 kashyap Asked on the change.
14:18:01 openstackgerrit Vlad Gusev proposed openstack/nova stable/queens: De-dupe subnet IDs when calling neutron /subnets API https://review.openstack.org/616551
14:19:21 dansmith mriedem: good for me to just double-ack this series from two stable cores? https://review.openstack.org/#/c/612496
14:20:49 mriedem yeah
14:22:20 maciejjozefczyk mriedem: stephenfin johnthetubaguy PTAL https://review.openstack.org/#/c/591607
14:23:51 mriedem s10 (vlad) should probably look at that again to make sure he's happy with it
14:26:57 mriedem dansmith: if you're in that stable kind of mood https://review.openstack.org/#/q/topic:bug/1797580+(status:open+OR+status:merged)
14:27:41 mriedem this has probably hung around too long as well https://review.openstack.org/#/q/topic:bug/1746863+status:open
14:28:11 dansmith no good deed, eh?
14:30:53 maciejjozefczyk mriedem: right, I don't know his nick or he's simply off (s10)
14:33:00 mriedem must be off
14:33:11 mriedem dansmith: you are rewarded with more reviews
14:34:00 kashyap jroll: BTW, I agree with you there; added a comment in the change
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/)

Earlier   Later