Hello all,
I wanted to share my thoughts about the recent patch which I submitted
https://review.openstack.org/#/c/217377/.
Abstract of the patch: it removes the encryption of default parameters when
running `heat-manage update_params encrypt`.
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.
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.
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
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)
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.
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.
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.
Let me know your thoughts.
Thanks,
-Pratik
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
