1. z.archive.ovsdb-dev@lists.opendaylight.org
  2. Messages
   Date   
Re: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Natarajan_Dhiraviam@...
 

Sam, Flavio

 

            Thanks for the inputs.

This allinone setup creates bridge, network & tenants.

 

We tried setting ODL_BOOT_WAIT to 300 and in one of two attempts br-int, OF port connection was all fine.

 

We are trying to get this set-up consistent…

 

We wait for below logs, before issuing a ovs-vsctl set-manager. Hope these are the ones to look for before doing a set-manager ?

Starting point is this

| INFO  | Event Dispatcher | FeaturesServiceImpl              | 20 - org.apache.karaf.features.core - 3.0.3 | Installing feature odl-ovsdb-openstack 1.2.0-SNAPSHOT

OVSDB socket is active

| INFO  | entLoopGroup-7-1 | LoggingHandler                   | 106 - io.netty.common - 4.0.26.Final | [id: 0xc3b7928a,      /0:0:0:0:0:0:0:0:6640] ACTIVE

OF socket is ready for listening

INFO  | Thread-59        | TcpHandler                       | 256 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.6.0.SNAPSHOT | Switch listener started and ready to accept incoming tcp/tls connections on port: 6653

 

Start to OF socket ready is typically a little over 3 mins in our OS-ODL setup (4GB RAM each in control/compute node) .

Regards

Natarajan

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Thursday, July 09, 2015 10:33 PM
To: Sabapathy, Ravi
Cc: Dhiraviam, Natarajan; ffernand@...; Anumala, Mohnish; ovsdb-dev@...; neutron-dev@...; Venkataraghavan, C
Subject: Re: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Natarajan,

what all does the allinone setup do besides stack and start odl? Meaning does it try to create any bridges or networks?

could you modify the allinone to add a 60s or 90s sleep in between when the ovsdb node manager is set and when odl starts? Or switch from all in one to external? I think what is happening is that odl is starting but it takes a while to get to a resting state. netvirt is the last service to run since it depends on neutron, openflowplugin and the southbound. Those can take a long time to start and then when netvirt finally starts it can take another 30s or so to start. So during that time if the stack is trying to connect to odl there can be issues.

Thanks, Sam

----- Original Message -----
> From: "Ravi Sabapathy"
> To: "Natarajan Dhiraviam" , ffernand@..., shague@..., "Mohnish Anumala"
> , ovsdb-dev@...,
> neutron-dev@...
> Cc: "C Venkataraghavan"
> Sent: Thursday, July 9, 2015 12:23:43 PM
> Subject: RE: Openstack-ODL integration issues in stable/kilo + Lithium
> 0.3.0
>
> ++Venkat
>
> From: Dhiraviam, Natarajan
> Sent: Thursday, July 09, 2015 11:56 AM
> To: Flavio Fernandes (ffernand@...); Sam
> Hague; Anumala, Mohnish; ovsdb-dev@...;
> neutron-dev@...
> Cc: Sabapathy, Ravi
> Subject: Openstack-ODL integration issues in stable/kilo + Lithium
> 0.3.0
>
> Hi Flavio, Sam & All,
>
>
> We were testing latest neutron/lithium odl / stable kilo devstack
> combo in all-in-one mode few days back, using modified Flavio's
> vagrant setup
> (http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html)
> we faced below issues(?).
>
>
>
> 1. on stacking - unstacking - stacking (with manager set appropriately),
> br-int is *NOT* getting created consistently
>
> 2. Even times when br-int was successfully created, OpenFlow connection
> to controller from ovswitch on control node is not setup consistently.
>
> Anybody else faced similar issues ?
>
>
>
> We created br-int / OF connection to ODL on port 6653 manually in above
> cases and could see that the default pipelines flows are getting
> programmed both on the control & compute node, however vxlan tunnel
> weren't getting created and we programmed it manually in the ovs.
> However ping from Tenant1-VM1 on control node to Tenant1-VM2 of
> compute node fails. Compute node has received the broadcast ARP
> request and sends it out to the Tenant1-VM2 as well. However the
> tenant is not responding back to the ARP request. Unfortunately we
> aren't able to dump / analyze packets on the Tenant1-VM2...
>
>
>
> Tenant / VM definitions are WRT below diagram.
>
> [cid:image001.jpg@...]
>
>
> Regards
> Natarajan & Ravi
>
>

Re: Base Feature List of ODL Lithium

Badrinath_Viswanatha@...
 

Sam,

    Thanks for the quick response and clarification.

Will test and confirm this, as I was seeing some inconsistent behavior, trying to use the helium feature install set in Lithium.

 

Thanks

Badri

 

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Thursday, July 09, 2015 8:25 PM
To: Viswanatha, Badrinath
Cc: ovsdb-dev@...; Venkataraghavan, C; Sabapathy, Ravi
Subject: Re: [ovsdb-dev] Base Feature List of ODL Lithium

Badri,

all that is needed for OepnStack and ODL integration is the odl-ovsdb-openstack feature.

If the list from Helium here is why they are no longer needed:

odl-base-all odl-aaa-authn odl-restconf: there was a bug with authn and restconf where they had to be installed in a certain order.

odl-nsf-all odl-adsal-northbound: needed for the odl-ovsdb-northbound

odl-mdsal-apidocs odl-dlux-core: only if you wanted dlux. This is not needed for openstack integration, it was just something to use if you wanted to use dlux to view the topology

odl-ovsdb-northbound: this is deprecated for Li. It can still be used, but you would also need to load the odl-ovsdb-plugin and not load odl-ovsdb-openstack. In this case you would not have openstack integration, you would see ovsdb events, but nothing from the neutron or openstack integration.

Thanks, Sam

