Date   

Error in connecting ovs

Prateek Garg (prategar) <prategar@...>
 

Hi Guys,

I am receiving an error when I connect an ovs with an existing bridge and port to controller. 
Steps:
  1. Set manager ptcp in ovs.
  2. Start southbound-karaf controller.
  3. Create ovsdb node in config.
  4. Create bridge
  5. Create port.
  6. Stop the controller
  7. Clean start the controller.
  8. Repeat step 3.
Expected: I should see the bridge, port and ovsdb node in operational store.
Actual: Nothing shows in operation store.

Could you please let me know if anyone else is also experiencing this issue.

Regards
Prateek


Re: OVSDB SB system test and scalability (if we can)

Luis Gomez
 

Adding Chaudhry (for some reason got removed)…

On May 8, 2015, at 10:54 AM, Luis Gomez <ecelgp@...> wrote:

Hi Sam, couple of things:

- Can you refer any documentation or POSTMAN collection for the small OVSDB pieces you mention or there is really nothing (other than code) as you say?

- The OpenStack is a different track Daniel is driving and trying to align with OPNFV goals. That one I am not 100% certain we can get it done this release according to latest Daniel comments in the integration call. However if with your experience with tempest test you think we can easily deploy stable openstack with unstable ODL and make some quick VM transport test, we can also take a look at that now.

BR/Luis



On May 8, 2015, at 10:39 AM, Sam Hague <shague@...> wrote:

Luis,

Welcome Chaudhry and Neelima! Yeah, this is great and something that would be really helpful to have. You are in good hands with Anil.

It would be good to include the whole southbound API and not just the tunnel overlay. The tunnel overlay API is still a work in progress. The underlying tasks to create an overlay are implemented so many users are currently using that in the meantime. I think that is actually easier to test since it broken down into smaller, understandable pieces - add bridge, add tunnel port, add flows to make tunnel. The links you mentioned below are the only ones we have right now. It is probably good to look at the ovsdb.yang or the restconf explorer to see the model. We can elaborate on the different steps needed to build a tunnel.

Scalability is also another test that is greatly needed. I don't think we have been updating the docker so not sure if it still works but it shouldn't take much to get it there if it is broken. I would suggest giving it a shot to see.

Question: how does this relate to other work for OpenStack integration? I recall Daniel was working on something related and Patrick was trying to get some multi-node testing setup. I think Daniel also might have done some docker work that we could leverage.

Thanks, Sam

----- Original Message -----
From: "Anil Vishnoi" <vishnoianil@...>
To: "Luis Gomez" <ecelgp@...>
Cc: "<ovsdb-dev@...>" <ovsdb-dev@...>, "Neelima Sharma"
<neelima.sharma@...>
Sent: Friday, May 8, 2015 4:29:26 AM
Subject: Re: [ovsdb-dev] OVSDB SB system test and scalability (if we can)

Thanks Luis, this looks great!


Welcome!! Chaudhry, Neelima , please feel free to ping me whenever you want
to discussion any thing , my irc handle is vishnoianil (or sometime i use
avishnoi).

Luis, About the docker testing, i think these instruction should work, but i
didn't try it personally. Sam/Flavio can probably comment on that.

Thanks
Anil

On Fri, May 8, 2015 at 8:26 AM, Luis Gomez < ecelgp@... > wrote:


Hi OVSDB devs,

Please correct me if I am wrong but it is my understanding the new OVSDB SB
protocol is going to be consumed by several projects in ODL (OpenStack, GBP,
SFC, etc…). So the integration group would like to help creating system test
for the overlay API as well as any other functionality you consider key in
this release. We would like to also include an scalability test for OVS
instances and tunnel creation if time allows.

So if you agree on the above let me introduce you the 2 people will be
helping (starting next week):

- Chaudhry Usama, OpenDaylight summer intern I mentor
- Neelima Sharma, freelance test engineer

I am sure Chaudhry and Neelima will be very welcome in the OVSDB community,
one of the most open and diverse in OpenDaylight :)

And now the basic questions to get started:

1) Information about new API, searching quickly:

- I can see there is already this wiki under construction:
https://wiki.opendaylight.org/view/OVSDB:MDSAL_Southbound
- There is also a POSTMAN collection with supported methods:
https://github.com/opendaylight/ovsdb/blob/master/resources/commons/OVSDB_Southbound.postman_collection
- Some instruction on how to enable the SB feature and considerations:
https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Lithium_Integration_Test
- Am I missing anything?

2) For scalability:

- I remember old OVSDB committers were using docker instances to encapsulate
OVS and therefore saving lot of resources (multiple OVS per host)
- I found this link:
https://wiki.opendaylight.org/view/OVSDB:Testing_with_Docker , do you know
if this is still updated?
- Any scalability/performance advice or concern is also welcome :)

Finally Chaudhry and Neelima have some experience with OVS but they will need
for sure some support with questions and issues when they start testing.
They both are in India so the time for the OVSDB call is not the best but I
will be in their behalf. I have also asked Anil to support them in the time
nobody (including me) is available. Obviously I will be mentoring them in
all that is test/automation as well as with my limited OVS knowledge so I do
not expect them to ask questions all the time to OVSDB devs that I know they
are very busy right now.

And this is all I wanted to say, please let me know if you have questions,
suggestions, or anything.

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 SB system test and scalability (if we can)

Luis Gomez
 

Hi Sam, couple of things:

- Can you refer any documentation or POSTMAN collection for the small OVSDB pieces you mention or there is really nothing (other than code) as you say?

- The OpenStack is a different track Daniel is driving and trying to align with OPNFV goals. That one I am not 100% certain we can get it done this release according to latest Daniel comments in the integration call. However if with your experience with tempest test you think we can easily deploy stable openstack with unstable ODL and make some quick VM transport test, we can also take a look at that now.

BR/Luis

On May 8, 2015, at 10:39 AM, Sam Hague <shague@...> wrote:

Luis,

Welcome Chaudhry and Neelima! Yeah, this is great and something that would be really helpful to have. You are in good hands with Anil.

