Open Stack

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/819073f6/attachment.html>