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.
Steve Baker [Thu, 5 Sep 2013 23:39:43 +0000 (11:39 +1200)]
Set a small max_template_size for test_long_yaml
Currently this test takes 22 seconds to run. As the intent
of the test seems to be to assert that limits are enforced,
this change reduces the default limit to speed test execution time.
Steve Baker [Fri, 30 Aug 2013 05:21:56 +0000 (17:21 +1200)]
Only validate credentials on create based on resources
This change relaxes the validation which checked for credentials
on stack create and update.
As implemented, having any of the following resources
in the template will result in credentials being mandatory
on create and update:
* AWS::AutoScaling::ScalingPolicy
* OS::Heat::HARestarter
* AWS::CloudFormation::WaitConditionHandle
For all other templates, credentials are not needed.
When trusts are merged, this logic could also be used to decide
whether a trust token needs to be created at all.
Code Review / openstack-build / heat-build.git / log