It would be good to include the whole southbound API and not just the tunnel overlay. The tunnel overlay API is still a work in progress. The underlying tasks to create an overlay are implemented so many users are currently using that in the meantime. I think that is actually easier to test since it broken down into smaller, understandable pieces - add bridge, add tunnel port, add flows to make tunnel. The links you mentioned below are the only ones we have right now. It is probably good to look at the ovsdb.yang or the restconf explorer to see the model. We can elaborate on the different steps needed to build a tunnel.

Scalability is also another test that is greatly needed. I don't think we have been updating the docker so not sure if it still works but it shouldn't take much to get it there if it is broken. I would suggest giving it a shot to see.

Question: how does this relate to other work for OpenStack integration? I recall Daniel was working on something related and Patrick was trying to get some multi-node testing setup. I think Daniel also might have done some docker work that we could leverage.

Thanks, Sam

----- Original Message -----
From: "Anil Vishnoi" <vishnoianil@...>
To: "Luis Gomez" <ecelgp@...>
Cc: "<ovsdb-dev@...>" <ovsdb-dev@...>, "Neelima Sharma"
<neelima.sharma@...>
Sent: Friday, May 8, 2015 4:29:26 AM
Subject: Re: [ovsdb-dev] OVSDB SB system test and scalability (if we can)

Thanks Luis, this looks great!


Welcome!! Chaudhry, Neelima , please feel free to ping me whenever you want
to discussion any thing , my irc handle is vishnoianil (or sometime i use
avishnoi).

Luis, About the docker testing, i think these instruction should work, but i
didn't try it personally. Sam/Flavio can probably comment on that.

Thanks
Anil

On Fri, May 8, 2015 at 8:26 AM, Luis Gomez < ecelgp@... > wrote:


Hi OVSDB devs,

Please correct me if I am wrong but it is my understanding the new OVSDB SB
protocol is going to be consumed by several projects in ODL (OpenStack, GBP,
SFC, etc…). So the integration group would like to help creating system test
for the overlay API as well as any other functionality you consider key in
this release. We would like to also include an scalability test for OVS
instances and tunnel creation if time allows.

So if you agree on the above let me introduce you the 2 people will be
helping (starting next week):

- Chaudhry Usama, OpenDaylight summer intern I mentor
- Neelima Sharma, freelance test engineer

I am sure Chaudhry and Neelima will be very welcome in the OVSDB community,
one of the most open and diverse in OpenDaylight :)

And now the basic questions to get started:

1) Information about new API, searching quickly:

- I can see there is already this wiki under construction:
https://wiki.opendaylight.org/view/OVSDB:MDSAL_Southbound
- There is also a POSTMAN collection with supported methods:
https://github.com/opendaylight/ovsdb/blob/master/resources/commons/OVSDB_Southbound.postman_collection
- Some instruction on how to enable the SB feature and considerations:
https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Lithium_Integration_Test
- Am I missing anything?

2) For scalability:

- I remember old OVSDB committers were using docker instances to encapsulate
OVS and therefore saving lot of resources (multiple OVS per host)
- I found this link:
https://wiki.opendaylight.org/view/OVSDB:Testing_with_Docker , do you know
if this is still updated?
- Any scalability/performance advice or concern is also welcome :)

Finally Chaudhry and Neelima have some experience with OVS but they will need
for sure some support with questions and issues when they start testing.
They both are in India so the time for the OVSDB call is not the best but I
will be in their behalf. I have also asked Anil to support them in the time
nobody (including me) is available. Obviously I will be mentoring them in
all that is test/automation as well as with my limited OVS knowledge so I do
not expect them to ask questions all the time to OVSDB devs that I know they
are very busy right now.

And this is all I wanted to say, please let me know if you have questions,
suggestions, or anything.

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 SB system test and scalability (if we can)

Sam Hague
 

Luis,

Welcome Chaudhry and Neelima! Yeah, this is great and something that would be really helpful to have. You are in good hands with Anil.

It would be good to include the whole southbound API and not just the tunnel overlay. The tunnel overlay API is still a work in progress. The underlying tasks to create an overlay are implemented so many users are currently using that in the meantime. I think that is actually easier to test since it broken down into smaller, understandable pieces - add bridge, add tunnel port, add flows to make tunnel. The links you mentioned below are the only ones we have right now. It is probably good to look at the ovsdb.yang or the restconf explorer to see the model. We can elaborate on the different steps needed to build a tunnel.

Scalability is also another test that is greatly needed. I don't think we have been updating the docker so not sure if it still works but it shouldn't take much to get it there if it is broken. I would suggest giving it a shot to see.

Question: how does this relate to other work for OpenStack integration? I recall Daniel was working on something related and Patrick was trying to get some multi-node testing setup. I think Daniel also might have done some docker work that we could leverage.

Thanks, Sam

----- Original Message -----
From: "Anil Vishnoi" <vishnoianil@...>
To: "Luis Gomez" <ecelgp@...>
Cc: "<ovsdb-dev@...>" <ovsdb-dev@...>, "Neelima Sharma"
<neelima.sharma@...>
Sent: Friday, May 8, 2015 4:29:26 AM
Subject: Re: [ovsdb-dev] OVSDB SB system test and scalability (if we can)

Thanks Luis, this looks great!


Welcome!! Chaudhry, Neelima , please feel free to ping me whenever you want
to discussion any thing , my irc handle is vishnoianil (or sometime i use
avishnoi).

Luis, About the docker testing, i think these instruction should work, but i
didn't try it personally. Sam/Flavio can probably comment on that.

Thanks
Anil

On Fri, May 8, 2015 at 8:26 AM, Luis Gomez < ecelgp@... > wrote:


Hi OVSDB devs,

Please correct me if I am wrong but it is my understanding the new OVSDB SB
protocol is going to be consumed by several projects in ODL (OpenStack, GBP,
SFC, etc…). So the integration group would like to help creating system test
for the overlay API as well as any other functionality you consider key in
this release. We would like to also include an scalability test for OVS
instances and tunnel creation if time allows.

