CNI cosmetics

[errordeveloper]

Paths

We've had to put CNI bits in /opt, as there was no way to tell kubelet to look in other places. As of kubernetes/kubernetes#32151 (already in 1.4), we can pass --cni-bin-dir= as well as --cni-conf-dir= to kubelet. I makes sense to put the plugins into /usr/lib/cni or /usr/lib/kubelet/cni/bin or /usr/libexec/cni - anything other then /opt is good. The reason for this is that traditionally /opt is used for installing ad-hoc pieces, not for things installed by the package manager. We could also move /etc/cni to /etc/kubernets/cni, so we have everything in one directory.

Package name

I seems like kuberentes-cni would be something user has to lookup, calling it kubernetes-cni-basic-network-plugins (or just kubernetes-basic-network-plugins) would make it more obvious. Word "basic" (or "vanilla" or "generic" or something similar) is also good, so we don't give user the impression that they'll have all the plugins.

[luxas]

cc @kubernetes/sig-cluster-lifecycle

I think /etc/cni/bin or just /opt/cni/bin (as it is now) are my preferred locations, as they have to work on CoreOS as well (where /usr/ is ro)

About naming, kubernetes-basic-cni sgtm, if we think we have to change it

[mattymo]

I think cni should definitely be in the package name, with the (searchable) package description being Kubernetes container network interface standard plugins. Deciding over calling the plugins basic, standard, or so on is not too important to me.

Secondly, it would be nice to make a search tree (overrideable by --cni-bin-dir) to meet these requirements. No decent RPM/DEB packager wants to use /opt these days. /usr/lib/$PKGNAME/cni/ or /usr/libexec/$PKGNAME are both okay paths for me. /etc/cni/bin I would -1 because there should be nothing except configuration files in /etc.

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[errordeveloper]

/remove-lifecycle rotten
/lifecycle frozen

[dims]

@errordeveloper @mattymo is this still relevant issue? can we please close the issue otherwise?

[errordeveloper]

I think it relevant.

…

On Tue, 23 Oct 2018, 4:10 pm Davanum Srinivas, ***@***.***> wrote: @errordeveloper <https://github.com/errordeveloper> @mattymo <https://github.com/mattymo> is this still relevant issue? can we please close the issue otherwise? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPWS-jPL7pZpXqSgCt7MK9anc7VFbfyks5unzFWgaJpZM4KDm3H> .

[justaugustus]

/help
/milestone v1.15
/priority important-soon
/area release-eng
related: kubernetes/sig-release#245

[k8s-ci-robot]

@justaugustus:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help
/milestone v1.15
/priority important-soon
/area release-eng
related: kubernetes/sig-release#245

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[justaugustus]

Closing as I agree with @BenTheElder's assessment in #862.

We're planning on moving the CNI plugins into the kubelet package.
See here to track the deprecation of kubernetes-cni deb/rpm packages: #885

/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

Closing as I agree with @BenTheElder's assessment in #862.

We're planning on moving the CNI plugins into the kubelet package.
See here to track the deprecation of kubernetes-cni deb/rpm packages: #885

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.