date:20190430

Re: [vpp-dev] backward PAPI-compatibility

2019-04-30 Thread Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io


> [1] https://gerrit.fd.io/r/#/c/19233/1/src/vnet/interface.api
> [2] https://gerrit.fd.io/r/#/c/19235/3/src/vnet/interface.api
> [3] https://gerrit.fd.io/r/#/c/19234/2/src/vnet/interface.api
> [4] https://gerrit.fd.io/r/#/c/19199/3/src/vnet/interface.api
> [5] https://gerrit.fd.io/r/#/c/19198/3/src/vnet/interface.api

Oops, I forgot Drafts are not visible in VPP Gerrit.
The links should be visible now.

Vratko.

From: vpp-dev@lists.fd.io  On Behalf Of Vratko Polak -X 
(vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Sent: Monday, 2019-April-29 16:30
To: vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] backward PAPI-compatibility

Hello VPP reviewers.

When adding a comment to API flag day document,
I have stumbled upon an idea,
that is somewhat larger than the document itself.
It has to do with a weaker form of VPP backward compatibility,
specific to clients using Python API (PAPI).

Here is the relevant part of the comment [0]:

I have realized, that although VPP binary API does not support
optional arguments nor default values,
PAPI does effectively support "false" values as default.
Here, false value is zero, empty string, list of zero length,
byte array (if size is fixed) initialized to each byte being zero, and so on.
I believe it also extends to structured types, "false" means each field
has the false value of its type.
And I guess something reasonable also works for unions.

This can give PAPI a limited form of forward compatibility.
A client application using PAPI is forward compatible
(conversely, VPP API change is backward compatible with respect to such client)
iff the added fields, when called with the "false" value,
do not change the behavior
(compared to the previous VPP behavior where the fields were not defined).

The larger idea is to change the current VPP API in a way
that makes future API changes backward PAPI-compatible.
This first change will be incompatible,
so the subsequent changes do not have to be.

Of course, my motivations are from CSIT committer point of view,
and fairly selfish. Direct users of binary API will have no benefit
from such a change, and I have no idea about users of jvpp or govpp.

There are several approaches to making VPP backward PAPI-compatible,
so I have prepared few examples.

A typical way to add a new functionality to an existing API call
currently looks like this [1].
The new field sw_if_index has a special value ~0,
which restores the previous behavior.
But that value is not "false",
so this change is not backward PAPI-compatible.

There are (at least) two ways the new functionality could have been handled
in a backward PAPI-compatible way (from original call without sw_if_index).
The "hard" way [2] is slightly easier to describe and implement,
but there is also the "soft" way [3].

If VPP committers start encouraging such backward PAPI-compatible changes,
it would look better if also the current calls were converted.
Here is what would such a conversion look like,
from current to hard [4] and from current to soft [5].
Both are PAPI-incompatible, but the soft only for sw_if_index 0,
while the hard for all values except ~0.

My personal preference is to recommend the hard way for new functionality,
and the soft way for converting the existing functionality.
This goal of this e-mail is to ask VPP committers which way they prefer.

Of course, any other comments are also welcome.

Vratko.

[0] https://gerrit.fd.io/r/#/c/18356/2/docs/automating_vpp_api_flag_day.rst@94
[1] https://gerrit.fd.io/r/#/c/19233/1/src/vnet/interface.api
[2] https://gerrit.fd.io/r/#/c/19235/3/src/vnet/interface.api
[3] https://gerrit.fd.io/r/#/c/19234/2/src/vnet/interface.api
[4] https://gerrit.fd.io/r/#/c/19199/3/src/vnet/interface.api
[5] https://gerrit.fd.io/r/#/c/19198/3/src/vnet/interface.api
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12880): https://lists.fd.io/g/vpp-dev/message/12880
Mute This Topic: https://lists.fd.io/mt/31384190/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] backward PAPI-compatibility

2019-04-30 Thread Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io


By the way, I prefer to have default values
defined already in .api.json files,
for example like this [6];
assuming it does not break language bindings.

That way we will have just one kind of backward compatibility,
so it will be easier to decide API version bumps.

Vratko.

[6] https://gerrit.fd.io/r/19246

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: Monday, 2019-April-29 16:30
To: vpp-dev 
Subject: backward PAPI-compatibility

Hello VPP reviewers.

When adding a comment to API flag day document,
I have stumbled upon an idea,
that is somewhat larger than the document itself.
It has to do with a weaker form of VPP backward compatibility,
specific to clients using Python API (PAPI).

