[openstack-dev] [networking-ovn] Re: [ovs-dev] Issue when using ovn with Openstack

[Ryan Moats]

"dev"  wrote on 07/19/2016 10:44:27 PM:

> From: Chen Li 
> To: d...@openvswitch.org
> Date: 07/19/2016 10:44 PM
> Subject: [ovs-dev] Issue when using ovn with Openstack
> Sent by: "dev" 

>
> Hi list,
>
> I have an all-in-one devstack environment with ovn enabled.
> I create a neutron network.
> Create a port A from the network with secgroup A
> Create a vm from the network with secgroup B.
> Secgroup B has both ICMP  and tcp 22 enabled.
>
> Then I try to ping the VM from the dhcp namespace, since the Secgroup B
has
> enabled ICMP,  I suppose this should work. But, unfortunately,  this do
not
> work. And,  the ssh failed too.
>
> Anyone can help me to solve this issue ?
>
> I did some basic checks and looks like flows are missing in table 52.
>
> Here are flows in table 52:
>
> sudo ovs-ofctl dump-flows br-int |grep table=52
>
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766,
priority=65535,icmp6,metadata=0x4,icmp_type=135,icmp_code=0
> actions=resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766,
priority=65535,icmp6,metadata=0x4,icmp_type=136,icmp_code=0
> actions=resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=4, n_bytes=1474,
> idle_age=7744, priority=2002,udp,reg15=0x2,metadata=0x4,nw_src=
> 192.168.0.0/24,tp_src=67,tp_dst=68
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7557.209s, table=52, n_packets=2, n_bytes=759,
> idle_age=7548, priority=2002,udp,reg15=0x3,metadata=0x4,nw_src=
> 192.168.0.0/24,tp_src=67,tp_dst=68
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766, priority=2001,ipv6,reg15=0x2,metadata=0x4 actions=drop
>  cookie=0x0, duration=7766.195s, table=52, n_packets=2, n_bytes=676,
> idle_age=7548, priority=2001,ip,reg15=0x2,metadata=0x4 actions=drop
>  cookie=0x0, duration=7557.209s, table=52, n_packets=0, n_bytes=0,
> idle_age=7557, priority=2001,ipv6,reg15=0x3,metadata=0x4 actions=drop
>  cookie=0x0, duration=7557.209s, table=52, n_packets=3979,
n_bytes=389774,
> idle_age=413, priority=2001,ip,reg15=0x3,metadata=0x4 actions=drop
>  cookie=0x0, duration=7766.195s, table=52, n_packets=0, n_bytes=0,
> idle_age=7766, priority=1,ipv6,metadata=0x4
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7766.195s, table=52, n_packets=8, n_bytes=2733,
> idle_age=7548, priority=1,ip,metadata=0x4
> actions=load:0x1->NXM_NX_REG0[1],resubmit(,53)
>  cookie=0x0, duration=7926.354s, table=52, n_packets=0, n_bytes=0,
> idle_age=7926, priority=0,metadata=0x1 actions=resubmit(,53)
>  cookie=0x0, duration=7790.771s, table=52, n_packets=129, n_bytes=5418,
> idle_age=408, priority=0,metadata=0x4 actions=resubmit(,53)
>
> Here are steps how I find flows are missing in table52:
>
> ovs-dpctl show
>
> port 0: ovs-system (internal)
> port 1: br-int (internal)
> port 2: tap446ef382-f0 (internal)
> port 3: tapc7c9f581-2d (internal)  => the dhcp port for the testing
> network
> port 4: o-hm0 (internal)=> the port create from the
> testing network with security group A
> port 5: tap275a5a25-79   => the port for the vm in the
> testing network with security group B
>
>
> sudo ip netns exec qdhcp-e8586b01-6441-4c3d-a90d-91bb0a54ec80 arp -n
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.0.6  ether   fa:16:3e:40:85:41   C
> tapc7c9f581-2d
> 192.168.0.12 ether   fa:16:3e:5c:fe:86   C
> tapc7c9f581-2d
>
>
> sudo ip netns exec qdhcp-e8586b01-6441-4c3d-a90d-91bb0a54ec80 ping
> 192.168.0.12  => This is the IP for the VM.
> PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
>
>
> ovs-dpctl dump-flows
>
> recirc_id(0),in_port(3),eth(src=fa:16:3e:b6:f6:25,dst=fa:16:3e:
> 5c:fe:86),eth_type(0x0806),arp(sip=192.168.0.2,tip=192.168.0.
> 12,op=1/0xff,sha=fa:16:3e:b6:f6:25,tha=00:00:00:00:00:00),
> packets:0, bytes:0, used:never,
> actions:userspace(pid=4294958325,slow_path(action))
> recirc_id(0),in_port(3),eth(src=00:00:00:00:00:00/01:00:00:00:00:
> 00,dst=fa:16:3e:5c:fe:86),eth_type(0x0800),ipv4(src=
> 192.168.0.0/255.255.255.0,proto=1,frag=no), packets:14, bytes:1372,
> used:0.974s, actions:drop
>
>
> sudo ovs-appctl ofproto/trace
> "recirc_id(0),in_port(3),eth(src=00:00:00:00:00:00/01:00:00:00:00:
> 00,dst=fa:16:3e:5c:fe:86),eth_type(0x0800),ipv4(src=
> 192.168.0.0/255.255.255.0,proto=1,frag=no)"
> => This produce a long output, and here are the end of the output:
>
> OpenFlow actions=resubmit(,52)
>
> Resubmitted flow: unchanged
>
> Resubmitted regs: reg0=0x1 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0 reg5=0x0
> reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0 reg12=0x0
> reg13=0x0 reg14=0x1 reg15=0x3
>
> Resubmitted  odp: drop
>
> Resubmitted megaflow:
>

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

"discuss"  wrote on 06/17/2016 05:24:19
PM:

> From: Cathy Zhang 
> To: Na Zhu 
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, John McDowall
> , discuss 
> Date: 06/17/2016 05:25 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
>
> Hi Juno,
>
> Here is an example.
>
> SrcSF   DST
> | |  |   |
> 1 2  3   4
> OVS1==OVS2==OVS3
>
> For bump-in-the-wire SF type, since what it does is just to pass the
> packet from its ingress port to egress port, broadcast and multicast
> packets will form  a loop on port 2 and 3.
> This problem is not specific to SFC though. A simple way to solve
> this is to put a bump-in-the-wire SF’s port 2 and port 3 in
> different subnets. For L3 SF, this is not an issue.

The above is a good reason for following OVN's pipeline logic
and not punting a packet to an output port in the ingress pipeline
(as I first expressed concerns about in [1]).

There is a loopback check in table 34 (between the ingress and egress
pipelines) that we can look at using to break the loops - program it
to drop broadcast/multicast traffic going between ports 2 and 3 and
the loop is broken.

Ryan

[1] http://openvswitch.org/pipermail/discuss/2016-May/021419.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 06/17/2016 04:07:38
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: discuss <disc...@openvswitch.org>, Na Zhu <na...@cn.ibm.com>,
> "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>, Srilatha Tangirala/San
> Francisco/IBM@IBMUS
> Date: 06/17/2016 04:07 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Ryan,
>
> See inline
>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Friday, June 17, 2016 at 7:26 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: discuss <disc...@openvswitch.org>, Na Zhu <na...@cn.ibm.com>,
> "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, Srilatha Tangirala
<srila...@us.ibm.com>
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Apologies for being delayed on replying and in-line back as well
>
> Ryan
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 06/15/2016
> 05:58:35 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Na Zhu <na...@cn.ibm.com>, Srilatha Tangirala/San Francisco/
> > IBM@IBMUS, "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev@lists.openstack.org>, discuss
> > <disc...@openvswitch.org>
> > Date: 06/15/2016 05:58 PM
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> >
> > Ryan,
> >
> > In-line
> >
> > Regards
> >
> > John
> >
> > From: Ryan Moats <rmo...@us.ibm.com>
> > Date: Tuesday, June 14, 2016 at 9:42 PM
> > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > Cc: Na Zhu <na...@cn.ibm.com>, Srilatha Tangirala <srila...@us.ibm.com
> > >, "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>, discuss <disc...@openvswitch.org>
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> >
> > "discuss" <discuss-boun...@openvswitch.org> wrote on 06/14/2016
10:31:40 PM:
> >
> > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > To: Na Zhu <na...@cn.ibm.com>
> > > Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> > > Development Mailing List \(not for usage questions\)"  > > d...@lists.openstack.org>, discuss <disc...@openvswitch.org>
> > > Date: 06/14/2016 10:48 PM
> > > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > > [networking-sfc] SFC andOVN
> > > Sent by: "discuss" <discuss-boun...@openvswitch.org>
> > >
> > > Juno,
> > >
> > > It is a container for port-pair-groups and flow-classifier. I
> > > imagine there could be more the than one port-chain per switch. Also
> > > we may want to extend the model beyond a single lswitch
> >
> > I agree that there could be more than one port-chain per switch,
determined
> > by the flow classifier.
> >
> > What I'm confused by is:
> >
> > 1. Why are items only recorded in logical switches?  I would think
> > that I could also attach an SFC to a logical router - although I admit
> > that the current neutron model for ports doesn't really allow that
> > easily.  Couple that with the change of name from Logical_Port to
> > Logical_Switch_Port, and I'm left wondering if we aren't better off
> > with the following "weak" links instead:
> > -the Port_Chain includes the logical switch as an external_id
> > -each Port_Pair_Group includes the Port_Chain as an external_id
> > -each Port_Pair includes the PPG as an external_id
> > -each Logical_Switch_Port includes the PP as an external_id
> >
> > I *think* that *might* allow me (in the future) to attach a port chain
> > to a logical router by setting the logical router as an external_id and
> > using Logical_Router_Ports to make up the PPs...
> >
> > JED> If there are “port-chain” tables for switches and routers I
> > think I agree. Not sure how this is impacted by the type of VNF (see
> > the last email to Juno). I struggle a bit with imagining the flows.
>
> RM&

Re: [openstack-dev] [networking-ovn] provider networks

[Ryan Moats]

Murali R <muralir...@gmail.com> wrote on 06/17/2016 12:33:09 PM:

> From: Murali R <muralir...@gmail.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org>, discuss <disc...@openvswitch.org>
> Date: 06/17/2016 12:33 PM
> Subject: Re: [ovs-discuss] [ovn] provider networks
>
> > Your question makes me think that you are using provider networks
> > in a way different from I have used them
>
> Actually it is standard
> Q_USE_PROVIDER_NETWORKING=True
> PHYSICAL_NETWORK=providernet
> PROVIDER_NETWORK_TYPE=flat
> OVS_PHYSICAL_BRIDGE=br-provider
> PROVIDER_SUBNET_NAME=provider-subnet
> FIXED_RANGE=10.145.253.0/24
> NETWORK_GATEWAY=10.145.253.1
> ALLOCATION_POOL=start=10.145.253.111,end=10.145.253.242
>
> So earlier, probably the full l3 support wasn't there. I made
> changes for logical flow additions in my own repo and use it for
> testing. I had to do a big merge for l3 extensions last night
> because networking-ovn eas expecting some idl extensions in new updates.
>
> The setup now creates a logical router in OVN and assigns the
> gateway address given above. The gateway should not be used to
> allocate address for OVN router.
>
> If I create another private network, add a new router attach it to
> public network created, the traffic is hitting my external company
> gateway all the way out. Not sure what is happening. Can I just
> delete the default router1 that the devstack setup created? Looks
> like I may have to do some manual configs to get this setup working.
> Or should I disable OVN_L3 in devstack?

I'm dropping the openvswitch discuss list and adding the openstack
dev list because this is very much now questions for that channel.

Right now, my test cloud is in a state where I can't answer your
question directly, but my memory is that a router should not be
created and if it is, that would be a bug against something...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

In-line below

"discuss"  wrote on 06/15/2016 05:51:20
PM:

> From: John McDowall 
> To: Na Zhu 
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, discuss 
> Date: 06/15/2016 05:51 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
>
> Juno,
>
> Apologies – I see your issue now, also I have got nothing done today
> – got sucked into an all day meeting. I was thinking very much from
> a  ovs/ovn perspective and also my first prototype was very simple.
>
> So while in networking=sfc/ovn the port-cahin does not have a switch
> I think port-chain needs a lswitch context as that is where the
> port-chain table is created. Let me try and lay this out. I am not
> sure if I am getting this right but it is a starting point for
> discussion and comment by the community.
>
> The first thing is that there could be three different types of
> VNF’s, L3, L2, and Bump in the Wire (BITW). I am not sure if it
> would be possible to mix and match these different types in a series
> of port-pair-groups. Also as a first phase I have been trying to
> remove the need for the VNF to participate in the service chain (or
> be aware of it). In addition I also wanted to remove the need for
> any “proxy” as documented in the NSH model, by moving a lot of the
> functionality to the ovn-northd.
>
> Mode 1: BITW
> Port-Pairs: The logical ports need to be on the same logical switch
> Port-pair-groups: They are made up of sets of port-pairs, until we
> see the load-balancing proposal for ovs/ovn not sure if port-pairs
> can be on different logical switches or not. This translates to a
> set of rules in the port-chain table that chains output ports of one
> VNF to the input port of the next VNF, until the last VNF when the
> traffic is forwarded to the final destination of the packet. If the
> port-chain is bi-directional then the rule set has to be implemented
> in reverse (many VNF’s Firewalls, Load Balancers etc need to see
> both legs of the traffic).
> Flow-classifier: Is a set of rules that are set as an ACL rule with
> first logical port of the first pair in the first port-pair-group.
> Likewise if the port-chain is bi-directional then the rules have to
> be symmetric to steer the traffic in both directions.
> Port-chain: defined on the same logical switch as the first logical-
> source-port of the flow-classifier, as this is where the port-chain
> table is created and the rules for traffic steering are inserted.
> Mode 2: L2
>
> I think this would be similar to the BITH case but instead of
> steering by logical ports the steering would be done by VLAN tags.
> This would also mean that the VNFs would have to be aware of the
> steering rules and be able to manipulate VLAN tags.
>
> Mode 3: L3
>
> This would require the VNF’s to be aware of the routing rules and
> set static routes/net hop rules for each step in the service chain.
>
> Modes 2 & 3 would require a much more sophisticated control plane to
> program both OVN and the VNFs.

