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
This also gets us away from autocommit, i.e. the last outstanding item
in our preparation for SQLAlchemy 2.x.
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change-Id: I95c5e5d6b33e73a1df2bf036df44aa2e06cc9640
Software deployments have FK constraints on software configs.
This change ensures the DBReferenceError caused by the constraints is
properly caught. With this change now heat returns 400 Bad Response,
instead of 500 Internal Server Error when a user tries to create
a software deployment with a non-existing software config.
Also, the stack_user_project_id field is defined as 64-chars-long
string in DB model, so we should ensure that the input value is shorter
than 65 chars. Otherwise it also results in DB error.
Story: 2010001
Task: 45098
Change-Id: I03274dc0cffa226140eb720458cce81e8b5ce187
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
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 13 of a serie of 28 patches
Change-Id: I09aa3b7ddd93087c3f92c76c893c609cb9473842
While we are careful to ensure there are no race conditions in updating
the software deployment metadata in the Heat database, there was no such
protection in place for the actual update of the metadata provided to
the server via Swift. In legacy Heat, this race could only occur when
software deployments were created from the REST API or from separate
stacks deploying software to the same server, because resources in the
same stack were handled by a single thread making synchronous calls to
create the software deployments. However, with convergence, resources in
the same stack not only can be processed concurrently but will tend to
be synchronised if they have the same dependencies (since they'll be
triggered by consecutive asynchronous RPC messages).
This handles the race by retrying if a concurrent update is detected by
the time the data has been provided to Swift.
Note that this is only guaranteed to result in the latest data being
available on the assumption that a later write to Swift cannot overwrite
an earlier one that has been accepted. This is probably *not* guaranteed
by Swift in the presence of clock skew. Nonetheless, this should
drastically reduce the failure rate.
Similar caveats would probably apply to Zaqar, although Zaqar nominally
provides FIFO queues (in practice, it likely depends on the backend
used). However, with Zaqar clients receive all updates, not just the
latest one, and os-collect-config stores the deployments contained in
every message. Thus, Zaqar is not affected even assuming out-of-order
arrival.
Change-Id: Ic9a447f27e8c51f91f47f93b0fd1e9710341ec38
Closes-Bug: #1731032
Include the server ID in existing logs, and add additional logs that will
let us know when updates to software deployments have happened and whether
they have succeeded or not. This should save considerable time
investigating in the future if there's ever any question of whether a
deployment has gone missing in Heat itself or somewhere on the target
server.
Change-Id: I33d7aee5974d03b7e41beab9fef4ad643cb0c469
Before making a software deployments update in the Swift backend, check
the data content to operate as a transaction.
Change-Id: I58d3af3d1de481b3d314313c9f39255504792634
Closes-Bug: #1731032
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
Serialize i18n messages before they reach the sql layer, to prevent an
issue with python3. This also fixes an issue with map behavior.
Change-Id: Ib934f5ac27cc1983a12c73f38927a116d50a5e6e
This change adds project information of software configs
if using admin context.
Change-Id: Ia26919aa1177a9366c65710becb2097b79e02445
Closes-Bug: #1646312
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
oslo_service Service usage in the engine was slightly wrong: we
inherited from the base class without using its threadgroup, and we also
inherited from it in utility classes that were not real services. This
cleans up those.
Change-Id: I0f902afb2b4fb03c579d071f9b502e3108aa460a
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
When the only way to define a Software Config was via a Heat resource, the
input and output configs were validated by the properties of the resource.
However, subsequently a REST API to create Software Configs directly was
added. That means that configs created in this way do not have the contents
of the inputs and outputs sections validated. This change adds validation
to ensure that the configs always follow the correct schema.
Change-Id: I8c66bb82484b75723524959be753a4cd20c0f84d
Consolidate the two sets of literals and standardise on the RPC API as the
source of the top-level keys.
Change-Id: I827e5b4eb0ba02ba9d1897dbc1c1da6f42823675
Instead of using a token that we need to create every time to poll the
Zaqar queue, create a signature and use it as an authentication
mechanism.
Change-Id: Ibf9f6c334eba024f6faa7d6bb708d6d9f778ee43
Curently you get events that look like this with the default
event formatter:
2016-05-11 17:49:12 [0]: SIGNAL_IN_PROGRESS Signal: deployment succeeded
Including the ID in the reason string will help (particularly in the
case of failure), as you can then easily show the deployment and
thus the stderr associated with the failure.
Change-Id: I59a3e9bf527040c4d807adc4f822bfa2c1591585
Related-Bug: #1564627
This changes the way SoftwareDeployment updates its internal status.
Instead of querying the deployment status in a loop using RPC client, it
makes a single call, which returns once the status has been updated.
Closes-Bug: #1549219
Change-Id: I484b7c8cb4a4e71817be6bea764f23b68a39b2d4
There are follow changes in this patch:
- Using exception ConcurrentTransactions for processing
concurrent transactions during writing metadata.
- wrapper @retry_on_conflict was used for metadata_set method to
allow retrying in the event of a race. The same wrapper was added for
_push_metadata_software_deployments method.
- added new parameter for metadata_set method - merge_metadata.
When RetryRequest exception is raised, oslo_db_api.wrap_db_retry
re-call metadata_set method and in this case we need to refresh
old metadata. It's mostly need for signals without data and id.
For example:
A and B signals come in the same moment and both get number 1,
because metadata was empty. Then during write in db RetryRequest
exception was raised for signal B. Metadata of this signal stores old
number - 1. So we should re-calculate this value using new length
of metadata and set number - 2.
Change-Id: I1ddbad7cde3036cfa9310c670609fcde607ffcac
Co-Authored-By: Zane Bitter <zbitter@redhat.com>
Partially-Bug: #1497274
We seem to be raising oslo_db execptions wrapping custom
heat exceptions and using them with oslo_db.wrap_db_retry.
Rather, we should use retrying module directly.
Change-Id: Iad6abcf129b75f7b56fe5bb2f2f05f04d56ba86b
This patch removes specific DeploymentConcurrentTransaction exception
and adds one common ConcurrentTransaction exception. New exception may
be re-sed for another cases with concurrent transactions with different
error message.
Change-Id: Iaa82732702ad6035a7784eb6689c2536535142f9
When a deployment is deleted the metadata needs to be pushed so that
stale deployment data is not present in the metadata. There is a risk
that stale data will mask other deployments.
Change-Id: I3df4d9a27be5e59609ac4374556d3c0c707b068b
Closes-Bug: #1523705
There is currently a race condition where software deployment populates
its metadata when being created, before the parent resource receives an
ID. This creates a window where the metadata is available but the
resource can't be signalled. This fixes it by providing the creation ID.
Change-Id: If58679138db95cf1da7ab5a4906217da446a391f
Closes-Bug: #1532445
Some catched exception with ``except XXX as e:`` raise with exception like
``raise e``, but in this way we lose the traceback. I propose we use
``raise`` to keep traceback.
Change-Id: I89fe43ef1af5374e4b2c4151ddc4b2d4f7729601
Zaqar queues were accessed and created with the user provided token, but
we need them to be in the stack project for instances to access them.
This changes to provide a stack user token instead.
Change-Id: If30ad4ad63b845b8dabe0b3ac0e4209057c3753c
Closes-Bug: #1532235
This change makes it possible to update a server's
software_config_transport property without replacing the server.
Some reasons for wanting to do this with long-running servers include:
- moving to POLL_TEMP_URL to reduce load on the heat engines, or to be
able to create deployments outside the stack
- moving to ZAQAR_MESSAGE once the host cloud has deployed zaqar
Any existing transport *must* continue working and return up-to-date
data for the lifecycle of the stack since it can't be known when all
servers have switched to the new transport. This means that a transport's
enabled status should be determined by the enabling resource data
rather than the software_config_transport property.
The os-collect-config configuration data needs to ensure that old
transport configurations are disabled. This includes local boot config
which remains on the server for its lifetime, and is outdated once the
transport changes. This disabling is achieved by setting any existing
configuration values to None.
This has been tested on a tripleo cloud by repeatedly switching between
POLL_TEMP_URL and POLL_SERVER_CFN during a stack update and confirming
that os-collect-config switches to the new transport.
Change-Id: I9c475f0c489c67db5895924050186228403f2773
Closes-Bug: #1519609
This change switches _push_metadata_software_deployments over to
using db_api.resource_update for deployment resource metadata
updates.
Using the atomic_key filter of resource_update allows this code
to detect if another transaction has updated the metadata, and
the wrap_db_retry decorator is used to perform retry attempts. No actual
resource locking is required since we just need to detect if another
transaction performed an update, so the engine_id is not specified.
This change uses db_api directly rather than the Resource object since
this change will need to be backported to Kilo (db_api.resource_update
was created for convergence, and is in Kilo, but Resource object using
it is not). This change can switch back to using the Resource object once the
backport is complete.
This rows_updated/RetryRequest/wrap_db_retry technique is used by other
OpenStack projects for concurrent transaction detection (such as nova,
for floating IP allocation).
Change-Id: Ibf9dd58a66a77d9ae9d4b519b0f11567977f416c
Closes-Bug: #1477329
Add a new Zaqar transport to distribute metadata to servers and retrieve
data out of them.
blueprint software-config-zaqar
Depends-On: Icd30e32a17247790dfd57d6420d67f9140020db6
Change-Id: If23ffb3553c3506b981c06bfb82dae41b93590a5
Fixes SoftwareConfigService to use Resource object
in place resource db api.
Implements blueprint versioned-objects
Change-Id: Idd9b1215275d899bbf8a7c1a603af9c35dda3008
Prototype implementation of oslo.versionedobjects.
This patch adds SoftwareDeployment object.
Partially implements bp versioned-objects
Co-Authored-By: ShaoHe Feng <shaohe.feng@intel.com>
Co-Authored-By: He Jie Xu <hejie.xu@intel.com>
Change-Id: I3666a8b2552d8c0c9dcf05efd9c423ff5252f77d
The size of EngineService is starting to affect maintainability.
This change creates service_software_config.SoftwareConfigService
and moves all the software config service method implementations
into it.
Software config calls to EngineService are delegated to
SoftwareConfigService. Unit tests remain in test_engine_service to
include the EngineService entrypoint methods in the test coverage.
Change-Id: Icf51dfd35423ac33a9126731862a90525c17306c
Related-Blueprint: software-config-trigger
lujiefsi