[openstack-dev] [Heat] Enabling and Reading notifications
Hello, I was looking for guidance as to how to enable notifications in heat and if there is already a tool that can read those events? Looking through the code, it gives somewhat conflicting information as to the extent to which notifications are supported. e.g. [1] says its not supported, but there is an integration test [2] available. Thanks, Pratik [1]: https://github.com/openstack/heat/blob/aa6449ce5df64a95df29a15bfe3edacbefb8f1aa/heat/api/openstack/v1/stacks.py#L222 [2]: https://github.com/openstack/heat/blob/master/heat_integrationtests/functional/test_notifications.py __ 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
[openstack-dev] [Heat]
Hello Heat team, I recently proposed a patch https://review.openstack.org/#/c/246481/ which changes some events when resources are signaled. I was wondering if anyone has any downstream services that depend on the events being in the format specified, since this patch would break that expectation. (Not sure if this is the correct way to solicit this information. Please let me know alternatives, if any :) ) Thanks, Pratik Mallya __ 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
[openstack-dev] [HEAT] Encrypting Default Parameters
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
[openstack-dev] [Heat] Assumptions regarding extensions to OpenStack api's
Hello Heat Team, I was wondering if OpenStack Heat assumes that the Nova extensions api would always exist in a cloud? My impression was that since these features are extensions, they may or may not be implemented by the cloud provider and hence Heat must not rely on it being present. My question is prompted by this code change: [0] where it is assumed that the os-interfaces extension [1] is implemented. If we cannot rely on that assumption, then that code would need to be changed with a 404 guard since that endpoint may not exist and the nova client may thus raise a 404. Thanks, Pratik Mallya Software Developer Rackspace, Inc. [0]: https://github.com/openstack/heat/commit/54c26453a0a8e8cb574858c7e1d362d0abea3822#diff-b3857cb91556a2a83f40842658589e4fR163 [1]: http://developer.openstack.org/api-ref-compute-v2-ext.html#os-interface __ 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
[openstack-dev] [Heat] Talk on Jinja Metatemplates for upcoming summit
Hello Heat Developers, As part of an internal development project at Rackspace, I implemented a mechanism to allow using Jinja templating system in heat templates. I was hoping to give a talk on the same for the upcoming summit (which will be the first summit after I started working on openstack). Have any of you worked/ are working on something similar? If so, could you please contact me and we can maybe propose a joint talk? :-) Please let me know! It’s been interesting work and I hope the community will be excited to see it. 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
Re: [openstack-dev] [Heat] Talk on Jinja Metatemplates for upcoming summit
Hey Pavlov, The main aim of this effort is to allow a more efficient template catalog management, not unlike what is given in [2]. As a service to our customers, Rackspace maintains a catalog of useful templates[3] which are also exposed to the user through the UI. The template authors of these templates had expressed difficulties in having to maintain several templates depending on resource availability, account-type etc., so they asked for the ability to use Jinja templating system to instead include everything in one Heat "meta-template" (Heat Template + Jinja, I’m not sure if that term is used for something else already :-) ). e.g. [4] shows a very simple case of having to choose between two templates depending upon the availability of Neutron on the network. I hope that clarifies things a bit. Let me know if you have more questions! Thanks! -Pratik [3] https://github.com/rackspace-orchestration-templates [4] https://github.com/rackspace-orchestration-templates/jinja-test/blob/master/jinja-test.yaml On Feb 2, 2015, at 1:44 PM, Pavlo Shchelokovskyy mailto:pshchelokovs...@mirantis.com>> wrote: Hi Pratik, what would be the aim for this templating? I ask since we in Heat try to keep the imperative logic like e.g. if-else out of heat templates, leaving it to other services. Plus there is already a spec for a heat template function to repeat pieces of template structure [1]. I can definitely say that some other OpenStack projects that are consumers of Heat will be interested - Trove already tries to use Jinja templates to create Heat templates [2], and possibly Sahara and Murano might be interested as well (I suspect though the latter already uses YAQL for that). [1] https://review.openstack.org/#/c/140849/ [2] https://github.com/openstack/trove/blob/master/trove/templates/default.heat.template Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com<http://www.mirantis.com/> On Mon, Feb 2, 2015 at 8:29 PM, Pratik Mallya mailto:pratik.mal...@rackspace.com>> wrote: Hello Heat Developers, As part of an internal development project at Rackspace, I implemented a mechanism to allow using Jinja templating system in heat templates. I was hoping to give a talk on the same for the upcoming summit (which will be the first summit after I started working on openstack). Have any of you worked/ are working on something similar? If so, could you please contact me and we can maybe propose a joint talk? :-) Please let me know! It’s been interesting work and I hope the community will be excited to see it. Thanks! -Pratik __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
[openstack-dev] [Heat] Vote for talk on using Metatemplates for heat
Hey Folks, In case you missed it, many of you might find the work we’ve done in maintaing catalogs of heat templates interesting. The proposal is here: https://www.openstack.org/vote-vancouver/presentation/one-heat-template-to-rule-them-all Please take a look if you haven’t already, and vote accordingly :-). 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
