Support for using existing etcd about puppetlabs-kubernetes HOT 13 CLOSED

I wasn't talking about adding a dependency to an external module - more the option of using an existing etcd cluster (which I could then setup with a diff. module if I wanted to).

from puppetlabs-kubernetes.

None of our servers that run public websites - have internet access. (for good reason - if a security flaw is found - the most likely place to find a "canary" - is by blocking traffic to internet - and watching those logs (they should be empty) (and hacked servers most often try to connect to some irc channel or other botnet control channel - which gets harder when they can't just connect out from the server). This is why we have mirrors of everything we use - and package everything. I f.ex. package kubernetes releases - and would like module to support using packages to install things, instead of expecting all servers to have internet access.

from puppetlabs-kubernetes.

@KlavsKlavsen we are not going to add a dependency to an external etcd module. The reason for this is support. Also this module only supports etcd with ssl, it will not work without SSL. What ssl options are missing ?

from puppetlabs-kubernetes.

@KlavsKlavsen that still leaves us with a support issue that I mentioned earlier. This module is supported and if there is an issue with your cluster all the settings are within this module which allows us to support it, if you have any issues in which the kube API server does not start due to the configuration of the external etcd server. How can we support that without a lot of troubleshooting?

from puppetlabs-kubernetes.

well then atleast support using a package instead of downloading an older version of etcd ?
Ubuntu 18.04 has 3.2.17. just as you do with docker-engine

from puppetlabs-kubernetes.

and just as you depend on other modules for some things (and choose NOT to depend on docker because it was JUST a simple package) - one could argue that you could have an optional dependency for the etcd module I suggest - which supports using Ubuntu 18.04's etcd package and sets it up. Testing it that works or not - is fairly easy, by just calling with with etcd-client.

from puppetlabs-kubernetes.

@KlavsKlavsen we are using the etcd version that the upstream Kubernetes recommends. What functionality is missing from etcd to run Kubernetes? Also I am interested to hear why installing from GitHub as the tagged release is better/worse than using apt or yum

from puppetlabs-kubernetes.

And probably you should also support to install etcd as a docker controlled service instead? just as kubespray does by default. Atleast then I could point that to my own dockerregistry server :)

from puppetlabs-kubernetes.

totally agree with @KlavsKlavsen

=> @scotty-c another point is the param $etcd_version.
I'd expect that if I set a version, then puppet brings my machine into this state.
With the archive / exec approach you can't upgrade without manually removing the binary.

2. Personally I also want to keep my system clean / minimal (e.g. without wget and 3rd party puppet modules)
3. with package you already have a powerful provider for installations maintained by puppetlabs.
   only define the package and that's it..
4. there are other security aspects: package signing keys

from puppetlabs-kubernetes.

@khaefeli, not all OS vendors have etcd packages and if they do they don't have all the versions. For example, Ubuntu 16.04 only has 2.2.5. So what would be the suggestion to for those users?

from puppetlabs-kubernetes.

@scotty-c To NOT tell kubernetes module that they already have an ETCD cluster they want it to use - and your module would do its default - to setup etcd itself :)

from puppetlabs-kubernetes.

usually there is a reason, why the package version is a little bit older in the package repo's.
if you choose an OS LTS version, you should always remember why you've chosen it:
long-term stable

if you want to have the latest features, you should:
a) upgrade to the latest Ubuntu version
b) accept the risks and use a backports package or use the software vendors repo / builds (like the github archive)

this is why I'd suggest to provide options (like other puppetlabs modules):

1. manage_etcd (boolean - default: true)
2. etcd_version (default: OS version default - no version hardcoding needed)
3. manage_etcd_repo (boolean: default: false)

notes:

1. provides the option to manage the etcd package with another module from forge or manually.
2. provides the option to enable / disable the default package versions
   true => enables a different repo / backports (maybe only if the requested version isn't available in the OS repo)
   false => don't care about the repos (and maybe use the github archive download for the latest go binary)

from puppetlabs-kubernetes.

@khaefeli We are not going to change the module to be able to manage etcd externally as mentioned earlier in the conversation.

I think it is unreasonable to tell people to upgrade there OS to support the etcd version with Puppet when that is not required upstream by Kubernetes or Kubeadm.

There are features that will address some of the issues in next release we will fix

from puppetlabs-kubernetes.