Date   

Re: OVSDB node-id

Chaudhry usama <chaudhryusama@...>
 

I was using the 18th June Lithium Artifact on my local VM. Not sure about the one used in ODL rackspace VM. You modified the code recently ?

On Mon, Jun 22, 2015 at 10:41 AM, Anil Vishnoi <vishnoianil@...> wrote:
The second version i the correct one, we recently modified the code to use bridge uuid as it's node id and not the <ip>:<port>. Are you running same ovsdb code on both the machines?

On Mon, Jun 22, 2015 at 11:03 AM, Luis Gomez <ecelgp@...> wrote:
Hi ovsdb devs,

We have question regarding ovsdb node-id:

- When we initiate an ovsdb connection from the OVS to ODL using local VM we get an ovsdb node-id like: "node-id": "ovsdb://127.0.0.1:6644” (ovsdb IP and tcp port)

However:

- When we do the same using ODL rackspace VM we get a node-id like: "node-id": "ovsdb://uuid/bb719b63-34ea-4586-a328-bd2f7bd6e5f7” 

Can anyone explain this difference in node-id representation?

BR/Luis


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




--
Thanks
Anil

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



Re: OVSDB node-id

Anil Vishnoi
 

The second version i the correct one, we recently modified the code to use bridge uuid as it's node id and not the <ip>:<port>. Are you running same ovsdb code on both the machines?

On Mon, Jun 22, 2015 at 11:03 AM, Luis Gomez <ecelgp@...> wrote:
Hi ovsdb devs,

We have question regarding ovsdb node-id:

- When we initiate an ovsdb connection from the OVS to ODL using local VM we get an ovsdb node-id like: "node-id": "ovsdb://127.0.0.1:6644” (ovsdb IP and tcp port)

However:

- When we do the same using ODL rackspace VM we get a node-id like: "node-id": "ovsdb://uuid/bb719b63-34ea-4586-a328-bd2f7bd6e5f7” 

Can anyone explain this difference in node-id representation?

BR/Luis


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




--
Thanks
Anil


OVSDB node-id

Luis Gomez
 

Hi ovsdb devs,

We have question regarding ovsdb node-id:

- When we initiate an ovsdb connection from the OVS to ODL using local VM we get an ovsdb node-id like: "node-id": "ovsdb://127.0.0.1:6644” (ovsdb IP and tcp port)

However:

- When we do the same using ODL rackspace VM we get a node-id like: "node-id": "ovsdb://uuid/bb719b63-34ea-4586-a328-bd2f7bd6e5f7” 

Can anyone explain this difference in node-id representation?

BR/Luis


Re: I think I've fixed SecGrps and SecGrpRules

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

Hi Ed,

 

Thanks for the inputs J.

 

Yes as per the pcap and the logs the request is reaching the Opendaylight. The default security groups which needs to be associated with the port when a vm is spawned comes as a part of the port create /update request. This will invoke programLocalRules in OF13Provider.java when port is created and updated. I see the error “could not find the ofport” is being thrown only in the case port create and  for port update I didn’t see this error (in debug mode I saw the OFport associated with interface retrieved ). But the code for adding the SG flows is commented out currently in OF13Provider. I tried uncommenting it but still it not adding the default security group rules flows since SecurityRuleRemoteIpPrefix being passed from networking-odl is null while odl expects 0.0.0.0/0.  In horizon UI it is set to 0.0.0.0/0, I think it may require a fix in the networking-odl.

 

The default security groups expected when a VM is spawned to have parity with openstack is as follows (correct me if I have missed any)

 

Ingress

1)      Allow traffic  from the DHCP server.

2)      Allow traffic from any other vm in the same network

 

Egress

1)      Allow DHCP traffic

2)      Disallow DHCP spoffing by the client.

3)      Allow all other traffic

 

Source

1)      Allow the traffic from the IP/Mac pair of the vm as source

2)      Disallow all the other traffic.

 

 

In the Ingress/EgressAclService currently supports only security rules realted to TCP and with no protocol selected . In my opinion we need to enhance the code related to default securityGroups rule in ODL to match with openstack  . Me and Ravi are planning to sign up for the trello card related to default  SecurityGroups.  Please let us know if you have any comments/suggestions/concerns.

 