----- Original Message -----
> From: "Badrinath Viswanatha"
> To: ovsdb-dev@...
> Cc: "C Venkataraghavan" , "Ravi Sabapathy"
>
> Sent: Thursday, July 9, 2015 10:26:41 AM
> Subject: [ovsdb-dev] Base Feature List of ODL Lithium
>
>
>
> Hi,
>
> For the Helium-OVSDB integration, there is a list of features to be
> enabled in opendaylight given as
>
>
>
>
> opendaylight-user@root> feature:install odl-base-all odl-aaa-authn
> odl-restconf odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs \
>
> odl-ovsdb-openstack odl-ovsdb-northbound odl-dlux-core
>
>
>
>
> in
>
> (
> https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight#Configur
> ing_Open_vSwitch_to_be_managed_by_OpenDaylight
> ).
>
>
>
>
>
> Can someone share with us, a corresponding feature list, that has been
> tested with OVSDB in lithium.
>
>
>
>
>
>
>
> Thanks
>
> Badri
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> ovsdb-dev mailing list
> ovsdb-dev@...
> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>

Re: FW: Reg: wiki (openstack and Opendaylight integration)

Thomas Bachman
 

Adding groupbasedpolicy-dev, which also implements a provider for neutron northbound. It seems like we should try to identify all the projects the implement a provider and have them all contribute to the wiki page, providing sections for how to run/use each provider?

cheers,

-Thomas


On Thu, Jul 9, 2015 at 7:39 PM, Tai, Hideyuki <hideyuki.tai@...> wrote:

Fowarding to this mail to the ovsdb-dev ML.

 

I think that page should list all ways to integrate with OpenStack.

 

From: vtn-dev-bounces@... [mailto:vtn-dev-bounces@...] On Behalf Of Venkatrangan G - ERS, HCL Tech
Sent: Wednesday, July 08, 2015 12:15
To: ovsdb-dev@....
Cc: vtn-dev@...
Subject: [vtn-dev] Reg: wiki (openstack and Opendaylight integration)

 

Hi ovsdb devs,

 

   I contribute to the VTN Project. VTN also supports integration with openstack. We would like to add the details to the page : https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight

  Kindly let us know if we can add VTN details also to the page.

 

 

Regards,

Venkat G

 



::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------


_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
FW: Reg: wiki (openstack and Opendaylight integration)

Tai, Hideyuki <hideyuki.tai@...>
 

Fowarding to this mail to the ovsdb-dev ML.

 

I think that page should list all ways to integrate with OpenStack.

 

From: vtn-dev-bounces@... [mailto:vtn-dev-bounces@...] On Behalf Of Venkatrangan G - ERS, HCL Tech
Sent: Wednesday, July 08, 2015 12:15
To: ovsdb-dev@....
Cc: vtn-dev@...
Subject: [vtn-dev] Reg: wiki (openstack and Opendaylight integration)

 

Hi ovsdb devs,

 

   I contribute to the VTN Project. VTN also supports integration with openstack. We would like to add the details to the page : https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight

  Kindly let us know if we can add VTN details also to the page.

 

 

Regards,

Venkat G

 



::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------
Re: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Flavio Fernandes <ffernand@...>
 


On Jul 9, 2015, at 1:03 PM, Sam Hague <shague@...> wrote:

Natarajan,

what all does the allinone setup do besides stack and start odl? Meaning does it try to create any bridges or networks?

could you modify the allinone to add a 60s or 90s sleep in between when the ovsdb node manager is set and when odl starts? Or switch from all in one to external? I think what is happening is that odl is starting but it takes a while to get to a resting state. netvirt is the last service to run since it depends on neutron, openflowplugin and the southbound. Those can take a long time to start and then when netvirt finally starts it can take another 30s or so to start. So during that time if the stack is trying to connect to odl there can be issues.


Good point, Sam. 

To do that, use something like “ODL_BOOT_WAIT=123” in local.conf


— flavio


Thanks, Sam

----- Original Message -----
From: "Ravi Sabapathy" <Ravi_Sabapathy@...>
To: "Natarajan Dhiraviam" <Natarajan_Dhiraviam@...>, ffernand@..., shague@..., "Mohnish Anumala"
<Mohnish_Anumala@...>, ovsdb-dev@..., neutron-dev@...
Cc: "C Venkataraghavan" <C_Venkataraghavan@...>
Sent: Thursday, July 9, 2015 12:23:43 PM
Subject: RE: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

++Venkat

From: Dhiraviam, Natarajan
Sent: Thursday, July 09, 2015 11:56 AM
To: Flavio Fernandes <ffernand@...> (ffernand@...); Sam Hague;
Anumala, Mohnish; ovsdb-dev@...;
neutron-dev@...
Cc: Sabapathy, Ravi
Subject: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Hi Flavio, Sam & All,


           We were testing latest neutron/lithium odl / stable kilo devstack
           combo in all-in-one mode few days back, using modified Flavio's
           vagrant setup
           (http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html)
           we faced below issues(?).



1.      on stacking - unstacking - stacking (with manager set appropriately),
br-int is *NOT* getting created consistently

2.      Even times when br-int was successfully created, OpenFlow connection
to controller from ovswitch on control node is not setup consistently.

Anybody else faced similar issues ?



     We created br-int / OF connection to ODL on port 6653 manually in above
     cases and could see that the default pipelines flows are getting
     programmed both on the control & compute node, however vxlan tunnel
     weren't getting created and we programmed it manually in the ovs.
     However ping from Tenant1-VM1 on control node to Tenant1-VM2 of
     compute node fails. Compute node has received the broadcast ARP
     request and sends it out to the Tenant1-VM2 as well. However the
     tenant is not responding back to the ARP request. Unfortunately we
     aren't able to dump / analyze  packets on the Tenant1-VM2...



Tenant / VM definitions are WRT below diagram.

