| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-05 | |||
| 10:36:48 | sean-k-mooney | nova | |
| 10:37:05 | mdbooth | kashyap: https://review.opendev.org/#/c/663011/6..7/nova/virt/libvirt/blockinfo.py ;) | |
| 10:37:09 | sean-k-mooney | it can if there is no merge conflict but in repo you should jsut rebase on top of the other | |
| 10:37:50 | mdbooth | sean-k-mooney: More thinking about octopus merges. | |
| 10:38:10 | kashyap | mdbooth: One moment | |
| 10:38:26 | mdbooth | sean-k-mooney: i.e. You've got several otherwise independent patches, then a change which requires all of them. | |
| 10:38:49 | sean-k-mooney | mdbooth: yep i have done that before and if there are no merge conflict it works | |
| 10:38:50 | lyarwood | erm it's a DNM Nova change so nope | |
| 10:38:58 | lyarwood | ah sean-k-mooney already said | |
| 10:39:10 | mdbooth | lyarwood: And I already noticed ;) | |
| 10:39:18 | sean-k-mooney | zuul create a new commit with all of the depencies as parents | |
| 10:39:57 | sean-k-mooney | so if the merge is possibel without conflict then zuul will do it if not it will mark the patch as in merge conflict | |
| 10:40:15 | mdbooth | In that case, lyarwood should be able to use Depends-On for the tempest job change | |
| 10:40:38 | sean-k-mooney | yes he can | |
| 10:41:03 | sean-k-mooney | and then just recheck and it will pick up the latest version each time | |
| 10:41:42 | kashyap | mdbooth: Heh, thanks | |
| 10:42:40 | sean-k-mooney | mdbooth: for that to work however the tempest change would have to not be based on the other change or zuul with skip the depends-on as its already satisfied | |
| 10:43:25 | mdbooth | sean-k-mooney: It would be academic in this case, tbh. I'm more just interested to know if it works :) I doubt lyarwood would bother on that basis. | |
| 10:44:23 | sean-k-mooney | i have used it in the past when i needed a bug fix someone else was writing form my own work but they did not want me to rebase my work ontop | |
| 11:01:08 | mdbooth | lyarwood: FYI, don't know if you've been doing this locally but your latest patch just completed a full set of py37 unit tests for me | |
| 11:01:47 | sean-k-mooney | mdbooth: the nova compute agent does not work proably under py37 the last time i tried it | |
| 11:01:59 | sean-k-mooney | it hangs when you try to boot a vm | |
| 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/ | |