[Snip to save BW]

I'm not so sure John.  I agree that OVN would have to know about the
VF type (BiW/L2/L3) and further that OVN would need to be told about
the appropriate L2/L3 "next port" information - either VLAN tags or
IP addresses, but once I have that, I think the actual vswitch
programming is fairly straightforward:  for L2, the vswitch is
programmed to use the VLAN tag to select the next PPG bucket and
for L3, the existing template for programming static routes can be
leveraged.

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

Apologies for being delayed on replying and in-line back as well

Ryan

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 06/15/2016 05:58:35
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Na Zhu <na...@cn.ibm.com>, Srilatha Tangirala/San Francisco/
> IBM@IBMUS, "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>, discuss
> <disc...@openvswitch.org>
> Date: 06/15/2016 05:58 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> Ryan,
>
> In-line
>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Tuesday, June 14, 2016 at 9:42 PM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: Na Zhu <na...@cn.ibm.com>, Srilatha Tangirala <srila...@us.ibm.com
> >, "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>, discuss <disc...@openvswitch.org>
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
>
> "discuss" <discuss-boun...@openvswitch.org> wrote on 06/14/2016 10:31:40
PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Na Zhu <na...@cn.ibm.com>
> > Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> > Development Mailing List \(not for usage questions\)"  > d...@lists.openstack.org>, discuss <disc...@openvswitch.org>
> > Date: 06/14/2016 10:48 PM
> > Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> > [networking-sfc] SFC andOVN
> > Sent by: "discuss" <discuss-boun...@openvswitch.org>
> >
> > Juno,
> >
> > It is a container for port-pair-groups and flow-classifier. I
> > imagine there could be more the than one port-chain per switch. Also
> > we may want to extend the model beyond a single lswitch
>
> I agree that there could be more than one port-chain per switch,
determined
> by the flow classifier.
>
> What I'm confused by is:
>
> 1. Why are items only recorded in logical switches?  I would think
> that I could also attach an SFC to a logical router - although I admit
> that the current neutron model for ports doesn't really allow that
> easily.  Couple that with the change of name from Logical_Port to
> Logical_Switch_Port, and I'm left wondering if we aren't better off
> with the following "weak" links instead:
> -the Port_Chain includes the logical switch as an external_id
> -each Port_Pair_Group includes the Port_Chain as an external_id
> -each Port_Pair includes the PPG as an external_id
> -each Logical_Switch_Port includes the PP as an external_id
>
> I *think* that *might* allow me (in the future) to attach a port chain
> to a logical router by setting the logical router as an external_id and
> using Logical_Router_Ports to make up the PPs...
>
> JED> If there are “port-chain” tables for switches and routers I
> think I agree. Not sure how this is impacted by the type of VNF (see
> the last email to Juno). I struggle a bit with imagining the flows.

RM> Back in the day when we discussed this internally here, SFCs could
RM> be inserted as BiW (which we do a good job with currently) and at
RM> network boundaries (which I'm not sure how I could do with the
RM> current model) - my router question is more one of leaving the
RM> door open for the boundary case (sorry for the pun) in the future.

> 2. I still don't see what Logical_Flow_Classifier is buying me that
> ACL doesn't - I can codify all of the classifiers given in the match
> criteria of an ACL entry and codify the first PPG of the SFC as
> the action of the ACL entry...
> JED> Flow classifiers do map to an ACL entry – just need additional
> metadata, I.e. Action of the ACL and wether the rules should be uni
> or bi-directional. Though that information could be in the port-chain.

RM> yes and I see the action field of the ACL table being extended
RM> to include "enter port chain " to cover that metadata.
RM> Why couldn't bidirectional Flow Classifiers at SFC just be
RM> implemented as a pair of uni-directional ACLs in the NB DB?
RM> I'll back off on this point if I can see an example of an flow
RM> classifier that can't be made to fit in the ACL table, but to
RM> date, I've not been able to construct such a beast.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

[Ryan Moats]

"discuss"  wrote on 06/14/2016 10:31:40
PM:

> From: John McDowall 
> To: Na Zhu 
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, discuss 
> Date: 06/14/2016 10:48 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
>
> Juno,
>
> It is a container for port-pair-groups and flow-classifier. I
> imagine there could be more the than one port-chain per switch. Also
> we may want to extend the model beyond a single lswitch

I agree that there could be more than one port-chain per switch, determined
by the flow classifier.

What I'm confused by is:

1. Why are items only recorded in logical switches?  I would think
that I could also attach an SFC to a logical router - although I admit
that the current neutron model for ports doesn't really allow that
easily.  Couple that with the change of name from Logical_Port to
Logical_Switch_Port, and I'm left wondering if we aren't better off
with the following "weak" links instead:
-the Port_Chain includes the logical switch as an external_id
-each Port_Pair_Group includes the Port_Chain as an external_id
-each Port_Pair includes the PPG as an external_id
-each Logical_Switch_Port includes the PP as an external_id

I *think* that *might* allow me (in the future) to attach a port chain
to a logical router by setting the logical router as an external_id and
using Logical_Router_Ports to make up the PPs...


2. I still don't see what Logical_Flow_Classifier is buying me that
ACL doesn't - I can codify all of the classifiers given in the match
criteria of an ACL entry and codify the first PPG of the SFC as
the action of the ACL entry...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 06/02/2016 11:03:28
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> Date: 06/02/2016 11:03 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Sure – may need some help and it will probably be next week before Iget
to it.
>
> Regards
>
> John

John-

Let me see what I can do to push the ball along...

Ryan

>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Wednesday, June 1, 2016 at 1:25 PM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Russell
Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/31/2016
> 07:57:02 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> > <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> > "OpenStack Development Mailing List"  > d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> > Date: 05/31/2016 07:57 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > More help is always great :-). As far as who to collaborate, what
> > ever Is easiest for everyone – I am pretty flexible.
> >
> > Regards
> >
> > John
>
> Ok, then I'll ask that we go the submit WIP patches to each of
> networking-sfc and networking-ovn and an RFC patch to d...@openvswitch.org
> and iterate through review.openstack.org and patchworks.
>
> Could you submit the initial patches today or tomorrow? I'd rather
> go that route since you have the lion's share of the work so far
> and credit where credit is due...
>
> Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/31/2016 07:57:02
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> Date: 05/31/2016 07:57 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> More help is always great :-). As far as who to collaborate, what
> ever Is easiest for everyone – I am pretty flexible.
>
> Regards
>
> John

Ok, then I'll ask that we go the submit WIP patches to each of
networking-sfc and networking-ovn and an RFC patch to d...@openvswitch.org
and iterate through review.openstack.org and patchworks.

Could you submit the initial patches today or tomorrow? I'd rather
go that route since you have the lion's share of the work so far
and credit where credit is due...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/31/2016 03:21:30
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> Date: 05/31/2016 03:22 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Let me add the tables to OVN for SFC. That will give us a working
> system to prototype the flow classifier approach on. Hopefully I can
> get something done by end of week.
>
> Regards
>
> John

I've got some internal folks that are willing to help with writing code (as
I will be once I clear my current firefights) so the question of how to
collaborate with code now arises...

Are you comfortable with putting the changes on r.o.o as WiP and patchworks
as RFC and work through the review process or would you rather work via
forks and pull requests in github?

Ryan

> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Tuesday, May 31, 2016 at 10:17 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Russell
Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/26/2016
> 11:08:43 AM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> > <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> > "OpenStack Development Mailing List"  > d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> > Date: 05/26/2016 11:09 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > My (incomplete) throughts about the flow-classifier are:
> >
> > 1)  ACL’s are more about denying access, while the flow classifier
> > is more about steering selected traffic to a path, so we would need
> > to deny-all except allowed flows.
> > 2)  The networking-sfc team has done a nice job with the drivers so
> > ovn has its own flow-classifier driver which allows us to align the
> > flow-classifier with the matches supported in ovs/ovn, which could
> > be an advantage.
>
> The ACL table has a very simple flow-classifier structure and I'd
> like to see if that can be re-used for the purpose of the SFC classifier
> (read that I feel the Logical_Flow_Classifier table is too complex).
> My initial thoughts were to look at extending the action column and
> using the external-ids field to differentiate between legacy ACLs and
> those that are used to intercept traffic and route it to an SFC.
>
> >
> > What were your thoughts on the schema it adds a lot of tables and a
> > lot of commands – cannot think of anyway around it
>
> In this case, I think that the other tables are reasonable and I'm
> uncomfortable trying to stretch the existing tables to cover that
> information...
>
> Ryan
>
> >
> > Regards
> >
> > John
> >
> > From: Ryan Moats <rmo...@us.ibm.com>
> > Date: Wednesday, May 25, 2016 at 9:12 PM
> > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org" <
> > disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>, OpenStack
> > Development Mailing List <openstack-dev@lists.openstack.org>,
> Russell Bryant <
> > russ...@ovn.org>
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/25/2016
> > 07:27:46 PM:
> >
> > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > > Development Mailing List" <openstack-dev@lists.openstack.org>, Ben
> > > Pfaff <b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant
> > > <russ...@ovn.org>
> > > Date: 05/25/2016 07:28 PM
> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/31/2016 03:19:54
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> Date: 05/31/2016 03:20 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Hopefully – just wanted to make sure it was there.
>
> Regards
>
> John

I think having that as one of the tests to make sure is a good idea...

Ryan

>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Tuesday, May 31, 2016 at 10:02 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Russell
Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/26/2016
> 10:59:48 AM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff <b...@ovn.org>
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, Justin
> > Pettit <jpet...@ovn.org>, OpenStack Development Mailing List
> > <openstack-dev@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> > Date: 05/26/2016 11:00 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Agree with your description of the problem. The only thing I would
> > add is that in the case of bi-directional chains the return flows
> > need to go through the same VNF(Port-pair).
>
> I'm pretty sure that is caught automagically, isn't it?
>
> Ryan
>
> >
> > Regards
> >
> > John
> >
> > From: Ryan Moats <rmo...@us.ibm.com>
> > Date: Wednesday, May 25, 2016 at 9:29 PM
> > To: Ben Pfaff <b...@ovn.org>
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, John McDowall
<
> > jmcdow...@paloaltonetworks.com>, Justin Pettit <jpet...@ovn.org>,
> > OpenStack Development Mailing List <openstack-dev@lists.openstack.org
> > >, Russell Bryant <russ...@ovn.org>
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ben Pfaff <b...@ovn.org> wrote on 05/25/2016 07:44:43 PM:
> >
> > > From: Ben Pfaff <b...@ovn.org>
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: John McDowall <jmcdow...@paloaltonetworks.com>,
> > > "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > > Development Mailing List <openstack-dev@lists.openstack.org>, Justin
> > > Pettit <jpet...@ovn.org>, Russell Bryant <russ...@ovn.org>
> > > Date: 05/25/2016 07:44 PM
> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > >
> > > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > > > As I understand it, Table 0 identifies the logical port and logical
> > > > flow. I'm worried that this means we'll end up with separate bucket
> > > > rules for each ingress port of the port pairs that make up a port
> > > > group, leading to a cardinality product in the number of rules.
> > > > I'm trying to think of a way where Table 0 could identify the
packet
> > > > as being part of a particular port group, and then I'd only need
one
> > > > set of bucket rules to figure out the egress side.  However, the
> > > > amount of free metadata space is limited and so before we go down
> > > > this path, I'm going to pull Justin, Ben and Russell in to see if
> > > > they buy into this idea or if they can think of an alternative.
> > >
> > > I've barely been following the discussion, so a recap of the question
> > > here would help a lot.
> > >
> >
> > Sure (and John gets to correct me where I'm wrong) - the SFC proposal
> > is to carry a chain as a ordered set of port groups, where each group
> > consists of multiple port pairs. Each port pair consists of an ingress
> > port and an egress port, so that traffic is load balanced between
> > the ingress ports of a group. Traffic from the egress port of a group
&g

Re: [openstack-dev] [Neutron][Release] Changing release model for *-aas services

[Ryan Moats]

"Armando M."  wrote on 05/31/2016 01:12:32 PM:

> From: "Armando M." 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 05/31/2016 01:13 PM
> Subject: [openstack-dev] [Neutron][Release] Changing release model
> for *-aas services
>
> Hi folks,
>
> Having looked at the recent commit volume that has been going into
> the *-aas repos, I am considering changing the release model for
> neutron-vpnaas, neutron-fwaas, neutron-lbaas from release:cycle-
> with-milestones [1] to release:cycle-with-intermediary [2]. This
> change will allow us to avoid publishing a release at fixed times
> when there's nothing worth releasing.
>
> I'll follow up with a governance change, as I know of the imminent
> deadline [3].
>
> Thoughts?
> Armando
>
> [1] https://governance.openstack.org/reference/tags/release_cycle-
> with-milestones.html
> [2] https://governance.openstack.org/reference/tags/release_cycle-
> with-intermediary.html
>
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html

+1 to this as it makes a *LOT* of sense to me...

Ryan (regXboi)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/26/2016 11:08:43
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org"
> <disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> Date: 05/26/2016 11:09 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> My (incomplete) throughts about the flow-classifier are:
>
> 1)  ACL’s are more about denying access, while the flow classifier
> is more about steering selected traffic to a path, so we would need
> to deny-all except allowed flows.
> 2)  The networking-sfc team has done a nice job with the drivers so
> ovn has its own flow-classifier driver which allows us to align the
> flow-classifier with the matches supported in ovs/ovn, which could
> be an advantage.

The ACL table has a very simple flow-classifier structure and I'd
like to see if that can be re-used for the purpose of the SFC classifier
(read that I feel the Logical_Flow_Classifier table is too complex).
My initial thoughts were to look at extending the action column and
using the external-ids field to differentiate between legacy ACLs and
those that are used to intercept traffic and route it to an SFC.

>
> What were your thoughts on the schema it adds a lot of tables and a
> lot of commands – cannot think of anyway around it

