Re: [vpp-dev] Discussion Topic: creating demo branches in git.fd.io/vpp

[Ole Troan (otroan)]

> The concern would be that without CI you have very limited visibility into 
> the impact of the patches pre-merge.  The automation at fd.io does a *lot* 
> for you…

Absolutely. For the hackathons CI was an order or two of magnitude too slow. 
And we would be doing the testing there and then.
I don’t know how applicable that experience is for someone who’s buildiing a 
demo though.

Cheers,
Ole



> On Wed, Nov 15, 2017 at 3:50 PM Jon Loeliger  wrote:
> On Wed, Nov 15, 2017 at 4:17 PM, Dave Wallace  wrote:
> Folks,
> 
> Per the action item from this yesterday's VPP weekly meeting, I'm asking for 
> opinions from the VPP community on allowing the creation of demo branches in 
> the VPP git repo.
> 
> ...
> 
> 
> Pro: Will allow utilization of LF infra to utilize CI process
> Pro: Will allow publishing of demo artifacts for ease of reproduction of the 
> demo.
> Con: Will pollute repo with ephemeral code that will rapidly become out of 
> date / dead.
> Con: Sets precedent which may cause large numbers of non-production branches 
> over time.
> 
> Please feel add additional Pro/Con comments here.  Comments are welcome from 
> all members of the VPP community.
> 
> Dave,
> 
> In my opinion, creating a cloned fork and adding demo code there would be a
> better approach.  And that demo code will likely become obsolete and bit-rot 
> over time,
> but it will forever be part of the repo.  Over time it will just be dead 
> weight bloat.
> The core code base should remain as a library and not get tied to any 
> specific application.
> 
> HTH,
> jdl
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] jvpp core future test failure (gerrit 8743)

[Ole Troan (otroan)]

s/map/dns

if you were to cut and paste.


#define vl_msg_name_crc_list
#include 
#undef vl_msg_name_crc_list

static void
setup_message_id_table (api_main_t * am)
{
#define _(id,n,crc) vl_msg_api_add_msg_name_crc (am, #n "_" #crc, id);
  foreach_vl_msg_name_crc_dns;
#undef _
}

Ole

On 13 Oct 2017, at 19:46, Ole Troan > 
wrote:

Dear Dave,

I wonder if you forgot to hookup the messages in the CRC dictionary?

#define vl_msg_name_crc_list
#include 
#undef vl_msg_name_crc_list

static void
setup_message_id_table (api_main_t * am)
{
#define _(id,n,crc) vl_msg_api_add_msg_name_crc (am, #n "_" #crc, id);
  foreach_vl_msg_name_crc_map;
#undef _
}

If my guess is correct, I’’ have a chat with the Java guys if we can come up 
with a slightly more user-friendly error message. ;-)

Best regards,
Ole


On 13 Oct 2017, at 19:31, Dave Barach (dbarach) 
> wrote:

Dear Ole,

See https://gerrit.fd.io/r/#/c/8743. It turns out that the java core future 
“make test” test fails as shown below.

The patch adds three xxx_reply_t binary api messages. See 
.../src/vnet/dns/dns.api.

It sure looks like the Java code knows about them, but isn’t doing a very good 
job of registering them. Note that I had to modify the binary API client 
library to keep Java from ASSERTing due to the NULL msg id’s squawked below.

What’s going on here? These messages work like a champ in vpp_api_test...

INFO: Testing Java future API for core plugin
[New Thread 0x7fffd5f9c700 (LWP 4611)]
vl_msg_api_config:671: Trying to register dns_enable_disable_reply with a NULL 
msg id!
vl_msg_api_config:671: Trying to register dns_name_server_add_del_reply with a 
NULL msg id!
vl_msg_api_config:671: Trying to register dns_resolve_name_reply with a NULL 
msg id!
[Thread 0x7fffd5f9c700 (LWP 4611) exited]
Exception in thread "main" java.lang.IllegalStateException: API mismatch 
detected: dns_resolve_name_reply_451ab6c0 is missing
 at io.fd.vpp.jvpp.core.JVppCoreImpl.init0(Native Method)
 at io.fd.vpp.jvpp.core.JVppCoreImpl.init(JVppCoreImpl.java:75)
 at io.fd.vpp.jvpp.JVppRegistryImpl.register(JVppRegistryImpl.java:72)
 at 
io.fd.vpp.jvpp.core.future.FutureJVppCoreFacade.(FutureJVppCoreFacade.java:25)
 at 
io.fd.vpp.jvpp.core.test.FutureApiTest.testFutureApi(FutureApiTest.java:50)
 at io.fd.vpp.jvpp.core.test.FutureApiTest.main(FutureApiTest.java:44)
[New Thread 0x7fffd54af700 (LWP 4612)]

Thanks… Dave


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] jvpp core future test failure (gerrit 8743)