So if you agree on the above let me introduce you the 2 people will be
helping (starting next week):

- Chaudhry Usama, OpenDaylight summer intern I mentor
- Neelima Sharma, freelance test engineer

I am sure Chaudhry and Neelima will be very welcome in the OVSDB community,
one of the most open and diverse in OpenDaylight :)

And now the basic questions to get started:

1) Information about new API, searching quickly:

- I can see there is already this wiki under construction:
https://wiki.opendaylight.org/view/OVSDB:MDSAL_Southbound
- There is also a POSTMAN collection with supported methods:
https://github.com/opendaylight/ovsdb/blob/master/resources/commons/OVSDB_Southbound.postman_collection
- Some instruction on how to enable the SB feature and considerations:
https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Lithium_Integration_Test
- Am I missing anything?

2) For scalability:

- I remember old OVSDB committers were using docker instances to encapsulate
OVS and therefore saving lot of resources (multiple OVS per host)
- I found this link:
https://wiki.opendaylight.org/view/OVSDB:Testing_with_Docker , do you know
if this is still updated?
- Any scalability/performance advice or concern is also welcome :)

Finally Chaudhry and Neelima have some experience with OVS but they will need
for sure some support with questions and issues when they start testing.
They both are in India so the time for the OVSDB call is not the best but I
will be in their behalf. I have also asked Anil to support them in the time
nobody (including me) is available. Obviously I will be mentoring them in
all that is test/automation as well as with my limited OVS knowledge so I do
not expect them to ask questions all the time to OVSDB devs that I know they
are very busy right now.

And this is all I wanted to say, please let me know if you have questions,
suggestions, or anything.

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 SB system test and scalability (if we can)

Anil Vishnoi
 

Thanks Luis, this looks great!


Welcome!! Chaudhry, Neelima , please feel free to ping me whenever you want to discussion any thing , my irc handle is vishnoianil (or sometime i use avishnoi).

Luis, About the docker testing, i think these instruction should work, but i didn't try it personally. Sam/Flavio can probably comment on that.

Thanks
Anil 

On Fri, May 8, 2015 at 8:26 AM, Luis Gomez <ecelgp@...> wrote:
Hi OVSDB devs,

Please correct me if I am wrong but it is my understanding the new OVSDB SB protocol is going to be consumed by several projects in ODL (OpenStack, GBP, SFC, etc…). So the integration group would like to help creating system test for the overlay API as well as any other functionality you consider key in this release. We would like to also include an scalability test for OVS instances and tunnel creation if time allows.

So if you agree on the above let me introduce you the 2 people will be helping (starting next week):

- Chaudhry Usama, OpenDaylight summer intern I mentor
- Neelima Sharma, freelance test engineer

I am sure Chaudhry and Neelima will be very welcome in the OVSDB community, one of the most open and diverse in OpenDaylight :)

And now the basic questions to get started:

1) Information about new API, searching quickly:

- I can see there is already this wiki under construction: https://wiki.opendaylight.org/view/OVSDB:MDSAL_Southbound
- There is also a POSTMAN collection with supported methods: https://github.com/opendaylight/ovsdb/blob/master/resources/commons/OVSDB_Southbound.postman_collection
- Some instruction on how to enable the SB feature and considerations: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Lithium_Integration_Test
- Am I missing anything?

2) For scalability:

- I remember old OVSDB committers were using docker instances to encapsulate OVS and therefore saving lot of resources (multiple OVS per host)
- I found this link: https://wiki.opendaylight.org/view/OVSDB:Testing_with_Docker, do you know if this is still updated?
- Any scalability/performance advice or concern is also welcome :)

Finally Chaudhry and Neelima have some experience with OVS but they will need for sure some support with questions and issues when they start testing. They both are in India so the time for the OVSDB call is not the best but I will be in their behalf. I have also asked Anil to support them in the time nobody (including me) is available. Obviously I will be mentoring them in all that is test/automation as well as with my limited OVS knowledge so I do not expect them to ask questions all the time to OVSDB devs that I know they are very busy right now.

And this is all I wanted to say, please let me know if you have questions, suggestions, or anything.

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



--
Thanks
Anil


OVSDB SB system test and scalability (if we can)

Luis Gomez
 

Hi OVSDB devs,

Please correct me if I am wrong but it is my understanding the new OVSDB SB protocol is going to be consumed by several projects in ODL (OpenStack, GBP, SFC, etc…). So the integration group would like to help creating system test for the overlay API as well as any other functionality you consider key in this release. We would like to also include an scalability test for OVS instances and tunnel creation if time allows.

So if you agree on the above let me introduce you the 2 people will be helping (starting next week):

- Chaudhry Usama, OpenDaylight summer intern I mentor
- Neelima Sharma, freelance test engineer

I am sure Chaudhry and Neelima will be very welcome in the OVSDB community, one of the most open and diverse in OpenDaylight :)

And now the basic questions to get started:

1) Information about new API, searching quickly:

- I can see there is already this wiki under construction: https://wiki.opendaylight.org/view/OVSDB:MDSAL_Southbound
- There is also a POSTMAN collection with supported methods: https://github.com/opendaylight/ovsdb/blob/master/resources/commons/OVSDB_Southbound.postman_collection
- Some instruction on how to enable the SB feature and considerations: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Lithium_Integration_Test
- Am I missing anything?

2) For scalability:

- I remember old OVSDB committers were using docker instances to encapsulate OVS and therefore saving lot of resources (multiple OVS per host)
- I found this link: https://wiki.opendaylight.org/view/OVSDB:Testing_with_Docker, do you know if this is still updated?
- Any scalability/performance advice or concern is also welcome :)

Finally Chaudhry and Neelima have some experience with OVS but they will need for sure some support with questions and issues when they start testing. They both are in India so the time for the OVSDB call is not the best but I will be in their behalf. I have also asked Anil to support them in the time nobody (including me) is available. Obviously I will be mentoring them in all that is test/automation as well as with my limited OVS knowledge so I do not expect them to ask questions all the time to OVSDB devs that I know they are very busy right now.