Here is the relevant part of the comment [0]:

I have realized, that although VPP binary API does not support
optional arguments nor default values,
PAPI does effectively support "false" values as default.
Here, false value is zero, empty string, list of zero length,
byte array (if size is fixed) initialized to each byte being zero, and so on.
I believe it also extends to structured types, "false" means each field
has the false value of its type.
And I guess something reasonable also works for unions.

This can give PAPI a limited form of forward compatibility.
A client application using PAPI is forward compatible
(conversely, VPP API change is backward compatible with respect to such client)
iff the added fields, when called with the "false" value,
do not change the behavior
(compared to the previous VPP behavior where the fields were not defined).

The larger idea is to change the current VPP API in a way
that makes future API changes backward PAPI-compatible.
This first change will be incompatible,
so the subsequent changes do not have to be.

Of course, my motivations are from CSIT committer point of view,
and fairly selfish. Direct users of binary API will have no benefit
from such a change, and I have no idea about users of jvpp or govpp.

There are several approaches to making VPP backward PAPI-compatible,
so I have prepared few examples.

A typical way to add a new functionality to an existing API call
currently looks like this [1].
The new field sw_if_index has a special value ~0,
which restores the previous behavior.
But that value is not "false",
so this change is not backward PAPI-compatible.

There are (at least) two ways the new functionality could have been handled
in a backward PAPI-compatible way (from original call without sw_if_index).
The "hard" way [2] is slightly easier to describe and implement,
but there is also the "soft" way [3].

If VPP committers start encouraging such backward PAPI-compatible changes,
it would look better if also the current calls were converted.
Here is what would such a conversion look like,
from current to hard [4] and from current to soft [5].
Both are PAPI-incompatible, but the soft only for sw_if_index 0,
while the hard for all values except ~0.

My personal preference is to recommend the hard way for new functionality,
and the soft way for converting the existing functionality.
This goal of this e-mail is to ask VPP committers which way they prefer.

Of course, any other comments are also welcome.

Vratko.

[0] https://gerrit.fd.io/r/#/c/18356/2/docs/automating_vpp_api_flag_day.rst@94
[1] https://gerrit.fd.io/r/#/c/19233/1/src/vnet/interface.api
[2] https://gerrit.fd.io/r/#/c/19235/3/src/vnet/interface.api
[3] https://gerrit.fd.io/r/#/c/19234/2/src/vnet/interface.api
[4] https://gerrit.fd.io/r/#/c/19199/3/src/vnet/interface.api
[5] https://gerrit.fd.io/r/#/c/19198/3/src/vnet/interface.api
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12881): https://lists.fd.io/g/vpp-dev/message/12881
Mute This Topic: https://lists.fd.io/mt/31384190/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Centos job failing because of python-ply package

2019-04-30 Thread Nitin Saxena

Hi,

The Centos job has been failing in https://gerrit.fd.io/r/#/c/18564/ because 
cmake is not able to find python-ply package.
I can see that the master branch has fix from Paul for this but still this is 
failing. Any help??

Thanks,
Nitin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12882): https://lists.fd.io/g/vpp-dev/message/12882
Mute This Topic: https://lists.fd.io/mt/31418969/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Centos job failing because of python-ply package

2019-04-30 Thread Nitin Saxena

Failure log from 
https://jenkins.fd.io/job/vpp-verify-master-centos7/18637/console

13:05:40 FAILED: vlibmemory/memclnt.api.h
13:05:40 cd 
/w/workspace/vpp-verify-master-centos7/build-root/build-vpp-native/vpp/vlibmemory
 && mkdir -p 
/w/workspace/vpp-verify-master-centos7/build-root/build-vpp-native/vpp/vlibmemory
 && /w/workspace/vpp-verify-master-centos7/src/tools/vppapigen/vppapigen 
--includedir /w/workspace/vpp-verify-master-centos7/src --input 
/w/workspace/vpp-verify-master-centos7/src/vlibmemory/memclnt.api --output 
/w/workspace/vpp-verify-master-centos7/build-root/build-vpp-native/vpp/vlibmemory/memclnt.api.h
13:05:40 Traceback (most recent call last):
13:05:40   File 
"/w/workspace/vpp-verify-master-centos7/src/tools/vppapigen/vppapigen", line 4, 
in 
13:05:40 import ply.lex as lex
13:05:40 ModuleNotFoundError: No module named 'ply'

-Nitin