Btw, for adding new security group ( which when created not associated with a port), I hope the call should come directly  NeutronSecurityGroupsNorthbound or neutron will send ODL Info about these SecurityGroup rules only when it is associated with a port?  Currently when I captured the packet in wireshark  the REST call for creating a security  going to 9696 port only but  not to the ODL port.

 

                                                                                                                                                                                                                                           

Thanks and Regards

Aswin

 

 

From: Edward Warnicke [mailto:hagbard@...]
Sent: Wednesday, June 17, 2015 6:17 PM
To: Vishal Thapar
Cc: Suryanarayanan, Aswin; Anil Vishnoi; ovsdb-dev@...; groupbasedpolicy-dev@...; Kenchappa, Ravindra; neutron-dev@...
Subject: Re: [ovsdb-dev] I think I've fixed SecGrps and SecGrpRules

 

Vishal,

 

Good job narrowing it down :)

 

You've cleared the ML2 driver (messages are getting to ODL)

 

If you would try it with the neutron northbound dummy-provider which gives good logging of messages received and correctly unmarshalled, we can clear the neutron northbound

and narrow it down to just the provider.

 

To test with the neutron northbound,

 

cd neutron

cd karaf/

mvn clean install

cd target/assembly/bin

./karaf

 

This will bring up the dummy-provider, which just logs messages received.  If you see your messages in the logs there, we know the

neutron northbound has correct behavior :)

 

Ed

 

 

On Wed, Jun 17, 2015 at 6:25 AM, Vishal Thapar <vishal.thapar@...> wrote:

Looks like rest calls are going from ODL Mech driver to ODL for security group as well as VM Port [IP .

 

Neutron log: 3389 and 3402

pcap: Frame 406 and 555.

 

Found this entry in karaf.log:

Line 569: 2015-06-18 01:51:59,928 | INFO  | ntDispatcherImpl | OF13Provider                     | 272 - org.opendaylight.ovsdb.openstack.net-virt-providers - 1.1.0.SNAPSHOT | programLocalRules: could not find ofPort for Port tap1220d276-15 on Node Uri [_value=ovsdb://uuid/b45dcd8f-5e20-42a0-abc0-f1373dc18f6c/bridge/br-int]

 

Relevant entries are line 567 to 570. This is where someone more familiar with OVSDB would be able to help.

 

Regards,

Vishal.

 

 

From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Suryanarayanan, Aswin
Sent: 17 June 2015 16:51
To: Anil Vishnoi; Edward Warnicke
Cc: ovsdb-dev@...; groupbasedpolicy-dev@...; Kenchappa, Ravindra; neutron-dev@...


Subject: Re: [ovsdb-dev] I think I've fixed SecGrps and SecGrpRules

 

Thanks Anil for the suggestions.

 

Hi Ed,

 

The logs and pcap are attached in the below link. There are some logs security groups in neutron server log. But I was not able to confirm whether the request reached ODL correctly. I am trying to understand the same.  But no flows related to security groups where  inserted. Let me know if any further logs are required.

 

The log is for the use case  Create Network -> Create Subnet -> Spawn VM.

 

https://drive.google.com/folderview?id=0BzO1nVcl7PumfmczY1lsWjJXSGc0SHVkYlNaYTh6TjdkZk1HazRqdzdCWUpjcFI4UzVIUW8&usp=sharing

 

Thanks and Regards

Aswin

 

From: Anil Vishnoi [mailto:vishnoianil@...]
Sent: Wednesday, June 17, 2015 3:06 AM
To: Edward Warnicke
Cc: Suryanarayanan, Aswin; ovsdb-dev@...; groupbasedpolicy-dev@...; neutron-dev@...; Kenchappa, Ravindra
Subject: Re: [ovsdb-dev] I think I've fixed SecGrps and SecGrpRules

 

I would say just enable the debug log in odl mechanism driver and you will get all the rest call details that it's sending to odl controller. 

 

On Wed, Jun 17, 2015 at 1:00 AM, Edward Warnicke <hagbard@...> wrote:

Aswin,

 

If you could stick the pcap files somwhere like google drive or dropbox and share them that would also be mega useful :)

 

Ed

 

On Tue, Jun 16, 2015 at 12:29 PM, Suryanarayanan, Aswin <aswin.suryanarayanan@...> wrote:

Hi Ed,

 

We checked with break points in  NeutronSecurityRulesNorthbound and NeutronSecurityGroupsNorthbound in neutron ODL. We will analyze with wireshark and get back.

 

Aswin

 

From: Edward Warnicke [mailto:hagbard@...]
Sent: Tuesday, June 16, 2015 11:40 PM
To: Suryanarayanan, Aswin
Cc: ovsdb-dev@...; Kenchappa, Ravindra; neutron-dev@...; groupbasedpolicy-dev@...
Subject: Re: [ovsdb-dev] I think I've fixed SecGrps and SecGrpRules

 

Looping in other interested parties.

 

Ravi,

 

Lets start debugging at the top :)

 

