On Tue, Aug 13, 2019 at 9:28 PM ChenQi <[email protected]> wrote: > > On 08/13/2019 08:31 PM, Bruce Ashfield wrote: > > > > On Tue, Aug 13, 2019 at 3:52 AM Chen Qi <[email protected]> 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 <[email protected]> >> --- >> 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 >> [email protected] >> 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 -- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