From: vpp-dev@lists.fd.io  On Behalf Of Nitin Saxena
Sent: Tuesday, April 30, 2019 4:52 PM
To: vpp-dev@lists.fd.io
Subject: [EXT] [vpp-dev] Centos job failing because of python-ply package

External Email

Hi,

The Centos job has been failing in https://gerrit.fd.io/r/#/c/18564/ because 
cmake is not able to find python-ply package.
I can see that the master branch has fix from Paul for this but still this is 
failing. Any help??

Thanks,
Nitin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12883): https://lists.fd.io/g/vpp-dev/message/12883
Mute This Topic: https://lists.fd.io/mt/31418969/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] span does not work with vlan sub_interface

2019-04-30 Thread Berna Demir

Hi

I've used following commands to span packets of vlan sub_interface
to a tap interface, but nothing captured on tap interface in Linux.

vpp_api_test> create_vlan_subif GigabitEthernet3/0/0 vlan 2100

vppctl>
set interface state GigabitEthernet3/0/0 up
set interface state GigabitEthernet3/0/0.2100 up
set interface state GigabitEthernetb/0/0 up
set interface ip address GigabitEthernet3/0/0.2100 192.168.111.1/24
set interface ip address GigabitEthernetb/0/0 192.168.222.1/24
tap connect test
set interface state tapcli-0 up
set interface span GigabitEthernet3/0/0.2100 both destination tapcli-0

In the bash:
#> tcpdump -nn -e -i test

Do you have any idea?

Cheers,
Berna
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12884): https://lists.fd.io/g/vpp-dev/message/12884
Mute This Topic: https://lists.fd.io/mt/31419104/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] span does not work with vlan sub_interface

2019-04-30 Thread Damjan Marion via Lists.Fd.Io



> On 30 Apr 2019, at 13:46, Berna Demir  wrote:
> 
> Hi
> 
> I've used following commands to span packets of vlan sub_interface 
> to a tap interface, but nothing captured on tap interface in Linux.
> 
> vpp_api_test> create_vlan_subif GigabitEthernet3/0/0 vlan 2100
> 
> vppctl>
> set interface state GigabitEthernet3/0/0 up
> set interface state GigabitEthernet3/0/0.2100 up
> set interface state GigabitEthernetb/0/0 up
> set interface ip address GigabitEthernet3/0/0.2100 192.168.111.1/24 
>  
> set interface ip address GigabitEthernetb/0/0 192.168.222.1/24 
> 
> tap connect test 
> set interface state tapcli-0 up 
> set interface span GigabitEthernet3/0/0.2100 both destination tapcli-0
> 
> In the bash:
> #> tcpdump -nn -e -i test
> 
> Do you have any idea?

By definition, SPAN is per-port feature, so it can be only applied to physical 
ports.
It grabs packets before ethertype/dot1q lookup happens.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12885): https://lists.fd.io/g/vpp-dev/message/12885
Mute This Topic: https://lists.fd.io/mt/31419104/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] span does not work with vlan sub_interface

2019-04-30 Thread Berna Demir

Thanks for explanation.
So I need to span parent interface.

On Tue, Apr 30, 2019 at 4:36 PM Damjan Marion  wrote:

>
>
> On 30 Apr 2019, at 13:46, Berna Demir  wrote:
>
> Hi
>
> I've used following commands to span packets of vlan sub_interface
> to a tap interface, but nothing captured on tap interface in Linux.
>
> vpp_api_test> create_vlan_subif GigabitEthernet3/0/0 vlan 2100
>
> vppctl>
> set interface state GigabitEthernet3/0/0 up
> set interface state GigabitEthernet3/0/0.2100 up
> set interface state GigabitEthernetb/0/0 up
> set interface ip address GigabitEthernet3/0/0.2100 192.168.111.1/24
> set interface ip address GigabitEthernetb/0/0 192.168.222.1/24
> tap connect test
> set interface state tapcli-0 up
> set interface span GigabitEthernet3/0/0.2100 both destination tapcli-0
>
> In the bash:
> #> tcpdump -nn -e -i test
>
> Do you have any idea?
>
>
> By definition, SPAN is per-port feature, so it can be only applied to
> physical ports.
> It grabs packets before ethertype/dot1q lookup happens.
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12886): https://lists.fd.io/g/vpp-dev/message/12886
Mute This Topic: https://lists.fd.io/mt/31419104/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-04-30 Thread Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io

> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File exists

That error is expected, it just means
the testbed is currently used by another job,
so this job should sleep a while and try again.

> the job was waiting (sleep) from 04:45:12 til 05:26:36

I believe my browser is showing me UTC timestamps,
which show values larger by 4 hours.

> we have 10m idle timeout

The ~3m period of sleeps are interleaved by quick periods
of activity, so we usually do not hit the timeout.

But the final sleep probably took longer for some reason

  09:26:36 ++ sleep 197s
  09:32:20 FATAL: command execution failed

and something bad has happened in less than 6 minutes.
So it does not look like the 10m timeout.

Vratko.

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 15:09
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Hello Jan

From logs I see that the job was waiting (sleep) from 04:45:12 til 05:26:36 
which could cause jnlp session to timed out as we have 10m idle timeout (client 
and server side) set on jenkins.fd.io 

Could you check that error: 

05:26:36 Reservation unsuccessful:
05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File exists

Cheers,

--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> Hello,
> 
> We are experiencing quite a lot of network issues when running CSIT 
> tests for 19.04 report:
> 
> Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> 1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing 
> down or has closed down
> 
> https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/console
> 
> Could you, please, have a look on it?
> 
> Thank you very much.
> 
> Regards,
> Jan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12887): https://lists.fd.io/g/vpp-dev/message/12887
Mute This Topic: https://lists.fd.io/mt/31419993/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-04-30 Thread Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io

>> interleaved by quick periods of activity

>>> 09:26:36 ++ sleep 197s

> send any keepalive packages

I always assumed the console outputs are enough
to keep jnlp connection alive.

Also, I believe this failure over weekend
has hit multiple jobs at once.

For example 
https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-hsw/333/console
  09:32:54 ++ sleep 184s
  09:33:09 FATAL: command execution failed

Vratko.

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 15:57
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Hello Vratko,

Thank you for explanation. I'm wondering within that period of time when 
reservation was unsuccessful (~40min) does the job keep jnlp connection alive 
(send any keepalive packages)? 

I checked the haproxy node where jnlp is runnining and I don't see any DOWN 
notification for it

Thanks,
--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File 
> > exists
> 
> That error is expected, it just means
> the testbed is currently used by another job, so this job should sleep 
> a while and try again.
> 
> > the job was waiting (sleep) from 04:45:12 til 05:26:36
> 
> I believe my browser is showing me UTC timestamps, which show values 
> larger by 4 hours.
> 
> > we have 10m idle timeout
> 
> The ~3m period of sleeps are interleaved by quick periods of activity, 
> so we usually do not hit the timeout.
> 
> But the final sleep probably took longer for some reason
> 
> 09:26:36 ++ sleep 197s
> 09:32:20 FATAL: command execution failed
> 
> and something bad has happened in less than 6 minutes.
> So it does not look like the 10m timeout.
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny 
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:09
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> issues
> 
> Hello Jan
> 
> From logs I see that the job was waiting (sleep) from 04:45:12 til
> 05:26:36 which could cause jnlp session to timed out as we have 10m 
> idle timeout (client and server side) set on jenkins.fd.io
> 
> Could you check that error:
> 
> 05:26:36 Reservation unsuccessful:
> 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': File 
> exists
> 
> Cheers,
> 
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > Hello,
> >
> > We are experiencing quite a lot of network issues when running CSIT 
> > tests for 19.04 report:
> >
> > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> >  1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is closing 
> > down or has closed down
> >
> > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-hsw/13/consol
> > e
> >
> > Could you, please, have a look on it?
> >
> > Thank you very much.
> >
> > Regards,
> > Jan
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12888): https://lists.fd.io/g/vpp-dev/message/12888
Mute This Topic: https://lists.fd.io/mt/31419993/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

2019-04-30 Thread Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io

> I increased idle timeout from 10min to 60min.

Was it around the time this [2] job failed recently?

  16:14:44 ++ sleep 184s
  16:16:29 FATAL: command execution failed

Vratko.

[2] https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-hsw/335/console

-Original Message-
From: csit-...@lists.fd.io  On Behalf Of Kenny Paul via RT
Sent: Tuesday, 2019-April-30 18:22
To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues


I increased idle timeout from 10min to 60min. Let's see if that makes any 
difference.

Regards,

--
Anton Baranov
Sr. System Operations Engineer
The Linux Foundation

On Tue Apr 30 10:03:46 2019, vrpo...@cisco.com wrote:
> >> interleaved by quick periods of activity
> 
> >>> 09:26:36 ++ sleep 197s
> 
> > send any keepalive packages
> 
> I always assumed the console outputs are enough to keep jnlp 
> connection alive.
> 
> Also, I believe this failure over weekend has hit multiple jobs at 
> once.
> 
> For example https://jenkins.fd.io/job/csit-vpp-perf-verify-master-3n-
> hsw/333/console
>   09:32:54 ++ sleep 184s
>   09:33:09 FATAL: command execution failed
> 
> Vratko.
> 
> -Original Message-
> From: csit-...@lists.fd.io  On Behalf Of Kenny 
> Paul via RT
> Sent: Tuesday, 2019-April-30 15:57
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> issues
> 
> Hello Vratko,
> 
> Thank you for explanation. I'm wondering within that period of time 
> when reservation was unsuccessful (~40min) does the job keep jnlp 
> connection alive (send any keepalive packages)?
> 
> I checked the haproxy node where jnlp is runnining and I don't see any 
> DOWN notification for it
> 
> Thanks,
> --
> Anton Baranov
> Sr. System Operations Engineer
> The Linux Foundation
> 
> On Tue Apr 30 09:27:56 2019, vrpo...@cisco.com wrote:
> > > 05:26:36 mkdir: cannot create directory '/tmp/reservation_dir':
> > > File
> > > exists
> >
> > That error is expected, it just means  the testbed is currently used 
> > by another job, so this job should sleep a while and try again.
> >
> > > the job was waiting (sleep) from 04:45:12 til 05:26:36
> >
> > I believe my browser is showing me UTC timestamps, which show values 
> > larger by 4 hours.
> >
> > > we have 10m idle timeout
> >
> > The ~3m period of sleeps are interleaved by quick periods of 
> > activity, so we usually do not hit the timeout.
> >
> > But the final sleep probably took longer for some reason
> >
> > 09:26:36 ++ sleep 197s
> > 09:32:20 FATAL: command execution failed
> >
> > and something bad has happened in less than 6 minutes.
> > So it does not look like the 10m timeout.
> >
> > Vratko.
> >
> > -Original Message-
> >  From: csit-...@lists.fd.io  On Behalf Of 
> > Kenny Paul via RT
> > Sent: Tuesday, 2019-April-30 15:09
> >  To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
> > 
> > Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
> >  Subject: [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network 
> > issues
> >
> > Hello Jan
> >
> > From logs I see that the job was waiting (sleep) from 04:45:12 til
> >  05:26:36 which could cause jnlp session to timed out as we have 10m 
> > idle timeout (client and server side) set on jenkins.fd.io
> >
> > Could you check that error:
> >
> > 05:26:36 Reservation unsuccessful:
> >  05:26:36 mkdir: cannot create directory '/tmp/reservation_dir': 
> > File exists
> >
> > Cheers,
> >
> > --
> > Anton Baranov
> > Sr. System Operations Engineer
> > The Linux Foundation
> >
> > On Mon Apr 29 02:58:28 2019, jgel...@cisco.com wrote:
> > > Hello,
> > >
> > > We are experiencing quite a lot of network issues when running 
> > > CSIT tests for 19.04 report:
> > >
> > > Caused: hudson.remoting.ChannelClosedException: Channel "unknown":
> > > Remote call on JNLP4-connect connection from vex-yul-rot-ingress-
> > >   1.ci.codeaurora.org/10.30.48.3:41068 failed. The channel is 
> > > closing down or has closed down
> > >
> > > https://jenkins.fd.io/job/csit-vpp-perf-verify-1904-3n-
> > > hsw/13/consol
> > > e
> > >
> > > Could you, please, have a look on it?
> > >
> > > Thank you very much.
> > >
> > > Regards,
> > > Jan
> >
> >
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12889): https://lists.fd.io/g/vpp-dev/message/12889
Mute This Topic: https://lists.fd.io/mt/31419993/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] backward PAPI-compatibility

Re: [vpp-dev] backward PAPI-compatibility

[vpp-dev] Centos job failing because of python-ply package

Re: [vpp-dev] Centos job failing because of python-ply package

[vpp-dev] span does not work with vlan sub_interface

Re: [vpp-dev] span does not work with vlan sub_interface

Re: [vpp-dev] span does not work with vlan sub_interface

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

Re: [vpp-dev] [csit-dev] [FD.io Helpdesk #73486] Jenkins.fd.io network issues

10 matches

Site Navigation

Mail list logo

Footer information