1)  When you create a VM, what call are you expecting to see to ODL, and how are you verifying you don't see it (wireshark, etc)

 

The reason I ask, is because the issue could be in any of the following components:

 

1) Neutron

2) ML2

3) ODL ML2 Driver (in Stackforge)

4) ODL Neutron Northbound (in ODL)

5) The provider

 

Usually, the simplest way to start debugging for me is to answer the question:

 

On the wire, do I see the REST calls I expected.

 

Once we know the answer to that, we can drill further down :)

 

Ed

 

 

 

On Tue, Jun 16, 2015 at 11:44 AM, Suryanarayanan, Aswin <aswin.suryanarayanan@...> wrote:

Hi Ed,

 

Me and Ravi  tired with the devstack kilo with latest code from networking-odl(few changes in neutron as well) along with latest ODL. We observed that when we created a network from horizon we received a call to NeutronSecurityRulesNorthbound  createSecurityRules with empty list. But when we created a vm call didn’t seem to reach Neutron northbound in ODL and no flows where inserted Table 40 or Table 90.  Shouldn’t we have the default rules to be added?  Could you please clarify?  Also when we tried to create SG from horizon UI, none of the call hit the Neutron Security Groups in ODL. Do that require any further changes in networking-odl/neutron?

 

Aswin


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

 

 


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



 

--

Thanks

Anil

 


Re: Openstack br-ex flows

Michał Skalski <michal@...>
 

Flavio helped me on IRC. To use bridge with different name than br-ex change in code is required: https://git.opendaylight.org/gerrit/#/c/22991/

Regards,
Michal

2015-06-19 12:51 GMT+02:00 Michał Skalski <michal@...>:

Hello everyone,

I think that I have a problem which was described in this issue https://bugs.opendaylight.org/show_bug.cgi?id=1147
I'm trying to add opendaylight to existing openstack env, but when I set manager address on ovs:

# ovs-vsctl set-manager tcp:192.168.0.4:6640

then on br-floating bridge which in my case do the same what br-ex on standard openstack I have no flows:

# ovs-ofctl -O OpenFlow13 dump-flows br-floating
OFPST_FLOW reply (OF1.3) (xid=0x2):

If a create br-ex and then set manager, I have this flows:
# ovs-ofctl -O OpenFlow13 dump-flows br-ex
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=76.070s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
 cookie=0x0, duration=76.069s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535

Is there is a way to opendaylight treat br-floating the same as br-ex and set flow with "actions=normal"? I'm using Helium-sr3 release.


Openstack br-ex flows

Michał Skalski <michal@...>
 

Hello everyone,

I think that I have a problem which was described in this issue https://bugs.opendaylight.org/show_bug.cgi?id=1147
I'm trying to add opendaylight to existing openstack env, but when I set manager address on ovs:

# ovs-vsctl set-manager tcp:192.168.0.4:6640

then on br-floating bridge which in my case do the same what br-ex on standard openstack I have no flows:

# ovs-ofctl -O OpenFlow13 dump-flows br-floating
OFPST_FLOW reply (OF1.3) (xid=0x2):

