Earlier  
Posted Nick Remark
#openstack-nova - 2018-12-05
16:32:25 cfriesen sean-k-mooney: regarding https://review.openstack.org/#/c/620959/, I believe the traits are already defined as part of https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/report-cpu-features-as-traits.html
16:32:47 mdbooth gibi: Problem is I can't prove it. I spent time this morning looking at a profiler and I can see a couple of opportunities for making that test slightly faster, but if I guessed wrong it's just going to be merge ping-pong.
16:33:50 mdbooth gibi: The other thing, of course, would be to increase the timeout.
16:36:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Add ratio online data migration when load compute node https://review.openstack.org/613499
16:36:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Add compute_node ratio online data migration script https://review.openstack.org/609995
16:36:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Note the aggregate allocation ratio restriction in scheduler docs https://review.openstack.org/620713
16:36:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Add docs for (initial) allocation ratio configuration https://review.openstack.org/622588
16:36:48 mriedem dansmith: done ^
16:39:06 dansmith mriedem: got 'em
16:39:15 mriedem thanks
16:39:25 mriedem approving the non-docs changes
16:40:02 mdbooth mriedem: What do you think would be acceptable criteria for re-proposing that patch, btw?
16:40:17 mriedem the racy test?
16:40:29 dansmith mriedem: I'll look at the following ones in a bit
16:40:37 mriedem dansmith: thanks
16:40:42 mdbooth mriedem: Yeah.
16:40:47 mriedem mdbooth: idk, maybe not using mocks/stubs on the libvirt driver in functional tests?
16:41:00 mriedem like i said, might be better to subclass the libvirt driver and override what you need
16:41:04 mdbooth mriedem: I suspect the *race* is against a slow test worker.
16:41:19 mdbooth I can't see any evidence of an ordering thing.
16:41:24 mriedem could also add the REQUIRES_LOCKING = True variable, but i don't know if that will help anything
16:41:42 mdbooth Which isn't to say that it's not an ordering thing, but without being able to reproduce it we're really just trying stuff.
16:41:52 mdbooth So... when have we tried enough stuff?
16:41:58 mriedem just, doing file i/o and mocks and such in a functional test like that with a real driver - i'm not really surprised there were side effects
16:42:07 mriedem mdbooth: i can't answer that
16:42:16 mdbooth mriedem: Me neither :/
16:42:57 mdbooth However, like I say I don't see any evidence of side effects, or globals, or anything like that.
16:43:23 mdbooth The failures look like it was just too slow to me.
16:43:30 mdbooth I can post performance improvements.
16:45:26 efried My boss just made me look at my remaining vacation time for the year. Turns out... I'm gone until January, starting this afternoon. melwitt mriedem Sundar edmondsw FYI.
16:45:43 mdbooth efried: \o/
16:45:43 aspiers efried: whoa nice, enjoy ;-)
16:45:54 efried :) thanks
16:46:02 lbragstad mriedem yan0s fwiw - i keystone doesn't either, but i can't really think of a reason not to?
16:46:20 lbragstad s/i//
16:46:20 mriedem lbragstad: perf?
16:46:32 melwitt efried: thanks for the heads up. enjoy your time off :)
16:46:52 mriedem efried: ack
16:46:57 lbragstad mriedem possibly - i could time it
16:47:09 mriedem efried: i'll just rebase and abuse any changes of yours that i need
16:47:24 efried mriedem: It would be easier just to merge them right now.
16:47:43 mriedem bah
16:47:55 mriedem my queue is already deep and i haven't started on either of the 2 things i said i'd do today
16:49:25 Sundar efried: Have fun and Happy Holidays!
16:49:31 efried Thanks
16:51:25 openstackgerrit Eric Fried proposed openstack/nova master: Add cyborg client to requirements https://review.openstack.org/623026
16:51:25 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Cyborg PCI handling https://review.openstack.org/623027
16:56:36 yan0s No I definitely needed to change the nova.conf
16:56:50 yan0s I was restarting the service in every try
16:57:11 yan0s @lbragstad
16:57:20 yan0s @mriedem
16:58:19 mriedem hmm, well i'm stumped then
16:58:20 lbragstad yeah - by default, oslo.policy isn't going to reload policy files on disk
16:58:44 mriedem lbragstad: but they shouldn't have had to explicitly configure nova.conf with [oslo_policy]/policy_file = policy.json
16:58:49 mriedem since that's the default in code
16:59:12 mriedem anyway, probably just something i'd need to mess with in devstack to see if i can recreate it
16:59:23 lbragstad this sounds like two different issues
17:03:19 lbragstad yan0s if you're in #openstack-oslo this might be more relevant to talk about there
17:07:57 openstackgerrit Eric Fried proposed openstack/nova master: Add cyborg client to requirements https://review.openstack.org/623026
17:07:58 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Cyborg PCI handling https://review.openstack.org/623027
17:25:12 mriedem gibi: not sure if you saw my comment in that notifications patch, but if we planned on switching the default format to unversioned, marking it as deprecated would be weird
17:29:08 openstackgerrit Stephen Finucane proposed openstack/nova master: Address nits on I08991796aaced2abc824f608108c0c786181eb65 https://review.openstack.org/614322
17:29:08 openstackgerrit Stephen Finucane proposed openstack/nova master: Address nits on I1f1fa1d0f79bec5a4101e03bc2d43ba581dd35a0 https://review.openstack.org/614323
17:31:47 stephenfin mriedem: I'd suggested going the other way, leaving it to deployers to manually set things if some tool can't consume versioned notifications. Maybe that's too severe though
17:32:37 mriedem stephenfin: by some tool you mean *all* tools?
17:32:42 mriedem at least all tools in openstack
17:33:14 mriedem as far as i know, nothing in openstack which consumes nova notifications uses versioned notifications
17:33:24 mriedem and it's on us to add that support to those already understaffed projects
17:33:33 stephenfin Apparently so. I thought there were some, based on some mailing list post from a while back
17:33:49 sean-k-mooney didnt we say we were removing the unversioned notification in denver
17:33:53 mriedem there are lots of projects that consume nova's notifications, but not versioned
17:33:58 mriedem no
17:34:01 mriedem we said we'd never remove them
17:34:04 stephenfin Not removing - just deprecating
17:34:06 stephenfin Yeah
17:34:13 stephenfin until they eventually break, presumably
17:34:40 sean-k-mooney sorry your right we said we woudl keep them but not add new unversioned notifications
17:35:13 mriedem we haven't been adding new unversioned notifications since...we had versioned notifications
17:35:37 mriedem getting telemetry over the hump is probably the biggest hurdle
17:35:39 mriedem within openstack
17:35:41 sean-k-mooney right but i gues what i ment is freezing the unversioned code.
17:35:47 mriedem it's already frozen
17:36:07 sean-k-mooney including bug fixes
17:36:11 mriedem deprecation would just be signaling, don't write new stuff with this
17:36:32 mriedem i can't remember the last time we had a bug fix that dealt with unversioned notifications
17:37:09 mriedem my concern is https://bugs.launchpad.net/nova/+bug/1805659
17:37:09 openstack Launchpad bug 1805659 in OpenStack Compute (nova) "nova notifications hammering the message bus" [Low,Confirmed]
17:37:11 mriedem which jmlowe brought up
17:37:22 mriedem today we default to send both, versioned and unversioned, which kills rpc
17:37:27 mriedem s/kills/doesn't help/
17:37:39 mriedem if nothing is consuming versioned yet, then that is a shitty default imo
17:38:02 mriedem i know we want to get people off the old stuff, but no one is doing that
17:38:18 sean-k-mooney ya just readign that makes sense but im kind of reluctent to default to old
17:38:32 mriedem and honestly without a schema that consumers can use, it's probably not really something they care about
17:38:37 mriedem since they can't do version negotiation
17:39:27 sean-k-mooney can we default to versioned going forward instead and tell peopel to enable both/unversions if they have a service that uses them?
17:39:45 mriedem we can do whatever
17:40:00 mriedem me? i'm going to go make lunch and try to think about something else.
17:40:21 sean-k-mooney ok :)
17:54:19 cfriesen sean-k-mooney: I replied to your comments on https://review.openstack.org/#/c/620959/

Earlier   Later