|
Prateek Garg (prategar) <prategar@...>
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
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
toggle quoted message
Show quoted text
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
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) <
>
> 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.
> ________________________________________
(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.
> ________________________________________
> 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) <
>>
>> 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
>
>
>
>> ________________________________________
>> 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) <
>>>
>>> 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...
|
|
Edward Warnicke <hagbard@...>
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
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
|
|
I'm guessing we need the uuid of the OVS to start and create the Operational State. ________________________________________ From: ovsdb-dev-bounces@... [ovsdb-dev-bounces@...] on behalf of Edward Warnicke [hagbard@...] Sent: Wednesday, April 22, 2015 2:58 PM To: Prateek Garg (prategar) Cc: ovsdb-dev@... 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@...<mailto: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@...<mailto:hagbard@...>> Date: Tuesday, April 21, 2015 at 1:18 PM To: Prateek Garg <prategar@...<mailto:prategar@...>> Cc: "ffernand@...<mailto:ffernand@...>" <ffernand@...<mailto:ffernand@...>>, "ovsdb-dev@...<mailto:ovsdb-dev@...>" <ovsdb-dev@...<mailto: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@...<mailto: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@...<mailto:hagbard@...>> To: Flavio Fernandes <ffernand@...<mailto:ffernand@...>> Cc: "ovsdb-dev@...<mailto:ovsdb-dev@...>" <ovsdb-dev@...<mailto:ovsdb-dev@...>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id Message-ID: <CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...<mailto:CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...>> 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@...<mailto:ffernand@...>> wrote: On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) < saichler@...<mailto: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.
________________________________________
From: ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...> [ ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...>] on behalf of Sharon Aicler (saichler) Sent: Monday, April 20, 2015 3:41 PM
To: Flavio Fernandes
Cc: ovsdb-dev@...<mailto:ovsdb-dev@...>
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@...<mailto:ffernand@...>]
Sent: Monday, April 20, 2015 1:25 PM
To: Sharon Aicler (saichler)
Cc: ovsdb-dev@...<mailto:ovsdb-dev@...>
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@...<mailto: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@...<mailto:ffernand@...>]
Sent: Friday, April 17, 2015 4:23 AM
To: Sharon Aicler (saichler)
Cc: ovsdb-dev@...<mailto:ovsdb-dev@...>
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@...<mailto: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: ovsdb://10.156.48.239:39490/bridge/br-ex<http://10.156.48.239:39490/bridge/br-ex>
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@...<mailto:ovsdb-dev@...>
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...<mailto:ovsdb-dev@...>
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@...<mailto:ovsdb-dev@...> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150420/0ac78b3d/attachment-0001.html>
|
|
Edward Warnicke <hagbard@...>
Sharon,
That UUID should already be there with whatever OpenVSwitch object we have... no need to ask for it again...
Ed
On Wed, Apr 22, 2015 at 3:00 PM, Sharon Aicler (saichler) <saichler@...> wrote: I'm guessing we need the uuid of the OVS to start and create the Operational State.
________________________________________
From: ovsdb-dev-bounces@... [ovsdb-dev-bounces@...] on behalf of Edward Warnicke [hagbard@...]
Sent: Wednesday, April 22, 2015 2:58 PM
To: Prateek Garg (prategar)
Cc: ovsdb-dev@...
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@...<mailto: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@...<mailto:hagbard@...>>
Date: Tuesday, April 21, 2015 at 1:18 PM
To: Prateek Garg <prategar@...<mailto:prategar@...>>
Cc: "ffernand@...<mailto:ffernand@...>" <ffernand@...<mailto:ffernand@...>>, "ovsdb-dev@...<mailto:ovsdb-dev@...>" <ovsdb-dev@...<mailto: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@...<mailto: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@...<mailto:hagbard@...>>
To: Flavio Fernandes <ffernand@...<mailto:ffernand@...>>
Cc: "ovsdb-dev@...<mailto:ovsdb-dev@...>"
<ovsdb-dev@...<mailto:ovsdb-dev@...>>
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
<CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...<mailto:CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...>>
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@...<mailto:ffernand@...>>
wrote:
> On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) <
saichler@...<mailto: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.
> ________________________________________
> From: ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...> [
ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...>] on behalf of Sharon Aicler
(saichler)
> Sent: Monday, April 20, 2015 3:41 PM
> To: Flavio Fernandes
> Cc: ovsdb-dev@...<mailto:ovsdb-dev@...>
> 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@...<mailto:ffernand@...>]
> Sent: Monday, April 20, 2015 1:25 PM
> To: Sharon Aicler (saichler)
> Cc: ovsdb-dev@...<mailto:ovsdb-dev@...>
> 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@...<mailto: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@...<mailto:ffernand@...>]
>> Sent: Friday, April 17, 2015 4:23 AM
>> To: Sharon Aicler (saichler)
>> Cc: ovsdb-dev@...<mailto:ovsdb-dev@...>
>> 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@...<mailto: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:
>>> ovsdb://10.156.48.239:39490/bridge/br-ex<http://10.156.48.239:39490/bridge/br-ex>
>>>
>>> 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@...<mailto:ovsdb-dev@...>
>>> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
> _______________________________________________
> ovsdb-dev mailing list
> ovsdb-dev@...<mailto:ovsdb-dev@...>
> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...<mailto:ovsdb-dev@...>
|
|
Hi Ed, I do not know the protocol, does the OVSDB send all the data to the manager once you set the manager in the OVS? @ what point do we create the ovsdb id for the model? ________________________________________ From: Edward Warnicke [hagbard@...] Sent: Wednesday, April 22, 2015 3:06 PM To: Sharon Aicler (saichler) Cc: Prateek Garg (prategar); ovsdb-dev@... Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id Sharon, That UUID should already be there with whatever OpenVSwitch object we have... no need to ask for it again... Ed On Wed, Apr 22, 2015 at 3:00 PM, Sharon Aicler (saichler) <saichler@...<mailto:saichler@...>> wrote: I'm guessing we need the uuid of the OVS to start and create the Operational State. ________________________________________ From: ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...> [ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...>] on behalf of Edward Warnicke [hagbard@...<mailto:hagbard@...>] Sent: Wednesday, April 22, 2015 2:58 PM To: Prateek Garg (prategar) Cc: ovsdb-dev@...<mailto:ovsdb-dev@...> 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@...<mailto:prategar@...><mailto:prategar@...<mailto: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@...<mailto:hagbard@...><mailto:hagbard@...<mailto:hagbard@...>>> Date: Tuesday, April 21, 2015 at 1:18 PM To: Prateek Garg <prategar@...<mailto:prategar@...><mailto:prategar@...<mailto:prategar@...>>> Cc: "ffernand@...<mailto:ffernand@...><mailto:ffernand@...<mailto:ffernand@...>>" <ffernand@...<mailto:ffernand@...><mailto:ffernand@...<mailto:ffernand@...>>>, "ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>" <ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto: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@...<mailto:prategar@...><mailto:prategar@...<mailto: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@...<mailto:hagbard@...><mailto:hagbard@...<mailto:hagbard@...>>> To: Flavio Fernandes <ffernand@...<mailto:ffernand@...><mailto:ffernand@...<mailto:ffernand@...>>> Cc: "ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>" <ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the node-id Message-ID: <CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...<mailto:CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...><mailto:CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...<mailto:CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@...>>> 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@...<mailto:ffernand@...><mailto:ffernand@...<mailto:ffernand@...>>> wrote: On Apr 20, 2015, at 7:12 PM, Sharon Aicler (saichler) < saichler@...<mailto:saichler@...><mailto:saichler@...<mailto: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.
________________________________________
From: ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...><mailto:ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...>> [ ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...><mailto:ovsdb-dev-bounces@...<mailto:ovsdb-dev-bounces@...>>] on behalf of Sharon Aicler (saichler) Sent: Monday, April 20, 2015 3:41 PM
To: Flavio Fernandes
Cc: ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>
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@...<mailto:ffernand@...><mailto:ffernand@...<mailto:ffernand@...>>]
Sent: Monday, April 20, 2015 1:25 PM
To: Sharon Aicler (saichler)
Cc: ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>
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@...<mailto:saichler@...><mailto:saichler@...<mailto: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@...<mailto:ffernand@...><mailto:ffernand@...<mailto:ffernand@...>>]
Sent: Friday, April 17, 2015 4:23 AM
To: Sharon Aicler (saichler)
Cc: ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>
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@...<mailto:saichler@...><mailto:saichler@...<mailto: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: ovsdb://10.156.48.239:39490/bridge/br-ex<http://10.156.48.239:39490/bridge/br-ex><http://10.156.48.239:39490/bridge/br-ex>
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@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>>
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
_______________________________________________ ovsdb-dev mailing list ovsdb-dev@...<mailto:ovsdb-dev@...><mailto:ovsdb-dev@...<mailto:ovsdb-dev@...>> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150420/0ac78b3d/attachment-0001.html>
|
|
Prateek Garg (prategar) <prategar@...>
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
Prateek,
Why are you doing a select? (curious) :)
Ed
toggle quoted message
Show quoted text
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
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
|
|
Edward Warnicke <hagbard@...>
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
Prateek,
Why are you doing a select? (curious) :)
Ed
|
|
Edward Warnicke <hagbard@...>
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
|
|
Prateek Garg (prategar) <prategar@...>
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
And why change ConnectionInfo (that really really is info about the ip and port...)
Ed
toggle quoted message
Show quoted text
Prateek,
Question... why not in the OvsdbNodeCreateCommand where all of the other operational info is being created and written?
Ed
|
|
Amit Mandke (ammandke) <ammandke@...>
Just to address the question from following mail. The way you specify the columns to select operation is you call setColumn(..) on a select.
Example:
Select<GenericTableSchema> bridgeSelect = op.select(bridge.getSchema());
List<String> columns = new ArrayList<>();
columns.add(bridge.getNameColumn().getSchema().getName());
bridgeSelect.setColumns(columns);
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
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
toggle quoted message
Show quoted text
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
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) <
>
> 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.
> ________________________________________
(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.
> ________________________________________
> 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) <
>>
>> 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
>
>
>
>> ________________________________________
>> 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) <
>>>
>>> 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...
|
|
What was the solution for the cases where ODL connects to the ovsdb nodes? In that case odl only has the ip:port of the node to make the outgoing connection.
The idea in this thread is to use the system-id, but that looks to only cover the case where the ovsdb node connects to ODL.
Thanks, Sam
toggle quoted message
Show quoted text
----- Original Message ----- From: "Amit Mandke (ammandke)" <ammandke@...>
To: "Prateek Garg (prategar)" <prategar@...>, "Edward Warnicke" <hagbard@...>,
ovsdb-dev@..., ffernand@...
Sent: Wednesday, April 22, 2015 7:20:02 PM
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id
Just to address the question from following mail. The way you specify the
columns to select operation is you call setColumn(..) on a select.
Example:
Select<GenericTableSchema> bridgeSelect = op.select(bridge.getSchema());
List<String> columns = new ArrayList<>();
columns.add(bridge.getNameColumn().getSchema().getName());
bridgeSelect.setColumns(columns);
-Amit
From: "Prateek Garg (prategar)" < prategar@... >
Date: Wednesday, April 22, 2015 at 2:54 PM
To: Edward Warnicke < hagbard@... >, " ovsdb-dev@...
" < ovsdb-dev@... >, " ffernand@... " <
ffernand@... >
Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the
node-id
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@... >
Cc: " ovsdb-dev@... "
< ovsdb-dev@... >
Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
node-id
Message-ID:
< CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@... >
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.
________________________________________
From: ovsdb-dev-bounces@... [ ovsdb-dev-bounces@... ] on behalf of Sharon Aicler
(saichler)
Sent: Monday, April 20, 2015 3:41 PM
To: Flavio Fernandes
Cc: ovsdb-dev@...
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)
Cc: ovsdb-dev@...
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)
Cc: ovsdb-dev@...
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:
ovsdb:// 10.156.48.239:39490/bridge/br-ex
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@...
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.opendaylight.org/pipermail/ovsdb-dev/attachments/20150420/0ac78b3d/attachment-0001.html
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
Edward Warnicke <hagbard@...>
Sam,
The thinking there is to do what we do for bridges... put the iid from config in the external-ids of OpenVSwitch, and on the operational side if that's present use it for the iid there too :)
Ed
On Thu, Apr 23, 2015 at 5:14 AM, Sam Hague <shague@...> wrote: What was the solution for the cases where ODL connects to the ovsdb nodes? In that case odl only has the ip:port of the node to make the outgoing connection.
The idea in this thread is to use the system-id, but that looks to only cover the case where the ovsdb node connects to ODL.
Thanks, Sam
----- Original Message -----
> From: "Amit Mandke (ammandke)" < ammandke@...>
> To: "Prateek Garg (prategar)" < prategar@...>, "Edward Warnicke" < hagbard@...>,
> ovsdb-dev@..., ffernand@...
> Sent: Wednesday, April 22, 2015 7:20:02 PM
> Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the node-id
>
> Just to address the question from following mail. The way you specify the
> columns to select operation is you call setColumn(..) on a select.
>
> Example:
>
> Select<GenericTableSchema> bridgeSelect = op.select(bridge.getSchema());
> List<String> columns = new ArrayList<>();
> columns.add(bridge.getNameColumn().getSchema().getName());
> bridgeSelect.setColumns(columns);
>
> -Amit
>
>
> From: "Prateek Garg (prategar)" < prategar@... >
> Date: Wednesday, April 22, 2015 at 2:54 PM
> To: Edward Warnicke < hagbard@... >, " ovsdb-dev@...
> " < ovsdb-dev@... >, " ffernand@... " <
> ffernand@... >
> Subject: Re: [ovsdb-dev] [Need Help] Arbitrary connection port is part of the
> node-id
>
> 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@... >
> Cc: " ovsdb-dev@... "
> < ovsdb-dev@... >
> Subject: Re: [ovsdb-dev] Arbitrary connection port is part of the
> node-id
> Message-ID:
> < CAFVSqg0kmBcNkGZ50vN-a0TgKswJeRNHVR-1PVvW40ukZuMtYw@... >
> 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.
> > ________________________________________
> > From: ovsdb-dev-bounces@... [
> ovsdb-dev-bounces@... ] on behalf of Sharon Aicler
> (saichler)
> > Sent: Monday, April 20, 2015 3:41 PM
> > To: Flavio Fernandes
> > Cc: ovsdb-dev@...
> > 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)
> > Cc: ovsdb-dev@...
> > 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)
> >> Cc: ovsdb-dev@...
> >> 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:
|
|
Edward Warnicke <hagbard@...>
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
And why change ConnectionInfo (that really really is info about the ip and port...)
Ed
|
|
Amit Mandke (ammandke) <ammandke@...>
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.
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
toggle quoted message
Show quoted text
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
And why change ConnectionInfo (that really really is info about the ip and port...)
Ed
|
|
Edward Warnicke <hagbard@...>
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.
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
|
|
Amit Mandke (ammandke) <ammandke@...>
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?
Not so tricky... we either get that dump or we are borked...
Ed
toggle quoted message
Show quoted text
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.
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
|
|
Edward Warnicke <hagbard@...>
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.
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?
Not so tricky... we either get that dump or we are borked...
Ed
|
|
Prateek Garg (prategar) <prategar@...>
Hi,
I have implemented this change and submitted the same:
Summary of changes:
- 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.
- 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.
- 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
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.
toggle quoted message
Show quoted text
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?
Not so tricky... we either get that dump or we are borked...
Ed
|
|
Prateek Garg (prategar) <prategar@...>
Hi,
It would be very helpful if you could please review the change:
Regards
Prateek
Hi,
I have implemented this change and submitted the same:
Summary of changes:
- 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.
- 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.
- 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
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.
toggle quoted message
Show quoted text
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?
Not so tricky... we either get that dump or we are borked...
Ed
|
|