If a create br-ex and then set manager, I have this flows:
# ovs-ofctl -O OpenFlow13 dump-flows br-ex
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=76.070s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
 cookie=0x0, duration=76.069s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535

Is there is a way to opendaylight treat br-floating the same as br-ex and set flow with "actions=normal"? I'm using Helium-sr3 release.


[Urgent] AAA, ALTO, DIDM, L2switch, NIC, Opflex, OVSDB, PCMM, Persistence, Reservation, SNBI, USC missing RC1 test status report

George Zhao <George.Y.Zhao@...>
 

AAA, ALTO, DIDM, L2switch, NIC, Opflex, OVSDB, PCMM, Persistence, Reservation, SNBI, USC Project Leads:

 

Your project still haven’t report RC1 test status, please do so.

 

Please note TSC reserve the right to drop project from Lithium release if RC1 status is not reported by 6/18  10:00 am PDT , which is just less than a couple of hours from now.

 

Thanks,

 

George


Re: odl-ovsdb-openstack observations

Chaudhry usama <chaudhryusama@...>
 

Yes, I can see the br-int configuration in config data store before disconnect controller from the ovs node.

I am  removing the ovsdb node from config data store.

On Thu, Jun 18, 2015 at 10:15 AM, Anil Vishnoi <vishnoianil@...> wrote:
Chaudhry, do you see br-int bridge configuration in config data store before you disconnect the ovs from controller? How are you disconnecting the ovs from controller? by removing ovsdb node config from data store or manually by removing the ovsdb manager ?

On Thu, Jun 18, 2015 at 9:42 AM, Chaudhry usama <chaudhryusama@...> wrote:
Sure Luis, i will add this test case later today.
Sure Edward, I will file the bug

On Thu, Jun 18, 2015 at 1:11 AM, Luis Gomez <ecelgp@...> wrote:
Chaudhry please leave a test case failing so that we know when the bug get fixed :)

On Jun 17, 2015, at 1:07 PM, Edward Warnicke <hagbard@...> wrote:

My gut feeling is that if you are only deleting the connection, only the connection should be deleted from the config subsystem... and then if you create the connection again, on reconnect
we should be pushing out that config if its not there...

So I would tend to call it a bug with reconnect...

Could you file a bug for it?

Ed

On Wed, Jun 17, 2015 at 1:18 PM, Chaudhry usama <chaudhryusama@...> wrote:
Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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




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



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




--
Thanks
Anil


Re: odl-ovsdb-openstack observations

Anil Vishnoi
 

Chaudhry, do you see br-int bridge configuration in config data store before you disconnect the ovs from controller? How are you disconnecting the ovs from controller? by removing ovsdb node config from data store or manually by removing the ovsdb manager ?

On Thu, Jun 18, 2015 at 9:42 AM, Chaudhry usama <chaudhryusama@...> wrote:
Sure Luis, i will add this test case later today.
Sure Edward, I will file the bug

On Thu, Jun 18, 2015 at 1:11 AM, Luis Gomez <ecelgp@...> wrote:
Chaudhry please leave a test case failing so that we know when the bug get fixed :)

On Jun 17, 2015, at 1:07 PM, Edward Warnicke <hagbard@...> wrote:

My gut feeling is that if you are only deleting the connection, only the connection should be deleted from the config subsystem... and then if you create the connection again, on reconnect
we should be pushing out that config if its not there...

So I would tend to call it a bug with reconnect...

Could you file a bug for it?

Ed

On Wed, Jun 17, 2015 at 1:18 PM, Chaudhry usama <chaudhryusama@...> wrote:
Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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




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



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




--
Thanks
Anil


Re: odl-ovsdb-openstack observations

Chaudhry usama <chaudhryusama@...>
 

Sure Luis, i will add this test case later today.
Sure Edward, I will file the bug

On Thu, Jun 18, 2015 at 1:11 AM, Luis Gomez <ecelgp@...> wrote:
Chaudhry please leave a test case failing so that we know when the bug get fixed :)

On Jun 17, 2015, at 1:07 PM, Edward Warnicke <hagbard@...> wrote:

My gut feeling is that if you are only deleting the connection, only the connection should be deleted from the config subsystem... and then if you create the connection again, on reconnect
we should be pushing out that config if its not there...

So I would tend to call it a bug with reconnect...

Could you file a bug for it?

Ed

On Wed, Jun 17, 2015 at 1:18 PM, Chaudhry usama <chaudhryusama@...> wrote:
Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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




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



Re: Work on CI systems and or bug fixing

Luis Gomez
 

Hi Ravi,

Sorry for not answering before, 2 things:

1) Can you make tomorrow’s Thursday integration call at 8AM PST details here [1]? This way you can check all open fronts we have in integration today.

2) Regarding OVSDB efforts in integration we have Chaudhry (ODL intern) helping with OVSDB SB plugin suite (the one you pointed out), Alexis and Mohamed (Inocybe) preparing the netvirt suite, and Marcus and Praveen (Intel) doing the perf/scalability test for OVSDB plugin.

You can sync with any of these folks if you want to help in any of these areas or you can take a new integration task, for the second is good to attend the weekly call.



On Jun 17, 2015, at 7:48 PM, Kenchappa, Ravindra <ravindra.kenchappa@...> wrote:

Hi Luis,
 
Can you send me some details on what are those CI Jenkins jobs we can start looking into and what feature requires additional automated test cases.  I am going through the configuration and of CI job https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-cds-southbound-all-stable-lithium/  and getting familiar. Please let me know.
 
Thanks,
Ravi
 
From: Kyle Mestery [mailto:mestery@...] 
Sent: Wednesday, June 17, 2015 7:22 AM
To: Anil Vishnoi; Armando Migliaccio
Cc: Kenchappa, Ravindra; Luis Gomez Palacios; ovsdb-dev@...
Subject: Re: [ovsdb-dev] Work on CI systems and or bug fixing
 

Armando and I have this underhand now from the OpenStack side. We should have these jobs back and voting ok with running Tempest tests by Friday I anticipate.

On the ODL side, there are real issues there. Flavio has the latest, but we could use help there for sure.
 
On Tue, Jun 16, 2015 at 4:37 PM, Anil Vishnoi <vishnoianil@...> wrote:
Adding Luis 
 
On Tue, Jun 16, 2015 at 11:48 PM, Kenchappa, Ravindra <ravindra.kenchappa@...> wrote:
Hi Guys,
Me  and Aswin  are from HP have spent some time to understand the ODL-OVSDB architecture. We wanted to work on security groups and hardware l2 gateway but then we heard that  some help is needed in stabilizing the CI systems.  We  can take up some work on CI system or defect fix . Please let us know whom do we work with to get started.
Thanks,
Ravi
 


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



 
-- 
Thanks
Anil


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



Re: Work on CI systems and or bug fixing

Kenchappa, Ravindra <ravindra.kenchappa@...>
 

Hi Luis,

 

Can you send me some details on what are those CI Jenkins jobs we can start looking into and what feature requires additional automated test cases.  I am going through the configuration and of CI job https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-cds-southbound-all-stable-lithium/  and getting familiar. Please let me know.

 

Thanks,

Ravi

 

From: Kyle Mestery [mailto:mestery@...]
Sent: Wednesday, June 17, 2015 7:22 AM
To: Anil Vishnoi; Armando Migliaccio
Cc: Kenchappa, Ravindra; Luis Gomez Palacios; ovsdb-dev@...
Subject: Re: [ovsdb-dev] Work on CI systems and or bug fixing

 

Armando and I have this underhand now from the OpenStack side. We should have these jobs back and voting ok with running Tempest tests by Friday I anticipate.

On the ODL side, there are real issues there. Flavio has the latest, but we could use help there for sure.

 

On Tue, Jun 16, 2015 at 4:37 PM, Anil Vishnoi <vishnoianil@...> wrote:

Adding Luis 

 

On Tue, Jun 16, 2015 at 11:48 PM, Kenchappa, Ravindra <ravindra.kenchappa@...> wrote:

Hi Guys,