In this case, I think that the other tables are reasonable and I'm
uncomfortable trying to stretch the existing tables to cover that
information...

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Wednesday, May 25, 2016 at 9:12 PM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: Ben Pfaff <b...@ovn.org>, "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit <jpet...@ovn.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Russell
Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/25/2016
> 07:27:46 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>, Ben
> > Pfaff <b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant
> > <russ...@ovn.org>
> > Date: 05/25/2016 07:28 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Ok – I will let the experts weigh in on load balancing.
> >
> > In the meantime I have attached a couple of files to show where I am
> > going. The first is sfc_dict.py and is a representation of the dict
> > I am passing from SFC to OVN. This will then translate to the
> > attached ovn-nb schema file.
> >
> > One of my concerns is that SFC almost doubles the size of the ovn-nb
> > schema but I could not think of any other way of doing it.
> >
> > Thoughts?
> >
> > John
>
> The dictionary looks fine for a starting point, and the more I look
> at the classifier, the more I wonder if we can't do something with
> the current ACL table to avoid duplication in the NB database
> definition...
>
> Ryan
>
> > From: Ryan Moats <rmo...@us.ibm.com>
> > Date: Wednesday, May 25, 2016 at 7:27 AM
> > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > Development Mailing List <openstack-dev@lists.openstack.org>, Ben Pfaff
<
> > b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant <
> russ...@ovn.org
> > >
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/24/2016
> > 06:33:05 PM:
> >
> > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > > Development Mailing List" <openstack-dev@lists.openstack.org>
> > > Date: 05/24/2016 06:33 PM
> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> > >
> > > Ryan,
> > >
> > > 

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/26/2016 10:59:48
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff <b...@ovn.org>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, Justin
> Pettit <jpet...@ovn.org>, OpenStack Development Mailing List
> <openstack-dev@lists.openstack.org>, Russell Bryant <russ...@ovn.org>
> Date: 05/26/2016 11:00 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Agree with your description of the problem. The only thing I would
> add is that in the case of bi-directional chains the return flows
> need to go through the same VNF(Port-pair).

