Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-08
12:54:47 jangutter sean-k-mooney: last time I checked, Neutron listens to OVSDB for that interface_id UUID to pop up in order to confirm the plugging.
12:55:22 sean-k-mooney jangutter: for the ml2 agent yes it check the interface_id in the external_ids colume of the port table
12:55:56 jangutter sean-k-mooney: yep, but is that guaranteed to be the same as VIFBase.id ?
12:56:12 sean-k-mooney jangutter: yes that is where we read if from
12:56:23 jangutter sean-k-mooney: why is interface_id then a field in the OVS port profile?
12:57:09 sean-k-mooney legacy reasons
12:57:15 sean-k-mooney basically it was used by libvirt
12:57:38 sean-k-mooney it got copied when we did the import from nova but its the same id
12:57:51 jangutter sean-k-mooney: o.m.w. here I was thinking that it's the whole reason behind port profiles!
12:58:02 sean-k-mooney jangutter: nope
12:58:46 jangutter sean-k-mooney: so, one VIF can only ever ever have one interface ID, and that's the same as its UUID?
12:58:59 sean-k-mooney looks like we are using it https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L124
12:59:15 sean-k-mooney jangutter: yep it should be
12:59:46 sean-k-mooney let me check nova to confirm but they should never be different as far as i know
12:59:53 jangutter sean-k-mooney: yep, that was the line of code that made me thought it could differ from vifbase.id.
13:00:27 sean-k-mooney i dont think it can but im checking
13:00:47 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Remove IPTools deprecated implementation https://review.openstack.org/605422
13:02:04 sean-k-mooney jangutter: so ya the neutron port uuid is stored in the id field https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L248-L264
13:03:08 jangutter sean-k-mooney: interface_id=vif.get('ovs_interfaceid') or vif['id']
13:03:14 sean-k-mooney jangutter: and here we even default it to the vif[id] if ovs_interfaceid is not set https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L288
13:03:23 sean-k-mooney yes
13:03:47 jangutter sean-k-mooney: yep.... Guess what, I've also wrote code like that.
13:04:18 jangutter sean-k-mooney: but my interpretation was that "ovs_interfaceid" is the new hotness and vif['id'] is old-and-busted.
13:05:26 sean-k-mooney jangutter: nope othere way around ovs_interfaceid i think was a nova networks thing
13:05:57 sean-k-mooney using neutron i dont think they can ever be different at least not currently
13:06:09 jangutter https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/test_vif.py#L84
13:06:46 jangutter sean-k-mooney: yeah, in the tests, there's a definite difference between uuids.ovs and uuids.vif
13:07:05 sean-k-mooney jangutter: that does not mean the tests are correct :)
13:07:30 jangutter sean-k-mooney: yep! thanks for showing me the error of my ways again! Important safety tip.
13:07:54 sean-k-mooney jangutter: https://github.com/openstack/nova/blob/a330c9a143dea8095a3d1c3eabd56193ad6f38b1/nova/network/neutronv2/api.py#L2651 so this is where its set :)
13:08:01 jangutter sean-k-mooney: makes me think of basic particle physics where time symmetry is a thing.
13:09:51 sean-k-mooney jangutter: by the way want to open a bug for the incorrect tests?
13:10:02 jangutter sean-k-mooney: this is pretty hilarious now that I think of it, I was almost actively undoing the direction that Nova, Neutron and OS-VIF is going.
13:10:41 jangutter sean-k-mooney: I'll try to get on it today: that looks like something nice to fix for future Jan's not to step into.
13:11:10 sean-k-mooney jangutter: ya i was thinking it would make a nice low hanging fruit style bug.
13:15:35 sean-k-mooney jangutter: this change kind of hurts me to read... https://github.com/openstack/nova/commit/1c07735f8e3b28f64fcd1252372aa9e6e917d960
13:18:22 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Handle missing marker during online data migration https://review.openstack.org/608572
13:19:28 jangutter sean-k-mooney: I would literally interpret that as: "the ovs interface-id should be different from the vif id"
13:20:42 sean-k-mooney jangutter:this code is from 6 years ago when quantum was not the default network backend in nova and nova-networks was still alive and well
13:21:36 sean-k-mooney it looks like there used to be a mapping table and nova used to generate uuids for the libvirt xml
13:23:03 jangutter sean-k-mooney: yep, with neutron and nova sharing the same UUID for the VIF, that's not needed now.
13:24:05 sean-k-mooney jangutter: i think origianly nova nad nutron used to use the name of the port as the common thing and the uuid only came a little later as more backends stared to appear
13:34:01 mriedem gibi: probably need some help from you on how the refactored functional assertFlavor.... checks should be done in https://review.openstack.org/#/c/606106/
13:34:14 mriedem i've found i still just need a simple assertFlavorMatchesAllocation method
13:34:56 mrch_ how to get rid of the "Instance not resizing, skipping migration." WARNINGS Spam, non of the req-IDs stand in the list: MariaDB [nova]> select * from instance_actions where action = "live-migration" and deleted = "0"
13:35:34 gibi mriedem: looking..
13:35:49 mriedem mrch_: i tried removing that here https://review.openstack.org/#/c/560467/
13:35:54 mriedem but that change needs to be rebased
13:40:05 gibi mriedem: I think the solution for that is here https://github.com/openstack/nova/blob/5c0235a579ccb52f7bce5de9bcb3c927c94b23b7/nova/tests/functional/test_servers.py#L4871
13:42:47 mrch_ mriedem: what does "rebased" mean?
13:51:45 mriedem mrch_: i need to rebase it on the current master branch and resolve merge conflicts
13:51:51 mriedem i.e. it's an old patch
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

Earlier   Later