Change WaitConditionHandle so it provides a pre-signed URL which
allows authenticated wait condition notification via the CFN API
blueprint metsrv-remove
Change-Id: I5c1c3a17ade35c810e49b1f27d80bcfea9e89485
Signed-off-by: Steven Hardy <shardy@redhat.com>
Encapsulate the keystone client in a heat-specific wrapper subclass
so we can put heat-specific implementation related to keystone in
one place. This will allow easier reuse of common code between
resources which need to manipulate stack users and ec2 keys
blueprint metsrv-remove
Change-Id: I3d9751023c52cb75ab5e1f62415b1db4e4361dec
Signed-off-by: Steven Hardy <shardy@redhat.com>
Add a new path to the CFN api, which implements CFN style waitcondition
notification - this means we can move away from the separate heat-metadata
service for this purpose, instead using the authenticated CFN API
blueprint metsrv-remove
Change-Id: I62cff7cb4c7a009fea2c8f62ea446d8d758f5429
Signed-off-by: Steven Hardy <shardy@redhat.com>
Instead of hardcoding the class for handling instances in autoscaling,
look up the class for the AWS::EC2::Instance resource type using the same
mechanism used for creating resources normally.
Change-Id: I37b9aff9a83b89cdc782467720970a04549d7b1e
Signed-off-by: Zane Bitter <zbitter@redhat.com>
Automatically load all resources as "plugins" when importing the package
heat.engine.resources, instead of having to list them explicitly.
Change-Id: I9d11ab9a5b1dd21bc5f9c2f0aad95c035a9c9aa0
Signed-off-by: Zane Bitter <zbitter@redhat.com>
Define the mapping from resource names to classes locally in each module
and then aggregate them. This moves the mappings near the definitions, and
provides the format for an eventual plug-in resource architecture.
Change-Id: I3e70d495c5a490ae20d38bf1aec7e28080a55520
Signed-off-by: Zane Bitter <zbitter@redhat.com>
Leave only the actual resource implementations in the heat.engine.resources
package. This is the first step to implementing a plugin-style architecture
for resources.
Change-Id: I8a63da4f54b087ee792969678f92da8e31787a3e
Signed-off-by: Zane Bitter <zbitter@redhat.com>
This is the result of running:
python tools/cfn-json2yaml templates/
and then cleaning up by hand to be more consistant, readable and
maintainable.
The following templates are enforced to parse to identical stacks
in the unit tests so any fundamental change to one must be made
to the other.
Quantum.template
Quantum.yaml
WordPress_Single_Instance.template
WordPress_Single_Instance.yaml
Change-Id: Ibe05a5c5a7a5bb1861c5f84a3dc41e2d632852fd
Fn::Join now has some preprocessing in resolve_static_data
where contiguous strings are joined into a single string.
This will allow equivalence tests to pass when comparing
JSON templates to hand-tidied YAML
Change-Id: I49fb2456388b3fd554ccec00920d7e84f6998183
So that the YAML format can be more terse, make empty version and
sections imply the lastest version and an empty dict for the
section content.
Change-Id: Ic8b86065534930852fff1488849dbbbbb6b85243
This checks to see if the 'template' attribute is a dict.
If not it uses format.parse_to_template to parse it.
Change-Id: Ic9b9ef3e88a33a93d5896277cc3d4da4fd55fc25
convert_json_to_yaml is a utility function used for tests and file conversion
utilities.
parse_to_template will take any string, infer the format, and parse to a
python structure. Currently it assumes the file is JSON if it starts with '{'
otherwise it attempts to parse it as YAML.
Change-Id: If15ccdaf912693f76b74bb1fe879145af1cb36b1
Enable the resource name to be retrieved from an object. Also allow a
ResourceIdentifier to be constructed from only the data passed through the
RPC API. This means we can use a single format for identifiers, but still
be able to extract important information such as the stack identifier and
resource name.
Change-Id: Ie9122cb1a835b30eb8e0713a9d5cdcb4a386eda7
Signed-off-by: Zane Bitter <zbitter@redhat.com>
The aim is to use a single sqlalchemy session for an RPC request.
The context object passed to EngineAPI methods is actually an RpcContext
which contains the same data as the RequestContext. The @request_context
decorator turns this back into a RequestContext which can now have other
behaviours added to it.
RequestContext now has a lazy loaded session attribute.
Save calls on created entities need to be passed the shared session.
Change-Id: Ied4e66deaca205362b84fb698f75cc872886607d
Avoid saving a session context, instead retrieve the DB stored
credentials for every periodic task trigger, and create a new
session context for each periodic event
Change-Id: I24ca70b478f06be26ca6cc74385b37d1a0cf098d
Signed-off-by: Steven Hardy <shardy@redhat.com>
Add a flag to the stack_get dbapi call, defaulted to False,
which allows us to specify that the admin context is being used
hence we don't want tenant-scoping condition applied.
This is needed to allow the admin context to retrieve stored
credentials per-stack (e.g for the periodic per-stack tasks)
Change-Id: I55e307b7940f7da13bd169271744e80d95ea0bd9
Signed-off-by: Steven Hardy <shardy@redhat.com>
Allow WatchRule.load to initialize an object based on an existing
sqlalchemy DB object, similar to parser.Stack, avoids doing two
DB lookups when running the periodic watch tasks
Change-Id: I280942b81e5fdee17acf5582e3d319045afa7914
Signed-off-by: Steven Hardy <shardy@redhat.com>
Use the stack thread groups, so a separate watch thread is started
for each stack - this avoids some of the context scoping problems
previously encountered since we can pass the correct context to the
periodic task when starting it
Fixes bug 1078779
Change-Id: I56e6a4b126199587e91548f450956d77ab2158f3
Signed-off-by: Steven Hardy <shardy@redhat.com>
Add option to retrieve all watch rules for a given stack, which
will be required to move to periodic watch threads per-stack
Ref bug 1078779
Change-Id: I350e2ee72c7eec0b91bf85ac52bb04e3cd00b4db
Signed-off-by: Steven Hardy <shardy@redhat.com>
Use physical_resource_name to ensure CloudWatchAlarm resources
are unique per tenant
Ref bug 1078779
Change-Id: Id37393decd8d4f89e79af5c7e9eeb21f4e494699
Signed-off-by: Steven Hardy <shardy@redhat.com>
Rework WatchRule to refer to stacks by uuid not name, this will
help us move to allowing non-unique stack names containing WatchRule
resources
Ref bug 1078779
Change-Id: Idbbbd65a05d7036860cc2feb044d568210071d21
Signed-off-by: Steven Hardy <shardy@redhat.com>
Previously a generic read error was given. Inform the user with proper
exceptions for: the case when a resource is present but non-responsive
and when a resource is present but the requested data could not be
found.
Fixes bug 1072951
Change-Id: I35b92cea38358691015f8752e80efc6720e34e48
Signed-off-by: Jeff Peeler <jpeeler@redhat.com>
Since the path stacks/{stack_name}/{stack_id}/resources exists for each
valid stack we can safely redirect to it from stacks/{stack_name}/resources
without having to perform any further checks in the engine, so we may as
well allow it.
Change-Id: I0169493479f8c6840de3edad271cf98e8fd5d1da
Signed-off-by: Zane Bitter <zbitter@redhat.com>
Steven Hardy