[meta-virtualization] [PATCH 1/4] cni: add 0.7.1 for cni and 0.7.5 for plugins

Bruce Ashfield bruce.ashfield at gmail.com
Tue Aug 13 20:16:54 PDT 2019


On Tue, Aug 13, 2019 at 9:28 PM ChenQi <Qi.Chen at windriver.com> wrote:
>
> On 08/13/2019 08:31 PM, Bruce Ashfield wrote:
>
>
>
> On Tue, Aug 13, 2019 at 3:52 AM Chen Qi <Qi.Chen at windriver.com> wrote:
>>
>> This version is proved to work well for simple k8s flannel setup.
>>
>
> Nope. We have no reason to use version locked recipes for this. I want one version for the layer, not a _git and a versioned set of plugins.
>
> Upgrade the main _cni plugin to the latest version, make sure it works with kubernetes and that's the version we'll use.
>
>
> I've replied in another email what problem is with the current version of  cni. Hope you can reproduce it on your side.
>
> Apart form this, I have several questions, and I hope to hear your opinion.
>
> 1. Docker version with k8s
>     I've seen warnings from k8s telling me that the current docker version is not supported/validated upstream. Do you think it's a problem? From what I know, k8s team is not very interested in validating latest docker.


I've never had any issues with using the latest Docker and k8s. Since
there's much more to the container world than kubernetes, it can't
dictate our version of docker. I'm also not willing to create frozen
versions for all of the projects that may have not tested/validated
with a particular version of docker. The frozen versions are a
maintenance nightmare, they'll bitrot and become security issues.

Our integration and testing with meta-virt is where we make sure that
our latest Docker version meets the needs of the projects, so we don't
need the upstream's project to validate our version. We are like any
other OS in that sense.

>
>
> 2. Docker upstream
>     We are currently using moby. There's another recipe called docker-ce, making use of docker-ce repo. Ubuntu is using docker-ce. I did a little investigation. Moby is actually the community version while docker-ce is maintained by Docker Inc. Do you think we should do something about it? Which one should we prefer? moby or docker-ce?


moby is the default, but I've always maintained a docker-ce recipe for
people that really want to follow that "docker the company" is pushing
out as a stamped version. But that curated version isn't truly the
upstream project. We don't want to follow what the corporation
blesses, we want the community version for a small/tight/new
integratino. We are consuming the bits directly via moby, and hence
can control exactly what we need.

For distros that want docker-ce, they can use the recipe in their
package lists that they need.

I logged this in the docker recipe itself:

#   - This could be called "docker-moby" or just "moby" in the future, but
#     that would require the creation of a virtual/docker dependency, which
#     is possible, but overkill at the moment (while we wait for the upstream
#     to stop changing).

I likely won't make that change for the fall release, but was planning
on doing it for the spring.

>
>
> 3. k8s version
>     The current version is not the latest stable version (1.15.2). I hope this 1.16 version would come be released stable, but we cannot control it. Do you think we should have a stable version of k8s?

With the rate of change of kubernetes and the small support window of
meta-virt, following a stable doesn't make sense at this point.
Tracking the tip/latest is what we do. Just like we do with the
reference kernels.  If there are every truly LTS kubernetes releases,
it could be reconsidered, but keeping more than one version around is
a version/maintenance issue. So going with the latest and greatest is
the best bet.

>
> From what I know, OE's policy is using stable version unless there's some compelling reason. All these container/k8s things are being actively developed, and that could be a reason. But should we also have some stable versions? I don't think users would like to use unstable version in their production environment.
>

The definition of stable varies per project. There's nothing
particularly stable about any given release, so putting cycles into an
older version and claiming it is stable is a false sense of security
for anyone using it.

Bruce

> Best Regards,
> Chen Qi
>
>
> Cheers,
>
> Bruce
>
>
>>
>> Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
>> ---
>>  recipes-networking/cni/cni_0.7.1.bb | 79 +++++++++++++++++++++++++++++
>>  1 file changed, 79 insertions(+)
>>  create mode 100644 recipes-networking/cni/cni_0.7.1.bb
>>
>> diff --git a/recipes-networking/cni/cni_0.7.1.bb b/recipes-networking/cni/cni_0.7.1.bb
>> new file mode 100644
>> index 0000000..7a3b87f
>> --- /dev/null
>> +++ b/recipes-networking/cni/cni_0.7.1.bb
>> @@ -0,0 +1,79 @@
>> +HOMEPAGE = "https://github.com/containernetworking/cni"
>> +SUMMARY = "Container Network Interface - networking for Linux containers"
>> +DESCRIPTION = "CNI (Container Network Interface), a Cloud Native Computing \
>> +Foundation project, consists of a specification and libraries for writing \
>> +plugins to configure network interfaces in Linux containers, along with a \
>> +number of supported plugins. CNI concerns itself only with network connectivity \
>> +of containers and removing allocated resources when the container is deleted. \
>> +Because of this focus, CNI has a wide range of support and the specification \
>> +is simple to implement. \
>> +"
>> +
>> +# 0.7.1
>> +SRCREV_cni = "4cfb7b568922a3c79a23e438dc52fe537fc9687e"
>> +# 0.7.5
>> +SRCREV_plugins = "a62711a5da7a2dc2eb93eac47e103738ad923fd6"
>> +SRC_URI = "\
>> +       git://github.com/containernetworking/cni.git;branch=master;name=cni \
>> +        git://github.com/containernetworking/plugins.git;branch=v0.7;destsuffix=plugins;name=plugins \
>> +       "
>> +
>> +RPROVIDES_${PN} += "kubernetes-cni"
>> +
>> +LICENSE = "Apache-2.0"
>> +LIC_FILES_CHKSUM = "file://src/import/LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
>> +
>> +GO_IMPORT = "import"
>> +
>> +PV = "0.7.1"
>> +
>> +inherit go
>> +inherit goarch
>> +
>> +do_compile() {
>> +       # link fixups for compilation
>> +       rm -f ${S}/src/import/vendor/src
>> +       mkdir -p ${S}/src/import/vendor/
>> +       ln -sf ./ ${S}/src/import/vendor/src
>> +       rm -rf ${S}/src/import/plugins
>> +       rm -rf ${S}/src/import/vendor/github.com/containernetworking/plugins
>> +
>> +       mkdir -p ${S}/src/import/vendor/github.com/containernetworking/cni
>> +
>> +       ln -sf ../../../../libcni ${S}/src/import/vendor/github.com/containernetworking/cni/libcni
>> +       ln -sf ../../../../pkg ${S}/src/import/vendor/github.com/containernetworking/cni/pkg
>> +       ln -sf ../../../../cnitool ${S}/src/import/vendor/github.com/containernetworking/cni/cnitool
>> +       ln -sf ${WORKDIR}/plugins ${S}/src/import/vendor/github.com/containernetworking/plugins
>> +
>> +       export GOPATH="${S}/src/import/.gopath:${S}/src/import/vendor:${STAGING_DIR_TARGET}/${prefix}/local/go"
>> +       export CGO_ENABLED="1"
>> +
>> +       cd ${S}/src/import/vendor/github.com/containernetworking/cni/libcni
>> +       ${GO} build
>> +
>> +       cd ${S}/src/import/vendor/github.com/containernetworking/cni/cnitool
>> +       ${GO} build
>> +
>> +       cd ${S}/src/import/vendor/github.com/containernetworking/plugins/
>> +       PLUGINS="$(ls -d plugins/meta/*; ls -d plugins/ipam/*; ls -d plugins/main/* | grep -v windows)"
>> +       mkdir -p ${WORKDIR}/plugins/bin/
>> +       for p in $PLUGINS; do
>> +           plugin="$(basename "$p")"
>> +           echo "building: $p"
>> +           ${GO} build -o ${WORKDIR}/plugins/bin/$plugin github.com/containernetworking/plugins/$p
>> +       done
>> +}
>> +
>> +do_install() {
>> +    localbindir="/opt/cni/bin"
>> +
>> +    install -d ${D}${localbindir}
>> +    install -d ${D}/${sysconfdir}/cni/net.d
>> +
>> +    install -m 755 ${S}/src/import/cnitool/cnitool ${D}/${localbindir}
>> +    install -m 755 -D ${WORKDIR}/plugins/bin/* ${D}/${localbindir}
>> +}
>> +
>> +FILES_${PN} += "/opt/cni/bin/*"
>> +
>> +INSANE_SKIP_${PN} += "ldflags already-stripped"
>> --
>> 2.17.1
>>
>> --
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


More information about the meta-virtualization mailing list