This generic mixin overloads plugin client() method to return
a client with max microversion unless a specific version is requested.
This provides two abstract methods
- get_max_microversion()
- is_version_supported()
for client plugins to override when supporting microversions.
Change-Id: I8873ab6d815671b6647b08578d1406dd874269f6
Gerrit used to allow regexps in topic: queries, but now topic: is only
for exact matches. intopic: can be used to search within topics.
Change-Id: Icc5c80ead124b4383198915984543a7987b1bf2e
Now that we depend on tenacity >=4.4.0, we can use the library's version of
the wait_random_exponential wait strategy in place of our own.
Change-Id: I13d3222808a98ef7e333f58df931c8f950ac1221
Depends-On: https://review.openstack.org/556309
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
Create a tox environment for running the unit tests against the lower
bounds of the dependencies.
Create a lower-constraints.txt to be used to enforce the lower bounds
in those tests.
Add openstack-tox-lower-constraints job to the zuul configuration.
See http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html
for more details.
Change-Id: I72fd5f8c87133713cd272de210b7e957880f48f9
Depends-On: https://review.openstack.org/555034
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
When we create user accounts in order to allow signalling back to Heat,
generate the passwords using a mix of upper- and lower-case letters, digits
and special characters. This should pass most password_regex filters that
users are likely to configure in Keystone, which was not true of the
previous method (using only hex characters from a UUID).
Change-Id: I7702d6ab550e4f1f53c4cea9f67ed0402afbd66d
Closes-Bug: #1666129
Closes-Bug: #1444429
When generating a random string, once we had selected from the various
required pools, we continued by selecting a pool at random and then
selecting a character from that pool at random. This did not take into
account the differing sizes of the available pools, nor the fact that the
same character could appear in multiple pools, which resulted in a
non-uniform probability distribution of characters. Since users mostly make
use of this feature to generate default passwords for services they are
deploying, this would result in the generated passwords having slightly
less entropy than expected (and pathological cases were possible).
Rectify this by always selecting non-constrained characters from a single
combined pool, and by ensuring that each character appears only once in any
pool we're selecting from.
Since we also want to use this method to generate passwords for OpenStack
Users, the new implementation is in a separate module in heat.common rather
than mixed in with the resource's logic. Also, use a StringIO object to
collect the characters rather than repeatedly appending to a string.
Change-Id: Ia7b63e72c1e3c0649290caf4fea8a32f7f89560b
Closes-Bug: #1757300
Related-Bug: #1666129
Related-Bug: #1444429
We were missing a call to update the template for convergence purpose
when updating an external resource.
Change-Id: I37e29aaf4110faa00c777c76640be485224720ca
Closes-Bug: #1756269
ricolin
OpenStack Proposal Bot
Zane Bitter
Zuul
rabi
wanghui
Doug Hellmann
Pavlo Shchelokovskyy
Thomas Herve