[Ole Troan (otroan)]

Dear Dave,

I wonder if you forgot to hookup the messages in the CRC dictionary?

#define vl_msg_name_crc_list
#include 
#undef vl_msg_name_crc_list

static void
setup_message_id_table (api_main_t * am)
{
#define _(id,n,crc) vl_msg_api_add_msg_name_crc (am, #n "_" #crc, id);
  foreach_vl_msg_name_crc_map;
#undef _
}

If my guess is correct, I’’ have a chat with the Java guys if we can come up 
with a slightly more user-friendly error message. ;-)

Best regards,
Ole


On 13 Oct 2017, at 19:31, Dave Barach (dbarach) 
> wrote:

Dear Ole,

See https://gerrit.fd.io/r/#/c/8743. It turns out that the java core future 
“make test” test fails as shown below.

The patch adds three xxx_reply_t binary api messages. See 
.../src/vnet/dns/dns.api.

It sure looks like the Java code knows about them, but isn’t doing a very good 
job of registering them. Note that I had to modify the binary API client 
library to keep Java from ASSERTing due to the NULL msg id’s squawked below.

What’s going on here? These messages work like a champ in vpp_api_test...

INFO: Testing Java future API for core plugin
[New Thread 0x7fffd5f9c700 (LWP 4611)]
vl_msg_api_config:671: Trying to register dns_enable_disable_reply with a NULL 
msg id!
vl_msg_api_config:671: Trying to register dns_name_server_add_del_reply with a 
NULL msg id!
vl_msg_api_config:671: Trying to register dns_resolve_name_reply with a NULL 
msg id!
[Thread 0x7fffd5f9c700 (LWP 4611) exited]
Exception in thread "main" java.lang.IllegalStateException: API mismatch 
detected: dns_resolve_name_reply_451ab6c0 is missing
 at io.fd.vpp.jvpp.core.JVppCoreImpl.init0(Native Method)
 at io.fd.vpp.jvpp.core.JVppCoreImpl.init(JVppCoreImpl.java:75)
 at io.fd.vpp.jvpp.JVppRegistryImpl.register(JVppRegistryImpl.java:72)
 at 
io.fd.vpp.jvpp.core.future.FutureJVppCoreFacade.(FutureJVppCoreFacade.java:25)
 at 
io.fd.vpp.jvpp.core.test.FutureApiTest.testFutureApi(FutureApiTest.java:50)
 at io.fd.vpp.jvpp.core.test.FutureApiTest.main(FutureApiTest.java:44)
[New Thread 0x7fffd54af700 (LWP 4612)]

Thanks… Dave

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Traceback Seen in invoke Python APIs with Parameters

[Ole Troan (otroan)]

Hi Hang,

You have to use named arguments. 
Change in 17.01. 

Best regards,
Ole

> On 18 Feb 2017, at 19:13, Hang Shi  wrote:
> 
> Hi, 
> 
> I am trying to use VPP python APIs and seeing the tracebacks (see below) for 
> Python APIs with parameters, while Python APIs without parameters are fine. 
> Will anyone help?  The APIs I tried is vpp.sw_interface_add_del_address.
> 
> below is the traceback and code snippets. Whole codes are attached as well. 
> 
> 
>  
> Traceback (most recent call last):
>   File "set_addr_test.py", line 53, in 
> main()
>   File "set_addr_test.py", line 45, in main
> loop = vpp.sw_interface_add_del_address(ifindex, 1, 1, 0, 16, addr)
> TypeError: () takes exactly 0 arguments (6 given)
> Cleaning up VPP on exit
>  
> 
> 
> 
>    
>   loop = vpp.create_loopback()
>   print(loop)
>   ifindex = loop.sw_if_index
>   print('{}'.format(ifindex))
> 
>   addr = str(IPv6Address(u'1::1').packed)
>   loop = vpp.sw_interface_add_del_address(ifindex, 1, 1, 0, 16, addr)
>   ...
>  
> 
> 
> The syntax from help  for this API: 
> 
> sw_interface_add_del_address(**kwargs)
> u16 _vl_msg_id, u32 client_index, u32 context, u32 sw_if_index, u8 
> is_add, u8 is_ipv6, u8 del_all, u8 address_length, u8 address
> 
> 
> 
> regards, 
> Hang
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Ole Troan (otroan)]

Ray,

> Well if they are a 'committer' then dispense with the extra bureaucracy and 
> give them commit rights?

It's a matter of granularity really. 
I could certainly imagine myself only having control of vnet/map and  not want 
to have responsibility or authority over anything else. 

When it comes down to it this is all merits based anyway. 

I hoped more less centralized bureaucracy and more distributed power, but I am 
sure that's what the great Russian leaders over the past centuries tried to 
achieve too. :-)

Best regards,
Ole
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev