Re: [vpp-dev] API versioning
Ole, Is this the PyPI package? https://pypi.python.org/pypi/vpp-papi If it is, how often will the package be updated? Also, it would be helpful to include in release notes VPP versions supported. Thanks Feng On Mon, Oct 9, 2017 at 5:09 AM, Ole Troan wrote: > Alec, > > > A good step in the right direction. How does this translate in terms of > python package versioning? > > Ideally, we should have a python PyPI package for programming VPP using > python library. > > Currently, it does not at all translate to python package versioning. > There is already a PyPI package. > > The VPP Python binding is currently completely independent of VPP version. > I might have taken the fact that it is a dynamic language a bit too far, > but currently on connect, combined with the JSON definitions the Python > binding dynamically creates the API. Of course given the flexibility of > plugins and that plugins provider their own APIs, tightly coupling VPP > Python binding and VPP version is a little tricky. > > I was thinking of adding a more application friendly wrapper for dealing > with API module versions. Something like pass in a associative array of > modules + required versions, and get a yes/no reply back. > > Best regards, > Ole > > > > > > From: on behalf of "Marek Gradzki -X > (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" > > Date: Thursday, October 5, 2017 at 4:38 AM > > To: Ole Troan , vpp-dev > > Subject: Re: [vpp-dev] API versioning > > > > +1 > > > > having explicit version number in the api file is a good thing in my > opinion. > > > > I think also Java bindings could benefit a bit from your proposal. > > > > While the only backward compatible api change is probably parameter > rename, > > one could generate more human friendly error messages on CRC mismatch. > > > > Regards, > > Marek > > > > -Original Message- > > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] > On Behalf Of Ole Troan > > Sent: 2 października 2017 14:37 > > To: vpp-dev > > Subject: [vpp-dev] API versioning > > > > All, > > > > I have received a few suggestions that especially the dynamic language > bindings (Python, Lua) would benefit from a better versioning system than > depending and storing the CRC values of each VPP API message. > > > > Could you please take a look at the proposal for semantic versioning of > API modules here: > > https://wiki.fd.io/view/VPP/API_Versioning > > > > Dave helped me with modifying the .api parser: > > https://gerrit.fd.io/r/#/c/8589/ > > > > This patch adds a new message "api_versions". That will return a > dictionary of API modules and their versions. > > > > I have also added version 1.0.0 to all .api files. Please let me know if > you want a different version string. E.g. major == 0, if it is experimental > and expected to change. > > > > Opinions? > > (and yes, I know we can do better with additional support for backwards > compatibility... one baby step at the time. ;-)) > > > > 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 > ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] [csit-dev] vhost multi-queue patch - verify job failing
I agree with Chris here. I also want to bring Centos into the conversation, Centos 7.2 ships with QEMU version 1.5.3 by default and 2.3.0 in qemu-ev channel, both of those supported versions in Centos contain backports from newer releases. I think it would be helpful if a commit (or set of commits) for upstream qemu can be identified so we can determine qemu version support in distro. Thanks, Feng On Thu, Oct 27, 2016 at 10:24 AM, Luke, Chris wrote: > Wait, you’re saying software people aren’t very good at documentation? > > > > Say it ain’t so! > > > > In any case, I echo Damjan’s sentiment; Just to publicly air my end user > oriented opinion: it’s important to minimize the variables to get VPP > going; that means it has to work with whatever QEMU/KVM Ubuntu 16.04 ships > with. I may elect to improve things with a newer version but it is also > important to me that it Just Works otherwise. > > > > Chris. > > > > *From:* csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] > *On Behalf Of *Pierre Pfister (ppfister) > *Sent:* Thursday, October 27, 2016 7:49 AM > *To:* Damjan Marion (damarion) > *Cc:* csit-...@lists.fd.io; vpp-dev > > *Subject:* Re: [csit-dev] vhost multi-queue patch - verify job failing > > > > I think I have a fix. > > I mean... I re-interprated some text from vhost-user.txt... Reverse > engineered DPDK's implementation... Looked at qemu messages... And tried to > find a way to make it work. > > > > It looks like the first ring pair is supposed to be enabled by default... > Well. I don't know if it is supposed to. But qemu 2.5 does not enable ring > 1 (it does enable ring 0). So I am not sure either qemu 2.5 or DPDK is > right. But it looks like it works. > > Let's see if it actually does... > > > > https://gerrit.fd.io/r/#/c/2922/18..20/vnet/vnet/devices/ > virtio/vhost-user.c > > > > You know. That's really when you get to like IETF's specifications. > > virtio specs, and vhost-user specs even more, are so ambiguous. > vhost-user.txt is in a git repository and subject to changes. I mean... > Seriously. > > I wish so hard virtio 1.1 will be a reboot of all this madness. > > > > - Pierre > > > > Le 27 oct. 2016 à 12:23, Damjan Marion (damarion) a > écrit : > > > > > > Yes, we should not break QEMU 2.5 compatibility, specially if that version > is default version provided in ubuntu 16.04. > > IMO we need to test both with 2.5 and 2.7 as long as ubuntu 16.04 is in > game. > > > > My understanding so far was that this is only "2.5-RC1" issue. > > > > > > > > On 27 Oct 2016, at 09:56, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES > at Cisco) wrote: > > > > I would leave decision to community. > > By merge this patch basically vhost-user on Qemu 2.5 would be failing - > maybe some disclaimer should be made or what about backward compatibility? > > > > *Peter Mikus* > Engineer – Software > > *Cisco Systems Limited* > > > > Planned absence: 28.10., 1.11., 17.11., 9.12., 19.-31.12. > > > > *From:* Pierre Pfister (ppfister) > *Sent:* Thursday, October 27, 2016 9:27 AM > *To:* Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) < > pmi...@cisco.com> > *Cc:* Edward Warnicke ; Maciek Konstantynowicz > (mkonstan) ; csit-...@lists.fd.io; Damjan Marion > (damarion) ; vpp-dev > *Subject:* Re: [csit-dev] vhost multi-queue patch - verify job failing > > > > Oh. Just notices you merged. > > I actually merged and pushed too... So a new test is started. Will > probably fail. > > > > Ideal Qemu would be 2.7. > > > > 2.5 is *old*. And the failing qemu was 2.5-rc1. Anything above 2.5-rc1 > should be good. > > > > - Pierre > > > > > > Le 27 oct. 2016 à 07:36, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at > Cisco) a écrit : > > > > Hi, > > > > Taking look. Yes it is using correct latest branch and Qemu 2.5.0 which is > default version of 16.04.1LTS (Debian 1:2.5+dfsg-5ubuntu10.5). As still > failing, there is question which Qemu version is specifically required (I > do not see it in the comments of patch) or if the patch itself is working. > > > > *Peter Mikus* > Engineer – Software > > *Cisco Systems Limited* > > > > Planned absence: 28.10., 1.11., 17.11., 9.12., 19.-31.12. > > > > *From:* Edward Warnicke [mailto:hagb...@gmail.com ] > *Sent:* Thursday, October 27, 2016 12:35 AM > *To:* Maciek Konstantynowicz (mkonstan) > *Cc:* Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) < > pmi...@cisco.com>; Pierre Pfister (ppfister) ; csit- > d...@lists.fd.io; Damjan Marion (damarion) ; vpp-dev < > vpp-dev@lists.fd.io> > *Subject:* Re: [csit-dev] vhost multi-queue patch - verify job failing > > > > Still failing, but apparently now using the correct CSIT branch: > > > > https://jenkins.fd.io/job/vpp-csit-verify-virl-master/1949/consoleFull > > > > "*14:55:18* + git clone https://gerrit.fd.io/r/csit --branch oper-161024" > > > > On Wed, Oct 26, 2016 at 2:45 PM, Maciek Konstantynowicz (mkonstan) < > mkons...@cisco.com> wrote: > > Excellent, thanks Ed! And let’s see … > > > -Maciek >
[vpp-dev] vpp-plugins RPM dependency
Hi All, With latest master builds of VPP (on Centos with rpm repo), it seems like it's necessary to install vpp-plugins package for vpp to start, without it, I get the following error when running vpp (with default config file): vlib_plugin_early_init:360: plugin path /usr/lib/vpp_plugins vlib_call_all_config_functions: unknown input `dpdk ' Looking at the spec file, vpp package depends on vpp-lib only, so it appears that we need to add vpp-plugins to the dependency list too. However, it also looks like vpp-plugins depends on vpp package, so I'm trying to figure out what the right dependency relationship is :) Thanks Feng ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vpp-plugins RPM dependency
So this would suggest that VPP by default (that is, by doing 'yum install vpp') will not have dpdk support, and vpp-plugins must also be installed to add it, I would think dpdk plugin should be either packaged or installed together with VPP by default, and can be disabled if desired. In any case, will deployment model stay this way? I'll need to make changes to puppet module to include other packages if that's how it will be going forward. Also, dpdk section should be commented out in the config file so we can start VPP service using the default config. Thanks Feng On Wed, Mar 22, 2017 at 2:46 PM, Ed Warnicke wrote: > Commenting out the dpdk stanza is a great workaround but we may want to > look at bit more closely at the issue... as installing the vpp project > should result in an out of the box runnable vpp. > > Ed > > On Wed, Mar 22, 2017 at 11:44 AM, Dave Barach (dbarach) > wrote: > >> Simply remove the “dpdk” stanza from /etc/vpp/startup.conf if you want to >> run vpp without the dpdk plugin. >> >> >> >> Thanks… Dave >> >> >> >> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On >> Behalf Of *Feng Pan >> *Sent:* Wednesday, March 22, 2017 1:47 PM >> *To:* vpp-dev >> *Subject:* [vpp-dev] vpp-plugins RPM dependency >> >> >> >> Hi All, >> >> >> >> With latest master builds of VPP (on Centos with rpm repo), it seems like >> it's necessary to install vpp-plugins package for vpp to start, without it, >> I get the following error when running vpp (with default config file): >> >> >> >> vlib_plugin_early_init:360: plugin path /usr/lib/vpp_plugins >> >> vlib_call_all_config_functions: unknown input `dpdk ' >> >> >> >> Looking at the spec file, vpp package depends on vpp-lib only, so it >> appears that we need to add vpp-plugins to the dependency list too. >> However, it also looks like vpp-plugins depends on vpp package, so I'm >> trying to figure out what the right dependency relationship is :) >> >> >> >> Thanks >> >> Feng >> >> ___ >> 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
