On Mon, May 15, 2017 at 02:09:41PM -0700, Tim Pepper wrote:
On Mon 15 May at 17:41:00 +0000 manohar.r.castelino(a)intel.com said:
> > kubernetes manages all, it just need the binary to be there :-)
> Why do we need the binary here. We should be able to kubectl deploy
> to instantiate the plugin. We are doing this to solve the stateless
> directory layout issue.
> If so we should fix the underlying issue vs packaging the weave binary.
Marcos & Obed: given the binary will be managed by kubernetes and not
systemd integrated, what's the benefit of packaging weave versus kubectl
deploying? From a user perspective it's not necessarily easier having the
dep's in the OS, and is even a potential point of confusion if typical
is having kubectl handle requirements. And the kubectl route means the
user has ability to control their specific dependencies' versioning,
insuring they get just what they want right? ClearLinux's fast moving
base is likely to be too fast for some conservative users and not fast
enough for the very CI/CD oriented users. It doesn't feel like a cloud
native approach to throw into the OS the plugins we think are interesting
at the versions we think are interesting.
Relative to the ClearLinux stateless feature, I prefer an approach which
patches kubernetes in support of statelessness. Such a patch would be
a great thing to propose as an upstream kubernetes PR. There's been
previous discussion of this in the k8s community. Code talks.
I agree, pushing the binaries doesn't make the issue to go away, however
I would buy us more time to get it done right while also provide something that
I've been working for a patch that works for almost 2 weeks now with no success,
hence the workaround, but if this is not wanted at all I'm also OK with that as
long as it's understood that it'll take more time to get this to work out of the
This would apply for both weave and calico CNI plugins.