Tuesday, 2015-07-21

*** salv-orlando has quit IRC00:57
*** salv-orlando has joined #openstack-neutron-ovn01:00
*** armax has quit IRC01:01
*** salv-orlando has quit IRC01:05
*** mestery has quit IRC01:29
*** s3wong has quit IRC01:46
*** armax has joined #openstack-neutron-ovn03:49
*** armax has quit IRC04:40
*** armax has joined #openstack-neutron-ovn04:42
gsagieyes, i have identified why the ports are not being deleted and working on a fix04:52
openstackgerritGal Sagie proposed openstack/networking-ovn: Fix logical port delete  https://review.openstack.org/20392405:23
openstackgerritGal Sagie proposed openstack/networking-ovn: Fix logical port delete  https://review.openstack.org/20392406:43
*** salv-orlando has joined #openstack-neutron-ovn06:52
*** fzdarsky has joined #openstack-neutron-ovn07:18
*** salv-orlando has quit IRC07:28
*** salv-orlando has joined #openstack-neutron-ovn08:25
*** fzdarsky has quit IRC08:29
*** fzdarsky has joined #openstack-neutron-ovn09:36
*** fzdarsky is now known as fzdarsky|afk11:40
*** salv-orlando has quit IRC11:40
*** salv-orlando has joined #openstack-neutron-ovn12:01
*** cascardo_ has joined #openstack-neutron-ovn12:53
openstackgerritGal Sagie proposed openstack/networking-ovn: Fix logical port delete  https://review.openstack.org/20392413:31
russellbgsagie: you test that latest rev?  i'm wondering if lswitch.verify('ports') needs to come before modifying the ports list13:32
russellbmaybe it doesn't matter though13:33
gsagierussellb: this is the way its done in neutron OVS lib13:33
gsagieif you look at all the examples, but i only verified it works, didnt verify dirty writes :)13:33
russellbok fine with me13:34
gsagiei think since its in the same transaction it doesnt matter13:34
russellbdo transaction errors not get reported as exceptions?  or cause a retry?13:35
russellbwondering why this was silently failing before13:35
russellband also worried about failures now when port deletes are happening in parallel13:35
russellbthey're all going to be trying to update 'ports' at the same time and some retries will be required to get it done13:35
gsagieit was not an error13:35
russellboh i thought i saw a comment about the transaction failing13:36
gsagiewell the transaction from what i saw returned "no change"13:36
gsagiethats why i wrote that this should probably be investigated inside OVN13:36
russellbit successfully did nothing :)13:37
russellbi don't think we can change it ... it'd be a change to ovsdb13:37
gsagiei havent really looked, let me see the schema defenitions, maybe its something there13:37
russellbor you could ask on ovs dev list and ben can explain whether or not it's possible to have it auto removed from lswitch ports list13:38
gsagiemaybe its something in the python IDL itself13:38
*** fzdarsky|afk is now known as fzdarsky13:46
*** mestery has joined #openstack-neutron-ovn14:04
*** otherwiseguy has quit IRC15:09
*** markmcclain has quit IRC15:09
*** shettyg has joined #openstack-neutron-ovn15:39
*** markmcclain has joined #openstack-neutron-ovn17:27
*** armax has quit IRC18:04
*** s3wong has joined #openstack-neutron-ovn18:08
*** otherwiseguy has joined #openstack-neutron-ovn18:12
*** armax has joined #openstack-neutron-ovn18:37
*** arosen has joined #openstack-neutron-ovn18:52
arosenhey russellb i'm trying out the localrc for computenode-local.conf.sample18:52
russellbcool, i haven't tried it in a while ...18:52
arosenthough i'm running into this issue just curious if you might know what it is off hand18:52
arosen2015-07-21 11:52:10.691 ERROR oslo_messaging._drivers.impl_rabbit [req-1d2621d1-4b74-4180-aa43-d8797c971984 None None] AMQP server closed the connection. Check login credentials: Socket closed18:53
arosenthe creds in the nova.conf on the compute node are correct18:53
arosenand i can telnet to rabbitmq on that ip and port just fine.18:53
russellbi didn't even know devstack set up rabbitmq credentials18:53
russellbso i'm afraid i don't know off hand what the issue is18:54
russellbthat's nova-compute.log ?18:54
russellbsure looks like a rabbitmq credentials issue *shrug*18:54
arosenrussellb:  i actually added "Check login credentials" to the log message in oslo.messaging a long time ago18:55
arosenrabbmitmq can close a connection for a number of reason but they don't tell the client why.18:55
arosenso it might not be the creds.18:55
russellbwell i haven't seen that ... maybe check rabbitmq log on the main controller node?18:56
russellband is the right address you'd expect?18:56
russellbsilly question, but sometimes easy to overlook the easy stuff18:56
russellbmeaning you're not accidentally running rabbitmq on the compute node as well or something18:56
arosenyup is the right node.18:57
arosenthis log is from
arosenthe rabbmit logs just say18:58
arosenclosing AMQP connection <0.2154.0> ( ->
arosenI'll keep digging though18:58
*** Bhargav has joined #openstack-neutron-ovn20:44
openstackgerritMerged openstack/networking-ovn: Fix logical port delete  https://review.openstack.org/20392421:18
*** mestery has quit IRC22:00
*** cascardo_ has quit IRC22:12
salv-orlandoarosen: did you sort that problem?22:42
salv-orlandorussellb: do you have a minute for a quick question on provider networks impl. There's only one thing I do not understand22:42
russellbsalv-orlando: hi22:43
russellbi need to leave here in a few minutes but can answer something quick22:43
salv-orlandorussellb: sure... why did you had to connect br-ethX to br-int?22:44
salv-orlandothat's my question22:44
salv-orlandoI cannot see a reason for bridging those switches22:44
salv-orlandobut I might be missing something obvious22:45
russellbi didn't *have* to, but it seemed to be the least invasive way to do it22:45
russellbbr-int is where OVN programs all of its flows22:45
salv-orlando(and yeah I should have asked that in #openvswitch but was too lazy to scroll down the channel list)22:45
russellband most of that is still relevant22:45
russellbso, it does all the same flow programming for port security, ACLs, in br-int like usual22:46
russellband then for input and output to the provider network, sends it off to br-ethX22:46
salv-orlandorussellb: cool. That explains it. I thought you were thinking that in the future one might want to bridge provider networks with tenant networks, but this explanation makes a whole lot more sense22:47
russellbno real reason it has to be that way22:47
russellbwell, Neutron's use case would never do that22:47
russellbhowever the implementation technically allows it22:47
russellbyou could have several regular logical ports and a localnet port as well22:47
russellbtraffic between the logical ports would go over tunnels like usual22:47
russellbbut ... i have no intention of using it that way with neutron22:47
russellbit's more a side effect than intended22:48
salv-orlandoyeah that's an interesting use case... kind of goes a bit into the vtep realm22:48
russellbVTEP gateways is how we'd want / expect people to do that22:48
russellbbut it's there, technically ...22:48
russellbsupposedly someone is going to write a software vtep gateway too using ovs + dpdk22:49
salv-orlandorussellb: sure. Eventually we'll figure out if there something useful that can be done with that.22:49
* russellb nods22:49
russellbok i need to run, hope that helps22:49
salv-orlandothanks bye22:49
salv-orlandohave a good one22:49
russellbthanks for looking at this stuff!  i really appreciate it22:49
salv-orlandothanks for doing this stuff... I am still stuck on trying to remember how to code in C22:49
*** fzdarsky has quit IRC22:51
openstackgerritOpenStack Proposal Bot proposed openstack/networking-ovn: Updated from global requirements  https://review.openstack.org/19684523:14

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!