Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-05-02
15:05:40 melwitt mriedem: also, thanks for swapping the runway blueprint. I forgot to do it last night
15:06:18 mriedem melwitt: re the rebuild + required image traits thing, at this point for simplicitly i'd probably just concede to the idea of failing in the api if the new image has required traits which aren't in the original image used to create the server
15:06:34 mriedem and then hope that no one ever asks to support that later
15:06:39 mriedem and if they do, you're no longer working on nova
15:07:52 melwitt based on my limited understanding of traits, I don't immediately see why the original image is tied to rebuilding with a new image and why it would need to reject it. so I shall read the thread to learn why :P
15:10:05 cfriesen__ sean-k-m1: sean-k-mooney[m]: do you know the current status of https://blueprints.launchpad.net/nova/+spec/sriov-physical-function-passthrough (where a device can be allocated as either a VF or the full PF)
15:11:37 mriedem melwitt: b/c the host the instance is running on during rebuild is filtered using the original image and it's required traits
15:12:59 melwitt oh, right, because rebuild can't move
15:13:02 melwitt I see
15:26:05 openstackgerrit Stephen Finucane proposed openstack/nova master: Deprecate the nova-consoleauth service https://review.openstack.org/565367
15:28:15 efried stephenfin: You gonna go around and change all the other deprecations in the docs? There were about a dozen I counted yesterday.
15:31:09 stephenfin efried: I can but where?
15:31:56 efried stephenfin: I went and looked for them yesterday. I can go find 'em again.
15:32:06 efried stephenfin: But I guess if I'm gonna do that, I may as well fix 'em myself :)
15:33:19 shewless Hi there. I have an instance which is allocated 2GB of RAM but when I look at the qemu process it looks like it's comsuming closer to 8GB of RAM. This is a huge discrepency. Can anyone help me figure out what's going on?
15:33:34 shewless It kind of looks like we are seeing an extra 6GB of memory usage (over what's been allocated) PER instance?
15:35:55 stephenfin efried: That...would make sense, yes :)
15:36:10 shewless I thought that in general a qemu process would use less or equal to what's been provisioned for that instance. Is that wrong?
15:38:30 efried # rgrep -i deprecated doc/source | awk -F: '$1 ~ /rst$/'
15:38:30 efried stephenfin: This produced 29 results, which will need to be inspected manually to see if a .. deprecated:: marker is actually appropriate:
15:42:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove IronicHostManager and baremetal scheduling options https://review.openstack.org/565805
15:42:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove [scheduler]/host_manager config option https://review.openstack.org/565806
15:42:35 mriedem jroll: ^
15:42:44 jroll woot
15:43:04 sahid shewless: we know that there are some kind of overheads depending of the number of vCPUs, devices... but 6GB looks crazy, perhaps you should ask #virt in OFTC servers with the exact arguments you are passing to QEMU
15:43:53 shewless sahid thanks I'll check there
15:45:02 openstackgerrit sahid proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820
15:45:03 openstackgerrit sahid proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514
15:45:04 openstackgerrit sahid proposed openstack/nova master: pci: don't consider case when match tags specs https://review.openstack.org/565808
15:50:54 efried stephenfin: That deprecated role ain't especially pretty IMO.
15:51:12 stephenfin In what regard?
15:51:59 efried let's see if your delta has rendered yet...
15:53:11 efried stephenfin: http://logs.openstack.org/67/565367/9/check/build-openstack-sphinx-docs/c46fab1/html/cli/nova-consoleauth.html
15:53:28 efried stephenfin: I guess I was expecting a box, like .. note::
15:53:33 openstackgerrit Jay Pipes proposed openstack/nova-specs master: update add-consumer-generation to focus on API https://review.openstack.org/565565
15:53:34 efried stephenfin: It's aight, I suppose.
15:53:34 sahid cfriesen__ it's implemented
15:56:45 stephenfin efried: Yeah, that's openstackdocstheme. Wonder what the reasoning for that was
15:57:27 efried stephenfin: I'm sure it's related to it never being used, but I wonder if it's cause or effect :)
15:59:02 stephenfin efried: Could be. I thought oslo.config used it but it actually uses '.. warning' too. I should fix that https://docs.openstack.org/nova/queens/configuration/config.html
15:59:15 openstackgerrit Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371
16:05:04 openstackgerrit Eric Fried proposed openstack/nova master: Use .. deprecated:: theme for deprecations https://review.openstack.org/565822
16:05:06 efried stephenfin: Here it is ^ but I'll probably abandon it, unless we want to fix the theme to make it prettier.
16:10:08 jroll jaypipes: do you know if we need to report these as zero, or can we just drop them all? https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L764
16:13:04 evrardjp mriedem: thanks for the patch in OSA :)
16:14:35 jroll jaypipes: ah, I think unit tests answered that for me, never mind. :)
16:16:50 mriedem evrardjp: np
16:20:03 arvindn05 mriedem: replied back to the thread on rebuild with image traits. Will look for further update from melwitt or dansmith
16:20:55 mriedem evrardjp: s/OSA/literally everything/ +(status:open+OR+status:merged)
16:20:59 mriedem https://review.openstack.org/#/q/topic:exact-filters+(status:open+OR+status:merged)
16:22:26 evrardjp mriedem: I haved guessed that ;)
16:22:32 evrardjp mriedem: but still thank you.
16:22:40 evrardjp :D
16:22:46 arvindn05 mriedem: i think we are on the same page in case we choose to reject the request at the API layer. the spec had the same intent
16:23:03 EmilienM mriedem: thanks for https://review.openstack.org/#/c/565824/ - I took over, just see my comment for the FYI
16:24:07 arvindn05 > If the image's required traits have changed from the original image, we can reject the rebuild request. Effectively, since the qualitative requirements have changed the user should create a new instance.
16:24:08 arvindn05 https://review.openstack.org/#/c/560718/6/specs/rocky/approved/glance-image-traits.rst - line 100. I will make it more clear like i did in the ML
16:25:51 mriedem EmilienM: ack thanks
16:26:40 mriedem EmilienM: i suspect the depends-on is backward anyway for any of these deployment projects that gate on ironic, which tripleo does?
16:26:58 mriedem but i didn't want the nova change depending on 20 random other deployment projects
16:27:04 EmilienM mriedem: yeah it's fine
16:38:26 openstackgerrit Arvind Nadendla proposed openstack/nova master: update scheduler to use image-traits https://review.openstack.org/560596
16:46:34 openstackgerrit Jim Rollenhagen proposed openstack/nova master: Ironic: report 0 for vcpus/memory_mb/disk_gb resources https://review.openstack.org/565841
16:46:48 jroll mriedem: one more in your ironic chain for you ^
16:51:18 mriedem question inline
16:53:24 jroll ah thanks
16:56:42 mriedem dansmith: so for this CLI to fix allocations in placement for instances scheduled using the CachingScheduler, i'm trying to think where that should live, since none of the nova-manage subcommands really fit that; we could do something like,
16:56:47 mriedem a) nova-manage placement ...
16:56:54 mriedem b) placement-manage ...
16:56:57 mriedem c) throw it in osc-placement
16:57:09 mriedem although (c) isn't really meant for something like this
16:57:20 dansmith yeah, it's a pretty oddball thing
16:57:30 mriedem we're fixing allocations for nova instances,
16:57:33 dansmith it's also a placement client sort of thing, so it's weird to have it in nova-manage,
16:57:36 mriedem so thinking: nova-manage placement fix_allocations
16:57:40 dansmith but placement-manage would be the opposite
16:58:06 mriedem right, we need the instance uuid to find it's host/node to get the node uuid to find the resource provider it should have allocations against
16:58:13 dansmith mriedem: maybe we need a generic nova-manage group, like "nova-manage fix-our-mess" or "nova-manage maintenance ..."
16:58:17 mriedem so doing instance lookups from a placement-manage is weird
16:58:56 dansmith could use that generic group for syncing aggregate membership, fixing cinder attachments (historically)
16:59:25 mriedem jaypipes: where were you going to throw the nova-manage sync CLI for aggregates?
16:59:37 dansmith mriedem: wherever you tell him to
16:59:38 dansmith :P
17:00:29 mriedem was just wondering if his gears were grinding on that yet
17:03:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove [scheduler]/host_manager config option https://review.openstack.org/565806
17:03:50 mriedem i'm partial to 'nova-manage placement ...'
17:03:59 mriedem but don't care too much
17:04:02 mriedem gonna get lunch
17:04:20 dansmith melwitt: mriedem: tssurya: I've been completely covered up in other stuff for the last week.. I have nothing cellsy to talk about, unless the cern peeps have things to report?
17:04:35 dansmith mriedem: well, I just don't know that we'll have enough in there to justify the group, but whatever you want
17:05:13 mriedem dansmith: we'll have at least 2 things, this and jay's sync aggs thing
17:05:20 mriedem i don't have any cells stuff to talk about
17:07:07 tssurya dansmith: not really except that we moved to cellsv2, and basic operations take more time than for cellsv1 , we are trying to optimize whatever possible, but since belmiro won't be around today as its a Euro unfriendly meeting timing, we can give the overall experience in the next week's meeting
17:07:56 dansmith tssurya: okay, yeah would be good to hear an analysis of what takes longer so we can think about what to do
17:08:27 tssurya dansmith: yep
17:09:00 dansmith cellsv1 cheated with cache coherency, so not surprising that some things will take longer to be correct ;)
17:09:43 tssurya dansmith: haha, yea I get it but querying to all 70 DBs versus top cell having all info is also the toll maybe
17:09:59 dansmith tssurya: you guys are on pike yeah?
17:10:10 tssurya dansmith: skipped pike, moved straight to queens :)
17:10:17 tssurya from ocata

Earlier   Later