We are updating all Python projects to publish artifacts to PyPI. The
name "heat" is already taken there by another project, and they have
rejected our request to claim the name. We therefore need to change the
dist name used to package heat. We have some other projects publishing
using an "openstack-" prefix, so I propose using the name
"openstack-heat". This will not change the imports or anything else
about how the code works, just how it is packaged.
Add a grenade plugin for upgrading between the packages with different
names so that we can clean up the old version of the code and avoid
discovering the heat plugins multiple times in different locations.
Change-Id: I59b55cffd9e648f842eb286b936f09c5b55a76db
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This adds basic framework for heat-status upgrade
check commands. For now it has only "check_placeholder"
check implemented.
Real checks can be added to this tool in the future.
Change-Id: I83629184b49a6cf91928df702db23156433d99f6
Story: 2003657
Task: 26131
Wait for the legacy stack to move to the IN_PROGRESS state before returning
from the API call in the stack update, suspend, resume, check, and restore
operations.
For the stack delete operation, do the same provided that we can acquire
the stack lock immediately, and thus don't need to wait for existing
operations to be cancelled before we can change the state to IN_PROGRESS.
In other cases there is still a race.
Change-Id: Id94d009d69342f311a00ed3859f4ca8ac6b0af09
Story: #1669608
Task: 23175
Previously when doing a delete in convergence, we spawned a new thread to
start the delete. This was to ensure the request returned without waiting
for potentially slow operations like deleting snapshots and stopping
existing workers (which could have caused RPC timeouts).
The result, however, was that the stack was not guaranteed to be
DELETE_IN_PROGRESS by the time the request returned. In the case where a
previous delete had failed, a client request to show the stack issued soon
after the delete had returned would likely show the stack status as
DELETE_FAILED still. Only a careful examination of the updated_at timestamp
would reveal that this corresponded to the previous delete and not the one
just issued. In the case of a nested stack, this could leave the parent
stack effectively undeletable. (Since the updated_at time is not modified
on delete in the legacy path, we never checked it when deleting a nested
stack.)
To prevent this, change the order of operations so that the stack is first
put into the DELETE_IN_PROGRESS state before the delete_stack call returns.
Only after the state is stored, spawn a thread to complete the operation.
Since there is no stack lock in convergence, this gives us the flexibility
to cancel other in-progress workers after we've already written to the
Stack itself to start a new traversal.
The previous patch in the series means that snapshots are now also deleted
after the stack is marked as DELETE_IN_PROGRESS. This is consistent with
the legacy path.
Change-Id: Ib767ce8b39293c2279bf570d8399c49799cbaa70
Story: #1669608
Task: 23174
Add a new property 'networks' to resource OS::Zun::Container.
This property is an ordered list of nics to be added to this container,
with information about connected networks, fixed ips, port etc.
This property can be updated without replacement.
Story: 2003106
Task: 23222
Change-Id: I4b8c0257b83e97444dd8ff6ce88e240d12278ec2
Resource type ``OS::Magnum::Bay`` is now hidden, please use
``OS::Magnum::Cluster`` instead.
Resource type ``OS::Magnum::BayModele`` is now hidden, please use
``OS::Magnum::ClusterTemplate`` instead.
Resource type ``OS::Nova::FloatingIP`` is now hidden, please use
``OS::Neutron::FloatingIP`` instead.
Resource type ``OS::Nova::FloatingIPAssociation`` is now hidden, please use
``OS::Neutron::FloatingIPAssociation`` instead.
Change-Id: I2ea1400cfe1f4eca24f2fb7b4b0ec27ca5e9538d
This allows users to insert a delay at some point in the workflow while
creating or deleting the stack. Unlike OS::Heat::TestResource, the delay
can be randomised so that when used in parallel across a scaling group it
can be used to work around thundering herd problems.
Change-Id: I49deb9560df9963120445c5900f79a1c5ca09cb5
This change adds 'network' to the addresses attribute of the
OS::Nova::Server resource. This enables resolving the
properties of the neutron network for the server resource.
Story: 1766946
Task: 19690
Change-Id: I5bef751982919103ecbefeee64bf0f2cbede0cd0
Adds attribute 'network' to the port resource.
Similar to the existing subnets attribute which returns
a list of all subnets. The network attribute returns
the properties of the neutron network.
Story: 1766946
Task: 18792
Change-Id: I6c667a0ff2c15aa27ca0d7943359e7f595630f87
Add a Blazar client plugin which will be used by a couple of Balazar
resources under development.
Change-Id: I0f68fc0525db3ba299d77019a102f24b9d3cea87
Task: 19754
Story: 2002085
Adds a attribute to the neutron Net resource to get the
segments of a network.
Story: 2001988
Task: 19610
Change-Id: I7acb3d29a01fa92bebdb2c85094655e27cb16a29
Neutron allows updating the segment_id property of a subnet
to enable migration from non routed network to a routed
network.
This changes the Subnet resource to allow updating the
segment property so that heat users can migrate ro a routed
network.
Story: 2001988
Task: 19609
Depends-On: Iffda823a149a1143f46ee9a05e9640b34bf42c51
Change-Id: I6682a67da1b728f65f603ee40a200e9e0ee2e5b3
This change adds 'subnets' to the addresses attribute of the
OS::Nova::Server resource. This enables resolving the subnet
properties for the server resource which brings parity with
OS::Neutron::Port's 'subnets' attribute.
Story: 1766946
Task: 19689
Change-Id: I6927f1e142e83df7258e259bffc86819e4cbe881
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
