| *** mili__ has joined #openstack-neutron | 00:07 | |
| *** mili_ has quit IRC | 00:11 | |
| *** mili__ has quit IRC | 00:15 | |
| *** mili_ has joined #openstack-neutron | 00:15 | |
| *** clev has quit IRC | 00:27 | |
| *** mili_ has quit IRC | 00:43 | |
| *** aymenfrikha has quit IRC | 00:43 | |
| *** yongli has joined #openstack-neutron | 01:05 | |
| *** banix has joined #openstack-neutron | 01:10 | |
| *** banix has quit IRC | 01:18 | |
| *** banix has joined #openstack-neutron | 01:20 | |
| *** banix has quit IRC | 01:36 | |
| *** otherwiseguy has quit IRC | 01:41 | |
| *** Jianyong has joined #openstack-neutron | 01:46 | |
| *** WackoRobie has quit IRC | 02:54 | |
| *** dguitarbite has joined #openstack-neutron | 03:22 | |
| *** dguitarbite has quit IRC | 03:34 | |
| *** banix has joined #openstack-neutron | 03:35 | |
| openstackgerrit | A change was merged to openstack/neutron: Remove unused imports https://review.openstack.org/64605 | 03:45 |
|---|---|---|
| *** nati_ueno has joined #openstack-neutron | 04:04 | |
| *** changbl has quit IRC | 04:05 | |
| *** changbl has joined #openstack-neutron | 04:10 | |
| *** nati_ueno has quit IRC | 04:16 | |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/python-neutronclient: Refactor tests/unit/test_shell.py https://review.openstack.org/41615 | 04:28 |
| *** bashok has joined #openstack-neutron | 04:42 | |
| *** julim has joined #openstack-neutron | 04:46 | |
| *** jecarey has joined #openstack-neutron | 04:53 | |
| *** banix has quit IRC | 04:57 | |
| *** h6w has joined #openstack-neutron | 05:07 | |
| *** bashok has quit IRC | 05:09 | |
| *** bashok has joined #openstack-neutron | 05:09 | |
| h6w | Quick question. If I want my VMs to be accessible to other machines on the VLAN, what overlaps in terms of ranges. Is it the "Public" address range, the "Floating IP" address range, both, or something else? | 05:11 |
| h6w | It seems that if I connect the VM to the "Public" network, it's assigned an IP according to Horizon, but there's no DHCP on the network so it doesn't get assigned that IP. | 05:15 |
| h6w | However, if I assign it the IP given by Horizon (ip a a <ipaddr> dev eth0) then I can ping/access the rest of the same network. | 05:29 |
| *** ashaikh_ has joined #openstack-neutron | 05:37 | |
| *** ashaikh has quit IRC | 05:38 | |
| *** ashaikh_ is now known as ashaikh | 05:38 | |
| *** bashok_ has joined #openstack-neutron | 05:38 | |
| *** bashok__ has joined #openstack-neutron | 05:39 | |
| *** bashok_ has quit IRC | 05:39 | |
| *** bashok has quit IRC | 05:42 | |
| *** yfried has quit IRC | 05:46 | |
| *** chandankumar has joined #openstack-neutron | 05:48 | |
| *** networkstatic has quit IRC | 06:01 | |
| *** jistr has joined #openstack-neutron | 06:08 | |
| *** h6w has left #openstack-neutron | 06:09 | |
| *** networkstatic has joined #openstack-neutron | 06:22 | |
| openstackgerrit | Jenkins proposed a change to openstack/neutron: Imported Translations from Transifex https://review.openstack.org/63877 | 06:34 |
| *** zhhuabj has quit IRC | 06:44 | |
| *** zhhuabj has joined #openstack-neutron | 06:44 | |
| *** evgenyf has joined #openstack-neutron | 06:50 | |
| *** zigo has joined #openstack-neutron | 06:56 | |
| *** yfried has joined #openstack-neutron | 06:59 | |
| *** Jianyong has quit IRC | 07:03 | |
| *** garyk has joined #openstack-neutron | 07:03 | |
| *** Jianyong has joined #openstack-neutron | 07:06 | |
| *** ashaikh has quit IRC | 07:21 | |
| *** irenab_ has joined #openstack-neutron | 07:29 | |
| *** sputnik13 has joined #openstack-neutron | 07:37 | |
| *** majopela has joined #openstack-neutron | 08:04 | |
| *** amuller has joined #openstack-neutron | 08:07 | |
| *** dguitarbite_ has joined #openstack-neutron | 08:12 | |
| *** ihrachys has joined #openstack-neutron | 08:17 | |
| *** pasquier-s has joined #openstack-neutron | 08:21 | |
| yfried | salv-orlando: ping | 08:24 |
| *** jlibosva has joined #openstack-neutron | 08:28 | |
| irenab_ | hi, any chance someone can review https://review.openstack.org/#/c/53609/ ? | 08:35 |
| majopela | hi irenab_, on it, | 08:41 |
| majopela | :) | 08:41 |
| irenab_ | majopela: thanks! | 08:42 |
| *** amuller has quit IRC | 08:46 | |
| *** amuller_ has joined #openstack-neutron | 08:46 | |
| *** jpich has joined #openstack-neutron | 09:00 | |
| *** ygbo has joined #openstack-neutron | 09:03 | |
| *** amuller_ has quit IRC | 09:15 | |
| *** amuller_ has joined #openstack-neutron | 09:24 | |
| *** amuller_ is now known as amuller | 09:25 | |
| *** tziOm has joined #openstack-neutron | 09:29 | |
| *** networkstatic has quit IRC | 10:00 | |
| *** sputnik13 has quit IRC | 10:17 | |
| openstackgerrit | Sean M. Collins proposed a change to openstack/neutron: Ensure entries in dnsmasq belong to a subnet using DHCP https://review.openstack.org/64578 | 10:25 |
| *** Jianyong has quit IRC | 10:30 | |
| *** dguitarbite_ has quit IRC | 10:43 | |
| yfried | salv-orlando: ping | 10:43 |
| tziOm | Anyone with some deeper insight to the ovs/vxlan implementation used in ovs/neutron? | 10:59 |
| *** pcm has joined #openstack-neutron | 11:13 | |
| *** pcm has quit IRC | 11:14 | |
| *** pcm has joined #openstack-neutron | 11:14 | |
| majopela | tziOm, what do you want to know exactly? (just curious, probably I don't have a deep enough insight) | 11:15 |
| tziOm | From what I can see, the one must specify endpoint ip or "flow" .. the way I am thinking, this kindoff breaks the good concept of vxlan.. using multicast to do neigbour-discovery (arp) and havind a bridge "arp" table for the vxlan link.. | 11:18 |
| tziOm | afaik this implementation demands that one plugs in a openflow switch (?) for the control, instead of the vxlan "interface" doing the job.. | 11:19 |
| majopela | I'm not sure if openvswitch does already implement vxlan multicast | 11:23 |
| majopela | and, about openflow, it does use it under the hood, yes | 11:24 |
| majopela | but in software, you don't need to use a physical openflow switch... | 11:25 |
| *** bashok__ has quit IRC | 11:28 | |
| *** jroovers has joined #openstack-neutron | 11:30 | |
| *** jorisroovers has joined #openstack-neutron | 11:39 | |
| *** jroovers has quit IRC | 11:41 | |
| *** WackoRobie has joined #openstack-neutron | 12:06 | |
| *** armax has joined #openstack-neutron | 12:10 | |
| *** WackoRobie has quit IRC | 12:10 | |
| openstackgerrit | Akihiro Motoki proposed a change to openstack/neutron: Return request-id in API response https://review.openstack.org/58270 | 12:13 |
| *** aymenfrikha has joined #openstack-neutron | 12:16 | |
| *** zzelle has joined #openstack-neutron | 12:25 | |
| *** jdev789 has joined #openstack-neutron | 12:32 | |
| *** jistr has quit IRC | 12:39 | |
| *** aymenfrikha has quit IRC | 12:48 | |
| *** jdev789 has quit IRC | 12:48 | |
| *** jorisroovers has quit IRC | 12:49 | |
| *** markvoelker has joined #openstack-neutron | 12:52 | |
| *** b3nt_pin` is now known as beagles | 12:59 | |
| *** [1]evgenyf has joined #openstack-neutron | 13:00 | |
| *** beagles is now known as Guest7975 | 13:00 | |
| *** evgenyf has quit IRC | 13:02 | |
| *** [1]evgenyf is now known as evgenyf | 13:02 | |
| *** aymenfrikha has joined #openstack-neutron | 13:04 | |
| *** jdev789 has joined #openstack-neutron | 13:05 | |
| openstackgerrit | A change was merged to openstack/neutron: Fix empty network deletion in db_base_plugin for postgresql https://review.openstack.org/63597 | 13:05 |
| *** jistr has joined #openstack-neutron | 13:07 | |
| *** Guest7975 has quit IRC | 13:08 | |
| *** b3nt_pin has joined #openstack-neutron | 13:12 | |
| *** Jianyong has joined #openstack-neutron | 13:12 | |
| openstackgerrit | enikanorov proposed a change to openstack/neutron: Fix race in get_network(s) in OVS plugin https://review.openstack.org/63918 | 13:15 |
| *** sputnik13 has joined #openstack-neutron | 13:22 | |
| *** sputnik13 has quit IRC | 13:27 | |
| *** yfried has quit IRC | 13:30 | |
| *** WackoRobie has joined #openstack-neutron | 13:35 | |
| anteaya | whoever tobbe at tail-f dot com is, let's get some stable urls and logs in the Tail-f NCS Jenkins third party testing messages, failure messages with no logs are pretty useless to developers https://review.openstack.org/#/c/63918/ | 13:42 |
| *** b3nt_pin is now known as beagles | 13:44 | |
| openstackgerrit | Sean M. Collins proposed a change to openstack/neutron: Ensure entries in dnsmasq belong to a subnet using DHCP https://review.openstack.org/64578 | 13:44 |
| sc68cal | anteaya: ++++++++ a million | 13:49 |
| openstackgerrit | Paul Michali proposed a change to openstack/neutron: Remove duplication for get_resources in services https://review.openstack.org/64676 | 13:49 |
| *** bvandenh has joined #openstack-neutron | 13:57 | |
| *** irenab_ has quit IRC | 13:58 | |
| *** aymenfrikha has quit IRC | 14:01 | |
| *** aymenfrikha has joined #openstack-neutron | 14:01 | |
| *** rkukura has left #openstack-neutron | 14:05 | |
| *** s3wong has joined #openstack-neutron | 14:06 | |
| *** peristeri has joined #openstack-neutron | 14:07 | |
| *** aymenfrikha has quit IRC | 14:11 | |
| anteaya | sc68cal: http://lists.openstack.org/pipermail/openstack-dev/2014-January/023292.html | 14:11 |
| *** rkukura has joined #openstack-neutron | 14:12 | |
| *** [1]evgenyf has joined #openstack-neutron | 14:15 | |
| sc68cal | anteaya: thanks - I'm not surprised that this topic is causing a vendor plugin to barf - https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/dnsmasq-mode-keyword,n,z | 14:15 |
| sc68cal | But we're trying to make IPv6 work correctly in Neutron with the Comcast IPv6 deployment | 14:16 |
| sc68cal | as well as make it more flexible, for some of the other ways v6 is being deployed by other Neutron users | 14:16 |
| *** evgenyf has quit IRC | 14:17 | |
| *** [1]evgenyf is now known as evgenyf | 14:17 | |
| sc68cal | But no logs mean we have no way to figure out what to fix | 14:18 |
| anteaya | no logs for any reason is unhelpful | 14:18 |
| anteaya | logs need to come before voting | 14:19 |
| anteaya | we are working on that in the documentation | 14:19 |
| anteaya | now if you want to take a look at two projects that really get it right, check out smokestack and turbo-hipster | 14:19 |
| sc68cal | anteaya: Gotcha. Yeah I might spend a sprint doing a spike on third party testing. We've got a full lab environment that I have set up with DevStack for v6 testing | 14:20 |
| sc68cal | so I might build a bot to start running tempest tests on it - although our deployment has some differences, so we'd need to add some config knobs to Tempest | 14:21 |
| sc68cal | For instance, we don't run the l3 agent, so no floating IPs, and Tempest assumes that floating IPs always exist | 14:21 |
| sc68cal | I think it requests some, and when it comes back with none it just sits there, confused. | 14:22 |
| anteaya | here is a great example of how to respond to an email about third party testing: http://lists.openstack.org/pipermail/openstack-dev/2013-December/023247.html | 14:22 |
| anteaya | this is uselful | 14:22 |
| anteaya | for those listening at home | 14:22 |
| anteaya | hmmm | 14:22 |
| anteaya | well ensure the logs cover those changes | 14:22 |
| anteaya | so we know what is being tested | 14:23 |
| sc68cal | yup | 14:23 |
| anteaya | you know you can stand up a jenkins and get a gerrit plug in to listen to our output stream? | 14:23 |
| sc68cal | anteaya: yep | 14:23 |
| anteaya | so you can minimize your work | 14:23 |
| anteaya | and you can take the code for our entire testing infra if you want it | 14:24 |
| anteaya | puppet stands it up | 14:24 |
| anteaya | I haven't done that one myself yet, I can't find the time *sigh* | 14:24 |
| anteaya | but I want to | 14:24 |
| sc68cal | Yeah - we'd need to slice up our lab env a bit for that, since the 3 machines are currently being used for dev/qa | 14:25 |
| sc68cal | before we could hand it totally over to puppet | 14:25 |
| sc68cal | might be able to do that for some of the machines currently dedicated to QA | 14:25 |
| *** jprovazn has joined #openstack-neutron | 14:28 | |
| anteaya | sc68cal: interesting | 14:32 |
| anteaya | keep me informed on your progress and I will do what I can to help | 14:32 |
| anteaya | keeping in mind, I haven't sailed that ship myself yet | 14:32 |
| *** aymenfrikha has joined #openstack-neutron | 14:35 | |
| *** jdev789 has quit IRC | 14:45 | |
| *** jdev789 has joined #openstack-neutron | 14:46 | |
| *** jdev789 has quit IRC | 14:46 | |
| *** clev has joined #openstack-neutron | 14:52 | |
| *** markmcclain has quit IRC | 14:54 | |
| *** Jianyong has quit IRC | 14:54 | |
| *** amuller has quit IRC | 14:58 | |
| *** jdev789 has joined #openstack-neutron | 14:59 | |
| *** jdev789 has quit IRC | 15:01 | |
| *** yfried has joined #openstack-neutron | 15:04 | |
| *** otherwiseguy has joined #openstack-neutron | 15:06 | |
| anteaya | otherwiseguy: hello there | 15:12 |
| anteaya | are you free to help the neutron quality cause? | 15:12 |
| anteaya | we could use you | 15:12 |
| *** dkehn_ is now known as dkehn | 15:17 | |
| *** clev has quit IRC | 15:20 | |
| *** s3wong has quit IRC | 15:25 | |
| *** markmcclain has joined #openstack-neutron | 15:26 | |
| *** aymenfrikha has quit IRC | 15:35 | |
| *** clev has joined #openstack-neutron | 15:35 | |
| *** bvandenh has quit IRC | 15:36 | |
| openstackgerrit | Amir Sadoughi proposed a change to openstack/python-neutronclient: Added --source-port-range-min, --source-port-range-max https://review.openstack.org/62130 | 15:44 |
| *** banix has joined #openstack-neutron | 15:44 | |
| *** haleyb has joined #openstack-neutron | 15:51 | |
| *** clev has quit IRC | 15:52 | |
| *** clev has joined #openstack-neutron | 15:53 | |
| *** ashaikh has joined #openstack-neutron | 15:54 | |
| *** alagalah has joined #openstack-neutron | 16:02 | |
| *** thedodd has joined #openstack-neutron | 16:08 | |
| *** jgrimm has joined #openstack-neutron | 16:12 | |
| *** thedodd has quit IRC | 16:16 | |
| ihrachys | hi. is it enough to set 'qpid_topology_version = 2' in neutron.conf to make sure neutron uses the new topology for its interactions? How can I check which topology is currently using by neutron (or any other openstack module)? | 16:17 |
| *** jprovazn has quit IRC | 16:19 | |
| *** thedodd has joined #openstack-neutron | 16:21 | |
| *** markmcclain has quit IRC | 16:21 | |
| *** jlibosva has quit IRC | 16:25 | |
| *** jlibosva has joined #openstack-neutron | 16:28 | |
| *** mlavalle has joined #openstack-neutron | 16:29 | |
| *** yfried is now known as yfried_brb | 16:30 | |
| *** jprovazn has joined #openstack-neutron | 16:30 | |
| *** jistr has quit IRC | 16:32 | |
| anteaya | lots of test failures happening right now, debugging is happening in -infra | 16:38 |
| anteaya | early direction might be a new MySQL_python release that happened today | 16:38 |
| anteaya | if so, global requirements should send out a version pin which will be a high priority patch | 16:40 |
| anteaya | watch for it, I will probably be offline when it happens | 16:41 |
| *** yfried_brb is now known as yfried | 16:42 | |
| openstackgerrit | A change was merged to openstack/neutron: Imported Translations from Transifex https://review.openstack.org/63877 | 16:44 |
| openstackgerrit | Yves-Gwenael Bourhis proposed a change to openstack/neutron: Changed DictModel to dict with attribute access. https://review.openstack.org/64696 | 16:46 |
| anteaya | my cab is here, see you | 16:49 |
| *** carl_baldwin has joined #openstack-neutron | 16:57 | |
| *** amuller has joined #openstack-neutron | 17:01 | |
| *** garyk has quit IRC | 17:06 | |
| *** zz_ajo is now known as ajo | 17:07 | |
| *** SumitNaiksatam has quit IRC | 17:18 | |
| *** ygbo has quit IRC | 17:18 | |
| *** jaypipes has joined #openstack-neutron | 17:18 | |
| *** jaypipes has quit IRC | 17:19 | |
| *** markmcclain has joined #openstack-neutron | 17:24 | |
| *** rwsu has joined #openstack-neutron | 17:27 | |
| *** aymenfrikha has joined #openstack-neutron | 17:29 | |
| *** mlavalle has quit IRC | 17:32 | |
| *** jpich has quit IRC | 17:33 | |
| *** evgenyf has quit IRC | 17:35 | |
| enikanorov__ | salv-orlando: Hi | 17:35 |
| salv-orlando | hi | 17:35 |
| enikanorov__ | good you are here :) I wanted to ask about NeutronDbPluginV2.register_dict_extend_funcs capability. You have introduced this, haven't you? | 17:36 |
| salv-orlando | yes, I did. | 17:37 |
| salv-orlando | I'm the one who's guilty of that crime. | 17:37 |
| enikanorov__ | the question would be: what were the reasons to make it a class method and store the dict in the class rather than in the instance | 17:37 |
| salv-orlando | the fact that we don't have a reliable way of invoking __init__ for a mixin | 17:38 |
| salv-orlando | or to have e mechanism in the base db class which initialises the mixins before using them | 17:38 |
| salv-orlando | as the plugins are instructed to *NOT* call super.__init__ | 17:38 |
| enikanorov__ | ok, I knew there should be reasons... | 17:39 |
| enikanorov__ | so here's the problem I'm trying to fix: | 17:39 |
| enikanorov__ | i'm trying to add a relationship and another dict_extend method for ovs plugin | 17:40 |
| *** alagalah has quit IRC | 17:40 | |
| enikanorov__ | in the usual way it is done in mixins | 17:40 |
| *** jaypipes has joined #openstack-neutron | 17:40 | |
| enikanorov__ | but i'm getting lots of ut failures, because mapping persists in NeutronDbPluginV2 | 17:41 |
| *** jlibosva has quit IRC | 17:41 | |
| *** jlibosva has joined #openstack-neutron | 17:41 | |
| enikanorov__ | I'm a bit stuck because the way register_dict_extend_funcs works is for a whole lifetime of application | 17:42 |
| enikanorov__ | so i can't reset it in reliable way | 17:42 |
| salv-orlando | since the method is added to the class | 17:42 |
| enikanorov__ | (by saying 'application i mean unit tests) | 17:42 |
| salv-orlando | it stays even when you switch plugins | 17:42 |
| enikanorov__ | yeah | 17:43 |
| salv-orlando | but I think we solved this by allowing to use a stringified form | 17:43 |
| salv-orlando | do you have this patch in gerrit? | 17:43 |
| enikanorov__ | yes | 17:43 |
| salv-orlando | link? | 17:43 |
| jaypipes | enikanorov__, salv-orlando: Happy New Year :) Do you agree with Amir on this bug: https://bugs.launchpad.net/neutron/+bug/1264608 that the bug should go into a blueprint? | 17:43 |
| enikanorov__ | salv-orlando: https://review.openstack.org/#/c/63918/ | 17:43 |
| salv-orlando | jaypipes: I did not see this bug beforehand. looking at it. | 17:45 |
| jaypipes | cheers | 17:45 |
| salv-orlando | enikanorov__: looking at your patch too | 17:47 |
| *** layer427expert has joined #openstack-neutron | 17:47 | |
| enikanorov__ | running two threads, huh? | 17:47 |
| enikanorov__ | :-) | 17:47 |
| *** layer427expert has quit IRC | 17:49 | |
| *** harlowja has joined #openstack-neutron | 17:49 | |
| *** layer427expert has joined #openstack-neutron | 17:50 | |
| *** layer427_ has joined #openstack-neutron | 17:50 | |
| *** layer427expert has quit IRC | 17:50 | |
| salv-orlando | enikanorov__: left a comment for you on gerrit. I think I have a hint to the reason of the failure. | 17:53 |
| enikanorov__ | let me see. also i think i've found a solution | 17:53 |
| enikanorov__ | yeah | 17:53 |
| enikanorov__ | thats' what i think too. i need just to rename it | 17:54 |
| salv-orlando | jaypipes: the bug is definitely valid. To me it could be both a bug or a blueprint, depending on the extent of the changes needed. | 17:54 |
| salv-orlando | Are you confident that just by grouping ovs-vsctl calls you'll get better performance? | 17:54 |
| salv-orlando | In the past I did not notice much difference (gain <10%) | 17:54 |
| salv-orlando | because that's something I tried for other reasons... | 17:55 |
| jaypipes | salv-orlando: yes. It took >1 hour to start the plugin with only 90 compute nodes. | 17:55 |
| salv-orlando | jaypipes: so I guess you did restart the agent on all compute nodes. | 17:55 |
| jaypipes | salv-orlando: during this time the l3 router node just crunched away at about 10 load agvg. | 17:56 |
| jaypipes | salv-orlando: yep. | 17:56 |
| jaypipes | oh, .... no, not the compute nodes. | 17:56 |
| jaypipes | only restarted the l3 router node agent plugin. | 17:56 |
| jaypipes | salv-orlando: OVS 2.0 would certainly help, but we were on OVS 1.11 on this particular deployment. | 17:57 |
| salv-orlando | jaypipes: got it. Did you restart the l3-agent as well? | 17:57 |
| *** garyk has joined #openstack-neutron | 17:57 | |
| jaypipes | salv-orlando: yes. | 17:57 |
| salv-orlando | help me… I do not remember is OVS 1.11 has multithreaded vswitchd | 17:57 |
| jaypipes | salv-orlando: nope, 2.0 has multi-thread | 17:57 |
| salv-orlando | jaypipes: thanks. Are startup times for the l3 agent long as well or are they 'normal'? | 17:59 |
| *** mlavalle has joined #openstack-neutron | 17:59 | |
| jaypipes | salv-orlando: can't remember :( since the L3 agent calls out to the ovs-plugin-agent, I think it's affected as well, but I'm not entirely sure | 18:00 |
| salv-orlando | I'm asking this because actually you restarted only one agent - so the size of the zone in terms of compute nodes is probably not the problem, which might instead lie in the load being handled by the l3 agent in terms of number of routers and interfaces | 18:00 |
| jaypipes | salv-orlando: the size of the zone dictates how many calls to ovs-vsctl add-br et al are made. | 18:01 |
| jaypipes | salv-orlando: since for each compute node, at least an add-br, add-tun is called. | 18:01 |
| jaypipes | or rather, add br-int, add br-tun | 18:01 |
| salv-orlando | jaypipes: sure, but you just told me that you restarted the plugin agent on one node only (the one hosting the network node), and not on all compute nodes :) | 18:02 |
| jaypipes | salv-orlando: and all of those calls are so slow because they all go through a rootwrap process | 18:02 |
| jaypipes | salv-orlando: if you combine all those calls into a single call to rootwrap ovs-vsctl add-br-int -- add br-tun ... -- add br-int ... -- add br-tun ..., etc ... then the call is much much faster to complete. | 18:03 |
| jaypipes | salv-orlando: yes, only restarted the agent on the L3 router node, not the compute nodes. | 18:03 |
| jaypipes | salv-orlando: but it still calls out to add a bunch of bridge int patches and tuns on restart. | 18:04 |
| jaypipes | salv-orlando: perhaps that is the true bug? :) | 18:04 |
| salv-orlando | yeah perhaps… because it should create, for each node, be it compute or network, only ONE integration bridge and only ONE tunnel bridge | 18:05 |
| salv-orlando | even if you're using provider networks mapped to vlans | 18:05 |
| *** bjornar has joined #openstack-neutron | 18:05 | |
| jaypipes | salv-orlando: yes, but with a hundred compute nodes, that's 200 interfaces, each of which gets its own rootwrap'd external process. | 18:05 |
| *** layer427_ has quit IRC | 18:05 | |
| salv-orlando | jaypipes: ok, you're talking about the ports, not the bridges :) Yes, it's more clear now. I got misled because you said 'ovs-vsctl add' and I thought add bridge | 18:06 |
| jaypipes | salv-orlando: so, when you restart the L3 agent, and do a ps aux | grep python | grep ovs (or similar), you see, for about two hours, various python processes spawning running rootwrap'd ovs-vsctl commands setting up each and every int bridge and tun for each compute node. | 18:06 |
| jaypipes | salv-orlando: ah, sorry, ports, yes... | 18:07 |
| jaypipes | salv-orlando: sorry about that! | 18:07 |
| jaypipes | salv-orlando: /me still relatively new to these things. | 18:07 |
| salv-orlando | no problem. I've doing this for longer, but most of them are still new to me. | 18:07 |
| jaypipes | hehe :) | 18:07 |
| *** layer427expert has joined #openstack-neutron | 18:07 | |
| jaypipes | salv-orlando: as peter feiner has pointed out on numerous occasions, rootwrap is deadly slow, so combining commands into a single call to a rootwrap'd process is a big time win.\ | 18:09 |
| *** layer427expert has quit IRC | 18:09 | |
| *** amuller has quit IRC | 18:12 | |
| salv-orlando | jaypipes: I am looking at the code to refresh about current status. root wrap is an issue, but single command execution might become challenging because tunnel port setup also requires flow setup (ovs-ofctl); in a nutshell I seem to recall 1 ovs-vsctl call and 2 ovs-ofctl call for each port. So in your case you should be able to go down from 600 calls to 401, which is already a good win | 18:12 |
| salv-orlando | jaypipes: and on another note, for a much better handling of tunnels, you should enable l2_population on the ovs agent; but I think you've already done that | 18:14 |
| jaypipes | salv-orlando: well, you could go even further than that, and do all the vsctl commands in one rootwrap'd call and all the ovs-ofctl calls in a second one. | 18:15 |
| jaypipes | salv-orlando: yes, we enabled l2_population. | 18:15 |
| salv-orlando | jaypipes: as these commands have runtime-dependent parameters, you should probably create on-the-fly a sort of script to feed to root wrap and then execute it. | 18:16 |
| salv-orlando | not sure how folks will see executing code generated from the code itself. | 18:16 |
| salv-orlando | but that is surely a way to work around the root wrap overhead | 18:17 |
| jaypipes | salv-orlando: yes, exactly. | 18:17 |
| *** layer427expert has joined #openstack-neutron | 18:18 | |
| salv-orlando | on the other hand you're observing huge startup times, which will make your clouds just useless | 18:19 |
| *** networkstatic has joined #openstack-neutron | 18:20 | |
| salv-orlando | so I wonder what percentage of this time is the root wrap overhead. If you have 200 nodes, assuming at least 1 vm on each node, you will need 199 tunnels on each host. | 18:20 |
| jaypipes | correct. | 18:21 |
| openstackgerrit | enikanorov proposed a change to openstack/neutron: Fix race in get_network(s) in OVS plugin https://review.openstack.org/63918 | 18:21 |
| *** markmcclain has quit IRC | 18:21 | |
| salv-orlando | and if setting up a tunnel takes 3600 seconds, that is about 18 seconds per tunnel, which is a lot. It would be great to measure how much is the root wrap overhead. | 18:22 |
| salv-orlando | Because I've been chasing as well failures due to ovs-vsctl taking a lot of time, but in my case switching to OVS 2.0 solved everything. | 18:22 |
| jaypipes | salv-orlando: but if you use the batched version of the ovs-vsctl CLI tool, you do a singular transaction within OVS to create multiple ports... so you get both the speedup of removing the multiple rootwrap calls as well as the speedup frmo having a single call to OVS... | 18:24 |
| salv-orlando | jaypipes: while I agree on the former, I tried the latter and did not get much improvement, because the cli tool makes a distinct ovsdb call for each command you pass on the command line | 18:25 |
| jaypipes | salv-orlando: oh? I did not realize that... that is certainly not clear from the man pages. | 18:26 |
| salv-orlando | the man pages are from the user perspective, and yes that's a single transaction. | 18:26 |
| salv-orlando | but the interactions with the kernel driver are not atomic | 18:27 |
| salv-orlando | I mean sorry… they are atomic | 18:27 |
| salv-orlando | but they're passed one at a time. | 18:27 |
| salv-orlando | anyway - I noticed from the code that your bottleneck appear to be in tunnel_sync | 18:28 |
| salv-orlando | which is executed in the first iteration of rpc_loop | 18:28 |
| jaypipes | k | 18:28 |
| salv-orlando | is that correct? | 18:28 |
| *** layer427expert has quit IRC | 18:28 | |
| jaypipes | salv-orlando: tunnel_sync was one of the places, yes... the others were the methods that began with setup_xxx() in __init__(). | 18:31 |
| salv-orlando | jaypipes: right. From my analysis the setup_xxx methods should have a fixed execution time (i.e.: no loops there), but setup_tunnel_sync might take a long time, unless l2_population is enabled, which you have. So I'm still puzzled. | 18:32 |
| *** markwash has joined #openstack-neutron | 18:32 | |
| sdague | salv-orlando: any idea if ovs 2.0 is in the cloud archive for ubuntu? | 18:33 |
| salv-orlando | I did not find it last time I checked; I installed it from sources | 18:34 |
| *** mlavalle has quit IRC | 18:35 | |
| *** markmcclain has joined #openstack-neutron | 18:37 | |
| *** layer427expert has joined #openstack-neutron | 18:37 | |
| *** networkstatic has quit IRC | 18:38 | |
| *** chandankumar has quit IRC | 18:38 | |
| *** nati_ueno has joined #openstack-neutron | 18:39 | |
| salv-orlando | jaypipes: another thing to check with people more expert than me on tunnelling in the ovs agent is whether destroying and recreating the tunnel bridge at each restart is really needed | 18:40 |
| jaypipes | salv-orlando: indeed, it probably isn't, but because of the use of --existing, the code is executing it anyway. | 18:41 |
| *** jroovers has joined #openstack-neutron | 18:41 | |
| *** layer427expert has quit IRC | 18:42 | |
| salv-orlando | yeah, but to me seems the code is actually destroying the bridge and recreating it. Which means that it will take a lot of time to recreate ports which are exactly as before, and also will cause a data plane outage which is something that should be always avoided. | 18:44 |
| salv-orlando | I will check this probably tomorrow, I don't have any multi-host environment right now. | 18:44 |
| *** layer427expert has joined #openstack-neutron | 18:45 | |
| *** nati_ueno has quit IRC | 18:47 | |
| *** jroovers has quit IRC | 18:48 | |
| *** nati_ueno has joined #openstack-neutron | 18:49 | |
| *** networkstatic has joined #openstack-neutron | 18:49 | |
| *** SumitNaiksatam has joined #openstack-neutron | 18:49 | |
| *** nati_ueno has quit IRC | 18:54 | |
| bjornar | Is neutron using the vxlan implementation in ovs or the kernel one? | 18:55 |
| *** thedodd has quit IRC | 18:58 | |
| mestery | OVS | 18:58 |
| mestery | Although, with kernels 3.12 and OVS >= 2.0, the two are one and same, save for the multicast support in the kernel verison which OVS doesn't use. | 18:58 |
| *** markvoelker has quit IRC | 18:59 | |
| *** gizmoguy_ has quit IRC | 18:59 | |
| *** sc68cal has quit IRC | 18:59 | |
| bjornar | mestery, one and the same with 3.12? that means it uses kernel implementation in 3.12+ and ovs >= 2.0? | 19:00 |
| *** evgenyf has joined #openstack-neutron | 19:00 | |
| mestery | bjornar: Yes. If you have OVS >= 2.0, and linux kernel >= 3.12, the same API calls for VXLAN encap/decap are used by the OVS VXLAN code and the kernel VXLAN ports. | 19:01 |
| bjornar | Because I was playing a bit with it the other day (kernel with vxlan and ovs >= 2.0) and I dont really understand the ovs implementation (when it comes to option remote_ip and key .. as opposed to kernels much more useful multicast group and vni... | 19:01 |
| *** mili_ has joined #openstack-neutron | 19:01 | |
| bjornar | mestery, the ovs version is more of a "ptp-vxlan" as long as you dont have a openflow controller, am i right? | 19:02 |
| mestery | bjornar: Yes, that's correct. | 19:03 |
| *** clev has quit IRC | 19:03 | |
| bjornar | So it it planned to make the ovs implementation work "correctly", that is out of the box without openflow controller? | 19:03 |
| *** markmcclain has quit IRC | 19:04 | |
| mestery | bjornar: Personally, I see VXLAN as useful with and without multicast, depends on your comfort level with multicast and the scaling of your controller with the lack of multicast. | 19:04 |
| mestery | bjornar: I don't understand what you mean by correctly. | 19:04 |
| *** mili_ has quit IRC | 19:04 | |
| bjornar | mestery, correctly as in works with multicast | 19:04 |
| bjornar | ..and keeps a "arp" cache | 19:05 |
| *** markmcclain has joined #openstack-neutron | 19:05 | |
| *** markvoelker has joined #openstack-neutron | 19:06 | |
| *** gizmoguy_ has joined #openstack-neutron | 19:06 | |
| *** sc68cal has joined #openstack-neutron | 19:06 | |
| *** mili_ has joined #openstack-neutron | 19:06 | |
| bjornar | say I have three vms in a teenant network running on 3 different nodes, with kernel vxlan I could add a if with vni=3 and some multicast address to each bridge, and everything would work | 19:06 |
| mestery | bjornar: There has been some interest in that, yes. But no one has submitted patches upstream into OVS for that yet. | 19:06 |
| bjornar | mestery, but could not the "patches" just use the kernel version and move the interface in on the bridge | 19:07 |
| bjornar | I mean.. in current state ovs-vxlan is worth "nothing" standalong with ovs | 19:07 |
| mestery | bjornar: Yes, you could conceivably do that. | 19:08 |
| mestery | bjornar: Worth nothing? How is being able to program tunnel interfaces from your OpenFlow controller worth nothning? | 19:08 |
| bjornar | with option:multicast_grp:239.1.1.8 option:vni=123 .. it would work as killer | 19:09 |
| mestery | bjornar: Through OVSDB and OpenFlow, you can control OVS completely from a remote controller. Seems like there might be some value there. | 19:09 |
| bjornar | mestery, I said worth nothing _standalone_ | 19:09 |
| *** mili_ has quit IRC | 19:10 | |
| mestery | bjornar: If you add with multicast, then I agree. | 19:10 |
| bjornar | openflow and sdn is fine and all, but not everyone needs it | 19:10 |
| mestery | bjornar: Choice is always good. | 19:10 |
| bjornar | and vxlan dont "need" it ... with multicast ;) | 19:10 |
| *** mili_ has joined #openstack-neutron | 19:10 | |
| *** mili_ has joined #openstack-neutron | 19:11 | |
| *** mili_ has quit IRC | 19:11 | |
| bjornar | mestery, but thinking the openflow way.. what are my options for a controller that will handle vxlan with openstack/neutron atm? | 19:11 |
| *** mili_ has joined #openstack-neutron | 19:12 | |
| mestery | bjornar: Ryu likley supports this, I haven't checked recently. OpenDaylight will support this when it releases in a few weeks. And VMware NSX/NVP supports this as well. | 19:12 |
| bjornar | mestery, and its part of openflow 1.3? | 19:13 |
| mestery | bjornar: You would currently need to use OVSDB and OpenFlow combined. The tunnel stuff is not part of OpenFlow at the moment, though I have not looked at the latest 1.4 stuff recently. | 19:14 |
| bjornar | mestery, ok.. could I check this out using odl from git atm? | 19:15 |
| mestery | Follow my handy-dandy instructions here (http://www.siliconloons.com/?p=523), and pop over to #opendaylight-ovsdb with questions. | 19:15 |
| mestery | :) | 19:15 |
| *** markmcclain has quit IRC | 19:15 | |
| *** markmcclain has joined #openstack-neutron | 19:17 | |
| *** mlavalle has joined #openstack-neutron | 19:18 | |
| bjornar | mestery, will look at it.. just installed odl some hours ago.. | 19:19 |
| mestery | bjornar: Good luck and have fun! | 19:19 |
| bjornar | mestery, so what is the remote_ip=flow ..? | 19:20 |
| bjornar | what does "flow" resolve to? | 19:20 |
| mestery | bjornar: Instead of pinning a single IP to a VXLAN port, you can set the remote IP used on a per-flow basis. | 19:20 |
| bjornar | mestery, Can the ovs vxlan implementation even be called vxlan when it does not support multicast? | 19:21 |
| mestery | bjornar: It allows ovs-vswitchd to maintain IP to port mappings, and pass that info down to the datapath for encap and use a single VXLAN port representation in the kernel. | 19:21 |
| mestery | bjornar: I think it depends on your view of VXLAN. We may be getting philosophical now. :) | 19:21 |
| *** thedodd has joined #openstack-neutron | 19:29 | |
| openstackgerrit | enikanorov proposed a change to openstack/neutron: Fix race in get_network(s) in OVS plugin https://review.openstack.org/63918 | 19:30 |
| *** larsks has quit IRC | 19:35 | |
| bjornar | mestery, isnt it like "it depends on your view of TCP"? .. ;) | 19:38 |
| mestery | bjornar: Heh :) | 19:38 |
| bjornar | But I understand the interest of certain companies :) .. that vxlan does not support multicast | 19:38 |
| mestery | bjornar: I don't know of those interests of which you speak, I only know of people who won't touch multicast with a ten-foot pole because of previous experience with it. | 19:39 |
| bjornar | multicast is fine on l3 with some decent routing | 19:42 |
| *** jlibosva has quit IRC | 19:45 | |
| bjornar | mestery, any way to run some mininet/ovs/vxlan testing without the neutron parts? | 19:49 |
| *** markmcclain has quit IRC | 19:49 | |
| mestery | With ODL, yes. With ODL and Neutron, no. | 19:50 |
| bjornar | So how would I go about doing this with odl? | 19:51 |
| *** mili__ has joined #openstack-neutron | 19:51 | |
| *** hermatize has joined #openstack-neutron | 19:52 | |
| *** markmcclain has joined #openstack-neutron | 19:53 | |
| *** mili_ has quit IRC | 19:53 | |
| openstackgerrit | Aaron Rosen proposed a change to openstack/python-neutronclient: Combine debug and verbose commandline options https://review.openstack.org/62469 | 19:54 |
| mestery | bjornar: I think you've crossed into the need to pop over to #opendaylight and/or #opendaylight-ovsdb now. :) | 19:55 |
| bjornar | yeah | 19:56 |
| hermatize | Hello - I would like to start contributing code to OpenStack, can anyone point me in the right direction? | 19:58 |
| hermatize | I'm a network/security guy during the day, learning software dev at night :-) | 19:58 |
| *** jgrimm has quit IRC | 20:00 | |
| *** dave_tucker_zzz is now known as dave_tucker | 20:07 | |
| *** markmcclain has quit IRC | 20:09 | |
| *** hermatize has quit IRC | 20:09 | |
| peristeri | hermatize: you could start looking at https://bugs.launchpad.net/neutron | 20:10 |
| *** markmcclain has joined #openstack-neutron | 20:11 | |
| *** jprovazn has quit IRC | 20:14 | |
| *** mrsnivvel has quit IRC | 20:14 | |
| *** mrsnivvel has joined #openstack-neutron | 20:15 | |
| *** dave_tucker is now known as dave_tucker_zzz | 20:20 | |
| *** zzelle has quit IRC | 20:25 | |
| openstackgerrit | Aaron Rosen proposed a change to openstack/neutron: Bump api_workers from 0 to 4 https://review.openstack.org/59787 | 20:29 |
| *** hermatize has joined #openstack-neutron | 20:35 | |
| *** hermatize has quit IRC | 20:37 | |
| *** zzelle_ has joined #openstack-neutron | 20:38 | |
| bjornar | mestery, what kind of tunneling does the "handy-dandy instructions" use? | 20:39 |
| *** hermatize has joined #openstack-neutron | 20:41 | |
| *** zzelle_ has quit IRC | 20:42 | |
| *** networkstatic has quit IRC | 20:43 | |
| *** zzelle_ has joined #openstack-neutron | 20:43 | |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Remove unnecessary call to get_dhcp_port from DeviceManager https://review.openstack.org/63492 | 20:44 |
| *** zzelle__ has joined #openstack-neutron | 20:46 | |
| *** zzelle__ has quit IRC | 20:46 | |
| *** SumitNaiksatam has quit IRC | 20:48 | |
| *** zzelle_ has quit IRC | 20:49 | |
| *** RajeshMohan has quit IRC | 20:49 | |
| mestery | bjornar: By default, GRE, but there are instructions on changing that to VXLAN I can send as well. | 20:50 |
| *** RajeshMohan has joined #openstack-neutron | 20:50 | |
| *** zzelle_ has joined #openstack-neutron | 20:50 | |
| bjornar | mestery, would be nice.. did not see any reference to either.. | 20:50 |
| * mestery nods. | 20:50 | |
| *** zzelle_ is now known as zzelle | 20:51 | |
| *** zzelle has quit IRC | 20:52 | |
| *** zzelle has joined #openstack-neutron | 20:52 | |
| *** layer427expert has quit IRC | 20:55 | |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Refactor to remove _recycle_ip https://review.openstack.org/64724 | 20:58 |
| *** zzelle has quit IRC | 21:00 | |
| *** zzelle has joined #openstack-neutron | 21:01 | |
| *** layer427expert has joined #openstack-neutron | 21:02 | |
| *** thedodd has quit IRC | 21:05 | |
| *** majopela has quit IRC | 21:05 | |
| bjornar | mestery, did you have the link? or do you need to write? | 21:07 |
| mestery | bjornar: Lets move this over to #opendaylight-ovsdb, I know some folks there that can help you with that ASAP. | 21:08 |
| *** yfried has quit IRC | 21:13 | |
| *** majopela has joined #openstack-neutron | 21:20 | |
| *** clev has joined #openstack-neutron | 21:26 | |
| *** dave_tucker_zzz is now known as dave_tucker | 21:29 | |
| *** banix has quit IRC | 21:31 | |
| *** evgenyf has quit IRC | 21:31 | |
| *** sputnik13 has joined #openstack-neutron | 21:45 | |
| *** networkstatic has joined #openstack-neutron | 21:46 | |
| *** beagles has quit IRC | 21:50 | |
| *** layer427expert has quit IRC | 21:59 | |
| *** majopela has quit IRC | 21:59 | |
| *** peristeri has quit IRC | 22:00 | |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Refactor to remove _recycle_ip https://review.openstack.org/64724 | 22:07 |
| *** layer427expert has joined #openstack-neutron | 22:10 | |
| *** thedodd has joined #openstack-neutron | 22:10 | |
| *** ashaikh has quit IRC | 22:12 | |
| *** majopela has joined #openstack-neutron | 22:12 | |
| *** hermatize has quit IRC | 22:15 | |
| *** WackoRobie has quit IRC | 22:15 | |
| *** h6w has joined #openstack-neutron | 22:16 | |
| *** majopela has quit IRC | 22:17 | |
| *** armax has left #openstack-neutron | 22:17 | |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Simplify ip allocation/recycling to relieve db pressure https://review.openstack.org/58017 | 22:18 |
| *** hermatize has joined #openstack-neutron | 22:19 | |
| *** ijw has quit IRC | 22:22 | |
| *** ijw has joined #openstack-neutron | 22:23 | |
| *** markwash has quit IRC | 22:27 | |
| *** sputnik13 has quit IRC | 22:29 | |
| *** bjornar has quit IRC | 22:31 | |
| *** markmcclain has quit IRC | 22:32 | |
| *** rwsu has quit IRC | 22:33 | |
| h6w | Is it possible to have my instances allocated IPs in the same range as my physical network? I thought that was what Neutron-VLAN was for. But it seems to be NATing instead of sharing. | 22:34 |
| h6w | Which range is the correct one to be overlapping with my physical network? Public or Floating IP, or both? | 22:34 |
| h6w | Sorry, I mean NATing instead of bridging. | 22:35 |
| *** clev has quit IRC | 22:38 | |
| openstackgerrit | Amir Sadoughi proposed a change to openstack/python-neutronclient: Added --source-port-range-min, --source-port-range-max https://review.openstack.org/62130 | 22:38 |
| *** rwsu has joined #openstack-neutron | 22:40 | |
| *** hermatize has quit IRC | 22:44 | |
| *** ashaikh has joined #openstack-neutron | 22:44 | |
| *** layer427expert has quit IRC | 22:50 | |
| *** rwsu has quit IRC | 22:59 | |
| *** ijw has quit IRC | 23:01 | |
| openstackgerrit | Berezovsky Irena proposed a change to openstack/neutron: Add update from agent to plugin on device up https://review.openstack.org/53609 | 23:09 |
| *** zzelle has quit IRC | 23:09 | |
| *** thedodd has quit IRC | 23:11 | |
| anteaya | okay group this is markmcclain's bug and could be considered the top gate bug right now: https://bugs.launchpad.net/tempest/+bug/1253896 | 23:11 |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Simplify ip allocation/recycling to relieve db pressure https://review.openstack.org/58017 | 23:12 |
| anteaya | 83 hits in teh last 7 days excluding experiemental jobs | 23:12 |
| *** rwsu has joined #openstack-neutron | 23:12 | |
| anteaya | who has the ability to lend a hand? | 23:12 |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Simplify ip allocation/recycling to relieve db pressure https://review.openstack.org/58017 | 23:26 |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Refactor to remove _recycle_ip https://review.openstack.org/64724 | 23:27 |
| openstackgerrit | Armando Migliaccio proposed a change to openstack/neutron: Rename nicira configuration elements to match new naming structure https://review.openstack.org/64747 | 23:31 |
| *** mlavalle has quit IRC | 23:33 | |
| *** bjornar has joined #openstack-neutron | 23:56 | |
| *** markwash has joined #openstack-neutron | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!