<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hello all,
<div class=""><br class="">
</div>
<div class="">I wanted to share my thoughts about the recent patch which I submitted <a href="https://review.openstack.org/#/c/217377/" class="">https://review.openstack.org/#/c/217377/</a>.</div>
<div class=""><br class="">
</div>
<div class="">Abstract of the patch: it removes the encryption of default parameters when running `heat-manage update_params encrypt`.</div>
<div class=""><br class="">
</div>
<div class="">Firstly, the current encrypt/decrypt behavior is incorrect: the default parameter is being read from template itself, and then stored in environment attribute of raw_template object; and if we run decrypt, it will insert the parameter value into
the environment, where it wasn’t originally. So, the encrypt->decrypt process does not bring the raw_template entries in the db back to their original state.</div>
<div class=""><br class="">
</div>
<div class="">This itself makes me think that its a bad idea to extract default parameters and store it as ‘environment parameters’: if we want to record a place for the variables used in the stack creation, we should create another location for it, not store
it as an environment parameter.</div>
<div class=""><br class="">
</div>
<div class="">Second, parameter encryption as its implemented currently, assumes that the parameters being encrypted are strings. This is true when we use the parameters from raw_template.environment: all of the different types are _stored_ as strings in the
db, and in the raw_template object. When fetching the default value of a template however, it is not guaranteed to be a string. This is because the default parameter is fetched from the raw template, and parsing the template might give you integers. e.g</div>
<div class=""><br class="">
</div>
<div class="">
<pre class="">heat_template_version: 2014-10-16
parameters:
flavor:
type: string
description: Flavor for the server to be created
default: 4353
hidden: true
resources:
test_server:
type: "OS::Nova::Server"
properties:
name: test-server
flavor: 2 GB General Purpose v1
image: Debian 7 (Wheezy) (PVHVM)</pre>
<div class="">A json representation of the above template is stored in the db. Trying to determine the default value consists of parsing this template, and in the above template, we will get an integer value, which causes encryption script to fail.</div>
</div>
<div class=""><br class="">
</div>
<div class="">One suggestion I received was that parameter encryption should handle encryption of non-string type properties. This is a fair expectation, imo. This can be easily implemented by simply converting all parameter values to string before encryption,
and decrypting them back to strings and storing them in the environment. Note that I mentioned that the database contains all the parameters as strings, so doing so should not break anything.</div>
<div class=""><br class="">
</div>
<div class="">While the above is a solution for the problem, I think the deeper issue is that we are not tracking the parameters actually used (both default and user-supplied) in stack-creation; these would be very useful during stack-updates, for instance.
Storing them in environment variables, while it may work now, does not seem like the best idea, as it breaks my mental model of what the different structures are suppose to represent. While the patch I submitted does not aim to resolve this issue, imo it does
make the process a bit cleaner so we can come up with a better solution in the future.</div>
<div class=""><br class="">
</div>
<div class="">Let me know your thoughts.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">-Pratik</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</body>
</html>