cloud-init uses cheetah for template rendering. It's a fine template language, but,
a) it's really not used very much
b) it pulls in a lot of dependencies that we really don't want in the minimal image.
Specifically, freetype, jbigkit-libs, lcms-libs, libjpeg-turbo, libtiff, libwebp, python-markdown, python-pillow, python-pygments, python-setuptools.
Since this is probably considerable work, I should add that the rationale here is more than "these packages take up bits" and "it looks silly on the image". Those things are true, but the more important thing is that historically, these graphics libraries are rife with security-sensitive bugs and often need updating. As we push the cloud image to be more primary, will probably need to start respinning for security updates, and we want to minimize the situations when that happens. Getting these things off the image significantly improves that position.
I am looking into it.
So on running grep cheetah this is what I find.
1:./cloud-init/packages/debian/changelog.in:## This is a cheetah
2:./cloud-init/packages/debian/control.in:## This is a cheetah template
4:./cloud-init/packages/redhat/cloud-init.spec.in:## This is a cheetah
6:./cloud-init/packages/suse/cloud-init.spec.in:## This is a cheetah
This are the places it seems to appear in the whole project.
I am going into them step by step to see what I can do about it.
Kindly excuse me for giving preference to 4 and 5 as this is what affects us here.
according to ./cloud-init/Requires:
# Used for untemplating any files or strings with parameters.
I therefore think that we may need to do it our own way if we need this to be dropped.
I am going to look into the design of it and see what is required.
This seems to be the only reason cheetah is here.
(In reply to Frankie Onuonga from comment #4)
> according to ./cloud-init/Requires:
> # Used for untemplating any files or strings with parameters.
> I therefore think that we may need to do it our own way if we need this to
> be dropped.
> I am going to look into the design of it and see what is required.
> This seems to be the only reason cheetah is here.
Awesome -- thanks!
Ok so I put this up with the package guys who are on the mainline (upstream) and we are looking into a lighter option with similar syntax. It also therefore means we will need to do a version bump up.
This is going to be a long term fix.
At least we have the discussions going on for now.
(In reply to Frankie Onuonga from comment #6)
> Ok so I put this up with the package guys who are on the mainline (upstream)
> and we are looking into a lighter option with similar syntax. It also
> therefore means we will need to do a version bump up.
> This is going to be a long term fix.
> At least we have the discussions going on for now.
Thanks Frankie. That sounds like absolutely the right approach and is very, very helpful -- even if it takes a while.
For some reason I was removed from the cc of this mail list.can I kindly be added back.
Yes sure no problem at all about this.
I think I will follow up and constantly update on progress.
sorry I have been off for sometime. Just to update.
I am going to mainstream to discuss some of the template engines found here.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.
More information and reason for this action is here:
We're going to need this in F21, so changing back to rawhide.
Also, I'd like to add to the OP that the cheetah stuff is now also pulling in additional packages (according to the package changelog, that used to be a bug) that we really don't want in our cloud images. Things like ghostscript and a few fonts. So this has actually gained more importance to us.
See also https://bugs.launchpad.net/cloud-init/+bug/1247132
It looks like cloud-init 0.7.6 addresses this actually.
Created attachment 957711 [details]
0.7.6 works here, ok if I push this to rawhide?