This commit adds the configuration options related to resource limits
in the Heat project. The `max_software_configs_per_tenant`,
`max_software_deployments_per_tenant`, and `max_snapshots_per_stack`
options have been added to control the maximum limits for software
configs, software deployments, stack snapshots.
Story: 2011006
Task: 49401
Change-Id: If33a1c6f3eb9e93f586931bc5c05104439c92bf9
Snapshot.get_all does not return all snapshots of the project but
returns all snapshots associated with a single stack, so its name
should contain _by_stack for consistency.
Change-Id: Ic6b93b7cfc84793077672b3f1052f03519e4c5a1
We don't have another ORM to content with here. Simplify
'heat.db.sqlalchemy' to 'heat.db'.
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change-Id: Id1db6c0ff126859f436c6c9b1187c250f38ebb62
With I04e7ad90944c2d03ce0e59ba16af9d60d6e01222 we allowed
update of previously-existing resource if replacement
creation has failed during last update. However, we force
update the status of the existing resource to 'COMPLETE'.
Therefore, in the next update if properties/type has not
changed for the resource it won't try to update/replace
the previously existing resource resulting in false positive
of stack updated successfully.
Task: 42194
Change-Id: Icc90a921ec67e49aec2c4acfad72235c57c78421
A simple matter of having log lines fit
with all the others. It will now match the
ambiguous standard.
Also change comments inline to alias with log fixes.
Change-Id: I4a2ed6134f70c2965811f75ccb6ab8221fa0e960
Story: #2007319
Task: 38830
Six is in use to help us to keep support for python 2.7.
Since the ussuri cycle we decide to remove the python 2.7
support so we can go ahead and also remove six usage from
the python code.
Review process and help
-----------------------
Removing six introduce a lot of changes and an huge amount of modified files
To simplify reviews we decided to split changes into several patches to avoid
painful reviews and avoid mistakes.
To review this patch you can use the six documentation [1] to obtain help and
understand choices.
Additional informations
-----------------------
Changes related to 'six.b(data)' [2]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
six.b [2] encode the given datas in latin-1 in python3 so I did the same
things in this patch.
Latin-1 is equal to iso-8859-1 [3].
This encoding is the default encoding [4] of certain descriptive HTTP
headers.
I suggest to keep latin-1 for the moment and to move to another encoding
in a follow-up patch if needed to move to most powerful encoding (utf8).
HTML4 support utf8 charset and utf8 is the default charset for HTML5 [5].
Note that this commit message is autogenerated and not necesserly contains
changes related to 'six.b'
[1] https://six.readthedocs.io/
[2] https://six.readthedocs.io/#six.b
[3] https://docs.python.org/3/library/codecs.html#standard-encodings
[4] https://www.w3schools.com/charsets/ref_html_8859.asp
[5] https://www.w3schools.com/html/html_charset.asp
Patch 14 of a serie of 28 patches
Change-Id: Iccb743056c631f2e0728013942d764cd8b1ecfe0
Use a single write to the database to convert each resource. Add a
method to the versioned object class that encapsulates the DB-specific
information, and get rid of the Resource.set_requires() classmethod that
just calls a method on the versioned object instance that's passed to
it.
Change-Id: Ieca7e0f0642c38c44fb8d7729333a0ccd93c9cb4
This adds a limit to the number of resources that ResourceChain creates
in parallel. It reduces memory usage drastically when ResourceChain
contains lots of resources. We use the number of active services, which
seems to give a reasonable balance between performance and memory
consumption.
Story: #2003975
Task: #26917
Change-Id: Id20fb89813b32927298b3a7c0abe23da710b04d1
When handling the command "openstack stack event list --nested-depth=n", we
obtain the list of nested stacks by querying the database for all resources
that share the root stack ID. However, since all we're getting is the stack
IDs, there's no need to query all of the fields and construct a versioned
object for each resource. Just get the set of stack IDs.
Change-Id: I12155433e2ac1af919aa4b5e780fb965cd5885d8
Related-Bug: #1588561
When doing "openstack stack resource list --nested-depth=n", we were
lazy-loading the resources' properties data. This is expensive, especially
when there are a large number of resources. Eager-load the data, as we
always use it to show the resources.
For consistency, always eager-load the resource 'data' (even in
resource_get), because the Resource versioned object accesses it
unconditionally.
Change-Id: Idb871fddf77bf24828878c315e19e200c28841be
Related-Bug: #1665503
Use a single transaction to create the replacement resource and set it as
the replaced_by link in the old resource. Also, ensure that no other
traversal has taken a lock on the old resource before we modify it.
If we end up bailing out and not creating a replacement or sending an RPC
message to check it, make sure we retrigger any new traversal.
Change-Id: I23db4f06a4060f3d26a78f7b26700de426f355e3
Closes-Bug: #1727128
In I462ce7161497306483286b78416f9037ac80d6fa we changed to use the
frozen_defintion properties for delete. However, When deleting a
resource from backup stack, where the resource is in INIT_COMPLETE,
setting the _stored_properties_data(_properties_data) to {} when
loading the resource from the db, results in error, when resources
access properties in handle_delete.
Change-Id: If76372c7ef9aee258efb1bfbc724d8637bc6a32c
Closes-Bug: #1709682
Eager load resource_properties_data in resources in the typical
resource-loading scenarios where properties data will be
accessed. Thus, we can save an extra db query per resource when
loading all the resources in a stack, for instance. Fall back to lazy
loading properties data in other scenarios.
Also, the resource object doesn't need to store a copy of its
ResourcePropertiesData object in self.rsrc_prop_data, so don't.
Change-Id: Ib7684af3fe06f818628fd21f1216de5047872948
Closes-Bug: #1665503
To avoid hard-to-debug bugs, rather than represent a db_stack's
raw_template as None if it hasn't been eagerly loaded, lazy load
it. In the lazy loading case, log a warning so developers are aware
there is a non-eager loading query that needs to be fixed.
Change-Id: Ic06a4bd7afbd4838ca97be302d75dede5402ae6e
Store resource attributes that may be cached in the DB, saving the
cost of re-resolving them later. This works for most resources,
specifically those that do not override the get_attribute() method.
Change-Id: I71f8aa431a60457326167b8c82adc03ca750eda6
Partial-Bug: #1660831
This was most likely meant as a max 2s delay here, not a max 2ms
delay.
Also includes a related change: when retries for metadata updates are
attempted, make sure we do not have a stale value of the atomic_key
(otherwise we'll just inevitably hit the ConcurrentTransaction issue).
Co-Authored-By: Crag Wolfe <cwolfe@redhat.com>
Partial-Bug: #1651768
Change-Id: Ie56e0e4ff93633db1f4752859d2b2a9506922911
Sometimes we know we will only access particular fields of a resource
object, rather than *all* of them. This commit allows the caller to
specify (optionally) the fields that should be populated when the
resource object is instantiated. This saves memory, trips to the db,
and in some cases avoids extra join queries (e.g. for resource.data or
resource.rsrc_prop_data).
Change-Id: I405888f46451d2657aa28f610f8ca555215ff5cf
Partial-Bug: #1680658
Eager load an event's resource properties data in the list_events
"show event" case, i.e. when an event uuid is specified. When showing
multiple events, the events' resource properties data should not be
eager loaded.
Change-Id: I12e371dcbdae398360e28200e68f4a75831f8f17
Closes-bug: #1665506
Working towards the goal of storing resource attributes in the db so
as to avoid re-resolving them when appropriate. Adds an 'attr_data'
object to the resource object, defined as a relationship on the
already existing resource_properties_data table.
Change-Id: I2104078d850da08b22547d7feab2bde00c543478
Partial-Bug: #1660831
Typically when retrieving a large number of events, we don't need to
load resource_properties_data for each event.
Change-Id: I6564fea91d19c24409075152a614cc036dc1ee34
Add the resource_properties_data association to resource and event
objects. The resource and event engine objects do not use yet
it but will soon.
Change-Id: Idecaafffbc5e9bfcd2355e2a165836a5ed89b16f
Prepare for the future when both resources and events refer to
ResourcePropertiesData rather than store the data themselves.
Change-Id: I0c5aefa9d73e1281e6477d46fe181d8948aee71b
The db.api module provides a useless indirection to the only
implementation we ever had, sqlalchemy. Let's use that directly instead
of the wrapper.
Change-Id: I80353cfed801b95571523515fd3228eae45c96ae
It's possible that we could end up with multiple resources with the same
physical resource ID, but that would be undetectable since we return only
one from the database layer. This change allows us to detect the problem an
return an error where the result is rendered ambiguous.
Change-Id: I2c5ddbe6731c33a09ec7c4a7b91dcfe414da4385
Just a refactor, no change in functionality.
The functions added to crypt are used to encrypt / decrypt resource
properties data dicts. Note that they should not be used for
encrypting / decrypting other things such as params or user creds
(which are just strings). An intermediate json conversion of each
value in a dict takes place before it is encrypted/decrypted.
Change-Id: Id6bcc90cbf430095719315ac7e9d3e8c9e745012
We are replacing all usages of the 'retrying' package with
'tenacity' as the author of retrying is not actively maintaining
the project. Tenacity is a fork of retrying, but has improved the
interface and extensibility (see [1] for more details). Our end
goal here is removing the retrying package from our requirements.
Tenacity provides the same functionality as retrying, but has the
following major differences to account for:
- Tenacity uses seconds rather than ms as retrying did.
- Tenacity has different kwargs for the decorator and
Retrying class itself.
- Tenacity has a different approach for retrying args by
using classes for its stop/wait/retry kwargs.
- By default tenacity raises a RetryError if a retried callable
times out; retrying raises the last exception from the callable.
Tenacity provides backwards compatibility here by offering
the 'reraise' kwarg.
- Tenacity defines 'time.sleep' as a default value for a kwarg.
That said consumers who need to mock patch time.sleep
need to account for this via mocking of time.sleep before
tenacity is imported.
- For retries that check a result, tenacity will raise if the retried
function raises, whereas retrying retried on all exceptions.
This patch updates all usages of retrying with tenacity.
Unit tests will be added/removed where applicable.
[1] https://github.com/jd/tenacity
Closes-Bug: #1635388
Change-Id: Iec0822cc0d5589b04c1764db518478d286455031
When partially removing eager loading of raw_template in stacks
(260b79ed28), we didn't get into account
that accessing the sqlalchemy field would create an additional query
whereas it was previously eager loaded. This removes it by only filling
the field when it's already fetched.
Change-Id: Ifa17c74e3559adaef56593a205101d92e9a37da5
Closes-Bug: #1634127
Always loading the raw template in situations where we didn't need it -
e.g. in identify_stack, where we just want the name + id (given one of
them), or when getting the summary stack list - uses up DB bandwidth and
memory unnecessarily.
This partially reverts commit 3ab0ede98c.
* The eager_load option to get_stack() is reinstated, but with the default
flipped to True. In places where we explicitly do not want to load the
template, we pass False.
* stack_get_by_name() no longer eagerly loads the template. There were no
instances of this where we subsequently use the template.
* stack_get_all() acquires an eager_load option, with the default set to
False. Direct users of objects.stack.Stack.get_all() will not eagerly
load by default, but users of engine.stack.Stack.load_all() will get the
template eagerly loaded. This practically always corresponds to what you
want.
Change-Id: I1f156c25ea26322be5b606a61dd77d80cadd65fc
Related-Bug: #1626675
Run `heat-manage migrate-convergence-1 <stack_id>` to migrate
legacy stack to convergence engine.
Heat engine is used for doing migration i.e. migration can't
be done offline.
Change-Id: Ie7c2498b37937438f16d154b154b3a6ecbf9ff74
Implements-bp: convergence-migrate-stack
We can use admin_context to have access to stacks
and software configs across projects. This removes
the tenant_safe flag from rpc and db api. This is
backward compatible with older rpc clients.
We still support use of global_tenant flag for listing
stacks and software configs. However, by default
an admin(user with admin role in admin_project)
would not need that.
Change-Id: I12303dbf30fb80290f95baba0c67cdf684f5f409
A context cache which memoizes the resources fetched by calls to
Resource.get_all_by_root_stack(..., cache=True)
which are recalled by subsequent calls to Resource.get_all_by_stack.
Because get_all_by_stack returns a collection instead of a single
resource, there is no way of taking advantage of the SQLAlchemy
identity map [1].
[1] http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#is-the-session-a-cache
Change-Id: Ia5aae0c86a586041020e9798566c9e0af48c180d
Partial-Bug: #1578854
The vast majority of stack fetches are immediately followed by a
raw_template fetch, so this change always eagerly fetches the
raw_template for every stack fetch.
During stack versioned object creation the stack's raw_template object
is used to construct the versioned raw template object.
Change-Id: I1a6fb8fb7d069b50dd5d623c989acd5582818ae1
Related-Bug: #1479723
Related-Bug: #1523748
lujiefsi