Open Stack

Hi Kevin.

We've hit this locally in the past, and adding core-dns i see the
sample for kubernetes atomic.

Spyros is dropping some fragments that are not needed to temporarily
get around the issue. Is there any trick in Heat we can use? zipping
the fragments should give some gain, is this possible?

Cheers,
  Ricardo

On Mon, Apr 24, 2017 at 11:56 PM, Kevin Lefevre <lefevre.kevin at gmail.com> wrote:
> 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.
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>