I'm pretty sure that is caught automagically, isn't it?

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Wednesday, May 25, 2016 at 9:29 PM
> To: Ben Pfaff <b...@ovn.org>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, John McDowall <
> jmcdow...@paloaltonetworks.com>, Justin Pettit <jpet...@ovn.org>,
> OpenStack Development Mailing List <openstack-dev@lists.openstack.org
> >, Russell Bryant <russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ben Pfaff <b...@ovn.org> wrote on 05/25/2016 07:44:43 PM:
>
> > From: Ben Pfaff <b...@ovn.org>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: John McDowall <jmcdow...@paloaltonetworks.com>,
> > "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > Development Mailing List <openstack-dev@lists.openstack.org>, Justin
> > Pettit <jpet...@ovn.org>, Russell Bryant <russ...@ovn.org>
> > Date: 05/25/2016 07:44 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > > As I understand it, Table 0 identifies the logical port and logical
> > > flow. I'm worried that this means we'll end up with separate bucket
> > > rules for each ingress port of the port pairs that make up a port
> > > group, leading to a cardinality product in the number of rules.
> > > I'm trying to think of a way where Table 0 could identify the packet
> > > as being part of a particular port group, and then I'd only need one
> > > set of bucket rules to figure out the egress side.  However, the
> > > amount of free metadata space is limited and so before we go down
> > > this path, I'm going to pull Justin, Ben and Russell in to see if
> > > they buy into this idea or if they can think of an alternative.
> >
> > I've barely been following the discussion, so a recap of the question
> > here would help a lot.
> >
>
> Sure (and John gets to correct me where I'm wrong) - the SFC proposal
> is to carry a chain as a ordered set of port groups, where each group
> consists of multiple port pairs. Each port pair consists of an ingress
> port and an egress port, so that traffic is load balanced between
> the ingress ports of a group. Traffic from the egress port of a group
> is sent to the ingress port of the next group (ingress and egress here
> are from the point of view of the thing getting the traffic).
>
> I was suggesting to John that from the view of the switch, this would
> be reversed in the openvswitch rules - the proposed CHAINING stage
> in the ingress pipeline would apply the classifier for traffic entering
> a chain and identify traffic coming from an egress SFC port in the
> midst of a chain. The egress pipeline would identify the next ingress SFC
> port that gets the traffic or the final destination for traffic exiting
> the chain.
>
> Further, I pointed him at the select group for how traffic could be
> load balanced between the different ports that are contained in a port
> group, but that I was worried that I'd need a cartesian product of rules
> in the egress chain stage.  Having thought about this some more, I'm
> realizing that I'm confused and the number of rules should not be that
> bad:
>
> - Table 0 will identify the logical port the traffic comes from
> - The CHAINING stage of the ingress pipeline can map that logical
>   port information to the port group the port is part of.
> - The CHAINING stage of the egress pipeline would use that port
>   group information to select the next logical port via a select group.
>
> I believe this requires a total number of rules in the CHAINING stages
> of the order of the number of ports in the service chain.
>
> The above is predicated on carrying the port group information from
> the ingress pipeline to the egress pipeline in metadata, so I would
> be looking to you for ideas on where this data could be carried, since
> I know that we don't have infinite space for said metadata...
>
> Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

Ben Pfaff <b...@ovn.org> wrote on 05/25/2016 07:44:43 PM:

> From: Ben Pfaff <b...@ovn.org>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: John McDowall <jmcdow...@paloaltonetworks.com>,
> "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Justin
> Pettit <jpet...@ovn.org>, Russell Bryant <russ...@ovn.org>
> Date: 05/25/2016 07:44 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:
> > As I understand it, Table 0 identifies the logical port and logical
> > flow. I'm worried that this means we'll end up with separate bucket
> > rules for each ingress port of the port pairs that make up a port
> > group, leading to a cardinality product in the number of rules.
> > I'm trying to think of a way where Table 0 could identify the packet
> > as being part of a particular port group, and then I'd only need one
> > set of bucket rules to figure out the egress side.  However, the
> > amount of free metadata space is limited and so before we go down
> > this path, I'm going to pull Justin, Ben and Russell in to see if
> > they buy into this idea or if they can think of an alternative.
>
> I've barely been following the discussion, so a recap of the question
> here would help a lot.
>

Sure (and John gets to correct me where I'm wrong) - the SFC proposal
is to carry a chain as a ordered set of port groups, where each group
consists of multiple port pairs. Each port pair consists of an ingress
port and an egress port, so that traffic is load balanced between
the ingress ports of a group. Traffic from the egress port of a group
is sent to the ingress port of the next group (ingress and egress here
are from the point of view of the thing getting the traffic).

I was suggesting to John that from the view of the switch, this would
be reversed in the openvswitch rules - the proposed CHAINING stage
in the ingress pipeline would apply the classifier for traffic entering
a chain and identify traffic coming from an egress SFC port in the
midst of a chain. The egress pipeline would identify the next ingress SFC
port that gets the traffic or the final destination for traffic exiting
the chain.

Further, I pointed him at the select group for how traffic could be
load balanced between the different ports that are contained in a port
group, but that I was worried that I'd need a cartesian product of rules
in the egress chain stage.  Having thought about this some more, I'm
realizing that I'm confused and the number of rules should not be that
bad:

- Table 0 will identify the logical port the traffic comes from
- The CHAINING stage of the ingress pipeline can map that logical
  port information to the port group the port is part of.
- The CHAINING stage of the egress pipeline would use that port
  group information to select the next logical port via a select group.

I believe this requires a total number of rules in the CHAINING stages
of the order of the number of ports in the service chain.

The above is predicated on carrying the port group information from
the ingress pipeline to the egress pipeline in metadata, so I would
be looking to you for ideas on where this data could be carried, since
I know that we don't have infinite space for said metadata...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/25/2016 07:27:46
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>, Ben
> Pfaff <b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant
> <russ...@ovn.org>
> Date: 05/25/2016 07:28 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Ok – I will let the experts weigh in on load balancing.
>
> In the meantime I have attached a couple of files to show where I am
> going. The first is sfc_dict.py and is a representation of the dict
> I am passing from SFC to OVN. This will then translate to the
> attached ovn-nb schema file.
>
> One of my concerns is that SFC almost doubles the size of the ovn-nb
> schema but I could not think of any other way of doing it.
>
> Thoughts?
>
> John

The dictionary looks fine for a starting point, and the more I look
at the classifier, the more I wonder if we can't do something with
the current ACL table to avoid duplication in the NB database
definition...

Ryan

> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Wednesday, May 25, 2016 at 7:27 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>, Ben Pfaff <
> b...@ovn.org>, Justin Pettit <jpet...@ovn.org>, Russell Bryant
<russ...@ovn.org
> >
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/24/2016
> 06:33:05 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>
> > Date: 05/24/2016 06:33 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks for getting back to me and pointing me in a more OVS like
> > direction. What you say makes sense, let me hack something together.
> > I have been a little distracted getting some use cases together. The
> > other area is how to better map the flow-classifier I have been
> > thinking about it a little, but I will leave it till after we get
> > the chains done.
> >
> > Your load-balancing comment was very interesting – I saw some
> > patches for load-balancing a few months ago but nothing since. It
> > would be great if we could align with load-balancing as that would
> > make a really powerful solution.
> >
> > Regards
> >
> > John
>
> John-
>
> For the load balancing, I believe that you'll want to look at
> openvswitch's select group, as that should let you set up multiple
> buckets for each egress port in the port pairs that make up a port
> group.
>
> As I understand it, Table 0 identifies the logical port and logical
> flow. I'm worried that this means we'll end up with separate bucket
> rules for each ingress port of the port pairs that make up a port
> group, leading to a cardinality product in the number of rules.
> I'm trying to think of a way where Table 0 could identify the packet
> as being part of a particular port group, and then I'd only need one
> set of bucket rules to figure out the egress side.  However, the
> amount of free metadata space is limited and so before we go down
> this path, I'm going to pull Justin, Ben and Russell in to see if
> they buy into this idea or if they can think of an alternative.
>
> Ryan
>
> >
> > From: Ryan Moats <rmo...@us.ibm.com>
> > Date: Monday, May 23, 2016 at 9:06 PM
> > To: John McDowall <jmcdow...@paloaltonetworks.com>
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> > Development Mailing List <openstack-dev@lists.openstack.org>
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016
> > 03:55:14 PM:
> >
> > > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > > Development Mailing List" <openstack-dev@lists.openstack.org>
> > > Date: 05/18/2016 03:55 PM
&g

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/24/2016 06:33:05
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/24/2016 06:33 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks for getting back to me and pointing me in a more OVS like
> direction. What you say makes sense, let me hack something together.
> I have been a little distracted getting some use cases together. The
> other area is how to better map the flow-classifier I have been
> thinking about it a little, but I will leave it till after we get
> the chains done.
>
> Your load-balancing comment was very interesting – I saw some
> patches for load-balancing a few months ago but nothing since. It
> would be great if we could align with load-balancing as that would
> make a really powerful solution.
>
> Regards
>
> John

John-

For the load balancing, I believe that you'll want to look at
openvswitch's select group, as that should let you set up multiple
buckets for each egress port in the port pairs that make up a port
group.

As I understand it, Table 0 identifies the logical port and logical
flow. I'm worried that this means we'll end up with separate bucket
rules for each ingress port of the port pairs that make up a port
group, leading to a cardinality product in the number of rules.
I'm trying to think of a way where Table 0 could identify the packet
as being part of a particular port group, and then I'd only need one
set of bucket rules to figure out the egress side.  However, the
amount of free metadata space is limited and so before we go down
this path, I'm going to pull Justin, Ben and Russell in to see if
they buy into this idea or if they can think of an alternative.

Ryan

>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Monday, May 23, 2016 at 9:06 PM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016
> 03:55:14 PM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>
> > Date: 05/18/2016 03:55 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > OK all three repos and now aligned with their masters. I have done
> > some simple level system tests and I can steer traffic to a single
> > VNF.  Note: some additional changes to networking-sfc to catch-up
> > with their changes.
> >
> > https://github.com/doonhammer/networking-sfc
> > https://github.com/doonhammer/networking-ovn
> > https://github.com/doonhammer/ovs
> >
> > The next tasks I see are:
> >
> > 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> > will pass a nested port-chain dictionary holding port-pairs/port-
> > pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> > 2. Align the interface between networking-ovn and ovs/ovn to match
> > the nested dictionary in 1.
> > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain
model.
> > 4. Add ability to support chain of port-pairs
> > 5. Think about flow-classifiers and how best to map them, today I
> > just map the logical-port and ignore everything else.
> >
> > Any other suggestions/feedback?
> >
> > Regards
> >
> > John
>
> John-
>
> (Sorry for sending this twice, but I forgot that text/html is not liked
> by the mailing lists ...)
>
> My apologies for not answering this sooner - I was giving a two day
> training on Tues/Wed last week and came back to my son graduating
> from HS the next day, so things have been a bit of a whirlwind here.
>
> Looking at the github repos, I like the idea of passing a dictionary
> from networking-sfc to networking-ovn. The flow classifiers should
> be relatively straightforward to map to ovs match rules (famous last
> words)...
>
> I've probably missed an orbit here, but in the ovn-northd implementation,
> I was expecting to find service chains in the egress and router pipelines
> in addition to the ingress pipeline (see below for why I

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/18/2016 03:55:14
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/18/2016 03:55 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> OK all three repos and now aligned with their masters. I have done
> some simple level system tests and I can steer traffic to a single
> VNF.  Note: some additional changes to networking-sfc to catch-up
> with their changes.
>
> https://github.com/doonhammer/networking-sfc
> https://github.com/doonhammer/networking-ovn
> https://github.com/doonhammer/ovs
>
> The next tasks I see are:
>
> 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> will pass a nested port-chain dictionary holding port-pairs/port-
> pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> 2. Align the interface between networking-ovn and ovs/ovn to match
> the nested dictionary in 1.
> 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain
model.
> 4. Add ability to support chain of port-pairs
> 5. Think about flow-classifiers and how best to map them, today I
> just map the logical-port and ignore everything else.
>
> Any other suggestions/feedback?
>
> Regards
>
> John

John-

(Sorry for sending this twice, but I forgot that text/html is not liked
by the mailing lists ...)

My apologies for not answering this sooner - I was giving a two day
training on Tues/Wed last week and came back to my son graduating
from HS the next day, so things have been a bit of a whirlwind here.

Looking at the github repos, I like the idea of passing a dictionary
from networking-sfc to networking-ovn. The flow classifiers should
be relatively straightforward to map to ovs match rules (famous last
words)...

I've probably missed an orbit here, but in the ovn-northd implementation,
I was expecting to find service chains in the egress and router pipelines
in addition to the ingress pipeline (see below for why I think a service
chain stage in the egress pipeline makes sense ...)

Also, in the ovn-northd implementation, I'm a little disturbed to see the
ingress side of the service chain sending packets to output ports - I
think that a more scalable (and more "ovs-like" approach) would be to
match the egress side of a port pair in the chaining stage of the
ingress pipeline, with an action that  set the input port register.
Then the egress pipeline would have a chaining stage where the output
port register would be set based on the ingress port of the next port
pair in the chain and the packet being punted to the proper output port
in the last table.  That should automagically build your function chain
and provide the basis for bucketizing multiple ingress ports for the
next port group to support hash based load balancing.

Does that make sense?

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John-
 
My apologies for not answering this sooner - I was giving a two day training on Tues/Wed last week and came back to my son graduating from HS the next day, so thiings have been a bit of a whirlwind here.
 
Looking at the github repos, I like the idea of passing a dictionary from networking-sfc to networking-ovn.  The flow classifiers should be relatively straightforward to map to ovs match rules (famous last words)...
 
I've probably missed an orbit here, but in the ovn-northd implementation, I was expecting to find service chains in the egress and router pipelines in addition to the ingress pipeline (see below for why I think a service chain stage in the egress pipeline makes sense ...)
 
Also, in the ovn-northd implementation, I'm a little disturbed to see the ingress side of the service chain sending packets to output ports - I think that a more
scalable (and more "ovs" approach) would be to match the egress side of a port pair in the chaining stage of the ingress pipeline, with an action that  set the input port register.  Then the egress pipeline would have a chaining stage where the output port register would be set based on the ingress port of the next port pair in the chain and the packet being punted to the proper output port in the last table.  That should automagically build your function chain and provider the bases for bucketizing multiple ingress ports for the next port group to support hash based load balancing.
 
Does that make sense?
 
Ryan
 
- Original message -From: John McDowall <jmcdow...@paloaltonetworks.com>To: Ryan Moats/Omaha/IBM@IBMUSCc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack Development Mailing List" <openstack-dev@lists.openstack.org>Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVNDate: Wed, May 18, 2016 3:55 PM 
Ryan,
 
OK all three repos and now aligned with their masters. I have done some simple level system tests and I can steer traffic to a single VNF.  Note: some additional changes to networking-sfc to catch-up with their changes.
 
https://github.com/doonhammer/networking-sfc 
https://github.com/doonhammer/networking-ovn
https://github.com/doonhammer/ovs 
 
The next tasks I see are:
 
 
Decouple networking-sfc and networking-ovn. I am thinking that I will pass a nested port-chain dictionary holding port-pairs/port-pair-groups/flow-classifiers from networking-sfc to networking-ovn.Align the interface between networking-ovn and ovs/ovn to match the nested dictionary in 1.Modify the ovn-nb schema and ovn-northd.c to march the port-chain model.Add ability to support chain of port-pairsThink about flow-classifiers and how best to map them, today I just map the logical-port and ignore everything else.
 
Any other suggestions/feedback?
 
Regards
 
John
  
From: Ryan Moats <rmo...@us.ibm.com>Date: Wednesday, May 11, 2016 at 1:39 PMTo: John McDowall <jmcdow...@paloaltonetworks.com>Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN 
  
John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/11/2016 12:37:40 PM:> From: John McDowall <jmcdow...@paloaltonetworks.com>> To: Ryan Moats/Omaha/IBM@IBMUS> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack> Development Mailing List" <openstack-dev@lists.openstack.org>> Date: 05/11/2016 12:37 PM> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN>> Ryan,>> I have done networking-sfc the files that I see as changed/added are:>> devstack/settings   Modified Runtime setting to pick up OVN Driver> networking_sfc/db/migration/alembic_migrations/versions/mitaka/> expand/5a475fc853e6_ovs_data_model.py Hack to work around> flow_classifier issue – need to resolve with SFC team.> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN Driver> networking_sfc/services/sfc/drivers/ovn/driver.py     Added ovn driver file> setup.cfg Inserted OVN driver entry>> I am currently working to clean up ovs/ovn.>> Regards>> JohnI can confirm that the networking-sfc rebase goes in clean againstmaster for me :) - Looking forward to ovs ...Ryan 
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/11/2016 12:37:40
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/11/2016 12:37 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> I have done networking-sfc the files that I see as changed/added are:
>
> devstack/settings   Modified Runtime setting to pick up OVN Driver
> networking_sfc/db/migration/alembic_migrations/versions/mitaka/
> expand/5a475fc853e6_ovs_data_model.py Hack to work around
> flow_classifier issue – need to resolve with SFC team.
> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN
Driver
> networking_sfc/services/sfc/drivers/ovn/driver.py Added ovn driver
file
> setup.cfg Inserted OVN driver entry
>
> I am currently working to clean up ovs/ovn.
>
> Regards
>
> John

I can confirm that the networking-sfc rebase goes in clean against
master for me :) - Looking forward to ovs ...

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/11/2016 12:37:40
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/11/2016 12:37 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> I have done networking-sfc the files that I see as changed/added are:
>
> devstack/settings   Modified Runtime setting to pick up OVN Driver
> networking_sfc/db/migration/alembic_migrations/versions/mitaka/
> expand/5a475fc853e6_ovs_data_model.py Hack to work around
> flow_classifier issue – need to resolve with SFC team.
> networking_sfc/services/sfc/drivers/ovn/__init__.py   Added for OVN
Driver
> networking_sfc/services/sfc/drivers/ovn/driver.py Added ovn driver
file
> setup.cfg Inserted OVN driver entry
>

Ack... I'll run throug those changes either later today or tomorrow
morning...

Thanks,
Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/11/2016 12:06:55
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/11/2016 12:07 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Looks good apart from:
>
> networking_ovn/common/extensions.py
>
> There should be no changes to that file, I removed them as they are
> from an older prototype.
>
> Regards
>
> John

Ah, ok, I must of missed that when rolling through the patch series -
I've updated my copy.

Are you tackling networking-sfc or ovs next?

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/11/2016 11:30:07
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/11/2016 11:30 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Apologies for missing the _init_.py files – removed them and
> remerged. When I do a compare from my repo to main I see three files
> changed (which I think is correct):
>
> networking_ovn/ovsdb/commands.py
> networking_ovn/ovsdb/impl_idl_ovn.py
> networking_ovn/ovsdb/ovn_api.py
>
> I could be doing something wrong as not an expert at merging repos.
> If I am doing something wrong let me know and I will fix it.
>
> Regards
>
> John

So the change I made to common/extensions.py was to avoid a merge
conflict, and I double checked and yes, the changes I had to
plugin.py are spurious, so here is an updated/corrected patch for
you to check against:

From eb93dc3984145f1b82be15d204c2f0790c1429bd Mon Sep 17 00:00:00 2001
From: RYAN D. MOATS <rmo...@us.ibm.com>
Date: Wed, 11 May 2016 09:10:18 -0500
Subject: [PATCH] test

Signed-off-by: RYAN D. MOATS <rmo...@us.ibm.com>
---
 networking_ovn/common/extensions.py  |1 +
 networking_ovn/ovsdb/commands.py |   78 ++
 networking_ovn/ovsdb/impl_idl_ovn.py |   18 
 networking_ovn/ovsdb/ovn_api.py  |   49 +
 4 files changed, 146 insertions(+), 0 deletions(-)

diff --git a/networking_ovn/common/extensions.py 
b/networking_ovn/common/extensions.py
index c171e11..55fc147 100644
--- a/networking_ovn/common/extensions.py
+++ b/networking_ovn/common/extensions.py
@@ -37,4 +37,5 @@ SUPPORTED_API_EXTENSIONS = [
 'subnet_allocation',
 'port-security',
 'allowed-address-pairs',
+'sfi',
 ]
diff --git a/networking_ovn/ovsdb/commands.py b/networking_ovn/ovsdb/commands.py
index 7ea7a6f..68a747f 100644
--- a/networking_ovn/ovsdb/commands.py
+++ b/networking_ovn/ovsdb/commands.py
@@ -164,6 +164,84 @@ class DelLogicalPortCommand(BaseCommand):
 setattr(lswitch, 'ports', ports)
 self.api._tables['Logical_Port'].rows[lport.uuid].delete()

+class AddLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, lswitch, may_exist, **columns):
+super(AddLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.lswitch = lswitch
+self.may_exist = may_exist
+self.columns = columns
+
+def run_idl(self, txn):
+try:
+lswitch = idlutils.row_by_value(self.api.idl, 'Logical_Switch',
+'name', self.lswitch)
+services= getattr(lswitch, 'services', [])
+except idlutils.RowNotFound:
+msg = _("Logical Switch %s does not exist") % self.lswitch
+raise RuntimeError(msg)
+if self.may_exist:
+service = idlutils.row_by_value(self.api.idl,
+ 'Logical_Service', 'name',
+ self.lservice, None)
+if service:
+return
+
+lswitch.verify('services')
+
+service = txn.insert(self.api._tables['Logical_Service'])
+service.name = self.lservice
+for col, val in self.columns.items():
+setattr(service, col, val)
+# add the newly created service to existing lswitch
+services.append(service.uuid)
+setattr(lswitch, 'services', services)
+
+class SetLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, if_exists, **columns):
+super(SetLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.columns = columns
+self.if_exists = if_exists
+
+def run_idl(self, txn):
+try:
+service = idlutils.row_by_value(self.api.idl, 'Logical_Service',
+'name', self.lservice)
+except idlutils.RowNotFound:
+if self.if_exists:
+return
+msg = _("Logical Service %s does not exist") % self.lservice
+raise RuntimeError(msg)
+
+for col, val in self.columns.items():
+setattr(service, col, val)
+
+class DelLogicalServiceCommand(BaseCommand):
+def __init__(self, api, lservice, lswitch, if_exists):
+super(DelLogicalServiceCommand, self).__init__(api)
+self.lservice = lservice
+self.lswitch = lswitch
+self.if_exists = if_exists
+
+def run_idl(self, txn):
+try:
+lservice = idlutils.row_by_value(self.api.idl, 'Logical_Service',
+ 'name

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/10/2016 11:11:57
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/10/2016 11:12 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Let me do that – I assume adding them to plugin.py is the right approach.
>
> I have cleaned up https://github.com/doonhammer/networking-ovn and
> did a merge so it should be a lot easier to see the changes. I am
> going to cleanup ovs/ovn next. Once I have everything cleaned up and
> make sure it is still working I will move the code over to the port-
> pair/port-chain model.
>
> Let me know if that works for you.
>
> Regards
>
> John
>
> From: Ryan Moats <rmo...@us.ibm.com>
> Date: Tuesday, May 10, 2016 at 7:38 AM
> To: John McDowall <jmcdow...@paloaltonetworks.com>
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev@lists.openstack.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/09/2016
> 10:46:41 AM:
>
> > From: John McDowall <jmcdow...@paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev@lists.openstack.org>
> > Date: 05/09/2016 10:46 AM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Thanks – let me try and get the code cleaned up and rebased. One
> > area that I could use your insight on is the interface to
> > networking-ovn and how it should look.
> >
> > Regards
> >
> > John
>
> Looking at this, the initial code that I think should move over are
> _create_ovn_vnf and _delete_ovn_vnf and maybe rename them to
> create_vnf and delete_vnf.
>
> What I haven't figured out at this point is:
> 1) Is the above enough?
> 2) Do we need to refactor some of OVNPlugin's calls to provide hooks
> for the SFC
>driver to use for when the OVNPlugin inheritance goes away.
>
> Ryan

I like the idea, but unfortunately, I'm still not able to apply the series
cleanly to openstack:master:
- the list of supported extensions has moved from plugin.py to
  commons/extensions.py
- the patches that create extensions/__init__.py and
  networking_ovn/db/migration/__init__.py complain of garbage
- the patch that adds Logging on fixed ips doesn't align with the new
  code structure for handling same
- the patch that removes experimental code also has a whole lot of
  changes that were part of the master devstack/plugin.sh and so
  confuses patch.  Worse, almost 90% of the changes to plugin.py fail
  because of the same commingling.

After walking through all the patches, I'm still seeing what looks like
some cruft: I'm not sure what networking_ovn/db/migration
and networking_ovn/extensions are doing anymore, as they only have
__init__.py files in them.

Even with that, I *think* the following patch below all the changes against
tip of the tree master...

Ryan

---
 networking_ovn/common/extensions.py |1 +
 networking_ovn/ovsdb/commands.py|   78 +++
 networking_ovn/ovsdb/impl_idl_ovn.py|   18 +++
 networking_ovn/ovsdb/ovn_api.py |   49 +++
 networking_ovn/plugin.py|   71 
 5 files changed, 217 insertions(+), 0 deletions(-)
 create mode 100644 networking_ovn/db/migration/__init__.py
 create mode 100644 networking_ovn/extensions/__init__.py

diff --git a/networking_ovn/common/extensions.py 
b/networking_ovn/common/extensions.py
index c171e11..55fc147 100644
--- a/networking_ovn/common/extensions.py
+++ b/networking_ovn/common/extensions.py
@@ -37,4 +37,5 @@ SUPPORTED_API_EXTENSIONS = [
 'subnet_allocation',
 'port-security',
 'allowed-address-pairs',
+'sfi',
 ]
diff --git a/networking_ovn/db/migration/__init__.py 
b/networking_ovn/db/migration/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/networking_ovn/extensions/__init__.py 
b/networking_ovn/extensions/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/networking_ovn/ovsdb/commands.py b/networking_ovn/ovsdb/commands.py
index 7ea7a6f..68a747f 100644
--- a/networking_ovn/ovsdb/commands.py
+++ b/networking_ovn/ovsdb/commands.py
@@ -164,6 +164,84 @@ class DelLogicalPortCommand(BaseCommand):
 setattr(lswitch, 'ports', ports)
 self.api

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/09/2016 10:46:41
AM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev@lists.openstack.org>
> Date: 05/09/2016 10:46 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks – let me try and get the code cleaned up and rebased. One
> area that I could use your insight on is the interface to
> networking-ovn and how it should look.
>
> Regards
>
> John

Looking at this, the initial code that I think should move over are
_create_ovn_vnf and _delete_ovn_vnf and maybe rename them to
create_vnf and delete_vnf.

What I haven't figured out at this point is:
1) Is the above enough?
2) Do we need to refactor some of OVNPlugin's calls to provide hooks for
the SFC
   driver to use for when the OVNPlugin inheritance goes away.

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