[


Regards
Natarajan & Ravi
Re: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Sam Hague
 

Natarajan,

what all does the allinone setup do besides stack and start odl? Meaning does it try to create any bridges or networks?

could you modify the allinone to add a 60s or 90s sleep in between when the ovsdb node manager is set and when odl starts? Or switch from all in one to external? I think what is happening is that odl is starting but it takes a while to get to a resting state. netvirt is the last service to run since it depends on neutron, openflowplugin and the southbound. Those can take a long time to start and then when netvirt finally starts it can take another 30s or so to start. So during that time if the stack is trying to connect to odl there can be issues.

Thanks, Sam

----- Original Message -----
From: "Ravi Sabapathy" <Ravi_Sabapathy@...>
To: "Natarajan Dhiraviam" <Natarajan_Dhiraviam@...>, ffernand@..., shague@..., "Mohnish Anumala"
<Mohnish_Anumala@...>, ovsdb-dev@..., neutron-dev@...
Cc: "C Venkataraghavan" <C_Venkataraghavan@...>
Sent: Thursday, July 9, 2015 12:23:43 PM
Subject: RE: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

++Venkat

From: Dhiraviam, Natarajan
Sent: Thursday, July 09, 2015 11:56 AM
To: Flavio Fernandes <ffernand@...> (ffernand@...); Sam Hague;
Anumala, Mohnish; ovsdb-dev@...;
neutron-dev@...
Cc: Sabapathy, Ravi
Subject: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Hi Flavio, Sam & All,


We were testing latest neutron/lithium odl / stable kilo devstack
combo in all-in-one mode few days back, using modified Flavio's
vagrant setup
(http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html)
we faced below issues(?).



1. on stacking - unstacking - stacking (with manager set appropriately),
br-int is *NOT* getting created consistently

2. Even times when br-int was successfully created, OpenFlow connection
to controller from ovswitch on control node is not setup consistently.

Anybody else faced similar issues ?



We created br-int / OF connection to ODL on port 6653 manually in above
cases and could see that the default pipelines flows are getting
programmed both on the control & compute node, however vxlan tunnel
weren't getting created and we programmed it manually in the ovs.
However ping from Tenant1-VM1 on control node to Tenant1-VM2 of
compute node fails. Compute node has received the broadcast ARP
request and sends it out to the Tenant1-VM2 as well. However the
tenant is not responding back to the ARP request. Unfortunately we
aren't able to dump / analyze packets on the Tenant1-VM2...



Tenant / VM definitions are WRT below diagram.

[cid:image001.jpg@...]


Regards
Natarajan & Ravi
Re: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Ravi Shankar S
 

++Venkat

 

From: Dhiraviam, Natarajan
Sent: Thursday, July 09, 2015 11:56 AM
To: Flavio Fernandes <ffernand@...> (ffernand@...); Sam Hague; Anumala, Mohnish; ovsdb-dev@...; neutron-dev@...
Cc: Sabapathy, Ravi
Subject: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

 

Hi Flavio, Sam & All,

 

            We were testing latest neutron/lithium odl / stable kilo devstack combo in all-in-one mode few days back, using modified Flavio’s vagrant setup (http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html) we faced below issues(?).

 

 

1.      on stacking - unstacking - stacking (with manager set appropriately), br-int is *NOT* getting created consistently

2.      Even times when br-int was successfully created, OpenFlow connection to controller from ovswitch on control node is not setup consistently.

 

Anybody else faced similar issues ?

 

      We created br-int / OF connection to ODL on port 6653 manually in above cases and could see that the default pipelines flows are getting programmed both on the control & compute node, however vxlan tunnel weren’t getting created and we programmed it manually in the ovs. However ping from Tenant1-VM1 on control node to Tenant1-VM2 of compute node fails. Compute node has received the broadcast ARP request and sends it out to the Tenant1-VM2 as well. However the tenant is not responding back to the ARP request. Unfortunately we aren’t able to dump / analyze  packets on the Tenant1-VM2...

 

Tenant / VM definitions are WRT below diagram.

topology

 

Regards

Natarajan & Ravi

 
Re: Base Feature List of ODL Lithium

Sam Hague
 

Badri,

all that is needed for OepnStack and ODL integration is the odl-ovsdb-openstack feature.

If the list from Helium here is why they are no longer needed:

odl-base-all odl-aaa-authn odl-restconf: there was a bug with authn and restconf where they had to be installed in a certain order.

odl-nsf-all odl-adsal-northbound: needed for the odl-ovsdb-northbound

odl-mdsal-apidocs odl-dlux-core: only if you wanted dlux. This is not needed for openstack integration, it was just something to use if you wanted to use dlux to view the topology

odl-ovsdb-northbound: this is deprecated for Li. It can still be used, but you would also need to load the odl-ovsdb-plugin and not load odl-ovsdb-openstack. In this case you would not have openstack integration, you would see ovsdb events, but nothing from the neutron or openstack integration.

Thanks, Sam

----- Original Message -----
From: "Badrinath Viswanatha" <Badrinath_Viswanatha@...>
To: ovsdb-dev@...
Cc: "C Venkataraghavan" <C_Venkataraghavan@...>, "Ravi Sabapathy" <Ravi_Sabapathy@...>
Sent: Thursday, July 9, 2015 10:26:41 AM
Subject: [ovsdb-dev] Base Feature List of ODL Lithium



Hi,

For the Helium-OVSDB integration, there is a list of features to be enabled
in opendaylight given as




opendaylight-user@root> feature:install odl-base-all odl-aaa-authn
odl-restconf odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs \

odl-ovsdb-openstack odl-ovsdb-northbound odl-dlux-core




in

(
https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight#Configuring_Open_vSwitch_to_be_managed_by_OpenDaylight
).





Can someone share with us, a corresponding feature list, that has been tested
with OVSDB in lithium.







Thanks

Badri













_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Base Feature List of ODL Lithium

Badrinath_Viswanatha@...
 

Hi,

   For the Helium-OVSDB integration, there is a list of features to be enabled in opendaylight given as

 

   opendaylight-user@root> feature:install odl-base-all odl-aaa-authn odl-restconf odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs \

   odl-ovsdb-openstack odl-ovsdb-northbound odl-dlux-core

 

in

(https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight#Configuring_Open_vSwitch_to_be_managed_by_OpenDaylight).

 

 

Can someone share with us, a corresponding feature list, that has been tested with OVSDB in lithium.

 

 

 

Thanks

Badri

 

 

 

 

 
Re: Security Groups implementation

Suryanarayanan, Aswin <aswin.suryanarayanan@...>
 

Hi Vishal,

As per my understanding in SG we have to support both stateful and stateless use cases both Ingress and Egress. We can claim Openstack parity only when both are done.
Currently we are working on the stateless use cases, for which we are not using Learn actions, which includes the stateless part of the default SG . In future once OVS supports conntrack we will have to add stateful use cases as well.

Thanks and Regards
Aswin

-----Original Message-----
From: Vishal Thapar [mailto:vishal.thapar@...]
Sent: Thursday, July 09, 2015 1:46 PM
To: Suryanarayanan, Aswin; ovsdb-dev@...
Subject: RE: [ovsdb-dev] Security Groups implementation

Hi Aswin,

Just to be clear, by stateless use cases do you mean you're using neither TCP Flags nor Learn action and require user to explicitly configure Ingress SG Rules to allow traffic?

Default SG behaviour is to allow all-egress and block all ingress traffic, ingress here refers to connections originating outside. A truly stateless won't be able to support this and require explicit ingress SG Rules to allow ingress traffic for connections originating from the VM/port.

Is my assumption correct?

Regards,
Vishal.

P.S.: This is an example of pseudo-stateful firewall that works with Default SG behaviour by learning return traffic rules:

https://github.com/stackforge/networking-vsphere/blob/master/networking_vsphere/drivers/ovs_firewall.py

-----Original Message-----
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Suryanarayanan, Aswin
Sent: 09 July 2015 12:54
To: ovsdb-dev@...
Subject: Re: [ovsdb-dev] Security Groups implementation

Hi Vishal,

Yes we are working on the provider in the net-virt. Neutron part is done , but we have to port it to MD-SAL.

Currently we are working with stateless use cases and trying to achieve openstack parity for that. As I understand 0VS 2.4 may support conn-track capabilities, we may have to wait for this to achieve the stateful use cases.

Thanks,
Aswin
----------------------------------------

Date: Thu, 9 Jul 2015 06:12:42 +0000
From: Vishal Thapar <vishal.thapar@...>
To: "neutron-dev@..."
<neutron-dev@...>,
"ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] Security Groups implementation
Message-ID:
<060FBE8F9E4A26488766FF6E902B43430F6BCD52@...>
Content-Type: text/plain; charset="us-ascii"

Hi,

I was looking for some information on the SG implementation in ODL. My understanding is that the provider in net-virt is in progress while NeutronNorthbound part of it is complete. Is this correct?

I was working with Amir on OVS Firewall during Icehouse/Juno before it got pushed back till conntrack support was available in OVS. My question is about the ODL implementation in-progress now, is it based off conntrack, or does it use one of the earlier approaches [TCP flags or Learn]?

I didn't find anything in wiki outlining the design of SG implementation. Could anyone shed any light on these?

Regards,
Vishal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150709/f32c1400/attachment-0001.html>

------------------------------
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Re: openstack neutron ovsdb port creation

Sam Hague
 

----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>
To: ovsdb-dev@...
Sent: Thursday, July 9, 2015 5:04:23 AM
Subject: [ovsdb-dev] openstack neutron ovsdb port creation

Hi,

I have read through ovsdb / openstack (helium), but I have issues
identifiying the actual ovs port creation.

Following from PortHandler.neutronPortCreated the only output I found is flow
programming related. But what I want to see is where ovs ports are created
through ovsdb.

To be more specific I would like to see the part where the ovs ports and ovs
interfaces are created by ovsdb, which are attached to tap devices to enable
connectivity to VM instances in an openstack environment.
Baudinot,

the ovsdb project will only add patch and tunnel ports as needed. The VM ports are added via the libvirt agent on the openstack compute nodes. The flow is like this:

Network creation:
1. User creates a network via openstack
2. neutron agents add ports to bridges for routers and dhcp namespaces - these are the tap ports you mention above
3. neutron and ovsdb port updates go to odl
4. neutron events passed to odl ovsdb project - not much happens here
5. ovsdb port events go directly to the odl ovsdb
6. odl ovsdb will relate the neutron events to the ovsdb events and build tunnels and push flows as needed.

VM Creation:
1. User creates VM's via openstack
2. nova calls libvirt to create VM
3. libvirt calls will allocate VM ports and add them to the br-int - these are the tap ports you mention above
4. Same as 3-6 above.


I assume that the opendaylight.neutron bundle itself is only responsible for
the northbound API to the neutron ml2 plugin and opendaylight.ovsdb does all
the work regarding to ovs.
yes, odl.neutron receives the incoming neutron rest APIs. And then effectively passes them through to odl.ovsdb to do the work.

Thank you

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Re: Marcelo - Unit test for the networking-odl L3

Marcelo Amaral <marcelo.amaral@...>
 

Hi Flavio,

Thank you very much!
I am carefully reading those references, and I will attempt to document them in the code.

Best,
Marcelo

On 09/07/15 05:36, Flavio Fernandes wrote:
On Jul 7, 2015, at 10:31 AM, Marcelo Amaral <marcelo.amaral@...> wrote:

Hi Flavio,

I am looking at you implementation of floating ip, since Swami asked me to understand and document it.
I have some questions. Would you mind helping me?
[ccing ovsdb-dev, Anil & Hideyuki]

Hello Marcelo,

As you probably know, it is my intention to write part 3 of the blog to talk about DNAT’s implementation in odl’s L3 obvsd netvirt.
I just need to bump it in the priority list; your email and Hideyuki’s question on irc have been a good motivators. ;) Thanks!

- When the method updateExternalRouterMac is invoked? In which context?
That is part of work Anil is wrapping up for ‘bug’ 3378 [1]. In the near future, a tracker like service written by Anil will call ‘updateExternalRouterMac’
so mac of nexthop gateway out of br-ex is known. Very good question. ;) A cheesy and cheap stop gap until then is to provide that mac address
via ovsdb.l3gateway.mac (in custom.properties). Not for long!

- When a tenant assign a floating IP to a VM, will the openstack neutron odl plugin request the odl controller to create snat rules into OVS?
(Are all the virtual network configuration going through the controller?)
Yes, a neutron message regarding the floating ip association is sent to odl via ml2. An example of how that message looks like can be seen here [2].
If you use postman, I shared a collection with the messages would would expect to see from ml2 to create/associate floating ips here [3].
By the way, you can ‘spy’ on all that ml2 communication. :) For details on doing that, look here [4].

In this case, the method handleNeutronFloatingIPEvent() is invoked to handle a floating ip creation:
1 - adding floatingIPArp: create FloatIpData mapping with OVS port, floating ip and tenant vm ip.
- The name of the method let me think that it is going to create ARP rules for the floating ip.
However, I don't know if I am missing something, but, It is not creating a rule (table 20 in case). Is it done in another step, or it is not related?
Yes, absolutely. The arp rules to handle floating ips are done here [5].

2 - creating the Inbound rule (ovs br, of br, floating ip, tenant vm ip). Here is where the magic happens :)
- Does it write a rule in table 30? Do you have an example how will be the rule in the end?
That is correct. An example of how table 30 looks like is here [6]. As you can see, we use REG3 to keep track of the segmentation id that goes with the tenant
associated with the floating ip. That is later on used in table 60 as part of the match [7]. I will — hopefully — do a better job showing that when I get a complete
working example in the blog.

