Max Rasskazov [Wed, 26 Mar 2014 16:49:02 +0000 (20:49 +0400)]
Patch Allow-Address-Pairs-feature.patch moved to code
Patch has been added to specs by:
> commit 17d6a09efb67cc9b19cc8a051401100e0896c531
> Author: Igor Yozhikov <iyozhikov@mirantis.com>
> Date: Mon Dec 23 16:21:49 2013 +0400
>
> Add new patches instead of 1 old
Patch info:
> From 94350f3206d067e7c9012ac5fb4c40555949d95c Mon Sep 17 00:00:00 2001
> From: Timur Sufiev <tsufiev@mirantis.com>
> Date: Thu, 5 Dec 2013 19:43:57 +0400
> Subject: [PATCH] Added support for Allow-Address-Pairs feature
>
> Added support for feature called Allow-Address-Pairs introduced in
> Ie73b3886c5be8e1fc4ade86a0cfb854267f345ac
>
> Implements: blueprint allowed-address-pairs
> Ported from: icehouse.
Change-request info:
> remote:
> remote: New Changes:\e[K
> remote: http://gerrit.mirantis.com/13908\e[K
> remote:
> To ssh://mrasskazov@gerrit.mirantis.com:29418/openstack/heat.git
> * [new branch] HEAD -> refs/publish/openstack-ci/fuel-5.0/2014.1/Allow-Address-Pairs-feature.patch
Max Rasskazov [Wed, 26 Mar 2014 16:48:49 +0000 (20:48 +0400)]
Patch Ability-to-configure-various-clients-used-by-the-Heat.patch moved to code
Patch has been added to specs by:
> commit 17d6a09efb67cc9b19cc8a051401100e0896c531
> Author: Igor Yozhikov <iyozhikov@mirantis.com>
> Date: Mon Dec 23 16:21:49 2013 +0400
>
> Add new patches instead of 1 old
Patch info:
> From ac190f0da6ce367cc833b92677266e7bbf7e2270 Mon Sep 17 00:00:00 2001
> From: Timur Sufiev <tsufiev@mirantis.com>
> Date: Thu, 5 Dec 2013 19:46:28 +0400
> Subject: [PATCH] Adds ability to configure various clients used by the Heat
>
> This commit adds config sections [clients_nova], [clients_swift],
> [clients_neutron], [clients_cinder], [clients_ceilometer] and
> [clients_keystone]. These sections contain additional configuration
> options for corresponding OpenStack clients.
> Currently those are only SSL-related setting ca_file, cert_file,
> key_file and insecure. Note, than not every client library is
> currently capable of utilizing all of the SSL settings.
>
> There is also a plain [clients] section that holds shared client
> options. Each option searched first at specific group (clients_xxx)
> and if it not found there then the value from [clients] group
> are taken (or default values if there is no such setting in this
> group). This allows defining shared configuration that would be
> used by most (or all) clients without repeating the same settings
> for each and every client separately
>
> Closes-Bug: #1213122
> Implements: blueprint clients-ssl-options
> Ported from: icehouse.
Change-request info:
> Your change was committed before the commit hook was installed.
> Amending the commit to add a gerrit change id.
> remote:
> remote: New Changes:\e[K
> remote: http://gerrit.mirantis.com/13907\e[K
> remote:
> To ssh://mrasskazov@gerrit.mirantis.com:29418/openstack/heat.git
> * [new branch] HEAD -> refs/publish/openstack-ci/fuel-5.0/2014.1/Ability-to-configure-various-clients-used-by-the-Heat.patch
Previous patches raise an error when a newly created stack would exceed
the limit. This one applies the same logic during an update. Note that
nested stack updates will be handled in another patch.
Steven Hardy [Thu, 19 Sep 2013 21:31:16 +0000 (22:31 +0100)]
Tolerate bad environment until validation
Currently if we get a bad environment for a template_resource,
it causes an exception in the resource constructor, which does cause
the stack create to fail, but also all subsequent operations too.
By tolerating the error in the constructor, we can catch it instead at
validation time.
In an earlier patch, the root stack creation was limited by the
max_resources_per_stack config setting. Now we need to apply the same
limit for nested stacks.
Provide config option to limit resources per stack
This provides an upper bounds on the number of resources a root level
stack can contain. The limitation is only applied to the engine creation
point so that existing stacks that are over the limit in the database
will not cause problems. Nested stacks will be addressed in a follow-up
patch.
Current implementation of get_flavor_id throws exception if input
value is a flavor id. This method is used in couple of resources
where input flavor could be flavor id. This change is to avoid
throwing exception if the input is flavor id.
This adds descriptions to the properties of:
* OS::Neutron::VPNService
* OS::Neutron::IPsecSiteConnection
* OS::Neutron::IKEPolicy
* OS::Neutron::IPsecPolicy
as well as gettext wrapping for the attributes description
Use the generic RequestLimitExceeded exception when possible
Rather than having lots of specific exceptions that all pertain to request
limitation, we can just use the RequestLimitExceeded exception when applicable,
which can also simplify the handling of exception mapping in fault.py.
In order to limit a stack's size in future changes, we need to know
how many resources are already in the stack. We also need to be able
to find the root stack object of a nested stack.
Steven Hardy [Thu, 12 Sep 2013 11:00:28 +0000 (12:00 +0100)]
Migrate remaining TEXT columns to LONGTEXT
To avoid cases where mysql silently truncates json data
when it is > 2^16 bytes, migrate all remaining TEXT columns
to LONGTEXT, in a similar way to the fix for bug #1210799
Combined with the fix for bug #1215501 which limits the request
body size, we should never truncate, even if mysql is configured
such that it can happen
Currently if defined SecurityGroups and SubnetId properties for
instance in heat template, the SecurityGroups were not associated
to the port created within the previous SubnetId, in another word,
the instance are not allocated to the specified security groups
defined in heat template.
* Modifies function _build_nics() in instance.py, adding an item
'security_groups' in the post body of create_port sending by neutronclient.
* Adds a new function _get_security_groups_id() to map security_groups
names to ids.
* Adds corresponding unit tests.
Use physical_resource_name as Ref for Instance/AS Group
This allows to distinguish groups by stack when using resource
OS::Metering::Alarm with the rule:
matching_metadata: {
'metadata.user_metadata.groupname': { 'Ref': 'WebServerASGroup'}}
Previously if any exceptions accidentally made their way to
eventlet.wsgi.server's response handler it would print their traceback.
We only want to show users tracebacks in debug mode. In production we
want them suppressed.
API services currently send the traceback to clients. While the client
hides it from user view, it is still present in the response, exposing
the service to details of the engine that administrators likely would
not like to have exposed.
The old dbinstance will soon be overtaken by the trove resource.
- The only reason for keeping this around is for people that don't
have trove installed and want to use the AWS resource.
- Seperating it out into a TemplateResource really makes it easier
for deployers and users to customise it.
- The old dbinstance did nothing "special" in python, and was really
one of the first "TemplateResources" as it attempted to convert properties
into parameters. Since this in now done a lot better in the TemplateResource
lets just make use of that.
This will make it easier to migrate to other distros and versions.
At the moment we need the templates installed into /etc/heat/templates
and this is not very nice for the tests. So this patch
replaces "/etc/heat/templates" with the project's own template
path so we can at least test the api of the template resources.
Code Review / openstack-build / heat-build.git / log