John McDowall <jmcdow...@paloaltonetworks.com> wrote on 05/08/2016 07:34:52
PM:

> From: John McDowall <jmcdow...@paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>
> Date: 05/08/2016 07:35 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Correcting ovs address
>
> Ryan,
>
> Thanks for taking a look at these  - really appreciate it. I will
> work on the rebasing this week and get everything current. At the
> same time I can get rid of some excess code as I went through a few
> iterations to get to this point. There are still a lot of
> unaddressed edge conditions and details that need to be thought
> through and addressed – but once we reach consensus on the approach
> we can start to address them.
>
> Thinking though the various repos in reverse order.
>
> OVS
> ===
>
> I would like to change the code to follow the model that Russell
> Bryant did in his patches see:  https://github.com/russellb/ovs/
> commits/chaining
>
> They have several advantages:
> 1. Creates a new table for chaining which should help isolate the
> code and make chaining more “atomic”
> 2. He follows the port-pair/port-chain model of SFC so integration
> should be cleaner
> 3. Following the port-pair/port-chain model makes extending the
> solution to handle a chain of VNFs fairly easy.
> If everyone is good with this I can work this into the patches and
rebase.

You are anticipating where I was looking to go, so I'm on board with
this idea.

> Networking-OVN
> ===
>
> There is some old code here in plugin.py that I think comes out.
> When I added OVN as a SFC Driver there was a lot of code that I
> added to  networking-ovn that became obsolete. The IDL code would be
> modified to follow the port-pair/port-chain. model.  The biggest
> question I have from your comments is the interface between the
> networking-sfc and networking-ovn. I think I agree with you that
> networking-ovn should expose an interface that is called by
> networking-sfc and that would remove the need to subclass OVNPlugin
> in the networking-sfc OVN driver. Is that what you were intending?

Yes, I was looking at how that subclass could be avoided.

> Networking-SFC
> ==
>
> If we follow Russell’s model in OVN/OVS then there very close
> alignment with the SFC model and the code will become simpler. Also
> removing the OVNPlugin dependency will also clean things up.

Yes, I was hoping that would be a side effect as well...

I like all of your proposed ideas and am looking forward to seeing
the next iteration. Please feel free to reach out if you need
another pair of hands to help with coding...

Ryan Moats
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Ryan Moats]

First, apologies for the cross-posting, but when this topic came up last
week,
I wasn't able to keep track of all the folks that asked to be included in
the email,
so I'm doing a mass post to try and catch everybody that might be
interested.

Second, John, thank you for stepping forward and mentioning that you've
been
working on code for SFC and OVN!!  I took a look at your repos on
github.com
(because I'm a firm believe in NOT re-inventing the wheel) and my initial
comments follow...

Networking-SFC (https://github.com/doonhammer/networking-sfc)
=

This repo is the cleanest, as I was able to merge the current
networking-sfc
master on top of it with no conflicts.  Looking around, I'm not entirely
comfortable with the idea of networking-sfc making direct calls to the OVN
IDL
in parallel to networking-ovn.  I believe a cleaner solution would be to
add the code to configure OVN for SFC to networking-ovn itself, and expose
an
API that the driver code in networking-sfc would call.

Networking-OVN (https://github.com/doonhammer/networking-ovn)
=

This repo makes me a bit nervous, as it claims to be 36 commits ahead
(and 129 commits behind) openstack-master.  That's a substantial drift, and
the first thing I wanted to do was see what merge conflicts might exist
when
I try to merge the current master into it.  There are two merge conflicts
detected in networking_ovn/plugin.py, and given (as I understand it) the
direction of splitting the networking-ovn monolithic plugin back into ML2
and L3 service portions, I encourage you to rebase this commit (if you
don't
have time, let me know and I'll see about fixing the merge issue).

OVS (https://github.com/doonhammer/ovs)
===

This repo also has some drift (in that it is 21 comits ahead and 406
commits
behind openvswitch master).  The merge conflicts I've found here are in
ovn/ovn-nb.ovsschema and ovn/northd/ovn-northd.c.  The ovsschema conflict
looks like it can be resolved by bumping the micro version of the current
master
and recalculating/inserting the schema checksum.  On the other hand, the
conflicts in ovn-northd.c are a bit more numerous (I count 22 of them as I
write
this).  I'm not sure what the easiest way is to get this rebased onto the
current tip of tree master...

The reason I'm interested in the rebasing exercises is I want to get to a
set
of patches that can be publically committed, at which point I (wearing my
operator hat) can evaluate them to see if they meet our needs for SFC.  If
you
need help with the rebasing, I'm happy to work with you...

Ryan Moats (regXboi on IRC, jayhawk87 on github)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][DVR]

[Ryan Moats]

"Armando M." <arma...@gmail.com> wrote on 12/04/2015 03:43:29 PM:

> From: "Armando M." <arma...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 12/04/2015 03:44 PM
> Subject: Re: [openstack-dev] [Neutron][DVR]
>
> > On 4 December 2015 at 05:56, Ryan Moats <rmo...@us.ibm.com> wrote:
> > I pretty much agree with Oleg here - I'm not sure an additional tag
> > for defects is needed.
> > The idea of a DvrImpact in the commit message is interesting, but
> > I'm not entirely convinced - if we
> > do it for one sub-project, do we need to do it for all sub-projects
> > and then what does that turn into?
> What does this mean? No other project should care about this. DVR is
> a core feature.

I'm trying to understand if (at its logical conclusion) we end up with
commit tags for all features (i.e. RbacImpact, BareMetalImpact, DbImpact,
etc.) and what that would do to the commit message...

Ryan Moats (regXboi)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

[Ryan Moats]

Apologies to those who get this twice - I'm fighting with mail
clients/servers this morning (and I'm pretty sure I'm losing)

As a US person, I'm going to vote -1 on moving to 1600 UTC on Tuesdays - I
already have too many other meetings stacked up in this slot...

Ryan Moats (regXboi)

Dina Belova <dbel...@mirantis.com> wrote on 12/04/2015 03:46:06 AM:

> From: Dina Belova <dbel...@mirantis.com>
> To: OpenStack Development Mailing List  d...@lists.openstack.org>, openstack-operators  operat...@lists.openstack.org>
> Date: 12/04/2015 03:46 AM
> Subject: [Performance][Proposal] Moving IRC meeting from 15:00 UTC
> to 16:00 UTC
>
> Dear performance folks,
>
> There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays
> ) to 16:00 UTC (also Tuesdays) to make them more comfortable for US guys.
>
> Please leave your +1 / -1 here in the email thread.
>
> Btw +1 from me :)
>
> Cheers,
> Dina
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][DVR]

[Ryan Moats]

I pretty much agree with Oleg here - I'm not sure an additional tag for
defects is needed.
The idea of a DvrImpact in the commit message is interesting, but I'm not
entirely convinced - if we
do it for one sub-project, do we need to do it for all sub-projects and
then what does that turn into?

I'm not yet for or against, I'm just trying to think what the commit
messages are going to end up looking like...

Ryan Moats (regXboi)

Oleg Bondarev <obonda...@mirantis.com> wrote on 12/04/2015 02:44:58 AM:

> From: Oleg Bondarev <obonda...@mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 12/04/2015 02:46 AM
> Subject: Re: [openstack-dev] [Neutron][DVR]
>
> On Thu, Dec 3, 2015 at 10:06 PM, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hpe.com> wrote:
> Hi Carl,
> Sounds reasonable suggestion.
> Thanks
> Swami
>
> -Original Message-
> From: Carl Baldwin [mailto:c...@ecbaldwin.net]
> Sent: Thursday, December 03, 2015 10:47 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Neutron][DVR]
>
> I was going to bring this up in the meeting this morning but IRC
> troubles prevented it.
>
> After chatting with Armando, I'd like to suggest a few enhancements
> to how we're tackling DVR during this cycle.  I'm hoping that these
> changes help us to get things done faster and more efficiently.  Let
> me know if you think otherwise.
>
> First, I'd like to suggest adding DvrImpact to the comment of any
> patches that are meant to improve DVR in some way.  People have
> asked me about reviewing DVR changes.  I can show them the DVR
> backlog [1] in launchpad but it would be nice to have a DVR
specificdashboard.
> With DvrImpact in the subject, we can make it even more convenient
> to find reviews.
>
> +1
>
>
> The other change I'd like to propose is to categorize our DVR
> backlog in to three categories:  broken, scale (loadimpact), and
newfeatures.
> I'd propose that we prioritize in that order.  Anyone have any
> suggestions for how to tag or otherwise categorize and tackle these?
>
> This might be useful but honestly I don't feel a strong need for
> categorizing dvr bugs at the moment because of the amount of bugs
> (currently I see 31 when filtering by l3-dvr-backlog tag).
> l3-dvr-backlog tag + High/Critical may stand for 'broken', l3-dvr-
> backlog + loadimpact for 'scale', l3-dvr-backlog + Wishlist for new
> (small) enhancements.
> I might be missing something though.
>
> I know there is a loadimpact (or similar) tag those.  Should we come
> up with a couple more tags to divide the rest?
>
> Thoughts?
>
> Carl
>
> [1] https://goo.gl/M5SwfS
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Bug deputy process

[Ryan Moats]

I missed this the first time around, but I concur with the comments of the
other deputies -
the effort only took me about an hour or two a day and I think it's been
rather helpful :)

Ryan Moats (regXboi)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Ether pad on O(n)/Linear Execution Time/Hyper-Scale

[Ryan Moats]

I promised during the DVR IRC meeting yesterday to re-run the L3 agent
experiments that I've been doing that have led to performance based patches
over the last two months and to provide an etherpad with both the results
and the methodology.

The etherpad is up for folks to review at [1].  While writing this, I
decided to no longer call this work "O(n)" or "Linear Execution Time" but
rather "Hyper-Scale" (because that sounds so much more cool (smile)).  Most
of what is there is methodology - while I've got some results from
yesterday, but I need to dig down some more, so I'll be updating that part
either tomorrow or early next week.

One thought that Kyle and I were discussing was should the "how" part go
into a devref, so that we aren't dependent on an etherpad.  I'm thinking
it's not a bad idea, but I'm wondering if it should only be in neutron or
if it should be elsewhere (like user docs that go along with code that
would implement [2] in oslo...

Thoughts and comments are welcome,
Ryan Moats (regXboi)

[1] https://etherpad.openstack.org/p/hyper-scale
[2] https://bugs.launchpad.net/neutron/+bug/1512864
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next week

[Ryan Moats]

Ditto Ryan (regXboi) Moats

Carl Baldwin  wrote on 11/02/2015 11:47:27 AM:

> From: Carl Baldwin 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 11/02/2015 11:48 AM
> Subject: Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next
week
>
> Thanks, Brian.  I'm planning to be there.
>
> Carl
>
> On Thu, Oct 29, 2015 at 10:17 PM, Brian Haley 
wrote:
> > A few of us had a discussion this week at Summit and decided to
re-start the
> > weekly Neutron Distributed Virtual Router (DVR) meeting.  The goal is
to
> > help:
> >
> > - Stabilize DVR - fix the bugs
> > - Address performance/scalability issues
> > - Get the DVR jobs voting again
> >
> > Meetings will be on Wednesdays starting next week at 15:00 UTC.  I'm in
the
> > process of updating
> >
http://eavesdrop.openstack.org/#Neutron_Distributed_Virtual_Router_Meeting
> > with a link to the meeting page and agenda, which is currently at
> > https://wiki.openstack.org/wiki/Meetings/Neutron-DVR
> >
> > -Brian
> >
> >
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Ryan Moats]

(With apologies to the Who)...

"Meet the new things, same as the old things"

DVR - let's make it real folks :)

Performance - I keep turning over rocks and finding things that just don't
make sense to me...

I suspect others will come a calling as we go...

Ryan Moats
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] congrats to armax!

[Ryan Moats]

First, congratulations to armax on being elected PTL for Mitaka.  Looking
forward to Neutron improving over the next six months.

Second thanks to everybody that voted in the election. Hopefully we had
something close to 100% turnout, because that is an important
responsibility of the population.

Ryan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][L3][QA] DVR job failure rate and maintainability

[Ryan Moats]

I couldn't have said it better, Sean.

Ryan Moats

"Sean M. Collins" <s...@coreitpro.com> wrote on 09/14/2015 05:01:03 PM:

> From: "Sean M. Collins" <s...@coreitpro.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/14/2015 05:01 PM
> Subject: [openstack-dev] [neutron][L3][QA] DVR job failure rate and
> maintainability
>
> [adding neutron tag to subject and resending]
>
> Hi,
>
> Carl Baldwin, Doug Wiegley, Matt Kassawara, Ryan Moats, and myself are
> at the QA sprint in Fort Collins. Earlier today there was a discussion
> about the failure rate about the DVR job, and the possible impact that
> it is having on the gate.
>
> Ryan has a good patch up that shows the failure rates over time:
>
> https://review.openstack.org/223201
>
> To view the graphs, you go over into your neutron git repo, and open the
> .html files that are present in doc/dashboards - which should open up
> your browser and display the Graphite query.
>
> Doug put up a patch to change the DVR job to be non-voting while we
> determine the cause of the recent spikes:
>
> https://review.openstack.org/223173
>
> There was a good discussion after pushing the patch, revolving around
> the need for Neutron to have DVR, to fit operational and reliability
> requirements, and help transition away from Nova-Network by providing
> one of many solutions similar to Nova's multihost feature.  I'm skipping
> over a huge amount of context about the Nova-Network and Neutron work,
> since that is a big and ongoing effort.
>
> DVR is an important feature to have, and we need to ensure that the job
> that tests DVR has a high pass rate.
>
> One thing that I think we need, is to form a group of contributors that
> can help with the DVR feature in the immediate term to fix the current
> bugs, and longer term maintain the feature. It's a big task and I don't
> believe that a single person or company can or should do it by
themselves.
>
> The L3 group is a good place to start, but I think that even within the
> L3 team we need dedicated and diverse group of people who are interested
> in maintaining the DVR feature.
>
> Without this, I think the DVR feature will start to bit-rot and that
> will have a significant impact on our ability to recommend Neutron as a
> replacement for Nova-Network in the future.
>
> --
> Sean M. Collins
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] PTL Candidancy

[Ryan Moats]

I'd like to announce my candidacy for the Mitaka cycle as Neutron PTL.

While not currently a Neutron core, I've been looking at hard at Neutron
for several cycles now and I feel that while we've accomplished a great
deal, more consolidation at this point will be desirable.  Therefore, if
elected, my goals for the Mitaka cycle will be:

1. Continue the decomposition efforts that Kyle has championed up through
the Liberty cycle.
2. Improve the performance and reliability of existing reference solutions
so that operators can be more confident when deploying neutron.
3. Like Liberty, we have a large list of new items for the design summit
[1], which we will work to pare down into items that can be delivered in
Mitaka

Thanks,
Ryan Moats (IRC handle: regXboi)

[1] https://etherpad.openstack.org/p/neutron-mitaka-designsummit
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

[Ryan Moats]

One thing came up during lunch was including unit and functional testing of
dual stack in the check and gate queues - I was regaled over lunch with one
operator's experiences in trying to run Neutron on a dual stack system.

Ryan Moats (regXboi)

Edgar Magana edgar.mag...@workday.com wrote on 08/19/2015 03:43:44 PM:

 From: Edgar Magana edgar.mag...@workday.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 08/19/2015 03:44 PM
 Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

 Actually, there were very few requirements collected. So, your
 summary is correct.

 I feel that this time we did not get a lot of input s we got during
 the Ops meet-up in Philadelphia.

 I also recommend to read the burning issues ether pads, there are
 few suggestions on the networking side. Actually, I believe
 Operators has expressed in this session some good feedback that they
 probaly did not want to repeat during the networking section.

 https://etherpad.openstack.org/p/PAO-ops-burning-issues

 Cheers,

 Edgar

 From: Assaf Muller
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 Date: Wednesday, August 19, 2015 at 1:34 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

 On Wed, Aug 19, 2015 at 2:52 PM, Edgar Magana edgar.mag...@workday.com
  wrote:
 Folks,

 I just want to share with you the feedback collected today during
 the networking session on Ops Meet-up:
 https://etherpad.openstack.org/p/PAO-ops-network-model

 Special thanks to Ryan and Doug for helping on some questions.

 The only action items for Neutron developers that I can spot are:
 1. Linux bridge + DVR / multi host
 2. Prevent data loss when restarting the OVS agent (The patch [1] is
 very close to merge anyway, nothing more to do here)
 3. Work as described by [2] (Big deployers team)
 The rest is either polling (Who uses what feature / plugin / etc) or
 generic comments with no actionable bugs or RFEs.
 Did I miss anything?

 [1] https://review.openstack.org/#/c/182920/
 [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases

 Cheers,

 Edgar


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

[Ryan Moats]

They didn't mention a release by name, so I think it may be fair that they
were testing pre-kilo - I'll take the action item to follow up with them...

Ryan

Sean M. Collins s...@coreitpro.com wrote on 08/19/2015 04:25:22 PM:

 From: Sean M. Collins s...@coreitpro.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 08/19/2015 04:26 PM
 Subject: Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

 On Wed, Aug 19, 2015 at 05:11:55PM EDT, Ryan Moats wrote:
  One thing came up during lunch was including unit and functional
testing of
  dual stack in the check and gate queues - I was regaled over lunch with
one
  operator's experiences in trying to run Neutron on a dual stack system.

 We are testing dual stack

 https://review.openstack.org/#/c/160856/

 Have they found gaps in our coverage?

 --
 Sean M. Collins


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][infra] - py34 tests, devstack/base trusty and how does the neutron check pipeline choose between them (oh my)...

[Ryan Moats]

I've spent the back half of this week chasing setup failures in the voting
py34 job that is part of the neutron check queue. Here are my two examples:
[1] is the signature that I'm trying to avoid, and [2] is a signature that
I'm happier with because it is more of a real failure...

AFAICT, the key difference between these two signatures is the image loaded
for testing. The first used devstack-trusty and the second used
bare-trusty-1438870493.template.openstack.org. Now, I may be wrong,
but it looks to me like devstack-trusty doesn't have the same packages
installed, as it tries to build
various needed extensions from source code and fails on missing the
python3-dev package.  OTOH, the bare-trusty
image is quite happy at this point.

What isn't quite clear to me (yet) from looking at the
openstack-infra/project-config setup is how the different images are
chosen, so I'm not sure yes if the selection of devstack-trusty for [1] is
the bug,
or the fact that devstack-trusty is missing pieces that bare-trusty has is
the bug.

Looking for help from knowledgeable people about how to go about getting
this addressed.

Thanks,
Ryan Moats
IRC: regXboi

[1]
http://logs.openstack.org/05/144205/3/check/gate-neutron-python34/3f6f7bf/console.html.gz
[2]
http://logs.openstack.org/89/160289/6/check/gate-neutron-python34/ed3ccec/console.html.gz
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Ryan Moats]

I will be there for my lightning talk, and I think armax and kevin_benton
will be there - it would be good to find some time for us to pow-wow, along
with some teleconference so that carl_baldwin and mestery can join in...

Ryan Moats (regXboi)

Mike Dorman mdor...@godaddy.com wrote on 08/03/2015 10:07:23 PM:

 From: Mike Dorman mdor...@godaddy.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org, OpenStack Operators openstack-
 operat...@lists.openstack.org
 Date: 08/03/2015 10:08 PM
 Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3]
 [Large Deployments Team] Representing a networks connected by routers

 I hope we can move this idea moving forward.  I was disappointed to see
 the spec abandoned.

 Some of us from the large deployers group will be at the Ops Meetup.
Will
 there be any representation from Neutron there that we could discuss with

 more?

 Thanks,
 Mike





 On 8/3/15, 12:27 PM, Carl Baldwin c...@ecbaldwin.net wrote:

 Kevin, sorry for the delay in response.  Keeping up on this thread was
 getting difficult while on vacation.
 
 tl;dr:  I think it is worth it to talk through the idea of inserting
 some sort of a subnet group thing in the model to which floating ips
 (and router external gateways) will associate.  It has been on my mind
 for a long time now.  I didn't pursue it because a few informal
 attempts to discuss it with others indicated to me that it would be a
 difficult heavy-lifting job that others may not appreciate or
 understand.  Scroll to the bottom of this message for a little more on
 this.
 
 Carl
 
 On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton blak...@gmail.com wrote:
 Also, in my proposal, it is more the router that is the grouping
 mechanism.
 
  I can't reconcile this with all of the points you make in the rest of
 your
  email. You want the collection of subnets that a network represents,
 but you
  don't want any other properties of the network.
 
 This is closer to what I'm trying to say but isn't quite there.  There
 are some subnets that should be associated with the segments
 themselves and there are some that should be associated with the
 collection of segments.  I want floating IPs that are not tied the an
 L2 network.  None of the alternate proposals that I'd heard addressed
 this.
 
 that the network object is currently the closest thing we have to
  representing the L3 part of the network.
 
  The L3 part of a network is the subnets. You can't have IP addresses
 without
  the subnets, you can't have floating IPs without the subnets, etc.
 
 You're right but in the current model you can't have IP addresses
 without the network either which is actually the point I'm trying to
 make.
 
  A Neutron network is an L2 construct that encapsulates L3 things. By
  encapsulating them it also provides an implicit grouping. The routed
  networks proposal basically wants that implicit grouping without the
  encapsulation or the L2 part.
 
 This sounds about right.  I think it is wrong to assume that we need
 an L2 network to encapsulate L3 things.  I'm feeling restricted by the
 model and the insistence that a neutron network is a purely L2
 construct.
 
 We don't associate floating ips with a network because we want to arp
 for
  them.  You're taking a consequence of the current model and its
 constraints
  and presenting that as the motivation for the model. We do so because

 there
  is no better L3 object to associate it to.
 
  Don't make assumptions about how people use floating IPs now just
 because it
  doesn't fit your use-case well. When an external network is
implemented
 as a
  real Neutron network (leaving external_network_bridge blank like we
 suggest
  in the networking guide), normal ports can be attached and can
  co-exist/communicate with the floating IPs because it behaves as an L2
  network exactly as implied by the API. The current model works quite
 well if
  your fabric can extend the external network everywhere it needs to be.
 
 Yes, when an external network is implemented as a real Neutron
 network all of this is true and my proposal doesn't change any of
 this.  I'm wasn't making any such assumptions.  I acknowledge that the
 current model works well in this case and didn't intend to change it
 for current use cases.  It is precisely that because it does not fit
 my use case well that I'm pursuing this.
 
 Notice that a network marked only as external doesn't allow normal
 tenants to create ports.  It must also be marked shared to allow it.
 Unless tenants are creating regular ports then they really don't care
 if arp or anything else L2 is involved because such an external
 network is meant to give access external to the cloud where L2 is
 really just an implementation detail.  It is the deployer that cares
 because of whatever infrastructure (like a gateway router) needs to
 work with it.  If the L2 is important, then the deployer will not
 attempt to use an L3 only

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

[Ryan Moats]

If that's the case, then I'd say let's just solve this right way and create
a new construct rather...

Ryan Moats

Kevin Benton blak...@gmail.com wrote on 07/28/2015 06:44:53 PM:

 From: Kevin Benton blak...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 07/28/2015 06:46 PM
 Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks
 connected by routers

 We need to work on that code quite a bit anyway for other features
 (get me a network, VLAN trunk ports) so adding a different parameter
 shouldn't be bad. Even if Nova doesn't initially buy in, we can
 always pre-create the port and pass it to Nova boot as a UUID.

 On Tue, Jul 28, 2015 at 6:15 AM, Ryan Moats rmo...@us.ibm.com wrote:
 Kevin, doesn't this in itself create technical debt on the nova side
 in the sense of what an instance attaches to?
 I agree that it looks like less technical debt than conditionally
 redefining a network, but without nova buy-in, it looks
 like a non-starter...

 Ryan

 Kevin Benton blak...@gmail.com wrote on 07/28/2015 02:15:13 AM:

 [snip]

  I would rather see something to reference a group of subnets that
  can be used for floating IP allocation and port creation in lieu of
  a network ID than the technical debt that conditionally redefining a
  network will bring.




__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

[Ryan Moats]

Kevin, doesn't this in itself create technical debt on the nova side in the
sense of what an instance attaches to?
I agree that it looks like less technical debt than conditionally
redefining a network, but without nova buy-in, it looks
like a non-starter...

Ryan

Kevin Benton blak...@gmail.com wrote on 07/28/2015 02:15:13 AM:

[snip]

 I would rather see something to reference a group of subnets that
 can be used for floating IP allocation and port creation in lieu of
 a network ID than the technical debt that conditionally redefining a
 network will bring.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][neutron] dvr job for kilo?

[Ryan Moats]

+1

Kyle Mestery mest...@mestery.com wrote on 07/27/2015 08:16:07 AM [with a
bit of cleanup]:

  On Mon, Jul 27, 2015 at 6:57 AM, Thierry Carrez thie...@openstack.org
wrote:
  Ihar Hrachyshka wrote:
   I noticed that dvr job is now voting for all stable branches, and
   failing, because the branch misses some important fixes from master.
  
   Initially, I tried to just disable votes for stable branches for the
   job: https://review.openstack.org/#/c/205497/ Due to limitations of
   project-config, we would need to rework the patch though to split the
   job into stable non-voting and liberty+ voting one, and disable the
   votes just for the first one.
  
   My gut feeling is that since the job never actually worked for kilo,
   we should just kill it for all stable branches. It does not provide
   any meaningful actionable feedback anyway.
  
   Thoughts?
 
  +1 to kill it.

 Agreed, lets get rid of it for stable branches.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

[Ryan Moats]

The alternative is to do what has been done with the neutron meeting itself
- have it be held in two alternating time slots.

Ryan

Damon Wang damon.dev...@gmail.com wrote on 07/22/2015 12:08:03 PM:

 From: Damon Wang damon.dev...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Eran Gampel eran.gam...@toganetworks.com, Antoni Segura
 Puimedon t...@midokura.com, Irena Berezovsky ir...@midokura.com
 Date: 07/22/2015 12:08 PM
 Subject: Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers
 networking to Neutron

 I'd like to recommend a tool:
 http://www.timeanddate.com/worldclock/meeting.html

 Since I base in Beijing, so I'd like to recommend UTC 1:00 to UTC 16:00

 Regards,
 Wei Wang

 2015-07-23 0:28 GMT+08:00 Gal Sagie gal.sa...@gmail.com:

 Hello Everyone,

 Project Kuryr is now officially part of Neutron's big tent.
 Kuryr is aimed to be used as a generic docker remote driver that
 connects docker to Neutron API's
 and provide containerised images for the common Neutron plugins.
 We also plan on providing common additional networking services
 API's from other sub projects
 in the Neutron big tent.

 We hope to get everyone on board with this project and leverage this
 joint effort for the many different solutions out there (instead of
 everyone re-inventing the wheel for each different project).

 We want to start doing a weekly IRC meeting to coordinate the
 different requierments and
 tasks, so anyone that is interested to participate please share your
 time preference
 and we will try to find the best time for the majority.

 Remember we have people in Europe, Tokyo and US, so we won't be able
 to find time that fits
 everyone.

 The currently proposed time is  Wedensday at 16:00 UTC

 Please reply with your suggested time/day,
 Hope to see you all, we have an interesting and important project ahead
of us

 Thanks
 Gal.


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] new etherpad for Neutron instrumentation

[Ryan Moats]

All-

After talking with Carl, Matt, and Gal about this subject on the IRC
channel this morning, I've created an etherpad [1] to gauge interest in
creating a blueprint for Neutron instrumentation.

