| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-05 | |||
| 09:40:25 | kashyap | mdbooth: I was saying it in the commit message, not in the code -- sorry, I didn't made that clear | |
| 09:41:01 | kashyap | Yes, because consistency is better than inconsistency, harmony is better than chaos, etc :D | |
| 09:42:03 | kashyap | I mention these (but never -1!) because "you play like you practise". | |
| 09:43:15 | lyarwood | kashyap: if I respin I'll change it to Q35 | |
| 09:43:37 | kashyap | lyarwood: Merci | |
| 10:09:04 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.opendev.org/645520 | |
| 10:09:04 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Validate requested host/node during servers create https://review.opendev.org/661237 | |
| 10:21:49 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887 | |
| 10:21:49 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using Q35 machine type https://review.opendev.org/663011 | |
| 10:32:16 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.opendev.org/602201 | |
| 10:35:00 | mdbooth | lyarwood: FYI you can just recheck the DNM tempest change | |
| 10:35:25 | mdbooth | Err, no you can't. Thought you were using Depends-On. | |
| 10:36:16 | sean-k-mooney | hehe if its not using Depends-On currently adding it should rerun it right :) | |
| 10:36:45 | mdbooth | sean-k-mooney: Can you Depends-On another change in the same repo? It would be really convenient if you could. | |
| 10:36:46 | sean-k-mooney | oh the tempest change is no | |
| 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 | |