Merge ~harlowja/cloud-init:no-cheetah into cloud-init:master
| Status: | Work in progress |
|---|---|
| Proposed branch: | ~harlowja/cloud-init:no-cheetah |
| Merge into: | cloud-init:master |
| Diff against target: |
62 lines (+11/-12) 2 files modified
cloudinit/templater.py (+11/-9) setup.py (+0/-3) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Server Team CI bot | continuous-integration | Needs Fixing on 2017-03-06 | |
| Scott Moser | 2016-10-12 | Disapprove on 2017-01-11 | |
|
Review via email:
|
|||
| Scott Moser (smoser) wrote : | # |
| Scott Moser (smoser) wrote : | # |
per Josh in irc:
so in [1] if people still have cheetah installed, and there templates say to use cheetah explicitly then it will still continue using cheetah the default though does change from:
- LOG.debug("Using Cheetah as the renderer for unknown template.")
- return ('cheetah', cheetah_render, text)
to jinja this maybe should cause a 0.8.0 version, idk
--
[1] https:/
| Joshua Harlow (harlowja) wrote : | # |
Ya, this changes the default away from cheetah; might be smart to bump some version number to denote this (just incase).
| Scott Moser (smoser) wrote : | # |
one thing we could do that would guarantee backwards compatibility would be to switch to jinja as default/unknown for python3 only, and still use cheetah for unknown in python2.
| Joshua Harlow (harlowja) wrote : | # |
that could be a solution; i'd be ok with that, other option is to release cloud-init 1.0 and switch it then.
| Scott Moser (smoser) wrote : | # |
I think that we should probably just leave this as it is.
I dont want to change the 'unknown' renderer to jinja. i'd prefer that be basic.
and in python3, since cheetah will never be available we have unknown -> basic.
The one change i think is valid is that its probably better to raise the exception on explicit 'jinja' request when jina isnot available then try to render it with the basic renderer which isnt even close.
| Scott Moser (smoser) wrote : | # |
Just to summarize. I'm going to leave this as 'Disapprove'.
Things we could do here:
* use the TemplaterNotFou
* explicitly make the renderer of unknown be 'builtin' if python3 (rather than implicitly getting that affect by the fallback since there will not be cheetah on python3).
FAILED: Continuous integration, rev:31b3af8d927
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https:/
https:/
Executed test runs:
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
Moving this to work-in-progress, feel free to move back to needs review if changes are made.
Unmerged commits
- 31b3af8... by Joshua Harlow on 2016-10-12


I think I'm OK with this. The big thing really is external users. But anyone using Python 3 has already moved.
Can you verify that there is no actual runtime change if cheetah is available (or on an existing distribution)