And this is all I wanted to say, please let me know if you have questions, suggestions, or anything.

BR/Luis


Re: [Need Help] Arbitrary connection port is part of the node-id

Prateek Garg (prategar) <prategar@...>
 

Hi,

I have implemented this change and submitted the same:

Summary of changes:
  1. In case of ptcp connection, save the iid of the ovsdb node in the external ids of the open_vswitch table when ovs connects to controller. This is done in case of ptcp connect only as tcp would be using system-id for iid which is not going to change in case of disconnect and reconnect of the same ovs. 
  2. In OvsdbConnectionInstance the iid for the ovsdb node would be genereated based on external ids of the ovs. If the iid is not present in the external ids the iid would be generated using the system-id (in case of tcp). There is also a fail safe, for the case when both system-id and open daylight-iid is not present in external_ids of open-vswitch which is to use the old way of generating the iid for the ovsdb node.
  3. The iid generated in the step 2 is provided to all required commands in OvsdbOperationalCommandAggregator to make sure the iid for ovsdb node is generated just once and all the commands use what they get and not have to regenerate the iid for the ovsdb node. 
The overall idea is to use the system-id for iid of ovsdb node when system-id is present in external-ids of the open-vswitch when connection in tcp mode. This is because the port changes when ovs reconnects to controller in tcp mode. Further, in all other scenarios the old way would be used.  

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 8:50 PM
To: "Amit Mandke (ammandke)" <ammandke@...>
Cc: Prateek Garg <prategar@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

If we do not receive the initial dump of the DB... we aren't getting anything to work at all... it s a fundamental failure.

And always remember that OVSDB can connect to us unsolicted... so we will always have to deal with ovsdb instances that we *didn't* create the connection for.  This is another reason that the solution I'm advocating for here is good... it works consistently in active and passive mode.

Ed

On Fri, Apr 24, 2015 at 7:08 PM, Amit Mandke (ammandke) <ammandke@...> wrote:
Isn’t that tricky for a person who is trying to connect ovs to controller? Its like you may or may not see the node in operations based whether or not it succeeds or fails to update.However the ovs would show conencted=true and manager ip, with no data in operations.  :-)

IMO connection received is exclusive event for creating ovsdb node and then registering for callbacks for update. Current implementation seems more logical(to me) than changing it for 1 case of IID creation. 

My further 2 cents on iid serialization/deserialization:

In general, IMO  this IID serialization and deserialization is a risk. And should be avoided if possible.  If a system is running for long period of time and for some reason someone connected disconnected same ovs nodes with diff setting once with IID passed to it once without. Your config would be looking very out of synch of your operations. On top of that if the apps that are trying to use this data programmatically would most likely fail to take care of such situations. 

Also different apps may choose different strategies to generate iids and would be impossible for them to coexist.

So having  only one way of creating IIDs would help in longer run. If one wants avoid iid  generation while connecting to OVS or creating bridges then we can always expose RPCs for that. However, if one wants to use CONFIG store to configure, then they have to build appropriate iid.

Thoughts?

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 2:09 PM
To: Amit Mandke <ammandke@...>
Cc: "Prateek Garg (prategar)" <prategar@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Not so tricky... we either get that dump or we are borked...

Ed

On Fri, Apr 24, 2015 at 2:07 PM, Amit Mandke (ammandke) <ammandke@...> wrote:
It sounds tricky, cause once you register for callbacks you can’t be sure of the sequence of all the updates right? Or even guaranty if each update would be processed?

So essentially you are letting go a sure-shot event where you received the connection to store the OVSDB node and relying on the future updates to create it.

I am not sure if that is the best thing to do.

-Amit


From: Edward Warnicke <hagbard@...>
Date: Friday, April 24, 2015 at 11:07 AM
To: "Prateek Garg (prategar)" <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

I had an idea last night as I was falling asleep that might be interesting.

How about we create the ovsdb-node in operational with the OpenVSwitchUpdateCommand (which should get tripped with the original dump of data from ovsdb on connect) rather than invoking OvsdbNodeCreatedCommand in the OvsdbConnectionInstance() constructor.  That way you have access to the info you need, don't have to do a select (and thus a new round trip) etc.

Thoughts?

Ed

On Wed, Apr 22, 2015 at 3:40 PM, Prateek Garg (prategar) <prategar@...> wrote:
This can be done in OvsdbNodeCreateCommand. The issue I see there is changing the signature of the OvsdbNodeCreateCommand’s constructor.
Let me know if its ok to change the signature and pass OvsdbClient.
However, I believe still we would need to run a select statement to get the system-id in OvsdbNodeCreateCommand.

Please let me know your thoughts.

Thanks
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 3:26 PM

To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

And why change ConnectionInfo (that really really is info about the ip and port...)

Ed

On Wed, Apr 22, 2015 at 3:25 PM, Edward Warnicke <hagbard@...> wrote:
Prateek,

Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?

Ed

On Wed, Apr 22, 2015 at 3:22 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi Ed,

The way I am implementing this is:

In OvsdbConnectionManager’s connected method, I’ll set system-Id from external_ids of open_Vswitch table in ConnectionInfo key (I’ll modify yang to add systemId field in connectionInfo to add system-id). Therefore to get the system-id in OvsdbConnectionManager’s connected method, I need to execute select operation on open_Vswitch table. 
So later when OvsdbNodeCreateCommand is called with ConnectionInfo, I’ll have the systemId to write to operation store.

Please let me know your thoughts on this approach.

Regards
Prateek

From: Edward Warnicke <hagbard@...>
Date: Wednesday, April 22, 2015 at 2:58 PM
To: Prateek Garg <prategar@...>
Cc: "ovsdb-dev@..." <ovsdb-dev@...>, "ffernand@..." <ffernand@...>
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id

Prateek,

Why are you doing a select? (curious) :)

Ed

On Wed, Apr 22, 2015 at 2:54 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

While implementing this use case I need some help using the select operation of ovsdb library. I am trying to read the Open_vSwitch table to get the data in external-ids. I am doing the following:

