| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-08 | |||
| 13:52:24 | mriedem | gibi: hmm, ok, so maybe i should move that into the base provider usage test class? | |
| 13:53:21 | mriedem | mrch_: i'll rebase it quick | |
| 13:53:26 | jaypipes | alex_xu: answered your question on https://review.openstack.org/#/c/555081/. Hopefully that explains things a bit better. let me know if you have further questions. | |
| 13:53:55 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081 | |
| 13:54:00 | gibi | mriedem: sure, you can move _check_allocation_during_evacuate I think it does not depend on anything in the current class | |
| 13:54:10 | mrch_ | mriedem: thx, but when the old one is queens im ok with it | |
| 13:54:48 | mriedem | mrch_: if my change is accepted on master then we (or you) would have to backport it to stable/rocky and then stable/queens | |
| 13:54:57 | mriedem | unless you're just going to run with that downstream | |
| 13:56:29 | openstackgerrit | Merged openstack/nova master: api-ref: Move the evacuate action to admin action https://review.openstack.org/607896 | |
| 13:56:36 | openstackgerrit | Merged openstack/nova master: Update doc https://review.openstack.org/605640 | |
| 13:56:48 | openstackgerrit | Merged openstack/nova master: libvirt: remove unused attribute driver for LibvirtConfigNodeDevice https://review.openstack.org/583246 | |
| 13:56:58 | openstackgerrit | Merged openstack/nova master: Set defult value of num_nvme_discover_tries=5 https://review.openstack.org/602351 | |
| 13:58:04 | mrch_ | mriedem: how long does it normally take until stable/queens centos repository has it? | |
| 13:59:50 | mriedem | i have no idea when centos picks up changes from upstream stable branches | |
| 14:00:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: RT: replace _instance_in_resize_state with _is_trackable_migration https://review.openstack.org/560467 | |
| 14:00:30 | mrch_ | mriedem: huge THX | |
| 14:00:31 | efried | n-sch meeting now in #openstack-meeting-alt | |
| 14:00:41 | bauzas | gibi: maybe I misunderstood https://review.openstack.org/#/c/605785/9/nova/compute/api.py@4375 but I provided a comment | |
| 14:00:50 | mriedem | mrch_: the people in #openstack-rpm-packaging might know when changes are picked up | |
| 14:00:56 | sean-k-mooney | melwitt: did you do a release of os-vif last week? | |
| 14:08:04 | openstackgerrit | Hamdy Khader proposed openstack/nova stable/rocky: Set defult value of num_nvme_discover_tries=5 https://review.openstack.org/608683 | |
| 14:09:09 | sean-k-mooney | mriedem: can we do stable releaes of os-vif and then use them with nova stable branches? the upperconstraitns appear to cap zstreams also https://github.com/openstack/requirements/blob/stable/pike/upper-constraints.txt#L458 | |
| 14:16:58 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Fix os-simple-tenant-usage result order https://review.openstack.org/608685 | |
| 14:17:18 | sean-k-mooney | dansmith: bauzas: got a second to answer a question about stable branch releases? | |
| 14:18:25 | sean-k-mooney | can we do a release of a lib os-vif in this case for a sable branch and then raise the z stream on stable/X to allow that z stream | |
| 14:19:04 | sean-k-mooney | the intent being to allow nova on stable/X to consume the zstream release of os-vif for stable/X | |
| 14:19:19 | dansmith | sean-k-mooney: you need to stop saying z-stream up here :) | |
| 14:19:41 | sean-k-mooney | well thats what tehy are called upstream too | |
| 14:20:10 | dansmith | um, really? I don't think I've heard that from non-redhat people but, whatever :) | |
| 14:20:30 | dansmith | sean-k-mooney: I don't think we bump requirements in stable other than to fix critical bugs, but mriedem is the right person to ask that | |
| 14:21:05 | sean-k-mooney | dansmith: well we used to call x.y.z releases z streams at intel too | |
| 14:21:27 | sean-k-mooney | ok well its for https://review.openstack.org/#/c/602384/ | |
| 14:21:30 | mriedem | mmm s390x stream | |
| 14:22:01 | dansmith | heh | |
| 14:23:38 | mriedem | so no we don't need to bump minimum required versions in stable for that os-vif change | |
| 14:23:47 | mriedem | upper-constraints can be bumped | |
| 14:23:59 | sean-k-mooney | mriedem: ya i just wanted to bump upper | |
| 14:24:08 | mriedem | otherwise assume stable GA'ed and is frozen with the minimum | |
| 14:38:06 | lpetrut | Hi, I have a trivial fix for "nova usage-list", which is counting instances twice: https://review.openstack.org/#/c/608685/ | |
| 14:48:01 | mriedem | lpetrut: it would be really nice if we could have a functional test to go along with that to show the regression | |
| 14:48:35 | mriedem | paging over simple tenant usage is confusing enough already | |
| 14:49:16 | lpetrut | sure, I'll add a test | |
| 14:52:01 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 14:54:38 | openstackgerrit | Jan Gutter proposed openstack/os-vif master: Add support for generic representors https://review.openstack.org/608693 | |
| 15:01:00 | openstackgerrit | Markus Hentsch proposed openstack/nova-specs master: Spec for the Nova part of Image Encryption https://review.openstack.org/608696 | |
| 15:07:30 | mriedem | jaypipes: email to yikun sent about those allocation ratio specs | |
| 15:08:05 | jaypipes | mriedem: ty | |
| 15:08:09 | mriedem | efried: gibi: fyi since i need to backport https://review.openstack.org/#/c/606106/ i'm not going to try and fit in the newly refactored assertion method usage and just copy the old methods into the test itself, which i will remove from master in a follow up | |
| 15:09:18 | efried | mriedem: ack, sounds fair. | |
| 15:24:11 | openstackgerrit | Martin Midolesov proposed openstack/nova master: Implementing graceful shutdown. https://review.openstack.org/608704 | |
| 15:24:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add volume-backed evacuate test https://review.openstack.org/604397 | |
| 15:24:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add post-test hook for testing evacuate https://review.openstack.org/602174 | |
| 15:24:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor TestEvacuateDeleteServerRestartOriginalCompute https://review.openstack.org/608705 | |
| 15:24:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400 | |
| 15:24:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix InstanceNotFound during _destroy_evacuated_instances https://review.openstack.org/606122 | |
| 15:24:35 | openstack | bug 1794996 in OpenStack Compute (nova) "_destroy_evacuated_instances fails and kills n-cpu startup if lazy-loading flavor on a deleted instance" [High,In progress] https://launchpad.net/bugs/1794996 - Assigned to Matt Riedemann (mriedem) | |
| 15:24:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional regression test for bug 1794996 https://review.openstack.org/606106 | |
| 15:31:19 | mriedem | gibi: on https://review.openstack.org/#/c/605785/ can we just fail fast in the API/conductor if the admin is trying to force a host during live migration and the instance has allocations on non-standard resource classes? where non-standard is anything other than VCPU/MEMORY_MB/DISK_GB? | |
| 15:31:41 | mriedem | granted, with jay's CPU resource tracking spec, VCPU would eventually be nested too... | |
| 15:31:58 | jaypipes | mriedem: *could* be an inventory on a child provider, yes. | |
| 15:32:19 | jaypipes | mriedem: though it's bauzas' spec that goes into that. | |
| 15:32:44 | jaypipes | mriedem: since he wanted to keep all the NUMA-ness in his spec and out of the cpu-resources spec. | |
| 15:33:32 | bauzas | ... and I need to rebase this spec | |
| 15:33:54 | bauzas | since we said to unplug the NUMA affinity from this spec | |
| 15:36:37 | openstackgerrit | Merged openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612 | |
| 15:43:13 | mriedem | sure, i just don't want to get too hung up on trying to bend over backward to honor that force parameter | |
| 15:43:18 | mriedem | which is a bad idea to use in the first place | |
| 15:44:14 | openstackgerrit | Merged openstack/nova master: Fix missing import in test_compute_mgr https://review.openstack.org/608426 | |
| 16:04:35 | mriedem | need another core to look at the vmware live migration patch https://review.openstack.org/#/c/270116/ | |
| 16:04:39 | mriedem | it's in a runway, +2 from me | |
| 16:04:41 | mriedem | CI is passing | |
| 16:04:57 | sean-k-mooney | mriedem: i was just talking to fungi about https://review.openstack.org/#/c/602384/ and the related bug | |
| 16:05:33 | sean-k-mooney | given its status he indicated we can talk about it here. | |
| 16:05:35 | fungi | yeah, a point-in-time summary of the situation would be helpful to add to that bug | |
| 16:05:58 | fungi | it's unclear to me how this can be a bug in nova but gets fixed by a patch to os-vif | |
| 16:06:11 | sean-k-mooney | fungi: i will update the bug today. | |
| 16:06:19 | fungi | much appreciated | |
| 16:07:03 | fungi | in particular if the vulnerability in the service has to be fixed by updating a dependent library, this is going to be complicated to communicate and may also make backporting harder | |
| 16:07:12 | sean-k-mooney | fungi: effectivly nova will wait for a notification form nuetron to know the port has been wired up on migration. | |
| 16:07:32 | sean-k-mooney | but in this edgecase os-vif is not used to plug the port libvirt is | |
| 16:07:51 | sean-k-mooney | as such we fallback to a time out and migrate without first having neutron wire up the port | |
| 16:08:23 | sean-k-mooney | neutron then wires up the port when the vm starts but that takes a little tiem to happen | |
| 16:08:47 | sean-k-mooney | the fix is to delegate to the os-vif lib to plug the interface in this edgecase also | |
| 16:09:17 | sean-k-mooney | that way the port will be wired up by neutron before we migrate | |
| 16:09:36 | fungi | and this is effectively a design flaw in nova because it assumes the call won't time out? or a bug in neutron for not treating it consistently using os-vif? | |
| 16:10:14 | sean-k-mooney | fungi: its legacy behavior form when nova woululd do firewalling for the port instead of neutron | |
| 16:10:54 | fungi | okay, so this will also eventually be solved when nova removes that deprecated behavior? | |
| 16:10:58 | sean-k-mooney | that said yes its partly a design flaw in nova. | |
| 16:11:29 | sean-k-mooney | yes if nova always used os-vif to plug the interface it would not happen | |
| 16:12:16 | fungi | and so https://review.openstack.org/602384 is basically a workaround to avoid having to switch nova to calling into os-vif for these? | |
| 16:12:33 | mriedem | umm...we use os-vif with nova-net too, so "yes if nova always used os-vif to plug the interface it would not happen" is kind of confusing | |
| 16:13:19 | sean-k-mooney | mriedem: the ovs plugin in os-vif was designed not to plug the interface in this case because libvirt does that | |
| 16:14:04 | sean-k-mooney | so we expressly do not create the ovs port and allow libvirt to do that currently. the change makes os-vif create the port which allows neutron to wire it up before we migrate the vm | |
| 16:15:16 | sean-k-mooney | mriedem: fungi so its not that nova does not call os-vif in this case. it does but os-vif was designed not to plug the interface in this case to maintain parity with how nova plugged interface before os-vif was split out | |
| 16:15:32 | sean-k-mooney | does that make sense? | |
| 16:16:00 | mriedem | shrug | |
| 16:16:03 | fungi | so the bug is in nova making assumptions about os-vif's behavior in this circumstance, or that os-vif doesn't fully implement the behavior nova expects? | |
| 16:16:20 | mriedem | sean-k-mooney: is this going to be a weird one off for ovs in os-vif only? | |
| 16:16:34 | mriedem | like will the behavior be different for all other vif types? | |
| 16:17:03 | mriedem | and when you say libvirt, do you mean the nova libvirt driver or libvirt the service? | |