Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-08
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?
16:17:11 sean-k-mooney that is a good question. i think there are a class of bugs related to this.
16:17:21 sean-k-mooney this bug predate os-vif
16:17:40 sean-k-mooney the original behavoir was incorrect
16:18:01 sean-k-mooney i say that becase anytime libvirt plugs the vif this can happen
16:18:48 sean-k-mooney this will not happen for vhost-user port as libvirt does not hanel plugin in that case. simplarly for siov libvirt set the vlan tag not neutron so that is safe
16:19:52 sean-k-mooney for now this is a one off but i need to look at other backends such as linux bridge to confirm this is a one off
16:19:56 fungi is this going to be backportable at least as far as stable/pike of os-vif? since we'll want a 1.7.1 tagged there for nova stable/pike to consume i guess
16:20:09 sean-k-mooney fungi: yes it should be
16:20:57 sean-k-mooney fungi: it requires not code change out side of os-vif and has no dependceis that i can tell to backport the change.
16:21:56 fungi i'm still a little iffy on how to go about describing this situation if we decide to publish an official advisory, particularly in that we consider it a nova bug but didn't patch nova to fix it. does the bug remain in nova even with newer os-vif? or is it simpler to explain it as a shortcoming of os-vif that we fixed to eliminate this behavior?
16:23:14 jaypipes mriedem: did the vmware live migration patch.
16:23:20 sean-k-mooney fungi: a newer os-vif will resolve the issue. my concern with calling this an os-vif only bug is if we go back to before we split out os-vif the bug i belive would still exist in the nova tree

Earlier   Later