OpenVSwitch ovs = TyperUtils.getTypedRowWrapper(dbSchema, OpenVSwitch.class);

                transaction.add(op.select(ovs.getSchema()));

                ListenableFuture<List<OperationResult>> results = transaction.execute();

List<OperationResult> resultList = results.get();


I am getting resultList as:

[OperationResult [count=0, uuid=null, rows=[Row [columns={}]], error=null, details=null]]

Query sent to Ovs db is:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":[],"where": []}]'


However, I want to send:

ovsdb-client transact '["Open_vSwitch",{"op":"select", "table":"Open_vSwitch", "columns":["external_ids"],"where": []}]'


It would be very helpful if someone could provide pointers on how to set column in select operation.


Regards

Prateek


From: Edward Warnicke <hagbard@...>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...>
Cc: "ffernand@..." <ffernand@...>, "ovsdb-dev@..." <ovsdb-dev@...>

Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id

The config/operational synch is best handled a little differently.

When you try to config an ovsdb-node to connect... you don't *really* know the systemid... just the IP:port.

The way we solved this for bridges, and the way I'd advocate solving it here is:

1)  If you are configing a ovsdb-node, write its iid to the external-ids of the openvswitch table
2)  When you get an openvswitch table, if it has an iid in its external-ids, use that in the operational data store as its iid
3)  If you don't get an iid in its external-ids... use some reasonable heuristic to contruct one.

For #3... I don't currently see a reason *not* to use systemid presuming its guaranteed unique and we contruct some kind of reasonable
Uri from it.

Ed

On Tue, Apr 21, 2015 at 1:09 PM, Prateek Garg (prategar) <prategar@...> wrote:
Hi,

In my opinion, the we can replace the node-id of the ovsdb node in md-sal to contain system_id from external properties. This would make sure that the config and operation store are in synch in case the controller reconnects to the same ovs in tcp mode.
I’ll make these changes, update postman collection and submit for approval. 

Regards
Prateek

----------------------------------------------------------------------
Date: Mon, 20 Apr 2015 21:28:28 -0700
From: Edward Warnicke <hagbard@...>
To: Flavio Fernandes <ffernand@...>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
Content-Type: text/plain; charset="utf-8"

Make sure we build in the same mechanism of storing iids in external_ids
that we use for bridges so that if someone configures a connection as an
ovsdb-node, it comes *back* in operational store with the same iid...

Ed

On Mon, Apr 20, 2015 at 8:12 PM, Flavio Fernandes <ffernand@...>
wrote:


> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>
> Hi,
> A further investigation by Amit has revealed that the system uuid is
automatically set by the OVS so we can use it out of the box to identify an
OVS instance. To see the external ID you can invoke the following cli:
>
> ovs-vsctl --columns=external-ids list open_vswitch
>
> looks like a win/win situation to me...:o)
>

ok!

? flavio



> Thanks,
>          Sharon.
> ________________________________________
ovsdb-dev-bounces@...] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
> In that case you are kind of "gambling" that two of your dockers won't
choose the same arbitrary port...:o)
> In any case, we can't have the ID of an element arbitrary change all the
time...As a quick and dirty fix, i would drop the port (and the "behind a
NAT" scenario) so ovsdb id's would be predictable and not change per
connection (it can even change in run-time if there was some network
connectivity issue)...
>
> A more suitable solution is probably generating and assigning a uuid to
each of the managed instances, if one does not exist...a quick googling i
found the following cli method:
>
> ovs-vsctl set open_vswitch . external-ids:system-id='"${UUID}"'
>
>
> Thanks,
>         Sharon.
> ________________________________________
> From: Flavio Fernandes [ffernand@...]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id
>
>> On Apr 20, 2015, at 3:24 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>
>> Hi,
>> Sorry, but does't a docker has a unique ip?
>
> yes and no. ;) I?m used to see docker behind nat on the vm that hosts
the containers. Then, from
> 'outside' the vm, various ovs instances reached using the same ip, but
different ports. Like this:
>
>        docker run -p 16640:6640 blablabla
>        docker run -p 16641:6640 blablabla
>        docker run -p 16642:6640 blablabla
>        ?
>
> ? flavio
>
>
>
>> ________________________________________
>> From: Flavio Fernandes [ffernand@...]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
>>
>>> On Apr 16, 2015, at 6:53 PM, Sharon Aicler (saichler) <
saichler@...> wrote:
>>>
>>> Hi all,
>>> The node-id of an ovs bridge contains the arbitrary port of the
outgoing connection instance and looks something like the following:
>>>
>>> This creates an issue if i place something in the configuration store
and the connection goes down due to some reason, the node-id will change
each time the connection is lost or I restart ODL/OVSDB.
>>> Any reason for this? can't we just use the ip? i don't think you can
run two instances of OVS in the same VM?
>>>
>>
>> Hi Sharon,
>>
>> That is not true. I?ve seen a VM with many OVS instances running;
mostly in a docker environment.
>>
>> But I see your point. When OVS is connecting to ODL (i.e. active
method) the port is not predictable. When ODL connects to
>> an OVS (passive mode), ODL will need to know that port, tho; so the
solution to this problem should ideally work on both
>> scenarios.
>>
>> ? flavio
>>
>>
>>
>>>
>>> Thanks,
>>>        Sharon.
>>> _______________________________________________
>>> ovsdb-dev mailing list
> _______________________________________________
> ovsdb-dev mailing list

_______________________________________________
ovsdb-dev mailing list

-------------- next part --------------
An HTML attachment was scrubbed...








Re: bridge-other-configs not configured on OVS Bridge

Sam Hague
 

Andrej,

it is possibly a bug. Can you file a bugzilla for the ovsdb product and plugin component?

Thanks, Sam

----- Original Message -----
From: "Andrej Kincel -X (akincel - Pantheon Technologies SRO at Cisco)" <akincel@...>
To: ovsdb-dev@...
Sent: Monday, May 4, 2015 8:32:44 AM
Subject: [ovsdb-dev] bridge-other-configs not configured on OVS Bridge



Hello guys,



