| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 12:01:57 | jangutter | (the versions of Netscape and IE probably correspond to the date that the original software was delivered by the contractors.) | |
| 12:02:40 | sean-k-mooney | ya the current maintainer (if there is one) proably has never seen that page | |
| 12:04:40 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove unused param from _fill_provider_mapping https://review.opendev.org/655107 | |
| 12:04:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move _fill_provider_mapping to the scheduler_utils https://review.opendev.org/655108 | |
| 12:04:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109 | |
| 12:04:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: allow getting resource request of every bound ports of an instance https://review.opendev.org/655110 | |
| 12:04:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111 | |
| 12:04:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: handle port allocation during migration https://review.opendev.org/655112 | |
| 12:04:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113 | |
| 12:04:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114 | |
| 12:13:39 | mriedem | i need a stable core to hit this queens backport https://review.opendev.org/#/c/640198/ | |
| 12:22:12 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.opendev.org/652197 | |
| 12:26:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468 | |
| 12:26:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't run tempest/devstack jobs on nova/test.py only changes https://review.opendev.org/655121 | |
| 12:32:53 | aspiers | vcpu:1 | |
| 12:32:57 | aspiers | oops | |
| 12:40:24 | kashyap | aspiers: When you're about -- remind me again, are you planning to cache the result of getDomainCapabilities(), as part of SEV work? | |
| 12:41:20 | aspiers | kashyap: not just planning, but https://review.opendev.org/#/c/633855/12/nova/virt/libvirt/host.py already does that | |
| 12:41:56 | kashyap | aspiers: Ah: | |
| 12:41:57 | kashyap | domain_caps[arch][machine_type] = \ | |
| 12:41:57 | kashyap | self._get_domain_capabilities(emulator_bin, arch, | |
| 12:41:57 | kashyap | machine_type, virt_type) | |
| 12:42:02 | aspiers | right | |
| 12:42:11 | kashyap | aspiers: So something to consider: | |
| 12:43:08 | kashyap | aspiers: This morning, while talking to a libvirt developer (Michal Privoznik), he was saying: caching domain capabilities probably doesn't make sense -- because it will be outdated everytime libvirt and QEMU are updated. | |
| 12:43:09 | arshad777 | Hi everyone: I am trying to create an instance on multi-node setup. But getting error "no valid host found". For detail refer url http://paste.openstack.org/show/749631/ | |
| 12:43:43 | arshad777 | compute services are running. Please refer url http://paste.openstack.org/show/749630/ for more detail | |
| 12:43:47 | aspiers | kashyap: it would only be cached in the running service, not persisted to disk | |
| 12:43:53 | kashyap | aspiers: As we know, there are 4 input values (path to qemu binary, guest architecture, machine type and virt type) -- so any change if one of them and we get a different set of capabilities | |
| 12:44:04 | kashyap | aspiers: Noted | |
| 12:44:05 | aspiers | kashyap: if a compute node's libvirt/QEMU gets updated, it seems reasonable to expect that nova-compute will get restarted too | |
| 12:44:19 | aspiers | or at least for major updates | |
| 12:44:32 | kashyap | aspiers: Yes, not "reasonable", it should, to avoid any surprises :-) | |
| 12:45:20 | mriedem | jaypipes: can you take a look at the stein regression bug fix series starting with the functional recreate test here? https://review.opendev.org/#/c/653268/ | |
| 12:45:48 | aspiers | kashyap: qemu binary path will have a single value and is programmatically obtained | |
| 12:46:11 | aspiers | and virt type will presumably be fixed within the context of the libvirt driver anyway | |
| 12:46:18 | aspiers | so in reality it's just two values which can change | |
| 12:46:23 | mriedem | gibi: can you take a look at the stein regression bug fix series starting here? https://review.opendev.org/#/c/653098/ | |
| 12:46:32 | kashyap | aspiers: True, good point. (So you're aware of it; just thought I'd notify.) | |
| 12:46:38 | gibi | mriedem: looking | |
| 12:46:38 | aspiers | unless it's possible to have the libvirt driver allowing both Xen and KVM on one host | |
| 12:46:43 | aspiers | which I assumed not | |
| 12:46:55 | aspiers | or at least that noone would be crazy enough to try that ;-) | |
| 12:47:04 | kashyap | aspiers: No, that's too FrankenStack to mix it like that :D | |
| 12:47:08 | aspiers | right | |
| 12:47:29 | kashyap | Okay, /me moves "office", home --> library; bbiab | |
| 12:48:57 | aspiers | kashyap: getting the emulator was the whole point of https://review.opendev.org/#/c/640483/ | |
| 12:51:54 | sean-k-mooney | aspiers: what were you going to use the emulator for? | |
| 12:52:35 | aspiers | for calling the API as per above | |
| 12:52:38 | aspiers | gotta run, biab | |
| 12:54:13 | sean-k-mooney | aspiers: you can only have kvm and zen on the same host if you run two agents. and are happy to support it entirly yourself because noone else will touch it :) | |
| 12:56:42 | sean-k-mooney | kashyap: if you did not restat the agent i think we would pick you the capablity changes via the periodic task but ya it would be an ill defined state untill that happened | |
| 12:57:08 | kashyap | Right | |
| 13:03:16 | mriedem | melwitt: about 5am i was thinking about quota and rebuild from cell0 - thoughts are in the spec https://review.opendev.org/#/c/648686/2/specs/train/approved/enable-rebuild-for-instances-in-cell0.rst@96 if you can check my thinking | |
| 13:03:49 | mriedem | tssurya: is your locked_reason stuff ready for review? if so, can you queue it up for runways? | |
| 13:04:58 | gibi | mriedem: what will happen if we run the migration, run archive, run migration, run archive again. Does that second archive fail to move the marker instance due to a unique constraint on the uuid field in the shadow table? | |
| 13:05:40 | openstackgerrit | Nikolay Fedotov proposed openstack/nova master: Fix disappearing ironic hypervisors after rebuilding hashring https://review.opendev.org/654584 | |
| 13:07:28 | gibi | mriedem: never mind, we dont add the unique constraint to the shadow tables | |
| 13:07:43 | gibi | mriedem: series starting at https://review.opendev.org/#/c/653098/ looks good to me | |
| 13:07:44 | mriedem | right | |
| 13:08:42 | mriedem | thinking about your migration + archive thing, i don't think we archive the deleted marker instance because of the fkey relationship to the vif | |
| 13:09:58 | mriedem | i also don't think we ever delete the marker vif even if we don't need to migrate any more records, | |
| 13:10:25 | mriedem | so eventually when we remove that online data migration, we'll likely also need to delete the marker vif so archiving can remove it and we can remove the hack in the api | |
| 13:13:05 | gibi | mriedem: hm, then I don't get how your functional test passes at https://review.opendev.org/#/c/653098/2/nova/tests/functional/regressions/test_bug_1825034.py@77 | |
| 13:13:35 | gibi | mriedem: or we delete the marker instance but no the marker vif? | |
| 13:13:49 | mriedem | correct | |
| 13:14:03 | mriedem | the instance record is soft deleted but the marker vif is not | |
| 13:14:19 | mriedem | efried: i reckon anything going into a runway slot today will get an extra week because of the summit yeah? | |
| 13:14:49 | gibi | mriedem: I see | |
| 13:15:30 | mriedem | melwitt: i removed the counting quotas from placement series out of the runway slot since the time expired but feel free to queue it back up | |
| 13:17:31 | bauzas | mriedem: sorry was on bank holiday yesterday, how can I help with some review ? | |
| 13:17:54 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137 | |
| 13:18:13 | mriedem | bauzas: stein regression series starting here would be good https://review.opendev.org/#/c/653268/ | |
| 13:18:30 | mriedem | bauzas: and i need review on this queens backport https://review.opendev.org/#/c/640198/ | |
| 13:18:47 | mriedem | we're very close to closing out pike | |
| 13:19:33 | mriedem | extra credit for https://review.opendev.org/#/c/639382/ which is #2 in my series of 45+ changes in the cross-cell series | |
| 13:20:12 | mriedem | gibi: could i also ask, when you get a min, to review this functional recreate test for a latent bug https://review.opendev.org/#/c/641521/ | |
| 13:20:39 | gibi | mriedem: sure, looking | |
| 13:22:36 | mriedem | thanks | |
| 13:28:39 | gibi | mriedem: done, looks good | |
| 13:29:43 | mriedem | thanks again, and i see you took the extra credit :) | |
| 13:30:01 | mdbooth | lyarwood: Just sent a thing on swap-volume to the ML which you might be interested in. | |
| 13:30:30 | gibi | mriedem: :) | |
| 13:31:54 | lyarwood | mdbooth: swap volume and interested should never appear in the same sentence | |
| 13:33:59 | mdbooth | lyarwood: I proposed a green field implemention :) You never know, it might even make you happy. | |
| 13:34:27 | mdbooth | lyarwood: Anyway, I wanted *something* written down before the PTG session just to ensure it has some structure. If we throw it away that's fine. | |
| 13:34:55 | tssurya | mriedem: not yet I am still writing test cases and notification changes. Will add it to the queue once that is done | |
| 13:36:43 | lyarwood | mdbooth: ack thanks | |
| 13:38:17 | efried | mriedem: Extra runway time: sure | |
| 13:38:22 | mriedem | mdbooth: without reading, if i wrote swap volume today i'd probably use the os-server-external-events API as the callback from cinder like we use for neutron and cinder's extend volume api | |
| 13:38:40 | efried | kashyap: ack, thx | |
| 13:38:52 | efried | lbragstad: Yup, got it figured, thanks. | |
| 13:40:06 | efried | eandersson: ack, will look. Either way would be fine. I was going to say this is temporary until we rip out ironicclient; but the region_name and min/max fixes should be backported, so the stable branches will carry that code for a while. | |
| 13:40:30 | efried | mriedem: ack, saw the test.py thing, +2, good call. | |
| 13:43:48 | mdbooth | mriedem: My proposal wasn't explicit about what rpc method was used, but it is explicit about synchronous guarantees. | |
| 13:44:25 | mdbooth | mriedem: If we can use something more appropriate to the task than the rest api whilst having explicit calls and waiting between cinder and nova that would be awesome. | |
| 13:45:25 | mdbooth | I don't think it's possible to do with 1-way asynchronous calls, though, and 2-way asynchronous calls would be more complex. | |
| 14:01:52 | mdbooth | mriedem: Thanks, btw. I'd completely forgotten to discuss rpc mechanisms in that mail. I just tacked it on. | |
| 14:03:38 | mriedem | mdbooth: i wasn't talking about rpc, i was talking about rest api | |
| 14:04:12 | mdbooth | mriedem: I was talking about 'rpc', where the rest api is a type of rpc | |