I think this is a place where the project has substantial gaps that could
create barriers to adoption by operators and would like (as we move
forward) to invite operators in to provide their input...

Thanks,
Ryan Moats

[1] https://etherpad.openstack.org/p/neutron-instrumentation__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

[Ryan Moats]

Gabriel Bezerra gabri...@lsd.ufcg.edu.br wrote on 03/10/2015 12:34:30 PM:


 Em 10.03.2015 14:24, Carl Baldwin escreveu:
  Neutron currently does not enforce the uniqueness, or non-overlap, of
  subnet cidrs within the address scope for a single tenant.  For
  example, if a tenant chooses to use 10.0.0.0/24 on more than one
  subnet, he or she is free to do so.  Problems will arise when trying
  to connect a router between these subnets but that is left up to the
  tenant to work out.
 
  In the current IPAM rework, we had decided to allow this overlap in
  the reference implementation for backward compatibility.  However,
  we've hit a snag.  It would be convenient to use the subnet cidr as
  the handle with which to refer to a previously allocated subnet when
  talking to IPAM.  If overlap is allowed, this is not possible and we
  need to come up with another identifier such as Neutron's subnet_id or
  another unique IPAM specific ID.  It could be a burden on an external
  IPAM system -- which does not allow overlap -- to work with a
  completely separate identifier for a subnet.
 
  I do not know of anyone using this capability (or mis-feature) of
  Neutron.  I would hope that tenants are aware of the issues with
  trying to route between subnets with overlapping address spaces and
  would avoid it.  Is this potential overlap something that we should
  really be worried about?  Could we just add the assumption that
  subnets do not overlap within a tenant's scope?
 
  An important thing to note is that this topic is different than
  allowing overlap of cidrs between tenants.  Neutron will continue to
  allow overlap of addresses between tenants and support the isolation
  of these address spaces.  The IPAM rework will support this.
 
  Carl Baldwin


 I'd vote for allowing against such restriction, but throwing an error in
 case of creating a router between the subnets.

 I can imagine a tenant running multiple instances of an application,
 each one with its own network that uses the same address range, to
 minimize configuration differences between them.


While I'd personally like to see this be restricted (Carl's position), I
know
of at least one existence proof where management applications are doing
precisely what Gabriel is suggesting - reusing the same address range to
minimize the configuration differences.

Ryan Moats__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api][neutron] Re: Best API for generating subnets from pool

[Ryan Moats]

Sorry, pulling this from the archives [1] because I seem to have lost the
original in my mailbox...

 1) (this is more for neutron people) Is there a real use case for
 requesting specific gateway IPs and allocation pools when allocating from
a
 pool? If not, maybe we should let the pool set a default gateway IP and
 allocation pools. The user can then update them with another call.
Another
 option would be to provide subnet templates from which a user can
choose.
 For instance one template could have the gateway as first IP, and then a
 single pool for the rest of the CIDR.

The use case that always comes to mind when questions like this are asked
is green-field vs
brown-field - if I am deploying something new, then no, I don't need the
ability to specify gateway IPs.  However, if I am dealing with an existing
deployment migration,
then I will want to be able to represent what is already out there.

 2) Is the action of creating a subnet from a pool better realized as a
 different way of creating a subnet, or should there be some sort of pool
 action? Eg.:

 POST /subnet_pools/my_pool_id/subnet
 {'prefix_len': 24}

 which would return a subnet response like this (note prefix_len might not
 be needed in this case)

 {'id': 'meh',
  'cidr': '192.168.0.0/24',
  'gateway_ip': '192.168.0.1',
  'pool_id': 'my_pool_id'}

 I am generally not a big fan of RESTful actions. But in this case the
 semantics of the API operation are that of a subnet creation from within
a
 pool, so that might be ok.

This would be my preferred approach of the two given.

Ryan Moats

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-March/058538.html__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] looking for status of an old wiki page work item

[Ryan Moats]

Yes, that looks much more detailed, thank you!

Ryan (having finished a minor wiki page edit)

Salvatore Orlando sorla...@nicira.com wrote on 02/05/2015 06:40:44 PM:

 From: Salvatore Orlando sorla...@nicira.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 02/05/2015 06:42 PM
 Subject: Re: [openstack-dev] [neutron] looking for status of an old
 wiki page work item

 I reckon the blueprint [1] supersedes the one in the old wiki page you
found.
 It lies in abandoned status as it did not make the release plan for
 Kilo. I am sure the author and the other contributors working on it
 will resume it for the next release.

 Salvatore

 [1] https://review.openstack.org/#/c/132661/

 On 5 February 2015 at 22:52, Ryan Moats rmo...@us.ibm.com wrote:
 I've run into a set of use cases where it would really be useful to
 be able to restrict which external networks a particular tenant can
 access, along the lines of the wiki page [1] talks about..

 When I checked for neutron blueprints, the only thing I found was
 [2] and that isn't really close.

 So, I'm wondering if there is a blueprint that I missed when I went
 searching or if there are folks that would be interested in seeing
 along the lines of [1] getting implemented...

 Thanks in advance,
 Ryan Moats

 [1] https://wiki.openstack.org/wiki/Neutron/sharing-model-for-
 external-networks
 [2] https://blueprints.launchpad.net/neutron/+spec/external-shared-
 net-ext-for-nuage-plugin



__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] looking for status of an old wiki page work item

[Ryan Moats]

I've run into a set of use cases where it would really be useful to be able
to restrict which external networks a particular tenant can access, along
the lines of the wiki page [1] talks about..

When I checked for neutron blueprints, the only thing I found was [2] and
that isn't really close.

So, I'm wondering if there is a blueprint that I missed when I went
searching or if there are folks that would be interested in seeing along
the lines of [1] getting implemented...

Thanks in advance,
Ryan Moats

[1]
https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks
[2]
https://blueprints.launchpad.net/neutron/+spec/external-shared-net-ext-for-nuage-plugin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

[Ryan Moats]

+1 to that idea...

Jay Pipes jaypi...@gmail.com wrote on 02/02/2015 04:35:36 PM:


 What about having a separate HTTP header that indicates the OpenStack
 Error Code, along with a generated URI for finding more information
 about the error?

 Something like:

 X-OpenStack-Error-Code: 1234
 X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234

 That way is completely backwards compatible (since we wouldn't be
 changing response payloads) and we could handle i18n entirely via the
 HTTP help service running on errors.openstack.org.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

[Ryan Moats]

Sigh... hit send too soon and forgot to sign...

+1 to that idea...

Ryan

Jay Pipes jaypi...@gmail.com wrote on 02/02/2015 04:35:36 PM:


 What about having a separate HTTP header that indicates the OpenStack
 Error Code, along with a generated URI for finding more information
 about the error?

 Something like:

 X-OpenStack-Error-Code: 1234
 X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234

 That way is completely backwards compatible (since we wouldn't be
 changing response payloads) and we could handle i18n entirely via the
 HTTP help service running on errors.openstack.org.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

[Ryan Moats]

I was waiting for this because I think I may have a slightly different (and
outside of the box) view on how to approach a solution to this.

Conceptually (at least in my mind) there isn't a whole lot of difference
between how the example below (i.e. updates from two concurrent threads) is
handled
and how/if neutron wants to support a multi-master database scenario (which
in turn lurks in the background when one starts thinking/talking about
multi-region support).

If neutron wants to eventually support multi-master database scenarios, I
see two ways to go about it:

1) Defer multi-master support to the database itself.
2) Take responsibility for managing the conflict resolution inherent in
multi-master scenarios itself.

The first approach is certainly simpler in the near term, but it has the
down side of restricting the choice of databases to those that have solved
multi-master and further, may lead to code bifurcation based on possibly
different solutions to the conflict resolution scenarios inherent in
multi-master.

The second approach is certainly more complex as neutron assumes more
responsibility for its own actions, but it has the advantage that (if done
right) would be transparent to the underlying databases (with all that
implies)

My reason for asking this question here is that if the community wants to
consider #2, then these problems are the place to start crafting that
solution - if we solve the conflicts inherent with the  two conncurrent
thread scenarios, then I think we will find that we've solved the
multi-master problem essentially for free.

Ryan Moats

Mike Bayer mba...@redhat.com wrote on 11/19/2014 12:05:35 PM:

 From: Mike Bayer mba...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 11/19/2014 12:05 PM
 Subject: Re: [openstack-dev] [Neutron] DB: transaction isolation and
 related questions

 On Nov 18, 2014, at 1:38 PM, Eugene Nikanorov enikano...@mirantis.com
wrote:

 Hi neutron folks,

 There is an ongoing effort to refactor some neutron DB logic to be
 compatible with galera/mysql which doesn't support locking
 (with_lockmode('update')).

 Some code paths that used locking in the past were rewritten to
 retry the operation if they detect that an object was modified
concurrently.
 The problem here is that all DB operations (CRUD) are performed in
 the scope of some transaction that makes complex operations to be
 executed in atomic manner.
 For mysql the default transaction isolation level is 'REPEATABLE
 READ' which means that once the code issue a query within a
 transaction, this query will return the same result while in this
 transaction (e.g. the snapshot is taken by the DB during the first
 query and then reused for the same query).
 In other words, the retry logic like the following will not work:

 def allocate_obj():
 with session.begin(subtrans=True):
  for i in xrange(n_retries):
   obj = session.query(Model).filter_by(filters)
   count = session.query(Model).filter_by(id=obj.id
 ).update({'allocated': True})
   if count:
return obj

 since usually methods like allocate_obj() is called from within
 another transaction, we can't simply put transaction under 'for'
 loop to fix the issue.

 has this been confirmed?  the point of systems like repeatable read
 is not just that you read the “old” data, it’s also to ensure that
 updates to that data either proceed or fail explicitly; locking is
 also used to prevent concurrent access that can’t be reconciled.  A
 lower isolation removes these advantages.

 I ran a simple test in two MySQL sessions as follows:

 session 1:

 mysql create table some_table(data integer) engine=innodb;
 Query OK, 0 rows affected (0.01 sec)

 mysql insert into some_table(data) values (1);
 Query OK, 1 row affected (0.00 sec)

 mysql begin;
 Query OK, 0 rows affected (0.00 sec)

 mysql select data from some_table;
 +--+
 | data |
 +--+
 |1 |
 +--+
 1 row in set (0.00 sec)

 session 2:

 mysql begin;
 Query OK, 0 rows affected (0.00 sec)

 mysql update some_table set data=2 where data=1;
 Query OK, 1 row affected (0.00 sec)
 Rows matched: 1  Changed: 1  Warnings: 0

 then back in session 1, I ran:

 mysql update some_table set data=3 where data=1;

 this query blocked;  that’s because session 2 has placed a write
 lock on the table.  this is the effect of repeatable read isolation.

 while it blocked, I went to session 2 and committed the in-progress
 transaction:

 mysql commit;
 Query OK, 0 rows affected (0.00 sec)

 then session 1 unblocked, and it reported, correctly, that zero rows
 were affected:

 Query OK, 0 rows affected (7.29 sec)
 Rows matched: 0  Changed: 0  Warnings: 0

 the update had not taken place, as was stated by “rows matched:

 mysql select * from some_table;
 +--+
 | data |
 +--+
 |1 |
 +--+
 1 row in set (0.00 sec)

 the code in question would do a retry

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

[Ryan Moats]

Ian Wells ijw.ubu...@cack.org.uk wrote on 11/19/2014 02:33:40 PM:

[snip]

 When you have a plugin that's decided to be synchronous, then there
 are cases where the DB lock is held for a technically indefinite
 period of time.  This is basically broken.

A big +1 to this statement

Ryan Moats___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

[Ryan Moats]

 Mike Bayer mba...@redhat.com wrote on 11/19/2014 02:10:18 PM:

  From: Mike Bayer mba...@redhat.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Date: 11/19/2014 02:11 PM
  Subject: Re: [openstack-dev] [Neutron] DB: transaction isolation and
  related questions
 
  On Nov 19, 2014, at 1:49 PM, Ryan Moats rmo...@us.ibm.com wrote:
 
  I was waiting for this because I think I may have a slightly
  different (and outside of the box) view on how to approach a solution
to this.
 
  Conceptually (at least in my mind) there isn't a whole lot of
  difference between how the example below (i.e. updates from two
  concurrent threads) is handled
  and how/if neutron wants to support a multi-master database scenario
  (which in turn lurks in the background when one starts thinking/
  talking about multi-region support).
 
  If neutron wants to eventually support multi-master database
  scenarios, I see two ways to go about it:
 
  1) Defer multi-master support to the database itself.
  2) Take responsibility for managing the conflict resolution inherent
  in multi-master scenarios itself.
 
  The first approach is certainly simpler in the near term, but it has
  the down side of restricting the choice of databases to those that
  have solved multi-master and further, may lead to code bifurcation
  based on possibly different solutions to the conflict resolution
  scenarios inherent in multi-master.
  The second approach is certainly more complex as neutron assumes
  more responsibility for its own actions, but it has the advantage
  that (if done right) would be transparent to the underlying
  databases (with all that implies)

 multi-master is a very advanced use case so I don’t see why it would
 be unreasonable to require a multi-master vendor database.
 Reinventing a complex system like that in the application layer is
 an unnecessary reinvention.

 As far as working across different conflict resolution scenarios,
 while there may be differences across backends, these differences
 will be much less significant compared to the differences against
 non-clustered backends in which we are inventing our own multi-
 master solution.   I doubt a home rolled solution would insulate us
 at all from “code bifurcation” as this is already a fact of life in
 targeting different backends even without any implication of
 clustering.   Even with simple things like transaction isolation, we
 see that different databases have different behavior, and if you
 look at the logic in oslo.db inside of https://github.com/openstack/
 oslo.db/blob/master/oslo/db/sqlalchemy/exc_filters.py you can see an
 example of just how complex it is to just do the most rudimental
 task of organizing exceptions into errors that mean the same thing.

I didn't say it was unreasonable, I only point out that there is an
alternative for consideration.