I’m having trouble setting up ‘bridge-other-configs’ on OVS Bridge. Pushing
values into network-topology configuration data store does not setup them on
target OVS Bridge (‘ovs-vsctl get Bridge br1 other_config’ returns empty
object).



The reverse direction is working, in other words, if I configure OVS Bridge
other config manually (ovs-vsctl set Bridge br1
other_config={"local_ip"="192.168.1.1"}) it will get to network-topology
operational data store.



I assume that this functionality was not implemented yet, are there any plans
for it?



Thanks,

Andrej



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


bridge-other-configs not configured on OVS Bridge

Andrej Kincel -X (akincel - Pantheon Technologies SRO@Cisco) <akincel@...>
 

Hello guys,

 

I’m having trouble setting up ‘bridge-other-configs’ on OVS Bridge. Pushing values into network-topology configuration data store does not setup them on target OVS Bridge (‘ovs-vsctl get Bridge br1 other_config’ returns empty object).

 

The reverse direction is working, in other words, if I configure OVS Bridge other config manually (ovs-vsctl set Bridge br1 other_config={"local_ip"="192.168.1.1"}) it will get to network-topology operational data store.

 

I assume that this functionality was not implemented yet, are there any plans for it?

 

Thanks,

Andrej

 


Re: Bugzilla for Southbound

Thomas Bachman
 

Thanks Sam -- I'd previously filed the bugs against "Other", so I just switched them to plugin.

cheers,

-Thomas



On Sun, May 3, 2015 at 3:58 PM, Sam Hague <shague@...> wrote:
Thomas,

I filed a case with the helpdesk to get access.

Until then use the plugin component and I can move them to southbound when that is created.

Thanks ,Sam

----- Original Message -----
> From: "Thomas Bachman" <bachman@...>
> To: ovsdb-dev@...
> Sent: Sunday, May 3, 2015 12:20:05 PM
> Subject: [ovsdb-dev] Bugzilla for Southbound
>
> Hi folks,
>
> I was wondering if someone could create a "southbound" component in OVSDB
> bugzilla (iirc, you have to be a committer to create new components -- and I
> am not). I've been testing this out, and thought it would be helpful to have
> a separate component for the southbound.
>
> cheers,
>
> -Thomas
>
>
> _______________________________________________
> ovsdb-dev mailing list
> ovsdb-dev@...
> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>


Re: Bugzilla for Southbound

Sam Hague
 

Thomas,

I filed a case with the helpdesk to get access.

Until then use the plugin component and I can move them to southbound when that is created.

Thanks ,Sam

----- Original Message -----
From: "Thomas Bachman" <bachman@...>
To: ovsdb-dev@...
Sent: Sunday, May 3, 2015 12:20:05 PM
Subject: [ovsdb-dev] Bugzilla for Southbound

Hi folks,

I was wondering if someone could create a "southbound" component in OVSDB
bugzilla (iirc, you have to be a committer to create new components -- and I
am not). I've been testing this out, and thought it would be helpful to have
a separate component for the southbound.

cheers,

-Thomas


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


Bugzilla for Southbound

Thomas Bachman
 

Hi folks,

I was wondering if someone could create a "southbound" component in OVSDB bugzilla (iirc, you have to be a committer to create new components -- and I am not). I've been testing this out, and thought it would be helpful to have a separate component for the southbound.

cheers,

-Thomas


Southbound defect: Ovsdb bridge creation doesn't work in given case

Amit Mandke (ammandke) <ammandke@...>
 

Hi,

If I create a bridge in config store, with a node id that doesn’t follow the strategy of iid that is followed by default, then the bridge doesn’t appear back in operational store. It does get created on OVS switch though. It is very easily reproducible.

I couldn’t find a solution to this problem, hence posting it to mailer. Has anyone come across this problem? Please provide any pointers if possible. 

Bridge URL: (to post / create bridge)

Bridge Post Data:
{
  "network-topology:node": [
        {
            "node-id": "ovsdb:testbr",
             "ovsdb:bridge-name": "testbr",
             "ovsdb:protocol-entry": [
                {
                  "protocol": "ovsdb:ovsdb-bridge-protocol-openflow-13"
                }
              ],
              "ovsdb:controller-entry": [
                {
                  "target": "tcp:171.69.75.42:6653"
                }
              ],
             "ovsdb:managed-by": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://171.69.75.42:57954']"
        }
    ]
}

I get following exception:

2015-04-30 14:01:34,768 | ERROR | lt-dispatcher-34 | InMemoryDataTreeModification     | 75 - org.opendaylight.yangtools.yang-data-impl - 0.7.0.SNAPSHOT | Could not create snapshot for /(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology/topology/topology[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology-id=ovsdb:1}]/node:NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node, modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb:testbr}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb:testbr}], modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id, modificationType=MERGE, childModification={}], AugmentationIdentifier{childNames=[(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-by, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-id, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-uuid, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-other-configs, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-type, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)fail-mode, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)flow-node, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)controller-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-ids, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-name, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-openflow-node-ref]}=NodeModification [identifier=AugmentationIdentifier{childNames=[(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-by, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-id, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-uuid, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-other-configs, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-type, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)fail-mode, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)flow-node, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)controller-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-ids, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-name, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-openflow-node-ref]}, modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)controller-entry=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)controller-entry, modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)controller-entry[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)target=tcp:171.69.75.42:6653}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)controller-entry[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)target=tcp:171.69.75.42:6653}], modificationType=WRITE, childModification={}]}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-name=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-name, modificationType=MERGE, childModification={}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-type=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-type, modificationType=MERGE, childModification={}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-by=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-by, modificationType=MERGE, childModification={}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol-entry=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol-entry, modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol-entry[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)ovsdb-bridge-protocol-openflow-13}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol-entry[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)ovsdb-bridge-protocol-openflow-13}], modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)protocol, modificationType=MERGE, childModification={}]}]}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-ids=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-ids, modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-ids[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-id-key=opendaylight-iid}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-ids[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-id-key=opendaylight-iid}], modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-id-value=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-id-value, modificationType=MERGE, childModification={}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-id-key=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-external-id-key, modificationType=MERGE, childModification={}]}]}], (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-uuid=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-uuid, modificationType=MERGE, childModification={}]}]}], (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954/bridge/testbr}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954/bridge/testbr}], modificationType=TOUCH, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point, modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}], modificationType=WRITE, childModification={}]}]}], (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954}], modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id, modificationType=MERGE, childModification={}], AugmentationIdentifier{childNames=[(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)db-version, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-node-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)interface-type-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)ovs-version, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)openvswitch-external-ids, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)connection-info, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)openvswitch-other-configs, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-type-entry]}=NodeModification [identifier=AugmentationIdentifier{childNames=[(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)db-version, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-node-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)interface-type-entry, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)ovs-version, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)openvswitch-external-ids, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)connection-info, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)openvswitch-other-configs, (urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)datapath-type-entry]}, modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-node-entry=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-node-entry, modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-node-entry[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-ref=/(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology/topology/topology[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology-id=ovsdb:1}]/node/node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb:testbr}]}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)managed-node-entry[{(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-ref=/(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology/topology/topology[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology-id=ovsdb:1}]/node/node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb:testbr}]}], modificationType=MERGE, childModification={(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-ref=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:ovsdb?revision=2015-01-05)bridge-ref, modificationType=MERGE, childModification={}]}]}]}]}]}]

java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954/bridge/testbr}], modificationType=TOUCH, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point, modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}], modificationType=WRITE, childModification={}]}]}]

at com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)[51:com.google.guava:18.0.0]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.apply(SchemaAwareApplyOperation.java:195)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.mutateChildren(AbstractNodeContainerModificationStrategy.java:113)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.applyTouch(AbstractNodeContainerModificationStrategy.java:155)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.applyMerge(AbstractNodeContainerModificationStrategy.java:132)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.apply(SchemaAwareApplyOperation.java:204)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModification.resolveSnapshot(InMemoryDataTreeModification.java:111)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModification.readNode(InMemoryDataTreeModification.java:95)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.controller.cluster.datastore.ShardTransaction.readData(ShardTransaction.java:131)[169:org.opendaylight.controller.sal-distributed-datastore:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.datastore.ShardWriteTransaction.readData(ShardWriteTransaction.java:128)[169:org.opendaylight.controller.sal-distributed-datastore:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.datastore.ShardReadWriteTransaction.handleReceive(ShardReadWriteTransaction.java:31)[169:org.opendaylight.controller.sal-distributed-datastore:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:34)[161:org.opendaylight.controller.sal-clustering-commons:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.common.actor.MeteringBehavior.apply(MeteringBehavior.java:97)[161:org.opendaylight.controller.sal-clustering-commons:1.2.0.SNAPSHOT]

at akka.actor.ActorCell$$anonfun$become$1.applyOrElse(ActorCell.scala:534)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.Actor$class.aroundReceive(Actor.scala:465)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.ActorCell.invoke(ActorCell.scala:487)[154:com.typesafe.akka.actor:2.3.9]

at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254)[154:com.typesafe.akka.actor:2.3.9]

at akka.dispatch.Mailbox.run(Mailbox.scala:221)[154:com.typesafe.akka.actor:2.3.9]

at akka.dispatch.Mailbox.exec(Mailbox.scala:231)[154:com.typesafe.akka.actor:2.3.9]

at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.pollAndExecAll(ForkJoinPool.java:1253)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1346)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

2015-04-30 14:01:34,775 | ERROR | lt-dispatcher-34 | OneForOneStrategy                | 155 - com.typesafe.akka.slf4j - 2.3.9 | Metadata not available for modification NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954/bridge/testbr}], modificationType=TOUCH, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point, modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}], modificationType=WRITE, childModification={}]}]}]

java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node-id=ovsdb://171.69.75.42:57954/bridge/testbr}], modificationType=TOUCH, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point, modificationType=MERGE, childModification={(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}]=NodeModification [identifier=(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)termination-point[{(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)tp-id=testbr}], modificationType=WRITE, childModification={}]}]}]

at com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)[51:com.google.guava:18.0.0]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.apply(SchemaAwareApplyOperation.java:195)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.mutateChildren(AbstractNodeContainerModificationStrategy.java:113)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.applyTouch(AbstractNodeContainerModificationStrategy.java:155)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.applyMerge(AbstractNodeContainerModificationStrategy.java:132)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.apply(SchemaAwareApplyOperation.java:204)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModification.resolveSnapshot(InMemoryDataTreeModification.java:111)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.yangtools.yang.data.impl.schema.tree.InMemoryDataTreeModification.readNode(InMemoryDataTreeModification.java:95)[75:org.opendaylight.yangtools.yang-data-impl:0.7.0.SNAPSHOT]

at org.opendaylight.controller.cluster.datastore.ShardTransaction.readData(ShardTransaction.java:131)[169:org.opendaylight.controller.sal-distributed-datastore:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.datastore.ShardWriteTransaction.readData(ShardWriteTransaction.java:128)[169:org.opendaylight.controller.sal-distributed-datastore:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.datastore.ShardReadWriteTransaction.handleReceive(ShardReadWriteTransaction.java:31)[169:org.opendaylight.controller.sal-distributed-datastore:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:34)[161:org.opendaylight.controller.sal-clustering-commons:1.2.0.SNAPSHOT]

at org.opendaylight.controller.cluster.common.actor.MeteringBehavior.apply(MeteringBehavior.java:97)[161:org.opendaylight.controller.sal-clustering-commons:1.2.0.SNAPSHOT]

at akka.actor.ActorCell$$anonfun$become$1.applyOrElse(ActorCell.scala:534)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.Actor$class.aroundReceive(Actor.scala:465)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)[154:com.typesafe.akka.actor:2.3.9]

at akka.actor.ActorCell.invoke(ActorCell.scala:487)[154:com.typesafe.akka.actor:2.3.9]

at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254)[154:com.typesafe.akka.actor:2.3.9]

at akka.dispatch.Mailbox.run(Mailbox.scala:221)[154:com.typesafe.akka.actor:2.3.9]

at akka.dispatch.Mailbox.exec(Mailbox.scala:231)[154:com.typesafe.akka.actor:2.3.9]

at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.pollAndExecAll(ForkJoinPool.java:1253)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1346)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b]

at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[151:org.scala-lang.scala-library:2.10.4.v20140209-180020-VFINAL-b66a39653b] 

-Amit


Re: Nominate Anil Vishnoi as OVSDB committer

abhishek jain <ashujain9727@...>
 

+1

On Apr 30, 2015 1:54 AM, "Kyle Mestery" <mestery@...> wrote:
+1

On Wed, Apr 29, 2015 at 1:52 PM, Sam Hague <shague@...> wrote:
I would like to nominate Anil Vishnoi as committer to the OVSDB project. Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

Thanks, Sam


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


Re: Nominate Anil Vishnoi as OVSDB committer

Kyle Mestery <mestery@...>
 

+1

On Wed, Apr 29, 2015 at 1:52 PM, Sam Hague <shague@...> wrote:
I would like to nominate Anil Vishnoi as committer to the OVSDB project. Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

Thanks, Sam


Re: Nominate Anil Vishnoi as OVSDB committer

Mishra, Sharad D <sharad.d.mishra@...>
 

+1

Regards,
Sharad Mishra

-----Original Message-----
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of Dave Tucker
Sent: Wednesday, April 29, 2015 12:05 PM
To: Sam Hague
Cc: Ashwin Raveendran; ovsdb-dev; evan zeller; Giovanni Meo; evanrzeller@...
Subject: Re: [ovsdb-dev] Nominate Anil Vishnoi as OVSDB committer

+1

On 29 Apr 2015, at 19:55, Sam Hague wrote:

+1 from Sam Hague

----- Original Message -----
From: "Flavio Fernandes" <ffernand@...>
To: "Sam Hague" <shague@...>
Cc: "ovsdb-dev" <ovsdb-dev@...>, "Madhu Venugopal"
<mavenugo@...>, "Dave Tucker"
<dave@...>, "Brent Salisbury" <brent.salisbury@...>,
"Ashwin Raveendran" <aswinnair@...>, "Giovanni Meo"
<gmeo@...>, "Kyle Mestery"
<mestery@...>, "evan zeller" <evan.zeller@...>,
evanrzeller@...
Sent: Wednesday, April 29, 2015 2:53:04 PM
Subject: Re: Nominate Anil Vishnoi as OVSDB committer

+1 from flaviof on having Anil aboard!

— flavio


On Apr 29, 2015, at 2:52 PM, Sam Hague <shague@...> wrote:

I would like to nominate Anil Vishnoi as committer to the OVSDB
project.
Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the
code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

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


Re: Nominate Anil Vishnoi as OVSDB committer

Evan Zeller <evanrzeller@...>
 

+1

On Wed, Apr 29, 2015 at 12:04 PM, Gabriel Robitaille-Montpetit <grmontpetit@...> wrote:
+1

On Wed, Apr 29, 2015 at 2:52 PM, Sam Hague <shague@...> wrote:
I would like to nominate Anil Vishnoi as committer to the OVSDB project. Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

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



Re: Nominate Anil Vishnoi as OVSDB committer

Dave Tucker <dave@...>
 

+1

On 29 Apr 2015, at 19:55, Sam Hague wrote:

+1 from Sam Hague

----- Original Message -----
From: "Flavio Fernandes" <ffernand@...>
To: "Sam Hague" <shague@...>
Cc: "ovsdb-dev" <ovsdb-dev@...>, "Madhu Venugopal" <mavenugo@...>, "Dave Tucker"
<dave@...>, "Brent Salisbury" <brent.salisbury@...>, "Ashwin Raveendran" <aswinnair@...>,
"Giovanni Meo" <gmeo@...>, "Kyle Mestery" <mestery@...>, "evan zeller" <evan.zeller@...>,
evanrzeller@...
Sent: Wednesday, April 29, 2015 2:53:04 PM
Subject: Re: Nominate Anil Vishnoi as OVSDB committer

+1 from flaviof on having Anil aboard!

— flavio


On Apr 29, 2015, at 2:52 PM, Sam Hague <shague@...> wrote:

I would like to nominate Anil Vishnoi as committer to the OVSDB project.
Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in
OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

Thanks, Sam


Re: Nominate Anil Vishnoi as OVSDB committer

Gabriel Robitaille-Montpetit <grmontpetit@...>
 

+1

On Wed, Apr 29, 2015 at 2:52 PM, Sam Hague <shague@...> wrote:
I would like to nominate Anil Vishnoi as committer to the OVSDB project. Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

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


Re: Nominate Anil Vishnoi as OVSDB committer

Sam Hague
 

+1 from Sam Hague

----- Original Message -----
From: "Flavio Fernandes" <ffernand@...>
To: "Sam Hague" <shague@...>
Cc: "ovsdb-dev" <ovsdb-dev@...>, "Madhu Venugopal" <mavenugo@...>, "Dave Tucker"
<dave@...>, "Brent Salisbury" <brent.salisbury@...>, "Ashwin Raveendran" <aswinnair@...>,
"Giovanni Meo" <gmeo@...>, "Kyle Mestery" <mestery@...>, "evan zeller" <evan.zeller@...>,
evanrzeller@...
Sent: Wednesday, April 29, 2015 2:53:04 PM
Subject: Re: Nominate Anil Vishnoi as OVSDB committer

+1 from flaviof on having Anil aboard!

— flavio


On Apr 29, 2015, at 2:52 PM, Sam Hague <shague@...> wrote:

I would like to nominate Anil Vishnoi as committer to the OVSDB project.
Current committers, please respond with a vote for the nomination.

Anil has been working on all the areas in the OVSDB project:
- worked on the adsal deprecation that required learning all the code in
OVSDB
- added an adsal compatibility layer for the plugin
- added different parts of the southbound
- working on migrating netvirt to the southbound

Thanks, Sam

3361 - 3380 of 4855