3 - creating the outbound rule
- Does it write a rule in table 100? Do you have an example how will be the rule in the end?
Yes, that is right. An example of that rule would look like this [8]. To connect to br-ex from br-int, we use a patch-port. On table 100, we use the priority to
weed out the floating ips from the rest of the internal tenant’s subnets. The gist [8] shows that floating ips in table 100 are checked after since their
priority is lower.

- How does it know the target host to configure the OVS?
That is done with the help of ovs’s port external id. When nova creates an ovs port/interface to be used by a tenant vm, is puts some bread crumbs in the
external_ids of the interface. That value is the neutron port uuid. Once we know how to map the ovs interface with the neutron port, we can pinpoint which
bridge/node (dpid) is the home of the floating ip address, just by connecting the dots. I talk a bit about the matching of ovs interface with neutron port in part 1
of the blog [9]. Since ovs is co-located with the compute node, we can infer where all the tenant’s ports are.

Best,

— flavio

Best regards,
Marcelo Amaral
[1]: https://bugs.opendaylight.org/show_bug.cgi?id=3378
[2]: https://gist.github.com/36bd41daa237d7ab780e
[3]: https://www.getpostman.com/collections/1e316aebd6cbb1991b25
[4]: https://wiki.opendaylight.org/view/NeutronNorthbound:Help_Us_Help_You
[5]: programFlowsForFloatingIPArpAdd —> https://github.com/opendaylight/ovsdb/blob/stable/lithium/openstack/net-virt/src/main/java/org/opendaylight/ovsdb/openstack/netvirt/impl/NeutronL3Adapter.java#L367
[6]: https://gist.github.com/103de83f5dd04af41b25
[7]: table=60 … ip,reg3=0x429,nw_dst=10.2.0.0/24 actions=set_field:fa:16:3e:4b:f8:4f->eth_src,dec_ttl,set_field:0x429->tun_id,goto_table:70
[8]: https://gist.github.com/0257eaf97c82a7feca31
[9]: http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html (look for external_ids)


WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer
openstack neutron ovsdb port creation

Baudinot Denis Gerold (badi) <badi@...>
 

Hi,

I have read through ovsdb / openstack (helium), but I have issues identifiying the actual ovs port creation.

Following from PortHandler.neutronPortCreated the only output I found is flow programming related. But what I want to see is where ovs ports are created through ovsdb.

To be more specific I would like to see the part where the ovs ports and ovs interfaces are created by ovsdb, which are attached to tap devices to enable connectivity to VM instances in an openstack environment.

I assume that the opendaylight.neutron bundle itself is only responsible for the northbound API to the neutron ml2 plugin and opendaylight.ovsdb does all the work regarding to ovs.

Thank you
Re: Security Groups implementation

Vishal Thapar <vishal.thapar@...>
 

Hi Aswin,

Just to be clear, by stateless use cases do you mean you're using neither TCP Flags nor Learn action and require user to explicitly configure Ingress SG Rules to allow traffic?

Default SG behaviour is to allow all-egress and block all ingress traffic, ingress here refers to connections originating outside. A truly stateless won't be able to support this and require explicit ingress SG Rules to allow ingress traffic for connections originating from the VM/port.

Is my assumption correct?

Regards,
Vishal.

P.S.: This is an example of pseudo-stateful firewall that works with Default SG behaviour by learning return traffic rules:

https://github.com/stackforge/networking-vsphere/blob/master/networking_vsphere/drivers/ovs_firewall.py

-----Original Message-----
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Suryanarayanan, Aswin
Sent: 09 July 2015 12:54
To: ovsdb-dev@...
Subject: Re: [ovsdb-dev] Security Groups implementation

Hi Vishal,

Yes we are working on the provider in the net-virt. Neutron part is done , but we have to port it to MD-SAL.

Currently we are working with stateless use cases and trying to achieve openstack parity for that. As I understand 0VS 2.4 may support conn-track capabilities, we may have to wait for this to achieve the stateful use cases.

Thanks,
Aswin
----------------------------------------

Date: Thu, 9 Jul 2015 06:12:42 +0000
From: Vishal Thapar <vishal.thapar@...>
To: "neutron-dev@..."
<neutron-dev@...>,
"ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] Security Groups implementation
Message-ID:
<060FBE8F9E4A26488766FF6E902B43430F6BCD52@...>
Content-Type: text/plain; charset="us-ascii"

Hi,

I was looking for some information on the SG implementation in ODL. My understanding is that the provider in net-virt is in progress while NeutronNorthbound part of it is complete. Is this correct?

I was working with Amir on OVS Firewall during Icehouse/Juno before it got pushed back till conntrack support was available in OVS. My question is about the ODL implementation in-progress now, is it based off conntrack, or does it use one of the earlier approaches [TCP flags or Learn]?

I didn't find anything in wiki outlining the design of SG implementation. Could anyone shed any light on these?

Regards,
Vishal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150709/f32c1400/attachment-0001.html>

------------------------------
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Re: Security Groups implementation

Suryanarayanan, Aswin <aswin.suryanarayanan@...>
 

Hi Vishal,

Yes we are working on the provider in the net-virt. Neutron part is done , but we have to port it to MD-SAL.

Currently we are working with stateless use cases and trying to achieve openstack parity for that. As I understand 0VS 2.4 may support conn-track capabilities, we may have to wait for this to achieve the stateful use cases.

Thanks,
Aswin
----------------------------------------

Date: Thu, 9 Jul 2015 06:12:42 +0000
From: Vishal Thapar <vishal.thapar@...>
To: "neutron-dev@..."
<neutron-dev@...>,
"ovsdb-dev@..." <ovsdb-dev@...>
Subject: [ovsdb-dev] Security Groups implementation
Message-ID:
<060FBE8F9E4A26488766FF6E902B43430F6BCD52@...>
Content-Type: text/plain; charset="us-ascii"

Hi,

I was looking for some information on the SG implementation in ODL. My understanding is that the provider in net-virt is in progress while NeutronNorthbound part of it is complete. Is this correct?

I was working with Amir on OVS Firewall during Icehouse/Juno before it got pushed back till conntrack support was available in OVS. My question is about the ODL implementation in-progress now, is it based off conntrack, or does it use one of the earlier approaches [TCP flags or Learn]?

I didn't find anything in wiki outlining the design of SG implementation. Could anyone shed any light on these?

Regards,
Vishal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150709/f32c1400/attachment-0001.html>

------------------------------
Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Natarajan_Dhiraviam@...
 

Hi Flavio, Sam & All,

 

            We were testing latest neutron/lithium odl / stable kilo devstack combo in all-in-one mode few days back, using modified Flavio’s vagrant setup (http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html) we faced below issues(?).

 

 

1.      on stacking - unstacking - stacking (with manager set appropriately), br-int is *NOT* getting created consistently

2.      Even times when br-int was successfully created, OpenFlow connection to controller from ovswitch on control node is not setup consistently.

 

Anybody else faced similar issues ?

 

      We created br-int / OF connection to ODL on port 6653 manually in above cases and could see that the default pipelines flows are getting programmed both on the control & compute node, however vxlan tunnel weren’t getting created and we programmed it manually in the ovs. However ping from Tenant1-VM1 on control node to Tenant1-VM2 of compute node fails. Compute node has received the broadcast ARP request and sends it out to the Tenant1-VM2 as well. However the tenant is not responding back to the ARP request. Unfortunately we aren’t able to dump / analyze  packets on the Tenant1-VM2...

 

Tenant / VM definitions are WRT below diagram.

topology

Regards

Natarajan & Ravi

 
Security Groups implementation

Vishal Thapar <vishal.thapar@...>
 

Hi,

 

I was looking for some information on the SG implementation in ODL. My understanding is that the provider in net-virt is in progress while NeutronNorthbound part of it is complete. Is this correct?

 

I was working with Amir on OVS Firewall during Icehouse/Juno before it got pushed back till conntrack support was available in OVS. My question is about the ODL implementation in-progress now, is it based off conntrack, or does it use one of the earlier approaches [TCP flags or Learn]?

 

I didn’t find anything in wiki outlining the design of SG implementation. Could anyone shed any light on these?

 

Regards,

Vishal.
Re: Marcelo - Unit test for the networking-odl L3

Flavio Fernandes <ffernand@...>
 

On Jul 7, 2015, at 10:31 AM, Marcelo Amaral <marcelo.amaral@...> wrote:

Hi Flavio,

I am looking at you implementation of floating ip, since Swami asked me to understand and document it.
I have some questions. Would you mind helping me?
[ccing ovsdb-dev, Anil & Hideyuki]

Hello Marcelo,

As you probably know, it is my intention to write part 3 of the blog to talk about DNAT’s implementation in odl’s L3 obvsd netvirt.
I just need to bump it in the priority list; your email and Hideyuki’s question on irc have been a good motivators. ;) Thanks!

- When the method updateExternalRouterMac is invoked? In which context?
That is part of work Anil is wrapping up for ‘bug’ 3378 [1]. In the near future, a tracker like service written by Anil will call ‘updateExternalRouterMac’
so mac of nexthop gateway out of br-ex is known. Very good question. ;) A cheesy and cheap stop gap until then is to provide that mac address
via ovsdb.l3gateway.mac (in custom.properties). Not for long!


- When a tenant assign a floating IP to a VM, will the openstack neutron odl plugin request the odl controller to create snat rules into OVS?
(Are all the virtual network configuration going through the controller?)
Yes, a neutron message regarding the floating ip association is sent to odl via ml2. An example of how that message looks like can be seen here [2].
If you use postman, I shared a collection with the messages would would expect to see from ml2 to create/associate floating ips here [3].
By the way, you can ‘spy’ on all that ml2 communication. :) For details on doing that, look here [4].

In this case, the method handleNeutronFloatingIPEvent() is invoked to handle a floating ip creation:
1 - adding floatingIPArp: create FloatIpData mapping with OVS port, floating ip and tenant vm ip.
- The name of the method let me think that it is going to create ARP rules for the floating ip.
However, I don't know if I am missing something, but, It is not creating a rule (table 20 in case). Is it done in another step, or it is not related?
Yes, absolutely. The arp rules to handle floating ips are done here [5].


2 - creating the Inbound rule (ovs br, of br, floating ip, tenant vm ip). Here is where the magic happens :)
- Does it write a rule in table 30? Do you have an example how will be the rule in the end?
That is correct. An example of how table 30 looks like is here [6]. As you can see, we use REG3 to keep track of the segmentation id that goes with the tenant
associated with the floating ip. That is later on used in table 60 as part of the match [7]. I will — hopefully — do a better job showing that when I get a complete
working example in the blog.

3 - creating the outbound rule
- Does it write a rule in table 100? Do you have an example how will be the rule in the end?
Yes, that is right. An example of that rule would look like this [8]. To connect to br-ex from br-int, we use a patch-port. On table 100, we use the priority to
weed out the floating ips from the rest of the internal tenant’s subnets. The gist [8] shows that floating ips in table 100 are checked after since their
priority is lower.

- How does it know the target host to configure the OVS?
That is done with the help of ovs’s port external id. When nova creates an ovs port/interface to be used by a tenant vm, is puts some bread crumbs in the
external_ids of the interface. That value is the neutron port uuid. Once we know how to map the ovs interface with the neutron port, we can pinpoint which
bridge/node (dpid) is the home of the floating ip address, just by connecting the dots. I talk a bit about the matching of ovs interface with neutron port in part 1
of the blog [9]. Since ovs is co-located with the compute node, we can infer where all the tenant’s ports are.

Best,

— flavio

Best regards,
Marcelo Amaral
[1]: https://bugs.opendaylight.org/show_bug.cgi?id=3378
[2]: https://gist.github.com/36bd41daa237d7ab780e
[3]: https://www.getpostman.com/collections/1e316aebd6cbb1991b25
[4]: https://wiki.opendaylight.org/view/NeutronNorthbound:Help_Us_Help_You
[5]: programFlowsForFloatingIPArpAdd —> https://github.com/opendaylight/ovsdb/blob/stable/lithium/openstack/net-virt/src/main/java/org/opendaylight/ovsdb/openstack/netvirt/impl/NeutronL3Adapter.java#L367
[6]: https://gist.github.com/103de83f5dd04af41b25
[7]: table=60 … ip,reg3=0x429,nw_dst=10.2.0.0/24 actions=set_field:fa:16:3e:4b:f8:4f->eth_src,dec_ttl,set_field:0x429->tun_id,goto_table:70
[8]: https://gist.github.com/0257eaf97c82a7feca31
[9]: http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html (look for external_ids)
Re: ODL Inventory

Khaldoon Al Zoubi <khaldoon.alzoubi@...>
 

Thanks Sam for all of the help. Problem solved.

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Thursday, July 02, 2015 3:02 PM
To: Khaldoon Al Zoubi
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] ODL Inventory

Khal,

no, those exceptions are OK. In the 7.12.1 schema datapath and iface type fields were added so you have to have the matching ovs version installed which most don't. I don't recall the exact ovs version that brought in the new fields but I think anything 2.3.1 and earlier will have the below exception.

Did you see my last response when you mentioned it was the openflow inventory that you were not seeing? That is why you don't see the switches. The southbound feature is what will get the ovsdb nodes into the inventory. You can see that in your logs since you have the exceptions below that go along with that. From there, though ,the odl-ovsdb-openstack feature needs to be running to set the Controller target for the bridges. This will cause the bridges to connect to ODL and the openflwoplugin will populate the openflow switch inventory.

Ok, yeah, I thought the controller address was being set manually in your
setup. If it isn't then the switches will not connect to odl openflowplugin
and no inventory update.

The odl-ovsd-openstack feature does that. When the nodes connect, the netvirt
app will set the controller target address so that the switches connect. At
that point there will be switches added to the inventory by openflowplugin.
Sam


----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...>
To: "Sam Hague" <shague@...>
Cc: ovsdb-dev@...
Sent: Thursday, July 2, 2015 2:46:50 PM
Subject: RE: [ovsdb-dev] ODL Inventory

Hi Sam,

Do you think the following two exceptions explain some of the problem I have.
Thanks.



2015-07-02 13:40:13,110 | DEBUG | n-invoker-impl-0 | OpenVSwitchUpdateCommand
| 251 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.SNAPSHOT |
Datapath types not supported by this version of ovsdb
org.opendaylight.ovsdb.lib.error.SchemaVersionMismatchException: The schema
version used to access this Table/Column does not match the required
version.
Current Version: 7.6.0
Added in Version: 7.12.1
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkVersion(TyperUtils.java:217)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkColumnSchemaVersion(TyperUtils.java:203)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.access$100(TyperUtils.java:37)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.processGetColumn(TyperUtils.java:307)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.invoke(TyperUtils.java:379)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at com.sun.proxy.$Proxy116.getDatapathTypesColumn(Unknown
Source)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.setDataPathTypes(OpenVSwitchUpdateCommand.java:221)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.execute(OpenVSwitchUpdateCommand.java:81)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.OvsdbOperationalCommandAggregator.execute(OvsdbOperationalCommandAggregator.java:30)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:77)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]
2015-07-02 13:40:13,118 | DEBUG | n-invoker-impl-0 | OpenVSwitchUpdateCommand
| 251 - org.opendaylight.ovsdb.southbound-impl - 1.1.0.SNAPSHOT |
Iface types not supported by this version of ovsdb
org.opendaylight.ovsdb.lib.error.SchemaVersionMismatchException: The schema
version used to access this Table/Column does not match the required
version.
Current Version: 7.6.0
Added in Version: 7.12.1
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkVersion(TyperUtils.java:217)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.checkColumnSchemaVersion(TyperUtils.java:203)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils.access$100(TyperUtils.java:37)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.processGetColumn(TyperUtils.java:307)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.lib.schema.typed.TyperUtils$1.invoke(TyperUtils.java:379)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at com.sun.proxy.$Proxy116.getIfaceTypesColumn(Unknown
Source)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.setInterfaceTypes(OpenVSwitchUpdateCommand.java:198)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.OpenVSwitchUpdateCommand.execute(OpenVSwitchUpdateCommand.java:82)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.OvsdbOperationalCommandAggregator.execute(OvsdbOperationalCommandAggregator.java:30)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
org.opendaylight.ovsdb.southbound.transactions.md.TransactionInvokerImpl.run(TransactionInvokerImpl.java:77)[251:org.opendaylight.ovsdb.southbound-impl:1.1.0.SNAPSHOT]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_79]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_79]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_79]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_79]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_79]

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Wednesday, July 01, 2015 1:33 PM
To: Khaldoon Al Zoubi
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] ODL Inventory



----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...>
To: "Sam Hague" <shague@...>
Cc: ovsdb-dev@...
Sent: Tuesday, June 30, 2015 3:46:14 PM
Subject: RE: [ovsdb-dev] ODL Inventory

Hi Sam,

The ovsdb loads the config and operational topology correctly, which is
good
I need that. But, what is not working for me is that openflowplugin is not
adding switches to inventory.
Ok, yeah, I thought the controller address was being set manually in your
setup. If it isn't then the switches will not connect to odl openflowplugin
and no inventory update.

The odl-ovsd-openstack feature does that. When the nodes connect, the netvirt
app will set the controller target address so that the switches connect. At
that point there will be switches added to the inventory by openflowplugin.



Thanks.

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Tuesday, June 30, 2015 12:39 PM
To: Khaldoon Al Zoubi
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] ODL Inventory

Khal,

