[opencontrail-dev] vnc openstack refactoring
Hello dev team, We (Cloudwatt) are working on refactoring the vnc_openstack code. The reason we are doing this activity is because - to optimize some code - particularly related to listing of resources (net-list, port-list etc) as presently it is taking lot of time and this can be optimized. - presently there are not much unit tests. By refactoring and reorganizing the code, we can add unit tests to cover various scenarios and data paths. - to make the code more organized so that maintaining could be easier. The code is here [1] and it is work in progress. We wanted to know the community's opinion/thoughts/comments/criticism on this activity. So please let us know the same. [1] - https://github.com/cloudwatt/contrail-controller/tree/vnc_openstack_refactor/src/config/vnc_openstack/vnc_openstack Thanks Numan ___ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
Re: [opencontrail-dev] Open bug #1436798
Hi, we are about to take a new snapshot to deploy last Opencontrail build. We need to know if we are vulnerables to bug #1441339 ? Can you open it please. Thanks; Foucault 2015-04-10 9:21 GMT+02:00 Édouard Thuleau : > Can you also mark this one #1441339 as public ? > > Édouard. > > On Wed, Apr 1, 2015 at 3:25 PM, Édouard Thuleau wrote: > >> Thanks >> >> On Wed, Apr 1, 2015 at 2:48 PM, Nagabhushana R >> wrote: >> >>> Done. >>> Somehow they are missing in our scrubs. >>> >>> -- >>> Bhushana >>> >>> On 01-Apr-2015, at 1:55 pm, Édouard Thuleau wrote: >>> >>> And that one https://launchpad.net/bugs/1438408 ? >>> >>> Édouard. >>> >>> On Tue, Mar 31, 2015 at 2:00 PM, Nagabhushana R >>> wrote: >>> Flipped. -- Bhushana On 31-Mar-2015, at 4:08 pm, Édouard Thuleau wrote: Thanks Bhushana, Can you also open that one https://launchpad.net/bugs/1420209 ? Édouard. On Thu, Mar 26, 2015 at 3:17 PM, Nagabhushana R wrote: > Done. > > -- > Bhushana > > On 26-Mar-2015, at 7:43 pm, Édouard Thuleau wrote: > > And this one https://launchpad.net/bugs/1433753, please. > > Édouard > > On Thu, Mar 26, 2015 at 12:30 PM, Foucault de Bonneval < > fouca...@thaumiers.com> wrote: > >> Hi, >> >> Regarding https://review.opencontrail.org/#/c/8651/ >> >> Is it possible to make public Bug: #1436798 >> >> Thx. >> Foucault >> >> ___ >> Dev mailing list >> Dev@lists.opencontrail.org >> >> http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org >> >> > ___ > Dev mailing list > Dev@lists.opencontrail.org > > http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org > > >>> >> > > ___ > Dev mailing list > Dev@lists.opencontrail.org > http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org > > ___ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
Re: [opencontrail-dev] Open bug #1436798
It should be accessible now. On Apr 13, 2015, at 1:25 PM, Foucault de Bonneval wrote: > Hi, we are about to take a new snapshot to deploy last Opencontrail build. > We need to know if we are vulnerables to bug #1441339 ? > > Can you open it please. > > Thanks; > Foucault > > 2015-04-10 9:21 GMT+02:00 Édouard Thuleau : > Can you also mark this one #1441339 as public ? > > Édouard. > > On Wed, Apr 1, 2015 at 3:25 PM, Édouard Thuleau wrote: > Thanks > > On Wed, Apr 1, 2015 at 2:48 PM, Nagabhushana R wrote: > Done. > Somehow they are missing in our scrubs. > > -- > Bhushana > > On 01-Apr-2015, at 1:55 pm, Édouard Thuleau wrote: > >> And that one https://launchpad.net/bugs/1438408 ? >> >> Édouard. >> >> On Tue, Mar 31, 2015 at 2:00 PM, Nagabhushana R wrote: >> Flipped. >> >> -- >> Bhushana >> >> On 31-Mar-2015, at 4:08 pm, Édouard Thuleau wrote: >> >>> Thanks Bhushana, >>> Can you also open that one https://launchpad.net/bugs/1420209 ? >>> >>> Édouard. >>> >>> >>> On Thu, Mar 26, 2015 at 3:17 PM, Nagabhushana R >>> wrote: >>> Done. >>> >>> -- >>> Bhushana >>> >>> On 26-Mar-2015, at 7:43 pm, Édouard Thuleau wrote: >>> And this one https://launchpad.net/bugs/1433753, please. Édouard On Thu, Mar 26, 2015 at 12:30 PM, Foucault de Bonneval wrote: Hi, Regarding https://review.opencontrail.org/#/c/8651/ Is it possible to make public Bug: #1436798 Thx. Foucault ___ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org ___ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org >>> >> > > > > ___ > Dev mailing list > Dev@lists.opencontrail.org > http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org > > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
Re: [opencontrail-dev] Problem creating a new data structure with Sandesh
Hi,
I got the following code modifying the test suite available in the
Sandesh C++ library folder:
int port = 8086;
ASSERT_LT(0, port);
std::cout << "Initializing Generator" << std::endl;
Sandesh::InitGenerator("SandeshUVEAlarmTest-Client",
"192.168.100.1", "Test", "0", evm_.get(), 0, NULL);
std::cout << "Connecting to collector" << std::endl;
Sandesh::ConnectToCollector("192.168.100.10", port);
std::cout << "Handshake done" << std::endl;
TASK_UTIL_EXPECT_TRUE(Sandesh::client()->state() ==
SandeshClientSM::ESTABLISHED);
std::cout << "Connection to collector should be established" << std::endl;
// add uve
// case 0
SandeshUVEData uve_data1;
uve_data1.set_name("uve1");
SandeshUVETest::Send(uve_data1);
Here I disabled the sever initialization step as I want to use a real
collector node (192.168.100.10). The execution is sent from IP
192.168.100.1.
However, when evaluating the client status it's not
SandeshClientSM::ESTABLISHED, it's in fact status 2, which is CONNECT.
So it seems to be a step missing.
On the connector log I get the following output for the execution:
2015-04-13 Mon 10:05:02:264.921 UTC contrail [Thread 140679780972416,
Pid 1975]: Session 192.168.100.10:8086::192.168.100.1:54945(15)<
Accepted session from 192.168.100.1:54945
2015-04-13 Mon 10:05:21:736.472 UTC contrail [Thread 140679780972416,
Pid 1975]: Session 192.168.100.10:8086::192.168.100.1:54945(15)< Read
failed due to error 2 : End of file
On the application I get the following:
2015-04-13 Mon 12:11:17:354.925 CEST Mahalanobis [Thread
140662758741952, Pid 5233]: primary 192.168.100.10:8086
2015-04-13 Mon 12:11:17:354.945 CEST Mahalanobis [Thread
140662758741952, Pid 5233]: secondary 0.0.0.0:0
Handshake done
2015-04-13 Mon 12:11:17:355.309 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvStart in state Idle
2015-04-13 Mon 12:11:17:355.415 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Disconnect
2015-04-13 Mon 12:11:17:355.566 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvDiscUpdate in state
Disconnect
2015-04-13 Mon 12:11:17:355.850 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Connect : Start Connect timer
192.168.100.10:8086
2015-04-13 Mon 12:11:17:355.984 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.012 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
2015-04-13 Mon 12:11:17:356.043 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.065 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
2015-04-13 Mon 12:11:17:356.093 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.116 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
So, it seems to connects correctly but fails sending the UVE.
Could anyone help me with this? Pointers to documentation would be
really valuable.
Best regards,
Alberto.
Quoting aguti...@ac.upc.edu:
Hi Megh,
Thanks for your help. With that I think I got the compilation at hand.
Now I'm trying to do a small application to send one message and die.
I defined the following toy sandesh for testing:
struct UveVirtualNetworkAgent {
1: string name(key="ObjectVNTable")
2: optional i32 cpu
}
uve sandesh UveVirtualNetworkAgentTrace {
1: UveVirtualNetworkAgent data;
}
Then I did the following code:
int main() {
Sandesh::InitGenerator()
UveVirtualNetworkAgent a;
a.set_name("TestUnit");
a.set_cpu(100);
UveVirtualNetworkAgentTrace::Send(a);
}
However I don't know which of the 2 InitGenerator functions from the
Sandesh module should I use and what is the meaning of each parameter.
static bool InitGenerator(const std::string &module,
const std::string &source,
const std::string &node_type,
const std::string &instance_id,
EventManager *evm,
unsigned short http_port,
CollectorSubFn csf,
const std::vector &collectors,
SandeshContext *client_context = NULL);
static void InitGenerator(const std::string &module,
const std::string &source,
const std::string &node_type,
const std::string &instance_id,
EventManager *evm,
unsigned short http_port,
SandeshContext *client_context = NULL);
Is there any source where it explains this part? I haven't found it yet.
And one more question: Does setting name(key="ObjectVNTable") to
"TestUnit" create a new table in the database that I could query
using de API of the analytics modu
Re: [opencontrail-dev] Problem creating a new data structure with Sandesh
Hi Alberto,
Sorry for the delay. Please see inline …
On Apr 13, 2015, at 3:14 AM, wrote:
> Hi,
>
> I got the following code modifying the test suite available in the Sandesh
> C++ library folder:
>
>int port = 8086;
>ASSERT_LT(0, port);
>std::cout << "Initializing Generator" << std::endl;
>Sandesh::InitGenerator("SandeshUVEAlarmTest-Client", "192.168.100.1",
> "Test", "0", evm_.get(), 0, NULL);
>std::cout << "Connecting to collector" << std::endl;
>Sandesh::ConnectToCollector("192.168.100.10", port);
>std::cout << "Handshake done" << std::endl;
>TASK_UTIL_EXPECT_TRUE(Sandesh::client()->state() ==
> SandeshClientSM::ESTABLISHED);
[Megh]: This should make sure that the client status is ESTABLISHED before
sending the message below.
>std::cout << "Connection to collector should be established" << std::endl;
>// add uve
>// case 0
>SandeshUVEData uve_data1;
>uve_data1.set_name("uve1");
>SandeshUVETest::Send(uve_data1);
>
> Here I disabled the sever initialization step as I want to use a real
> collector node (192.168.100.10). The execution is sent from IP 192.168.100.1.
>
> However, when evaluating the client status it's not
> SandeshClientSM::ESTABLISHED, it's in fact status 2, which is CONNECT. So it
> seems to be a step missing.
>
> On the connector log I get the following output for the execution:
> 2015-04-13 Mon 10:05:02:264.921 UTC contrail [Thread 140679780972416, Pid
> 1975]: Session 192.168.100.10:8086::192.168.100.1:54945(15)< Accepted session
> from 192.168.100.1:54945
>
> 2015-04-13 Mon 10:05:21:736.472 UTC contrail [Thread 140679780972416, Pid
> 1975]: Session 192.168.100.10:8086::192.168.100.1:54945(15)< Read failed due
> to error 2 : End of file
>
> On the application I get the following:
> 2015-04-13 Mon 12:11:17:354.925 CEST Mahalanobis [Thread 140662758741952,
> Pid 5233]: primary 192.168.100.10:8086
> 2015-04-13 Mon 12:11:17:354.945 CEST Mahalanobis [Thread 140662758741952,
> Pid 5233]: secondary 0.0.0.0:0
> Handshake done
> 2015-04-13 Mon 12:11:17:355.309 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Processing scm::EvStart in state Idle
> 2015-04-13 Mon 12:11:17:355.415 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Disconnect
> 2015-04-13 Mon 12:11:17:355.566 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Processing scm::EvDiscUpdate in state Disconnect
> 2015-04-13 Mon 12:11:17:355.850 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Connect : Start Connect timer 192.168.100.10:8086
[Megh]: From the logs it does not seem that the state machine has moved to
ESTABLISHED. Your code should have failed when checking for the state above.
> 2015-04-13 Mon 12:11:17:355.984 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Processing scm::EvSandeshSend in state Connect
> 2015-04-13 Mon 12:11:17:356.012 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Wrong state: Connect for event: EvSandeshSend
> 2015-04-13 Mon 12:11:17:356.043 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Processing scm::EvSandeshSend in state Connect
> 2015-04-13 Mon 12:11:17:356.065 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Wrong state: Connect for event: EvSandeshSend
> 2015-04-13 Mon 12:11:17:356.093 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Processing scm::EvSandeshSend in state Connect
> 2015-04-13 Mon 12:11:17:356.116 CEST Mahalanobis [Thread 140662631671552,
> Pid 5233]: Wrong state: Connect for event: EvSandeshSend
>
>
>
> So, it seems to connects correctly but fails sending the UVE.
>
>
>
> Could anyone help me with this? Pointers to documentation would be really
> valuable.
My guess is that the TASK_UTIL_EXPECT_TRUE code is not waiting enough. Can you
please check?
The client state machine after connecting to the collector, sends a control
message to move to ClientInit state, and after that on receipt of the reply
from the collector moves to established. You can look at the code in
sandesh_client_sm.cc for details.
https://github.com/Juniper/contrail-sandesh/blob/master/library/cpp/sandesh_client_sm.cc
Thanks
Megh
>
> Best regards,
> Alberto.
>
> Quoting aguti...@ac.upc.edu:
>
>> Hi Megh,
>>
>> Thanks for your help. With that I think I got the compilation at hand.
>>
>> Now I'm trying to do a small application to send one message and die.
>>
>> I defined the following toy sandesh for testing:
>> struct UveVirtualNetworkAgent {
>>1: string name(key="ObjectVNTable")
>>2: optional i32 cpu
>> }
>>
>> uve sandesh UveVirtualNetworkAgentTrace {
>> 1: UveVirtualNetworkAgent data;
>> }
>>
>> Then I did the following code:
>> int main() {
>>Sandesh::InitGenerator()
>>
>>UveVirtualNetworkAgent a;
>>a.set_name("TestUnit");
>>a.set_cpu(100);
>>UveVirtualNetworkAgentTrace::Send(a);
>> }
>>
>> However I don't know which of the 2 InitGenerator functions from the Sandesh
>> module should I use a
Re: [opencontrail-dev] Problem creating a new data structure with Sandesh
Hi Megh,
Thank you for the reply. I already went thru client_sm module but
didn't get any clue about when does the state change, thanks.
You are correct, TASK_UTIL_EXPECT_TRUE is just a conditional print. I
tried to make a loop with that condition (negated) but it seems to
stay forever there, so there must be something failing.
I explored the traffic using tshark and I found that there was a
handshake on the ConnectToCollector, but at
SandeshUVETest::Send(uve_data1) there is no message because client
state machine is not in the correct state.
Any clue about this?
Thank you once more for your support,
Alberto.
Quoting Megh Bhatt :
Hi Alberto,
Sorry for the delay. Please see inline ...
On Apr 13, 2015, at 3:14 AM,
wrote:
Hi,
I got the following code modifying the test suite available in the
Sandesh C++ library folder:
int port = 8086;
ASSERT_LT(0, port);
std::cout << "Initializing Generator" << std::endl;
Sandesh::InitGenerator("SandeshUVEAlarmTest-Client",
"192.168.100.1", "Test", "0", evm_.get(), 0, NULL);
std::cout << "Connecting to collector" << std::endl;
Sandesh::ConnectToCollector("192.168.100.10", port);
std::cout << "Handshake done" << std::endl;
TASK_UTIL_EXPECT_TRUE(Sandesh::client()->state() ==
SandeshClientSM::ESTABLISHED);
[Megh]: This should make sure that the client status is ESTABLISHED
before sending the message below.
std::cout << "Connection to collector should be established" <<
std::endl;
// add uve
// case 0
SandeshUVEData uve_data1;
uve_data1.set_name("uve1");
SandeshUVETest::Send(uve_data1);
Here I disabled the sever initialization step as I want to use a
real collector node (192.168.100.10). The execution is sent from IP
192.168.100.1.
However, when evaluating the client status it's not
SandeshClientSM::ESTABLISHED, it's in fact status 2, which is
CONNECT. So it seems to be a step missing.
On the connector log I get the following output for the execution:
2015-04-13 Mon 10:05:02:264.921 UTC contrail [Thread
140679780972416, Pid 1975]: Session
192.168.100.10:8086::192.168.100.1:54945(15)< Accepted session from
192.168.100.1:54945
2015-04-13 Mon 10:05:21:736.472 UTC contrail [Thread
140679780972416, Pid 1975]: Session
192.168.100.10:8086::192.168.100.1:54945(15)< Read failed due to
error 2 : End of file
On the application I get the following:
2015-04-13 Mon 12:11:17:354.925 CEST Mahalanobis [Thread
140662758741952, Pid 5233]: primary 192.168.100.10:8086
2015-04-13 Mon 12:11:17:354.945 CEST Mahalanobis [Thread
140662758741952, Pid 5233]: secondary 0.0.0.0:0
Handshake done
2015-04-13 Mon 12:11:17:355.309 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvStart in state Idle
2015-04-13 Mon 12:11:17:355.415 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Disconnect
2015-04-13 Mon 12:11:17:355.566 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvDiscUpdate in state
Disconnect
2015-04-13 Mon 12:11:17:355.850 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Connect : Start Connect timer
192.168.100.10:8086
[Megh]: From the logs it does not seem that the state machine has
moved to ESTABLISHED. Your code should have failed when checking for
the state above.
2015-04-13 Mon 12:11:17:355.984 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.012 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
2015-04-13 Mon 12:11:17:356.043 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.065 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
2015-04-13 Mon 12:11:17:356.093 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.116 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
So, it seems to connects correctly but fails sending the UVE.
Could anyone help me with this? Pointers to documentation would be
really valuable.
My guess is that the TASK_UTIL_EXPECT_TRUE code is not waiting
enough. Can you please check?
The client state machine after connecting to the collector, sends a
control message to move to ClientInit state, and after that on
receipt of the reply from the collector moves to established. You
can look at the code in sandesh_client_sm.cc for details.
https://github.com/Juniper/contrail-sandesh/blob/master/library/cpp/sandesh_client_sm.cc
Thanks
Megh
Best regards,
Alberto.
Quoting aguti...@ac.upc.edu:
Hi Megh,
Thanks for your help. With that I think I got the compilation at hand.
Now I'm trying to do a small application to send one message and die.
I defined the following to
Re: [opencontrail-dev] Problem creating a new data structure with Sandesh
Hi Megh,
Thank you for the reply. I already went thru client_sm module but
didn't get any clue about when does the state change, thanks.
You are correct, TASK_UTIL_EXPECT_TRUE is just a conditional print. I
tried to make a loop with that condition (negated) but it seems to
stay forever there, so there must be something failing.
I explored the traffic using tshark and I found that there was a
handshake on the ConnectToCollector, but at
SandeshUVETest::Send(uve_data1) there is no message because client
state machine is not in the correct state.
Any clue about this?
Thank you once more for your support,
Alberto.
Quoting Megh Bhatt :
Hi Alberto,
Sorry for the delay. Please see inline ...
On Apr 13, 2015, at 3:14 AM,
wrote:
Hi,
I got the following code modifying the test suite available in the
Sandesh C++ library folder:
int port = 8086;
ASSERT_LT(0, port);
std::cout << "Initializing Generator" << std::endl;
Sandesh::InitGenerator("SandeshUVEAlarmTest-Client",
"192.168.100.1", "Test", "0", evm_.get(), 0, NULL);
std::cout << "Connecting to collector" << std::endl;
Sandesh::ConnectToCollector("192.168.100.10", port);
std::cout << "Handshake done" << std::endl;
TASK_UTIL_EXPECT_TRUE(Sandesh::client()->state() ==
SandeshClientSM::ESTABLISHED);
[Megh]: This should make sure that the client status is ESTABLISHED
before sending the message below.
std::cout << "Connection to collector should be established" <<
std::endl;
// add uve
// case 0
SandeshUVEData uve_data1;
uve_data1.set_name("uve1");
SandeshUVETest::Send(uve_data1);
Here I disabled the sever initialization step as I want to use a
real collector node (192.168.100.10). The execution is sent from IP
192.168.100.1.
However, when evaluating the client status it's not
SandeshClientSM::ESTABLISHED, it's in fact status 2, which is
CONNECT. So it seems to be a step missing.
On the connector log I get the following output for the execution:
2015-04-13 Mon 10:05:02:264.921 UTC contrail [Thread
140679780972416, Pid 1975]: Session
192.168.100.10:8086::192.168.100.1:54945(15)< Accepted session from
192.168.100.1:54945
2015-04-13 Mon 10:05:21:736.472 UTC contrail [Thread
140679780972416, Pid 1975]: Session
192.168.100.10:8086::192.168.100.1:54945(15)< Read failed due to
error 2 : End of file
On the application I get the following:
2015-04-13 Mon 12:11:17:354.925 CEST Mahalanobis [Thread
140662758741952, Pid 5233]: primary 192.168.100.10:8086
2015-04-13 Mon 12:11:17:354.945 CEST Mahalanobis [Thread
140662758741952, Pid 5233]: secondary 0.0.0.0:0
Handshake done
2015-04-13 Mon 12:11:17:355.309 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvStart in state Idle
2015-04-13 Mon 12:11:17:355.415 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Disconnect
2015-04-13 Mon 12:11:17:355.566 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvDiscUpdate in state
Disconnect
2015-04-13 Mon 12:11:17:355.850 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Connect : Start Connect timer
192.168.100.10:8086
[Megh]: From the logs it does not seem that the state machine has
moved to ESTABLISHED. Your code should have failed when checking for
the state above.
2015-04-13 Mon 12:11:17:355.984 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.012 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
2015-04-13 Mon 12:11:17:356.043 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.065 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
2015-04-13 Mon 12:11:17:356.093 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Processing scm::EvSandeshSend in state
Connect
2015-04-13 Mon 12:11:17:356.116 CEST Mahalanobis [Thread
140662631671552, Pid 5233]: Wrong state: Connect for event:
EvSandeshSend
So, it seems to connects correctly but fails sending the UVE.
Could anyone help me with this? Pointers to documentation would be
really valuable.
My guess is that the TASK_UTIL_EXPECT_TRUE code is not waiting
enough. Can you please check?
The client state machine after connecting to the collector, sends a
control message to move to ClientInit state, and after that on
receipt of the reply from the collector moves to established. You
can look at the code in sandesh_client_sm.cc for details.
https://github.com/Juniper/contrail-sandesh/blob/master/library/cpp/sandesh_client_sm.cc
Thanks
Megh
Best regards,
Alberto.
Quoting aguti...@ac.upc.edu:
Hi Megh,
Thanks for your help. With that I think I got the compilation at hand.
Now I'm trying to do a small application to send one message and die.
I defined the following to
Re: [opencontrail-dev] Problem creating a new data structure with Sandesh
Hi Alberto,
Please see inline …
On Apr 13, 2015, at 2:03 PM, wrote:
> Hi Megh,
>
> Thank you for the reply. I already went thru client_sm module but didn't get
> any clue about when does the state change, thanks.
>
> You are correct, TASK_UTIL_EXPECT_TRUE is just a conditional print. I tried
> to make a loop with that condition (negated) but it seems to stay forever
> there, so there must be something failing.
[Megh]: Are you saying even having loop with usleep() the condition is not met?
>
> I explored the traffic using tshark and I found that there was a handshake on
> the ConnectToCollector, but at SandeshUVETest::Send(uve_data1) there is no
> message because client state machine is not in the correct state.
>
> Any clue about this?
[Megh]: The data will be dropped till the state moves to ESTABLISHED.
Thanks
Megh
>
> Thank you once more for your support,
> Alberto.
>
> Quoting Megh Bhatt :
>
>> Hi Alberto,
>> Sorry for the delay. Please see inline ...
>>
>> On Apr 13, 2015, at 3:14 AM,
>> wrote:
>>
>>> Hi,
>>>
>>> I got the following code modifying the test suite available in the Sandesh
>>> C++ library folder:
>>>
>>> int port = 8086;
>>> ASSERT_LT(0, port);
>>> std::cout << "Initializing Generator" << std::endl;
>>> Sandesh::InitGenerator("SandeshUVEAlarmTest-Client", "192.168.100.1",
>>> "Test", "0", evm_.get(), 0, NULL);
>>> std::cout << "Connecting to collector" << std::endl;
>>> Sandesh::ConnectToCollector("192.168.100.10", port);
>>> std::cout << "Handshake done" << std::endl;
>>> TASK_UTIL_EXPECT_TRUE(Sandesh::client()->state() ==
>>> SandeshClientSM::ESTABLISHED);
>> [Megh]: This should make sure that the client status is ESTABLISHED before
>> sending the message below.
>>> std::cout << "Connection to collector should be established" << std::endl;
>>> // add uve
>>> // case 0
>>> SandeshUVEData uve_data1;
>>> uve_data1.set_name("uve1");
>>> SandeshUVETest::Send(uve_data1);
>>>
>>> Here I disabled the sever initialization step as I want to use a real
>>> collector node (192.168.100.10). The execution is sent from IP
>>> 192.168.100.1.
>>>
>>> However, when evaluating the client status it's not
>>> SandeshClientSM::ESTABLISHED, it's in fact status 2, which is CONNECT. So
>>> it seems to be a step missing.
>>>
>>> On the connector log I get the following output for the execution:
>>> 2015-04-13 Mon 10:05:02:264.921 UTC contrail [Thread 140679780972416, Pid
>>> 1975]: Session 192.168.100.10:8086::192.168.100.1:54945(15)< Accepted
>>> session from 192.168.100.1:54945
>>>
>>> 2015-04-13 Mon 10:05:21:736.472 UTC contrail [Thread 140679780972416, Pid
>>> 1975]: Session 192.168.100.10:8086::192.168.100.1:54945(15)< Read failed
>>> due to error 2 : End of file
>>>
>>> On the application I get the following:
>>> 2015-04-13 Mon 12:11:17:354.925 CEST Mahalanobis [Thread 140662758741952,
>>> Pid 5233]: primary 192.168.100.10:8086
>>> 2015-04-13 Mon 12:11:17:354.945 CEST Mahalanobis [Thread 140662758741952,
>>> Pid 5233]: secondary 0.0.0.0:0
>>> Handshake done
>>> 2015-04-13 Mon 12:11:17:355.309 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Processing scm::EvStart in state Idle
>>> 2015-04-13 Mon 12:11:17:355.415 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Disconnect
>>> 2015-04-13 Mon 12:11:17:355.566 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Processing scm::EvDiscUpdate in state Disconnect
>>> 2015-04-13 Mon 12:11:17:355.850 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Connect : Start Connect timer 192.168.100.10:8086
>> [Megh]: From the logs it does not seem that the state machine has moved to
>> ESTABLISHED. Your code should have failed when checking for the state above.
>>> 2015-04-13 Mon 12:11:17:355.984 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Processing scm::EvSandeshSend in state Connect
>>> 2015-04-13 Mon 12:11:17:356.012 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Wrong state: Connect for event: EvSandeshSend
>>> 2015-04-13 Mon 12:11:17:356.043 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Processing scm::EvSandeshSend in state Connect
>>> 2015-04-13 Mon 12:11:17:356.065 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Wrong state: Connect for event: EvSandeshSend
>>> 2015-04-13 Mon 12:11:17:356.093 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Processing scm::EvSandeshSend in state Connect
>>> 2015-04-13 Mon 12:11:17:356.116 CEST Mahalanobis [Thread 140662631671552,
>>> Pid 5233]: Wrong state: Connect for event: EvSandeshSend
>>>
>>>
>>>
>>> So, it seems to connects correctly but fails sending the UVE.
>>>
>>>
>>>
>>> Could anyone help me with this? Pointers to documentation would be really
>>> valuable.
>> My guess is that the TASK_UTIL_EXPECT_TRUE code is not waiting enough. Can
>> you please check?
>>
>> The client state machine after connecting to the collector, sends a control
