Open Stack

Hi, I recently stumbled on this bug https://bugs.launchpad.net/magnum/+bug/1680900 in which Spyros says we are about to hit the 64k limit for Nova user-data.

One way to prevent this is to reduce the size of software config. But there is still many things to be added to templates.

I’m talking only about Kubernetes for now :

I know some other Kubernetes projects (on AWS for example with kube-aws) are using object storage (AWS S3) to bypass the limit of AWS Cloudformation and store stack-templates and user-data but I don’t think it is possible on OpenStack with Nova/Swift

Since we rely on an internet connection anyway (except when running local copy of hypercube image) for a majority of deployment when pulling hypercube and other Kubernetes components, maybe we could rely on upstream for some user-data and save some space.

A lot of driver maintenance include syncing Kubernetes manifest from upstream changes, bumping version, this is fine for the core components for now (api, proxy, controller, scheduler) but is bit more tricky when we start adding the addons (which are bigger and take a lot more space).

Kubernetes official salt base deployment already provides templating (sed) for commons addons, e.g.:

https://github.com/kubernetes/kubernetes/blob/release-1.6/cluster/addons/dns/kubedns-controller.yaml.sed

These template are already versioned and maintained by upstream. Depending on the Kubernetes branches used we could get directly the right addons from upstream. This prevents errors and having to sync and upgrade the addons.

This is just a thought and of course there are downsides to this and maybe it goes against the project goal because we required internet access but we could for example offer a way to pull addons or other config manifest from local object storage.

I know this also causes problems for idempotence and gate testing because we cannot vouch for upstream changes but in theory Kubernetes releases and addons are already tested against a specific version by their CI.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170424/f739af0b/attachment.sig>