the openstack modules do not write anything to operational. It relies on
the
southbound to do that and openstack listens for those changes when they
happen. After that the openstack netvirt modules will do things like add
bridges, but it is the southbound which will update the operational
topology. If you are looking for the openflow nodes, then the
openflowplugin
does that (look in the earlier email where I mentioned that)

1. Did you verify the southbound feature loaded? feature:list -i | grep
ovsdb. look for southbound.
2. Try the postman calls. look in the ovsdb/resources/commons dir for the
southbound postman. Use the "Get config topology" and "get operational
topology" restconf calls and see if you get the ovsdb:1 node.
3. Add the ovs-vsctl set-manager tcp:<odlip>:6640 and verify if the ovsdb
node connected to odl, ovs-vsctl show.
4. Then try the postman calls again to see if the node shows up.

Sam

----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...>
To: "Sam Hague" <shague@...>
Cc: ovsdb-dev@...
Sent: Tuesday, June 30, 2015 12:27:13 PM
Subject: RE: [ovsdb-dev] ODL Inventory

Hi Sam,

I commented out the openstack bundles in odl-ovsdb-openstack (please see
below) to test if odl-ovsdb-southbound-impl-ui will be able to load the
inventory operational node into datastore. Well, it didn't do it. Is that
mean that the openstack bundles are doing extra work to populate the
inventory? Thanks.

--------
<feature name="odl-ovsdb-openstack" description="OpenDaylight :: OVSDB ::
OpenStack Network Virtualization"
version='${openstack.netvirt.version}'>
<feature version='${mdsal.version}'>odl-mdsal-broker</feature>
<feature
version="${openflowplugin.version}">odl-openflowplugin-nsf-model</feature>
<feature
version="${networkconfig.neutron.version}">odl-neutron-service</feature>
<feature
version="1.1.0-SNAPSHOT">odl-ovsdb-southbound-impl-ui</feature>
<feature
version="${openflowplugin.version}">odl-openflowplugin-flow-services</feature>
<feature
version="${openflowplugin.version}">odl-openflowplugin-nxm-extensions</feature>
<!--
<bundle>mvn:org.opendaylight.ovsdb/utils.servicehelper/${ovsdb.utils.servicehelper.version}</bundle>
<bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt/${openstack.netvirt.version}</bundle>
<bundle>mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${openstack.netvirt.providers.version}</bundle>
<configfile
finalname="etc/opendaylight/karaf/netvirt-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt/${project.version}/xml/config</configfile>
<configfile
finalname="etc/opendaylight/karaf/netvirt-providers-impl-default-config.xml">mvn:org.opendaylight.ovsdb/openstack.net-virt-providers/${project.version}/xml/config</configfile>
-->
</feature>


-----Original Message-----
From: Khaldoon Al Zoubi
Sent: Thursday, June 25, 2015 3:45 PM
To: 'Sam Hague'
Cc: ovsdb-dev@...
Subject: RE: [ovsdb-dev] ODL Inventory

Thanks Sam. Actually, this what I thought I need to do (only include
odl-ovsdb-southbound-impl in my features.xml), but I am not sure what
part
I
am missing. I believe the devstack & ODL connection works since I am able
to
see neutron elements in datastore when executing commands like (neutron
net-create net-1). So feature odl-neutron-service works.

However, when I am running ODL purely from the OVSDB project it works and
I
can see the operational nodes. So, I am missing something in my project.

Thanks Sam as always.

Regards,
Khal


-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Thursday, June 25, 2015 2:41 PM
To: Khaldoon Al Zoubi
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] ODL Inventory

Khal,

the OVSDB southbound plugin [1] will populate the topology with the ovsdb
node information, including the bridges and ports. With devstack as part
of
the local.conf config the ODL address is specified. In the final steps of
the stack.sh the OVSDB Manager entry is set to that address and the OVSDB
nodes will connect to ODL. The OVSDB southbound plugin will see that
connection and begin to populate the MDSAL operational datastore - stores
the node, the bridge, the ports as termination points.

From there the netvirt [2] application listens for the operational
updates.
netvirt also listens on the neutron events coming from the northbound
side.
With these two sets of events netvirt will satisfy the neutron requests.

The openflow nodes inventory is populated via the openflowplugin. When
the
OVSDB nodes connect and netvirt sees that it will create the required
bridges, i.e, br-int, and then set the Controller address. Those bridges
will then connect to ODL openflowplugin port and openflowplugin will add
the
switches to the inventory.

So you just need the odl-ovsdb-southbound-impl or
odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which
will
get the inventory for you.

Thanks, Sam

[1] ovsdb/southbound/southbound-impl
[2] ovsdb/openstack

----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...>
To: ovsdb-dev@...
Sent: Thursday, June 25, 2015 12:15:05 PM
Subject: [ovsdb-dev] ODL Inventory



Hi,



I can’t figure out how OVSDB populate ODL Inventory based on openstack
(i.e.
specifically after ./stack.sh is complete). Also, is there a feature I
can
include in my project to do that.



Thanks much.

Khal

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Re: restconf/mdsal wildcard queries

Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES@Cisco) <ttkacik@...>
 

Hi Sam,
We are planning to indroduce some support of queries and filtering in MD-SAL
And hopefully also NETCONF and RESTCONF (this is tracked by https://bugs.opendaylight.org/show_bug.cgi?id=2300)

I added to bug report your use-case so we would consider it during design
of filtering and queries.

I plan to post soon draft release plans for yangtools, md-sal, netconf (and restconf included) so we can move conversation forward.

Tony

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Monday, July 06, 2015 10:35 PM
To: Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco); ovsdb-dev; Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)
Subject: restconf/mdsal wildcard queries

Tony, Robert,

Anil mentioned there is a possibility to add wildcard queries to mdsal? Is that a feature that can be added for Be?

The idea is to be able to search for something using a field in the model that is not a key. For instance, the ovsdb.yang imports the network-topology and adds a Node to the datastore. The model augments the node to include ip-addresses. We would like the ability to issue a restconf query to return the node with that ip-address.

Today to do this we would implement an RPC to terminate in our backend code. Then retrieve all the Nodes in the datastore, loop over them and look for the specific matching data. We figure this is a common block of code that might be able to be implemented in the mdsal itself.

Thanks, Sam
3181 - 3200 of 4855