Re: [vpp-dev] jvpp core future test failure (gerrit 8743)
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)
mailto:dbar...@cisco.com>> 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)
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 mailto:otr...@cisco.com>>
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)
mailto:dbar...@cisco.com>> 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] Discussion Topic: creating demo branches in git.fd.io/vpp
> 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] Committer / Maintainer model.
Ray, > I suspect the Maintainers versus Committers description was included for my > benefit :-) Most definitely not! :-) Agreeing on the right words to use for something is half the battle. > My 2c is that my experience of this model is that maintainers typically get > frustrated and disillusioned over time and become inactive, as they feel they > are minions, doing the tough and often invisble review work but with no real > authority over a feature. You end up with maintainer churn etc. > > That is why I push for a strong correlation between maintainers and > committers. Committers should be a maintainer of something and the number of > maintainers who are not committers should be small. A maintainer with no > commit rights, should be a committer in waiting with a clear path to > graduating to be a committer. I see that. Interesting to see how it develops. Not suggesting we should cast this in stone. . I imagined the opposite. That a maintainer had super-powers for his feature, but perhaps wasn't so interested in the rest of the system. Then the role of the committer is more one of architectural oversight and someone who ensures that the right hoops were jumped. I kind of think of a maintainer as a committer for a particular feature/area/plugin. Try and then adjust as we go along? Cheers, Ole > > Ray K > >> On 21/12/2016 12:18, Ole Troan wrote: >> Guys, >> >> The discussion we had on the Tuesday meeting about the maintainers file got >> me thinking. >> >> I think there are two problems with the current model. >> - It puts a high burden on the committers, since at least one among the >> committer set has to know every piece of the code. >> Aka. it doesn't scale very well. >> - It doesn't allow the code authors aka maintainers of a given component any >> control of changes to 'their' component. >> >> Proposal: >> 1) Each component has a set of owners (or named list). >> 2) When a change is submitted. A gerrit hook processes the list of changed >> files, and automatically adds the component owner lists or individuals to >> the reviews list. >>(e.g. Ole Troan (vnet/map), Neale Ranns (vnet/ip)) >> 3) A committer will then see when maintainers have +1 for each affected >> component. And then either submit or chase component owners for review. >> >> A maintainer can then raise a "discuss" by a -1. >> >> If there is support for this we need to: >> - create maintainer file (and keep this up to date) >> - write gerrit hook >> >> Btw, Damjan pointed me to the Xen project's definition of maintainers vs >> committers: >> >> Maintainers >> >> Maintainers own one or several components in the Xen tree. A maintainer >> reviews and approves changes that affect their components. It is a >> maintainer's prime responsibility to review, comment on, co-ordinate and >> accept patches from other community member's and to maintain the design >> cohesion of their components. Maintainers are listed in a MAINTAINERS file >> in the root of the source tree. >> >> Committers >> >> Committers are Maintainers that are allowed to commit changes into the >> source code repository. The committer acts on the wishes of the maintainers >> and applies changes that have been approved by the respective maintainer(s) >> to the source tree. Due to their status in the community, committers can >> also act as referees should disagreements amongst maintainers arise. >> Committers are listed on the sub-project's team portal (e.g. Hypervisor team >> portal). >> >> >> Views? >> >> Best regards, >> Ole >> ___ >> 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.
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
Re: [vpp-dev] Fix for vpp-verify-master-ubuntu1604 build failures
Dave, On a rebased build I just hot the following... related? O. 08:08:01 + echo IS_CSIT_VPP_JOB= 08:08:01 IS_CSIT_VPP_JOB= 08:08:01 + git log --oneline 08:08:01 + grep 37682e1 08:08:01 + '[' x '!=' xTrue ']' 08:08:01 + echo 'Building using "make verify"' 08:08:01 Building using "make verify" 08:08:01 + '[' x == xTrue ']' 08:08:01 + make UNATTENDED=yes verify 08:08:01 Reading package lists... 08:08:01 Building dependency tree... 08:08:01 Reading state information... 08:08:01 Package pkg-config is not available, but is referred to by another package. 08:08:01 This may mean that the package is missing, has been obsoleted, or 08:08:01 is only available from another source 08:08:01 08:08:01 E: Package 'pkg-config' has no installation candidate 08:08:01 E: Unable to locate package chrpath 08:08:01 E: Unable to locate package default-jdk-headless 08:08:01 Makefile:166: recipe for target 'install-dep' failed 08:08:01 make: *** [install-dep] Error 100 08:08:01 Build step 'Execute shell' marked build as failure 08:08:01 [ssh-agent] Stopped.? From: vpp-dev-boun...@lists.fd.io on behalf of Dave Wallace Sent: Thursday, February 2, 2017 4:15 AM To: vpp-dev Subject: Re: [vpp-dev] Fix for vpp-verify-master-ubuntu1604 build failures On 2/1/17 9:55 PM, Dave Wallace wrote: Folks, After today's ubuntu mirror issue was resolved, Ed, Vanessa, and I discovered another failure mode for the vpp-verify-master-ubuntu1604 verify job. In the process of diagnosing the failure, Ed discovered and fixed a bug in "make verify" that was the root cause of this issue. See https://gerrit.fd.io/r/#/c/4993/ for details. I merged this patch and verified that it resolved the vpp-verify-master-ubuntu1604 failure for https://gerrit.fd.io/r/#/c/4897. I have subsequently rebased all patches in the gerrit:vpp queue that were open and current. Any patch that has merge conflicts will need to be rebased manually. Thanks to Ed for his keen eyesight and Vanessa for cancelling her after hours plans to stay and help resolve the issue. I have also cherry-picked 4993 to stable/1701, but that still requires merging. Please disregard the following, it appears that the other jobs are waiting in the build queue and have not been posted to gerrit yet. I also noticed that stable/1701 only has verify jobs for ubuntu1404 and centos7. We should add a verify job for ubuntu1604 as well. -daw- Please help monitor the status of the verify jobs that are now in progress. Thanks, -daw- ___ 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
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