BTW, I view your examples from oslo as helping make my argument for
me (and I don't think that was your intent :) )

  My reason for asking this question here is that if the community
  wants to consider #2, then these problems are the place to start
  crafting that solution - if we solve the conflicts inherent with the
  two conncurrent thread scenarios, then I think we will find that
  we've solved the multi-master problem essentially for free”.

 Maybe I’m missing something, if we learn how to write out a row such
 that a concurrent transaction against the same row doesn’t throw us
 off, where is the part where that data is replicated to databases
 running concurrently on other IP numbers in a way that is atomic
 come out of that effort “for free” ?   A home-rolled “multi master”
 scenario would have to start with a system that has multiple
 create_engine() calls, since we need to communicate directly to
 multiple database servers. From there it gets really crazy.  Where’sall
that ?

Boiled down, what you are talking about here w.r.t. concurrent
transactions is really conflict resolution, which is the hardest
part of implementing multi-master (as a side note, using locking in
this case is the equivalent of option #1).

All I wished to point out is that there are other ways to solve the
conflict resolution that could then be leveraged into a multi-master
scenario.

As for the parts that I glossed over, once conflict resolution is
separated out, replication turns into a much simpler problem with
well understood patterns and so I view that part as coming
for free.

Ryan___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Ryan Moats]

+1

Sumit Naiksatam sumitnaiksa...@gmail.com wrote on 08/08/2014 02:44:55 PM:

 From: Sumit Naiksatam sumitnaiksa...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 08/08/2014 02:45 PM
 Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy -
Renaming

 Thanks Jay for your constructive feedback on this. I personally think
 that 'policy-target' is a good option. I am not sure what the rest of
 the team thinks, perhaps they can chime in.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Ryan Moats]

Edgar-

I can't speak for anyone else, but in my mind at least (and having been
involved in the work that led up to 3198),
the members of the groups being discussed here are not PEPs.   As 3198
states, being a PEP implies running COPS
and I don't see that as necessary for membership in GBP groups.

Ryan Moats

Edgar Magana edgar.mag...@workday.com wrote on 08/07/2014 04:02:43 PM:

 From: Edgar Magana edgar.mag...@workday.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 08/07/2014 04:03 PM
 Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy -
Renaming

 I am sorry that I could not attend the GBP meeting.
 Is there any reason why the IEFT standard is not considered?
 http://tools.ietf.org/html/rfc3198

 I would like to understand the argument why we are creating new
 names instead of using the standard ones.

 Edgar

 From: Ronak Shah ronak.malav.s...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)

 openstack-dev@lists.openstack.org
 Date: Thursday, August 7, 2014 at 1:17 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

 Hi,
 Following a very interesting and vocal thread on GBP for last couple
 of days and the GBP meeting today, GBP sub-team proposes following
 name changes to the resource.


 policy-point for endpoint
 policy-group for endpointgroup (epg)

 Please reply if you feel that it is not ok with reason and suggestion.

 I hope that it wont be another 150 messages thread :)

 Ronak___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Ryan Moats]

Edgar Magana edgar.mag...@workday.com wrote on 08/07/2014 04:37:39 PM:

 From: Edgar Magana edgar.mag...@workday.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 08/07/2014 04:40 PM
 Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy -
Renaming

 Ryan,

 COPS implies a common protocol to communicate with PEPs, which
 implies the same communication mechanism basically.
 So, you are implying that “endpoints” in GBP will use “different”
 protocol to communicate with “decisions” entities?

Nope, I'm saying that the members of groups are not *required* to do
enforcement.
They *could* (based on the implementation), but calling them PEPs means
they would *have* to.

Ryan___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Ryan Moats]

Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:

[snip]

 AFAICT, there is nothing that can be done with the GBP API that cannot
 be done with the low-level regular Neutron API.

I'll take you up on that, Jay :)

How exactly do I specify behavior between two collections of ports residing
in the same IP subnet (an example of this is a bump-in-the-wire network
appliance).

I've looked around regular Neutron and all I've come up with so far is:
(1) use security groups on the ports
(2) set allow_overlapping_ips to true, set up two networks with
identical CIDR block subnets and disjoint allocation pools and put a
vRouter between them.

Now #1 only works for basic allow/deny access and adds the complexity of
needing to specify per-IP address security rules, which means you need the
ports to have IP addresses already and then manually add them into the
security groups, which doesn't seem particularly very orchestration
friendly.

Now #2 handles both allow/deny access as well as provides a potential
attachment point for other behaviors, *but* you have to know to set up the
disjoint allocation pools, and your depending on your drivers to handle the
case of a router that isn't really a router (i.e. it's got two interfaces
in the same subnet, possibly with the same address (unless you thought of
that when you set things up)).

You can say that both of these are *possible*, but they both look more
complex to me than just having two groups of ports and specifying a policy
between them.

Ryan Moats___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Ryan Moats]

Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 02:12:05 PM:

 From: Aaron Rosen aaronoro...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 08/06/2014 02:12 PM
 Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
 and the way forward

 Hi Ryan,

 On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote:
 Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM:

 [snip]


  AFAICT, there is nothing that can be done with the GBP API that cannot
  be done with the low-level regular Neutron API.

 I'll take you up on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-
 wire network appliance).

 Would you mind explaining what behavior you want between the two
 collection of ports?

That's the point - I want a framework that will work regardless of the
specifics of the behavior later on.

 I've looked around regular Neutron and all I've come up with so far is:
 (1) use security groups on the ports
 (2) set allow_overlapping_ips to true, set up two networks with
 identical CIDR block subnets and disjoint allocation pools and put a
 vRouter between them.

 Now #1 only works for basic allow/deny access and adds the
 complexity of needing to specify per-IP address security rules,
 which means you need the ports to have IP addresses already and then
 manually add them into the security groups, which doesn't seem
 particularly very orchestration friendly.

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 neutron security-group-create group1
 neutron security-group-create group2

 # allow members of group1 to ssh into group2 (but not the other way
around):
 neutron security-group-rule-create --direction ingress --port-range-
 min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2

 # allow members of group2 to be able to access TCP 80 from members
 of group1 (but not the other way around):
 neutron security-group-rule-create --direction ingress --port-range-
 min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1

 # Now when you create ports just place these in the desired security
 groups and neutron will automatically handle this orchestration for
 you (and you don't have to deal with ip_addresses and updates).

 neutron port-create --security-groups group1 network1
 neutron port-create --security-groups group2 network1

While those rule instances aren't particularly interesting, I concede that
security groups can handle allow/deny. However, allow/deny is the least
interesting part of the problem :)

 Now #2 handles both allow/deny access as well as provides a
 potential attachment point for other behaviors, *but* you have to
 know to set up the disjoint allocation pools, and your depending on
 your drivers to handle the case of a router that isn't really a
 router (i.e. it's got two interfaces in the same subnet, possibly
 with the same address (unless you thought of that when you set things
up)).

 Are you talking about the firewall as a service stuff here?

No, I'm being more general than any of the curret *aaS items, I'm thinking
of the general service insertion case.

 You can say that both of these are *possible*, but they both look
 more complex to me than just having two groups of ports and
 specifying a policy between them.

 Would you mind proposing how this is done in the Group policy api?
 From what I can tell in the new proposed api you'd need to map both
 of these groups to different endpoints i.e networks.

Note: I'm not going to use the pure group policy API as I have been a fan
of the
2-group approach from day 1, I'm going to use the commands as stated in the
patch set, and I'm going to assume (dangerous I know) that I can specify
endpoint-group on port create

neutron grouppolicy-endpoint-group-create group1
neutron grouppolicy-endpoint-group-create group2
neutron port-create --endpoint-group group1 network1
neutron port-create --endpoint-group group2 network1
neutron grouppolicy-policy-action-create action
neutron grouppolicy-policy-classifier-create classifier
neutron grouppolicy-policy-rule-create --action action --classifier
classifer rule
neutron policy-apply rule group1 group2

One major difference between GP and current neutron (other than security
groups) is in your last statement about tying things to networks.  Like
security groups, groups in GP can have ports that span networks.  Unlike
security groups, GP allows more rich policy than just allow.

That of course begs the question of extending security groups (think this
blueprint https://review.openstack.org/#/c/93112/ ) but that approach may
have its own issues.

Ryan



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

[Ryan Moats]

[snipping to save BW]

Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 03:26:24 PM:

 Note: I'm not going to use the pure group policy API as I have been
 a fan of the
 2-group approach from day 1, I'm going to use the commands as stated
 in the patch set, and I'm going to assume (dangerous I know) that I
 can specify endpoint-group on port create

 neutron grouppolicy-endpoint-group-create group1
 neutron grouppolicy-endpoint-group-create group2

 neutron port-create --endpoint-group group1 network1
 neutron port-create --endpoint-group group2 network1

 Sorry, I don't follow what this port-create command does? Here ---
 https://docs.google.com/presentation/d/

1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
  --- shows that endpoint-groups map to networks so i'm confused why
 network1 is coming into play here?

Let's be careful that we aren't mixing concepts. First, this is where I
said I'm going to assume I can do this above comes in and so the network
applies to the port-create, not to the group.

Second, the mapping you site is optional and a subtle point is that while
a group maps to a multiplicity of subnets, those subnets can themselves be
in different networks, so a group does not automatically equate to a
network.

 neutron grouppolicy-policy-action-create action
 neutron grouppolicy-policy-classifier-create classifier
 neutron grouppolicy-policy-rule-create --action action --classifier
 classifer rule
 neutron policy-apply rule group1 group2

 Mind mapping this to my example so we can see how to achieve the
 same thing in group policy (with protocols and all)?  Looks like you
 would also need to specify (--provided-contracts, --consumed-
 contracts) when you create the endpoint-groups. Also, I don't see a
 cli command policy-apply so i'm not sure really what that does.

This is where I invoke my I'm a fan of the 2-group approach statement
above.
This is my proposed shorthand for the following three commands:

neutron grouppolicy-contract-create --poilcy-rule rule contract
neutron grouppolicy-endpoint-group-update --provides-contract contract
group2
neutron grouppolicy-endpoint-group-update --consumes-contract contract
group1

see:
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041467.html

 One major difference between GP and current neutron (other than
 security groups) is in your last statement about tying things to
 networks.  Like security groups, groups in GP can have ports that
 span networks.

 So are you saying that group policy doesn't allow us to do different
 enforcement points on the same network as we do today?

That was not my intent.  I was only trying to point out that these groups
(like security groups) are not scoped by networks.

  Unlike security groups, GP allows more rich policy than just allow.

 Right - I can see that GP does provide an allow/deny construct,
 though as you pointed out we can extend the current security group
 concept in neutron to provide allow/deny semantics to achieve the
 same thing no?

My only comments is that GP has been in the pipeline longer that the BP I
cite below...

 That of course begs the question of extending security groups (think
 this blueprint https://review.openstack.org/#/c/93112/ ) but that
 approach may have its own issues.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy

[Ryan Moats]

Yes

Henry Fourie louis.fou...@huawei.com wrote on 07/31/2014 12:32:23 PM:

 From: Henry Fourie louis.fou...@huawei.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Cc: Subrahmanyam Ongole song...@oneconvergence.com
 Date: 07/31/2014 12:33 PM
 Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group
 gap in group policy

 Ryan,
So this is intended to associate a contract with a source EPG and
 a destination EPG – right?
 -  Louis
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] A request for sub-projects to post meeting summary emails to the ML

[Ryan Moats]

I had occasion to walk through all of the archives of the openstack-dev
mailing list and it dawned on me that neutron sub-projects aren't as
regular in posting summary messages of IRC meetings to the ML as they could
be.

I'd like to suggest that going forward, sub-projects post a summary email
of an IRC meeting to the ML with a note of anything that was agreed in the
meeting and include a link to the meeting minutes and transcript.

Thanks,
Ryan Moats (regXboi)___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy

[Ryan Moats]

As promised in Monday's Neutron IRC minutes [1], this mail is a trip down
memory lane looking at the history of the
Neutron GP project..  The original GP google doc [2] included specifying
policy via both a produce/consume 1-group
approach and as a link between two groups.  There was an email thread [3]
that discussed the relationship between
these models early on, but that discussion petered out and during a later
IRC meeting [4] the concept of contracts
were added, but without changing the basic use case requirements from the
original document.  A followup meeting [5]
began the discussion of how to express the original model from the contract
data model but that discussion doesn't
appear to have been completed either.  The PoC in Atlanta raised a set of
issues [6],[7] around the complexity of the
resulting PoC code.

The good news is that having looked through the proposed GP code commits
(links to which can be found at [8) I
believe that folks that want to be able to specify policies via the 2-group
approach (and yes, I'm one of them) can have
that without changing the model encoded in those commits. Rather, it can be
done via the WiP CLI code commit by
providing a profiled API - this is a technique used by the IETF, CCITT,
etc. to allow a rich API to be consumed in
common ways.  In this case, what I'm envisioning is something like

neutron policy-apply [policy rule] [src group] [destination group]

in this case, the CLI would perform the contract creation for the policy
rule, and assigning the proper produce/consume
edits to the specified source and destination groups.  Note:  this is in
addition to the CLI providing direct access to the
underlying data model.  I believe that this is the simplest way to bridge
the gap and provide support to folks who want
to specify policy as something between two groups.

Ryan Moats (regXboi)

References:
[1]
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt
[2]
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#
[3]
http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html
[4]
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html
[5]
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html
[6] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html
[7]
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html
[8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Trying to make sense of allow_overlapping_ips in neutron

[Ryan Moats]

Apologies if this is posted to the wrong place, but after talking with Kyle
Mestery (mest...@cisco.com), he suggested that I bring my question here...

I'm trying to make sense of the allow_overlapping_ips configuration
parameter in neutron.

When this entry is true, then a tenant can have subnets with overlapping
IPs in different networks (i.e. the scope of the subnet validation search
is the other subnets associated with the network) which makes sense.

But, when this entry is false, then the validation search appears to cover
all subnets across all tenants.  I'm trying to understand the logic of
this, because I would have expected that in this case, the search scope
would be all subnets across a single tenant.

As it is now, it looks like if an install has this configuration parameter
set to false, then there is no way for that install to reuse the net 10
address space.

Can somebody lend me a hand and either (a) tell me I'm reading the code
wrong or (b) explain why that choice was made?

Thanks in advance,
Ryan Moats
rmo...@us.ibm.com___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev