| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-08 | |||
| 12:54:17 | jangutter | sean-k-mooney: when the port gets plugged into OVS, there's an interface_id UUID added to the OVSDB config. | |
| 12:54:45 | sean-k-mooney | yes that is pulled form the ID field in the base os-vif VIF object | |
| 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 | |