Me  and Aswin  are from HP have spent some time to understand the ODL-OVSDB architecture. We wanted to work on security groups and hardware l2 gateway but then we heard that  some help is needed in stabilizing the CI systems.  We  can take up some work on CI system or defect fix . Please let us know whom do we work with to get started.

Thanks,

Ravi

 


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



 

--

Thanks

Anil


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

 


Re: odl-ovsdb-openstack observations

Luis Gomez
 

Chaudhry please leave a test case failing so that we know when the bug get fixed :)

On Jun 17, 2015, at 1:07 PM, Edward Warnicke <hagbard@...> wrote:

My gut feeling is that if you are only deleting the connection, only the connection should be deleted from the config subsystem... and then if you create the connection again, on reconnect
we should be pushing out that config if its not there...

So I would tend to call it a bug with reconnect...

Could you file a bug for it?

Ed

On Wed, Jun 17, 2015 at 1:18 PM, Chaudhry usama <chaudhryusama@...> wrote:
Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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




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


Re: odl-ovsdb-openstack observations

Edward Warnicke <hagbard@...>
 

My gut feeling is that if you are only deleting the connection, only the connection should be deleted from the config subsystem... and then if you create the connection again, on reconnect
we should be pushing out that config if its not there...

So I would tend to call it a bug with reconnect...

Could you file a bug for it?

Ed

On Wed, Jun 17, 2015 at 1:18 PM, Chaudhry usama <chaudhryusama@...> wrote:
Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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





Re: odl-ovsdb-openstack observations

Luis Gomez
 

What about step 1) it seems the first time you connect the ovsdb plugin programs the switch in config datastore...

On Jun 17, 2015, at 12:13 PM, Anil Vishnoi <vishnoianil@...> wrote:

​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: odl-ovsdb-openstack observations

Chaudhry usama <chaudhryusama@...>
 

Thanks Vishnoi.


On what parameter does it makes this decision whether to initiate the create "br-int" request ? Checking the operational datastore or whether the bridge as entity connected to the controller or some-other parameter.

On Thu, Jun 18, 2015 at 12:18 AM, Chaudhry usama <chaudhryusama@...> wrote:
Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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





Re: odl-ovsdb-openstack observations

Chaudhry usama <chaudhryusama@...>
 

Only the connection to the OVSDB node has been deleted

On Thu, Jun 18, 2015 at 12:15 AM, Edward Warnicke <hagbard@...> wrote:
There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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




Re: odl-ovsdb-openstack observations

Edward Warnicke <hagbard@...>
 

There might be a subtlety here... was it just the connection that was deleted?  Or also the accompanying configuration of bridges using that connection?

Ed

On Wed, Jun 17, 2015 at 1:13 PM, Anil Vishnoi <vishnoianil@...> wrote:
​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil

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



Re: odl-ovsdb-openstack observations

Anil Vishnoi
 

​​
As per my understanding this is expected behavior. Config data store is meant for user configuration and operational data store is to reflect the operational state of the connected node.

So in (3) user didn't do any configuration as such, so you should not see any thing in config data store, but because br-int already present in the node, operational data store is reflecting that state correctly.


On Thu, Jun 18, 2015 at 12:37 AM, Chaudhry usama <chaudhryusama@...> wrote:
Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

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




--
Thanks
Anil


odl-ovsdb-openstack observations

Chaudhry usama <chaudhryusama@...>
 

Hi All,
     While playing with opendaylight controller with karaf feature installed ( odl-ovdb-openstack) observe few things. Need clarification on that.

1) If a clean OVS is connected with the controller. As you connect the controller, it creates a br-int bridge ( br-int bridge added to the config data-store and operational topology). Great

2) If i manually delete the bridge when the controller is connected to the OVS node. The bridge is automatically deleted from the config data store. Great

3) if the connection to the OVS node is deleted but the br-int remains in it and controller is not restarted. Now, if the controller is again connected to the OVS. The controller doesn't create the br-int bridge so the br-int remains in the operational topology but not in the config data-store.

--> One reason which i understood was, as the br-int is already connected to the controller so the controller has a condition on that connection.
Is this observation correct ?

Need comments on that. Thanks

Regards,
Chaudhry

3261 - 3280 of 4855