acstgen: consider: replace base64/gzip trick with proper inlining in ARM template about acs-engine HOT 7 CLOSED

Well, more importantly, it won't work for certain things that need interpolation into them (kube-proxy needs to have kubernetesHyperkubeSpec woven into it...

from acs-engine.

Another limit to consider is CRP's limit on CustomData (I think around 85k chars). It will be great to avoid downloading provisioning scripts externally, and keep these in CustomData or CustomScriptExtension as the network can be still stabilizing during provisioning.

from acs-engine.

CRP's limit of custom data is: 64k characters or 87380 Base64 characters

from acs-engine.

I think the problem we're hitting currently is that the string expression limit is much smaller, like 16K or something. I can dig up details, I think Anders raised it previously for me whenever I was doing similar stuff with azkube.

from acs-engine.

I was playing around doing something similar in cloud-formation and very quickly hit the 64K userdata limit.

from acs-engine.

There's three different issues I see here:

1. We shouldn't have so many helper functions that purely serve to do string munging, base64 and gzip. We should have helper funtions injected into the template context so that someone can do {{ .SomeField | b64 | gzip }}. A large amount of boiler plate template functions could be purged.
2. There is an upper-bound of 64K on userdata. I don't think acs-engine is in any risk of hitting this anytime soon.
3. There is an upper-bound of 16K for string expressions in the template. I was just told that we could potentially get this bumped up higher if needed.

from acs-engine.

doesn't look like we are actually going to do this. Closing it. Reopen if you have objections

from acs-engine.