| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-07 | |||
| 17:31:47 | sean-k-mooney | so it proable should be moved into the linuxbridge pluging for os-vif | |
| 17:31:55 | sfinucan | sean-k-mooney: ...and even then, doesn't neutron have its own anti-spoofing stuff? | |
| 17:32:01 | sfinucan | e.g. http://kimizhang.com/neutron-ml2-port-security/ | |
| 17:32:03 | sean-k-mooney | for ovs yes | |
| 17:32:09 | sean-k-mooney | for linux bridge proably | |
| 17:32:13 | sean-k-mooney | not sure though | |
| 17:32:24 | sean-k-mooney | again i think this is mainly for nova-networks | |
| 17:32:25 | sfinucan | that blog suggests yes for linucbridge | |
| 17:32:31 | sfinucan | *linuxbridge | |
| 17:32:42 | openstackgerrit | Dan Smith proposed openstack/nova master: Add an update_cell command to nova-manage https://review.openstack.org/430354 | |
| 17:33:05 | sean-k-mooney | if you are using nova-netwokrs this code would be needed for firewall support because you would not have nova | |
| 17:33:09 | sean-k-mooney | * neutron | |
| 17:33:18 | nikeshm | lyarwood: qemu-utils 2.0.0+dfsg-2ubuntu1.30 amd64 QEMU utilities | |
| 17:33:23 | sean-k-mooney | nova-networks without nova would be hard | |
| 17:34:31 | sean-k-mooney | general question but is nova-networks dead yet? | |
| 17:35:06 | sean-k-mooney | can we actully start deleting the code for it. i kindof lost track of that effort | |
| 17:35:21 | lyarwood | nikeshm: and libvirt? | |
| 17:36:21 | nikeshm | lyarwood: libvirt-dev 1.2.2-0ubuntu13.1.17 amd64 development files for the libvirt library | |
| 17:40:34 | sfinucan | sean-k-mooney: Nope. It's there for another 2-3 cycles at least :( | |
| 17:41:10 | sean-k-mooney | :( really... why... | |
| 17:42:32 | sfinucan | sean-k-mooney: cells v1 | |
| 17:42:48 | sfinucan | need a migration path to cells v2 then another cycle for folks to switch over | |
| 17:42:49 | sean-k-mooney | cells v1 only works with nova-networks? | |
| 17:43:45 | sfinucan | from the looks of things, yup | |
| 17:43:57 | sean-k-mooney | sfinucan: so ocate cells v2 pike miragtion and queens remove nova networks? | |
| 17:44:20 | sfinucan | nope. cells v2 isn't complete yet | |
| 17:44:28 | sean-k-mooney | hum ok i taught cells v1 worked with neutron i guess not. | |
| 17:44:35 | sfinucan | you can't use more than one cell in cells v2 | |
| 17:44:54 | mriedem | sean-k-mooney: sfinucan: you can use neutron with cells v1 | |
| 17:44:58 | mriedem | godaddy is running ovs | |
| 17:45:07 | mriedem | it requires patches for the external vif plug event callbackstuff | |
| 17:45:10 | mriedem | but people are doing it | |
| 17:45:14 | sfinucan | mriedem: So what's the tie with nova-net? | |
| 17:45:24 | mriedem | nova-net will only start in ocata if running cells v1 | |
| 17:45:24 | sfinucan | I thought that was the one blocker stopping us killing it | |
| 17:45:36 | mriedem | nova-net will go when cells v1 goes | |
| 17:45:41 | sfinucan | right, but not the other way round | |
| 17:45:48 | sfinucan | ? | |
| 17:46:00 | mriedem | right | |
| 17:46:10 | lyarwood | nikeshm: hmmm can you document this in a bug and I'll take a look this evening? I can't reproduce that locally on Fedora 24 | |
| 17:46:18 | sfinucan | so why don't we keep cells v1 (which doesn't have a complete migration path) and kill nova-net (which does - neutron) | |
| 17:46:42 | mriedem | sfinucan: because then we'd have to switch the cells v1 CI job to neutron, | |
| 17:46:52 | mriedem | and we don't have that external vif plugging callback stuff plumbed into cells v1 upstream | |
| 17:47:00 | mriedem | which would require work to make cells v1 work with nova in our CI | |
| 17:47:12 | mriedem | work we don't care to do for something that we're effectively crippling and setting up to remove | |
| 17:48:13 | sfinucan | mriedem: ah, so it's a non-trivial amount of work | |
| 17:48:19 | mriedem | correct | |
| 17:48:34 | sfinucan | Gotcha. I didn't get that link. Thanks for clearing it up | |
| 17:48:50 | mriedem | np | |
| 17:49:33 | sfinucan | mikal: Do I recall talk of file injection going away? | |
| 17:49:35 | sean-k-mooney | sfinucan: so back to your original question we proably have to keep that function untill cells v1 goes... or move it to the linux bridge os-vif driver | |
| 17:49:49 | sfinucan | sean-k-mooney: That would sound about right | |
| 17:50:19 | mriedem | blam! pike is the current focus of dev now https://launchpad.net/nova | |
| 17:50:33 | sfinucan | But we probably don't need to keep it after that point, because neutron can do what libvirt is doing here | |
| 17:51:24 | sfinucan | ...and what libvirt is doing probably wouldn't even work for folks using OVS and/or security groups, which is most people if the surveys are to be believed | |
| 17:55:58 | mriedem | sfinucan: i plan on proposing a spec for pike to deprecate file injection (personalities) in the REST API (outside of config drive anyway) | |
| 17:56:34 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2016-November/107195.html | |
| 17:56:35 | mdbooth | mriedem: Fun. Does that mean nobody is using that? | |
| 17:57:16 | mriedem | via config drive or the personality files or just in general? | |
| 17:57:32 | gabor_antal_ | Hey there, may I ask a question? Is it okay if I update test-requirements with a newer version of hacking? | |
| 17:57:45 | mdbooth | cfriesen mriedem: Incidentally, IIRC that also fails for config drives because we're constantly blowing config drives away and rebuilding them. | |
| 17:58:05 | mriedem | gabor_antal_: requirements changes to nova go through the openstack/requirements repo, and updating hacking there is a global change which impacts all projects, | |
| 17:58:10 | mriedem | gabor_antal_: so it's a large undertaking | |
| 17:58:55 | mriedem | mdbooth: http://lists.openstack.org/pipermail/openstack-dev/2016-November/107195.html was also in the operators list and go no responses | |
| 17:58:59 | auggy | nova bugs team meeting at the top of the hour in #openstack-meeting-4 ! | |
| 17:59:02 | mriedem | so i have no idea how much it's used | |
| 18:00:00 | johnthetubaguy | honestly, I am not sure as operators if they would know either | |
| 18:00:04 | openstackgerrit | Diana Clarke proposed openstack/nova master: Reduce the number of COMMIT & SELECT 1 statements https://review.openstack.org/430390 | |
| 18:00:09 | gabor_antal_ | mriedem: Should we propose to that repo or where? I just checked the new hacking, and has a great feature | |
| 18:00:40 | mriedem | gabor_antal_: if you're going to propose it, it starts in the openstack/requirements repo | |
| 18:03:46 | gabor_antal_ | mriedem: I think I wanted to push this, but that is already merged: https://review.openstack.org/#/c/409626/ | |
| 18:04:31 | mriedem | gabor_antal_: oh so we just need to update https://github.com/openstack/nova/blob/master/test-requirements.txt#L5 | |
| 18:04:48 | mriedem | i didn't realize hacking was excluded from global updates | |
| 18:04:53 | mriedem | then i guess it's simpler since it's just nova | |
| 18:05:19 | gabor_antal_ | Yeah, so then it's okay if I modify this line, | |
| 18:35:09 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Fix races with nfs volume mount/umount https://review.openstack.org/383859 | |
| 18:52:22 | openstackgerrit | Sean McCully proposed openstack/nova master: allocations.consumer_id is not used in query. https://review.openstack.org/430399 | |
| 19:00:25 | openstackgerrit | John Garbutt proposed openstack/nova master: Stop _undefine_domain erroring if domain not found https://review.openstack.org/430400 | |
| 19:02:58 | cdent | edleafe, bauzas: didn't we already have a fix like 430399 ^^ before? | |
| 19:15:05 | openstackgerrit | John Garbutt proposed openstack/nova master: WIP: Stop leaving failed live-migrates in the migrating state https://review.openstack.org/430404 | |
| 19:15:43 | cdent | edleafe, bauzas never mind, it's not, it's the same problem somewhere else | |
| 19:17:05 | johnthetubaguy | mriedem: FYI, there seems to be another nastly little live-migrate bug that has cropped up in our testing: https://review.openstack.org/430400 | |
| 19:17:21 | johnthetubaguy | mriedem: still investigation, just a general heads up that stuff is cooking there | |
| 19:19:52 | mriedem | johnthetubaguy: ok i've left my -1 for your dessert :) | |
| 19:24:12 | openstackgerrit | Sean McCully proposed openstack/nova master: allocations.consumer_id is not used in query. https://review.openstack.org/430399 | |
| 19:50:24 | cfriesen | johnthetubaguy: got a theory on the race in https://bugs.launchpad.net/nova/+bug/1662626 between live migration and deletion. instance deletion synchronizes on instance.uuid, but I don't think _post_live_migration() does. | |
| 19:50:24 | openstack | Launchpad bug 1662626 in OpenStack Compute (nova) "live-migrate left in migrating as domain not found" [Undecided,In progress] - Assigned to John Garbutt (johngarbutt) | |
| 20:02:31 | johnthetubaguy | cfriesen: it could be, I need to look at what the periodic tasks are doing, there is just a loop of live-migrates on a test rig for this test, AFAIK. | |
| 20:02:50 | johnthetubaguy | mriedem: yeah, you are right, I meant to look that up, but wanted dinner | |
| 20:04:51 | cfriesen | question...if instance.old_flavor refers to a deleted flavor, will it still be able to load it from the DB? | |
| 20:28:52 | mriedem | cfriesen: yes | |
| 20:29:08 | mriedem | the old_flavor is stored in the extras table | |
| 20:29:26 | mriedem | *instance_extra | |
| 20:38:14 | cfriesen | do we allow resizing from a flavor with ephemeral/swap to a flavor without? I only see a check for root_gb. | |
| 20:38:18 | cfriesen | mriedem: thanks | |
| 20:43:20 | openstackgerrit | Emilien Macchi proposed openstack/nova master: DNM - test tripleo without nova api in WSGI/apache https://review.openstack.org/429008 | |
| 20:43:49 | openstackgerrit | Maciej Szankin proposed openstack/nova master: conf: mark glance.api_servers opt as required https://review.openstack.org/428241 | |
| 21:03:15 | smcginnis | johnthetubaguy: Start here: https://review.openstack.org/#/c/297140/ | |
| 21:03:28 | smcginnis | johnthetubaguy: Then here: https://review.openstack.org/#/c/346438/ | |
| 21:04:28 | smcginnis | johnthetubaguy: Actually, the second one isn't the one I was looking for. This one might be more interesting: https://review.openstack.org/#/c/346470/ | |