Earlier  
Posted Nick Remark
#openstack-nova - 2019-06-05
11:02:09 sean-k-mooney i think eventlets is not working properly
11:02:18 mdbooth Which agent?
11:02:26 sean-k-mooney nova-compute
11:02:38 mdbooth The service?
11:02:41 sean-k-mooney yes
11:02:44 mdbooth Ah, ok
11:03:08 sean-k-mooney it stop produceing all log output in the journal and the vm never boots
11:03:26 mdbooth sean-k-mooney: It's definitely running on RHEL 8
11:03:30 sean-k-mooney at least that is what i was seeing on fedora 29
11:03:51 sean-k-mooney rhel8 is not useing py37
11:04:02 sean-k-mooney or atleast i thought it was using py36
11:04:10 mdbooth Obviously
11:05:29 sean-k-mooney the unit test do actully run however on py37 as do the fucntional test i belive so it seams to only be an issue when we do actul socket io to connect to libvirt
11:05:43 sean-k-mooney to be honest i didnt debug it
11:09:29 lyarwood mdbooth: I've been watching it using http://zuul.openstack.org/status and https://github.com/kk7ds/openstack-gerrit-dashboard
11:10:02 lyarwood I was just bouncing between unit and functional tests failing for stupid reasons
11:10:13 lyarwood should be resolved now
11:10:18 mdbooth lyarwood: Ack.
11:38:42 aspiers efried: https://review.opendev.org/#/c/638680/ looking a lot better now, thanks for the recheck
11:38:55 aspiers although I do wonder what the hell you were doing awake at that time
12:27:02 mdbooth artom: Looking at https://review.opendev.org/#/c/644881/19/nova/compute/manager.py
12:27:34 mdbooth Which neutron call generates the event when we're using OVS hybrid: setup_networks_on_host or migrate_instance_finish?
12:30:49 sean-k-mooney migrate_instance_finish calls _update_port_binding_for_instance
12:30:55 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2728
12:31:05 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L3186
12:31:29 sean-k-mooney so _update_port_binding_for_instance triggers teh event when the portbinding is updated
12:31:38 mdbooth sean-k-mooney: Thanks.
12:45:36 sean-k-mooney mdbooth: i added some clarification to https://review.opendev.org/#/c/644881/19/nova/compute/manager.py
12:45:54 openstackgerrit Adam Spiers proposed openstack/nova master: Track inventory for new MEM_ENCRYPTION_CONTEXT resource class https://review.opendev.org/662105
12:46:00 sean-k-mooney although i think the comment artom left in the code is sufficent
12:46:00 mdbooth sean-k-mooney: Thanks
12:53:15 mdbooth artom: I think you're missing a test.
12:56:18 kashyap Goddamned Gerrit utterly ****s up formatting when you try to quote-reply to a long message, that has some indentation.
13:01:40 kashyap [No it's not possible; curses under my breath and moves on.]
13:03:51 artom mdbooth, sorry, caught me during daycare taxi
13:04:11 artom Looks like sean-k-mooney answered your question
13:04:20 artom mdbooth, sean-k-mooney, thanks for the reviews, will address shortly
13:04:41 sean-k-mooney artom: i havent asked for any changes so mine is a noop :)
13:10:05 openstackgerrit Merged openstack/nova master: Change the default of notification_format to unversioned https://review.opendev.org/603079
13:12:20 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887
13:15:59 artom lyarwood, well, depends what we want to show with it
13:16:14 artom If we just want it to pass with only the IDE/SATA CDROM changes, then yeah
13:16:30 artom Once we actually fix the PCIE ports in Nova, then that bit should be removed from the DNM patch
13:16:52 artom Err, that was for a question asked in downstream IRC
13:23:16 lyarwood artom: okay so moving back here, testing q35 instead of the default machine type in upstream CI
13:23:55 lyarwood artom: I personally think that's fine in one job but we still need to cover the default somewhere
13:24:30 artom lyarwood, yeah, that was my feeling as well - we can't add an entire new job given the gate resource constraints, and we should keep testing the default as well
13:24:39 artom So where do we stick q35? nova-next?
13:25:08 kashyap artom: An email needs to be written to discuss on the list
13:25:28 kashyap [nova] Test 'q35' machine type in the Gate
13:25:31 kashyap Or something like that
13:25:39 artom kashyap, sounds like a plan
13:25:53 artom Who's doing the needful?
13:25:58 kashyap I can do that. But not now
13:26:19 kashyap One of the main reasons is that upstream and (nor a certain major Linux distro) QEMU doesn't "fix" bugs or add additional features to the 'pc' machine type
13:26:42 kashyap Not least because it's considered legacy (20+ years old), and difficult to extend
13:27:09 artom That's an argument for outright switching the default, no?
13:27:41 kashyap It is. We've had approximately 240 email-long threads about it.
13:27:53 artom Hah :(
13:28:00 kashyap Sorry, by "we" as in QEMU and libvirt.
13:28:18 kashyap Some fear the backwards compat that it "might" break something
13:28:20 artom Well, I meant in Nova, but in QEMU works too
13:28:24 kashyap But we can't ever be paralyzed
13:28:44 kashyap artom: Yes: https://review.openstack.org/#/c/631154/
13:28:52 kashyap "Gracefully handle QEMU machine types for guests"
13:29:38 artom kashyap, oh, had no idea that existed, thanks
13:29:42 kashyap artom: For now, installer tools are supposed to configure the default.
13:29:50 artom Will add to the pile of specs to review
13:30:23 artom ... which I guess makes sense (installer configuring the machine type)
13:30:58 kashyap That's one reason I put on the back burner for this cycle
13:33:10 yaawang johnthetubaguy: mriedem Could you please take a look at auto-converge/post-copy spec? I've updated it. https://review.opendev.org/#/c/651681/
14:05:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.opendev.org/512552
14:05:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove global state from the FakeDriver https://review.opendev.org/656709
14:05:36 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add functional test coverage for bug 1724172 https://review.opendev.org/512553
14:05:37 openstack bug 1724172 in OpenStack Compute (nova) rocky "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Medium,Confirmed] https://launchpad.net/bugs/1724172
14:06:20 efried cfriesen: Thanks for the update.
14:09:14 aspiers https://review.opendev.org/#/c/638680/ got a +1 from Zuul finally
14:10:05 efried yup, \o/
14:10:35 aspiers is it just me or are we getting some semi-spam +1 reviews?
14:11:38 efried happens all the time
14:11:41 aspiers ah ok
14:11:58 efried stat padders
14:13:30 aspiers :-(
14:14:22 aspiers kashyap: funny this should just emerge after we were talking about it the other day https://itnext.io/pyramid-of-doom-the-signs-and-symptoms-of-a-common-anti-pattern-c716838e1819
14:14:38 kashyap Hiya
14:15:24 kashyap aspiers: Hehe, "pyrmaid of doom"
14:16:55 gibi aspiers: they are coming in batches
14:17:01 gibi aspiers: https://www.stackalytics.com/?metric=marks&module=nova-group&company=awcloud
14:17:03 kashyap aspiers: On "semi-spam +1s", I wonder if they would dare to do that had it were an e-mail
14:17:15 kashyap Imagine sending random +1s to e-mail based patch workflows.
14:17:26 aspiers right
14:17:41 kashyap Each Gerrit change is an island, nobody notices it (beside those who do). So who cares who craps on it
14:17:41 aspiers perhaps someone in the foundation can have a word?
14:18:03 kashyap aspiers: This is something we have to live with, as a community-based open source project, afraid.
14:18:15 aspiers kashyap: not sure I agree
14:18:28 aspiers there's nothing to stop us raising complaints about this behaviour
14:18:44 kashyap aspiers: Oh, certainly; there was a recent thread about it on the list, too
14:18:48 kashyap (Not sure you noticed it)
14:19:06 aspiers I think I saw it
14:19:09 lyarwood mdbooth / kashyap / sean-k-mooney ; https://review.opendev.org/#/c/663011/ is ready for another round of reviews btw

Earlier   Later