Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-25
21:00:25 mriedem nova meeting
21:00:39 melwitt good call excluding all the other jobs too
21:27:02 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640207
21:28:49 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove deprecated 'default_flavor' config option https://review.opendev.org/645476
21:29:32 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix cleaning up console tokens https://review.opendev.org/637716
21:31:48 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix nova-grenade-live-migration run book for opendev migration https://review.opendev.org/655800
21:38:10 efried mriedem: thanks for running that.
21:38:18 mriedem np
21:47:28 efried melwitt: tinyurl pointing to the charts for the project update
21:47:35 efried melwitt: since there's all those links on 'em
21:48:10 melwitt oh, the slides. yeah, that's fine
21:49:50 mriedem dansmith: i think the multi-cell job has yielded it's first victim
21:50:00 dansmith in a good way?
21:50:08 mriedem if latent bugs are a good thing
21:51:37 mriedem apparently in this addFloatingIP code, we fetch the instance from the cell at the top and pass down the targeted context for that instance,
21:51:46 mriedem and if the floating IP is associated with another instance we fetch that https://github.com/openstack/nova/blob/a991980863f056323c1ee9fd6a46dbc4cb899eca/nova/network/neutronv2/api.py#L2390
21:51:59 mriedem but if that instance is in another cell, bingo bango you've got yourself a 404 mister
21:52:12 mriedem shits the bed right here https://github.com/openstack/nova/blob/a991980863f056323c1ee9fd6a46dbc4cb899eca/nova/network/neutronv2/api.py#L2400
21:52:38 dansmith mriedem: pretty sure you're over your bingo bango quota for the week
21:53:05 mriedem umm, actually one of the cells was down and now i have no quota limit
21:53:37 mriedem you get to experience that kind of dry wit and more in person next week
21:54:28 dansmith looking forward to the "and more" there
21:54:52 mriedem you'll have to pay for the full riderman experience
21:55:16 dansmith so...many...nws...things....to...say
21:57:32 efried Beyond that, yes, the long-term benefit is cutting the python-*client packages out of the picture, removing that tech debt. That relationship is brittle and causes us to either fear changing it or break things when we do.
21:57:32 efried mriedem, melwitt: As soon as I can figure out how to fixture the sdk (see https://storyboard.openstack.org/#!/story/2005475) we could actually do clouds.yaml immediately.
21:59:28 efried ...immediately. Because the sdk proxies are Adapter subclasses, so we can just swap them seamlessly for the ksa adapter's we're hacking up today. Then cut the actual client libs out at our leisure.
21:59:30 mriedem but then we'll have (1) old style config for cinder (2) normalized ksa config for all the other non-sdk clients we use and (3) sdk clouds.yaml thing
21:59:50 efried deprecation period for oslo.config stuff obviously.
21:59:52 mriedem seems like a configuration mess until everyting is cut over
22:00:17 efried And operators already have clouds.yaml for the most part, so they'll have very little to do.
22:00:50 efried (by "already" I mean, if they're running stein+)
22:01:03 mriedem "That relationship is brittle and causes us to either fear changing it or break things when we do." as the recent ironicclient stuff can tell i suppose,
22:01:08 efried exactly
22:01:12 dansmith efried: which is like nobody right?
22:01:17 mriedem but i imagine we'll hit a new class of weird bugs once we start using the sdk
22:01:18 efried though I didn't want to bring that up
22:01:28 efried because I broke it by introducing the ksa config...
22:01:37 mriedem i'm not sure how much damage we get from glance/neutron/cinder client
22:02:13 mriedem what's being used for nova/cyborg in that series? just ksa?
22:02:16 mriedem or the sdk?
22:02:23 efried dansmith: Right, this is setting up for a future time when people are actually using the releases we're working on and we've got new jobs and don't care anymore.
22:02:35 efried I've been pushing Sundar to use sdk
22:03:03 efried I gave him the placement code for the cyborg side of his demo and set it up to use sdk
22:03:09 mriedem so if we did the sdk thing, cyborg integration could be the guinea pig, and then i'd think cinder since we haven't ksa'd our cinder stuff yet
22:04:14 efried I was going to do placement first, because it would be a transparent swap under the covers - we don't have a placementclient, so we would just set up SchedulerReportClient._client as the Connection.placement proxy (which is an Adapter subclass) instead of the raw Adapter.
22:04:25 efried get/put/etc primitives come along for free.
22:04:59 efried I PoC'd this already and it works seamlessly in tempest. It just blows up all the unit and functional tests until I figure out fixtures (see above)
22:05:21 mriedem ok
22:05:49 efried ...and then ironicclient, because we have lots of support for that from the ironic team, and dtantsur|afk is a sdk core who can help to some extent
22:06:26 efried and I have a guy coming on board (hi dustinc) who's trying to be involved in ironic who has started looking at it.
22:07:07 efried but yeah, could look into tackling cinder early, I see the benefit since it got left behind with ksa.
22:07:16 efried never could figure that f'in thing out.
22:15:06 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Correct signature on fake_get_availability_zones https://review.opendev.org/655806
22:21:29 mriedem dansmith: so i'm going to rev this multi-cell job patch to disable the failing test here until there is a bug fix - while doing that, what do you think about just making the job non-voting in the check queue for a bit until we're happy with it through the ptg?
22:21:57 dansmith mriedem: I'm good with whatever, but it seems like non-voting to collect data is what we would normally do
22:28:02 mriedem ack
22:28:03 mriedem done
22:28:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Add nova-multi-cell job https://review.opendev.org/655222
22:28:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Enable n-novnc in nova-multi-cell job https://review.opendev.org/655711
22:52:24 openstackgerrit melanie witt proposed openstack/nova master: Use futurist.ThreadPoolExecutor in scatter_gather_cells https://review.opendev.org/650172
23:06:40 efried o/ see y'all tomorrow
23:41:19 artom
23:56:51 rm_work so, is it possible to run nova unit tests with tox on OSX? anyone manage this? or is it just impossible (seems that pyinotify is not compatible with osx so the env build just fails)
#openstack-nova - 2019-04-26
01:23:34 mriedem dims: didn't you used to run nova unit tests in osx? ^
01:50:53 mnaser I usually run them.. I haven't had troubles
01:51:10 mnaser i.. don't usually run the whole suite tho
01:54:50 mriedem tsk
02:10:52 dims mriedem : right as mnaser said, not the full suite ... a while ago
02:28:10 openstackgerrit Merged openstack/python-novaclient master: Drop py35 tests https://review.opendev.org/643873
02:32:34 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Change the default value of swap in the show flavor details API https://review.opendev.org/648919
04:44:41 openstackgerrit melanie witt proposed openstack/nova master: Add 'path' query parameter to console access url https://review.opendev.org/649372
05:13:35 openstackgerrit Merged openstack/nova master: Don't run tempest/devstack jobs on nova/test.py only changes https://review.opendev.org/655121
06:42:30 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Change the default value of swap in the show flavor details API https://review.opendev.org/648919
08:28:40 openstackgerrit Merged openstack/nova master: Delete require_instance_exists_using_uuid https://review.opendev.org/650994
08:33:58 slaweq hi nova developers :)
08:34:25 slaweq can someone familiar with nova-metadata take a look at my comment in https://bugs.launchpad.net/neutron/+bug/1821912/comments/12 ?
08:34:26 openstack Launchpad bug 1821912 in neutron "intermittent ssh failures in various scenario tests" [High,Confirmed]
08:34:45 gibi efried: thanks for the onboarding slide update
08:35:08 slaweq I'm not sure what's exectly happend (or not happend) on nova's side there so any help would be useful
08:35:32 slaweq gibi: efried: if You would have some time, maybe You can take a look at ^ :)
08:35:34 slaweq thx in advance
08:47:22 openstackgerrit ya.wang proposed openstack/nova-specs master: Add spec for expose-auto-converge-post-copy https://review.opendev.org/651681
08:48:14 gibi slaweq: hi! looking... (but not super familiar with the metadata part of nova)
08:48:25 slaweq gibi: thx a lot
09:08:14 openstackgerrit Stephen Finucane proposed openstack/nova master: test_rpc: "deepcopy" global options https://review.opendev.org/655843
09:20:15 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655332
09:26:57 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Always disconnect volumes after libvirtError exceptions https://review.opendev.org/655712
09:27:18 lyarwood mdbooth: ^ and the one below it might interest you btw, simple bugfixes.
09:29:32 kashyap aspiers: Hi, when you're about, some more design comments upcoming for the getDomCapabilities() patch
09:30:30 kashyap aspiers: Talking to libvirt folks, they strongly suggest to not cache the capabilities at all. I will write some details and possible suggestions in the patch.
09:33:51 aspiers kashyap: ok
09:34:21 kashyap aspiers: In short, if you want to start thinking about it: we're suggested to query domCapabilities once at the beginning of building domain XML process, but then forget them right after
09:34:37 kashyap I asked the libvirt dev to also comment in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1683471
09:34:39 openstack bugzilla.redhat.com bug 1683471 in libvirt "getDomainCapabilities claims SEV is supported for pc-i440fx-1.4 machine type" [Unspecified,Closed: notabug] - Assigned to libvirt-maint
09:34:59 aspiers kashyap: but this is the point I already made in the comment - that approach totally fails in the OpenStack world
09:35:13 kashyap In the doc string, right?
09:35:21 aspiers kashyap: because we need to know stuff before placement time, not just at launch time
09:35:54 aspiers kashyap: https://review.opendev.org/#/c/655268/2/nova/virt/libvirt/host.py@690
09:36:17 aspiers I suspect the libvirt folks were only thinking of the single hypervisor paradigm when they designed this

Earlier   Later