summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Always fetch temp URL key before generation" into stable/junojuno-eol2014.2.4stable/junoJenkins2015-11-132-10/+17
|\
| * Always fetch temp URL key before generationSteve Baker2015-11-122-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | SwiftClientPlugin.get_temp_url has the potential to race with itself when storing a new tempurl key to the swift account, leading to tempurls being built with a key that has been overridden. This change always fetches the key from swift before creating a temp URL. Change-Id: Id5897fdd834cc5d3b74fda8d2317d084a5564c51 Closes-Bug: #1413366
* | Merge "Expose stack_user_project_id in stack-show" into stable/junoJenkins2015-11-134-2/+5
|\ \
| * | Expose stack_user_project_id in stack-showSteve Baker2015-11-124-2/+5
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stack_user_project_id is currently never exposed by heat, so the user has no way of discovering what it is. This has a couple of implications: - The user can't call the REST API create_software_deployment unless they know the stack_user_project_id of the stack that the server resource belongs to - user can't do manual cleanup of stack_user_project_id when necessary This change adds stack_user_project_id to the formatted output of the stack-show REST API call. Change-Id: I0a2d337401c164eb58dbce63e01f68f98f8d467e Closes-Bug: #1413398
* | Merge "Validate nova server's metadata" into stable/junoJenkins2015-11-122-0/+14
|\ \
| * | Validate nova server's metadataAngus Salkeld2015-11-122-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents "foo" getting passed into the metadata. This can happen when using get_attr() to return a dynamic value. Change-Id: I17eab659e65a51963e510add4d71fbc90a3a3a53 Closes-bug: #1338811 (cherry picked from commit 22df43e2f1e4dd6050e61f0808e6970b0cb05dac)
* | | Merge "Make sure template resource's metadata is refreshed" into stable/junoJenkins2015-11-122-0/+41
|\ \ \
| * | | Make sure template resource's metadata is refreshedAngus Salkeld2015-11-122-0/+41
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This copies the code snippet from instance.py, which refreshes the metadata when we get a signal on a referenced resource. Note: a functional test is coming in a later commit. Closes-bug: 1418942 Change-Id: I5980c9cf4dc355b9bfa93273bc26a768ab9abdb8 (cherry picked from commit e5ffaff0b3326bcf2840f781501b9f7bb6513ccd)
* | | Merge "Update template paths for environment-mapped TemplateResources" into ↵Jenkins2015-11-121-9/+14
|\ \ \ | | | | | | | | | | | | stable/juno
| * | | Update template paths for environment-mapped TemplateResourcesZane Bitter2015-11-111-9/+14
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When updating a template resource, we weren't taking into account the possibility that the new environment could be mapping the resource to a different template path. This change ensures we recalculate the template name from the new environment before reloading the template during an update. Change-Id: I5f84f6fd60925d3dba0b8e8dec867657c8c5c9ef Closes-Bug: #1452534 (cherry picked from commit 686f317ccae280bd8b536379e89ba743746ae159)
* | | Merge "Don't re-bind environment for get_file during stack update" into ↵Jenkins2015-11-122-1/+50
|\ \ \ | |_|/ |/| | | | | stable/juno
| * | Don't re-bind environment for get_file during stack updateZane Bitter2015-11-092-1/+50
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | While we're in the process of updating a stack, we set the stack's environment to the new, updated values. However, we don't want to change existing resources' idea of their own values until we have explivitly done an update of them to bring them into line with the new template/environment. So when parsing a template snippet containing the get_file intrinsic, store the files dict to which it will refer. get_file will resolve to the new file only when the template has been updated. Closes-Bug: #1445170 Change-Id: I8ec32b0e38389cd314e4b2b2d8c65f61f8a9c41e (cherry picked from commit e4447e7b66cf4691218b067643b5e25de72e31ba)
* | stack delete fails when instance is soft deletedRakesh H S2015-11-102-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an environment where reclaim_instance_interval is set to non-zero in nova, an delete request will only soft delete an instance.(status=SOFT_DELETED, so that the instance can be reclaimed if required by using 'nova restore <instance_id>') Now in the above environment, when an delete stack is requested by user, stack will hang until reclaim_instance_inerval or timeout. Hence status=SOFT_DELETED for an instance should be handled by heat, which this patch proposes. Closes-Bug: #1377290 Change-Id: I86ea788131f113e3deb7aebfccecd7f5e4957ae5 (cherry picked from commit 633a6bb14413b6a8523b6c142df32a7289e05a93)
* | Merge "Updated from global requirements" into stable/junoJenkins2015-11-101-2/+2
|\ \ | |/ |/|
| * Updated from global requirementsOpenStack Proposal Bot2015-10-151-2/+2
| | | | | | | | Change-Id: Ib422941aa023d8bcdc4b9aaa7af8e386e822cdda
* | Merge "ASG scaling account for cooldown timestamp & in-progress" into ↵Jenkins2015-10-216-123/+241
|\ \ | |/ |/| | | stable/juno
| * ASG scaling account for cooldown timestamp & in-progressyanyanhu2015-10-066-123/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are cases where it takes a long time to create a new resource as requested by the scaling operation on an ASG resource, for instance, a nova server creation followed by a complex SoftwareDeployment. During this process, additional alarms may come in but failed to be blocked by the current cooldown checking mechanism because the very first timestamp has yet to be generated. This is leading to unexpected size adjustment to the ASG. This patch augments the existing cooldown checking mechanism with a scaling-in-progress test so that additional alarms arriving during the very first scaling operation will be ignored. Change-Id: Ib8aa83eed366df7097c9cbb9247eca866ae4b620 Co-Authored-By: Zane Bitter <zbitter@redhat.com> Closes-Bug: #1375156
* | Merge "Detect container failure when checking create complete" into stable/junoJenkins2015-10-122-0/+27
|\ \
| * | Detect container failure when checking create completeRandall Burt2015-03-082-0/+27
| | | | | | | | | | | | | | | Change-Id: I77f56ec544a82e13cd5a00a3adcfde6c0dda822e (cherry picked from commit 0f368be6b9069d829a7f6b57b39d37d2d5830b44)
* | | Merge "Save updated-in-place resources to backup stack" into stable/junoJenkins2015-10-112-0/+159
|\ \ \
| * | | Save updated-in-place resources to backup stackkairat_kushaev2015-10-082-0/+159
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch changes the approach of resource backup during stack update. It stores the definition of resource that needs to be updated in-place to backup stack(if it was not created before). Without this functionality, InvalidTemplateReference will be thrown every time when update-replaced resource has a reference to updated in-place resource and stack update was failed. In this case, backup stack has a resource that refers to not-presented another resource and backup stack deletion generates an exception. Change-Id: I436c44a579bb4df3031d1a17b9ca5b62da37afeb Closes-bug: #1446575 (cherry picked from commits da3777342a344a2dafb9244b7afca8722a398caa and 3786262aed62d81ad35de3d4f703c38223907ffd)
* | | Merge "Fix stack-list after failed update" into stable/junoJenkins2015-10-092-0/+116
|\ \ \
| * | | Fix stack-list after failed updateRakesh H S2015-10-022-0/+116
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a update is being performed, the existing template is updated incrementally as resources change. Now if update fails, template will have mix of resources from existing and new template. Hence we need to ensure we have the user params of both. Closes-Bug: #1477812 Change-Id: I9e6831c58b167809e3faed519d2fb4f7c61244fc (cherry picked from commit cb3734bf906e5c5677e499820c5d513b33aca64f)
* | | Only write to template files if template data changesSteve Baker2015-10-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the template data is assigned to the files dict regardless of whether the data has changed or not. This has no consequence on Liberty, but the files dict in Kilo and Juno is a sqlalchemy MutableDict so these assignments are triggering updates to the raw_template table. These updates are even triggered for calls to heat resource-list. With large raw_template records this can make heat unusable. Therefore this fix is presented here as having no effect (and being harmless) to git master, but high priority backports for Kilo and Juno. Change-Id: Ibb714a9c5dc9f6879ff108419127da985a57897b Closes-Bug: #1494108 (cherry-picked from 779ba8e431aecac3c451c08aedcc0ad8cf0a4449)
* | | Make ResourceDefinition round-trip stable to avoid extra writesSteve Baker2015-10-084-8/+11
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The part of a ResourceDefinition that lists explicit dependencies was not round-trip stable. As a result, when we copied a new resource definition into the existing template during a stack update, we would end up rewriting the template unnecesarily (i.e. even though we check for changes) every time if depends_on was not specified in the resource originally. At the end of each update, we write the new template to the DB in its entirety, which removes these extra lines again, ensuring that we will experience the same problem on every update. This was causing a *lot* of unnecessary writes. This change ensures that the definition remains stable across a round-trip, so that no unnecessary changes appear in the template. Change-Id: If7292e49755db0153d7d0db9f7d3875fa9c1d408 Partial-Bug: #1494108 (cherry-picked from 9ebac709e2d3e8814fdee9de99ff49a4681b0ab2)
* | Merge "Prevent hanging in DELETE_IN_PROGRESS" into stable/junoJenkins2015-09-251-3/+4
|\ \
| * | Prevent hanging in DELETE_IN_PROGRESSPavlo Shchelokovskyy2015-09-231-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When during update one resource is deleted and another independent resource takes long to update itself, deleting such stack when it is UPDATE_IN_PROGRESS led to a stack being stuck in DELETE_IN_PROGRESS as deleting backup stack was not finding the already deleted resource. Change-Id: Ib0c42b718a88ac994c53165362a38da2ad5b6b41 Closes-Bug: #1384750 (cherry picked from commit e44629dab01057c65a14218f5d3ae19d5cdcf9e0)
* | | Merge "Make sure to delete stack when SNAPSHOT_IN_PROGRESS" into stable/junoJenkins2015-09-252-2/+12
|\ \ \ | |/ /
| * | Make sure to delete stack when SNAPSHOT_IN_PROGRESShuangtianhua2015-09-222-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | If there is no snapshot data, no need to start a task runner of rsrc.delete_snapshot. Change-Id: I1b868eda8a7a0a2ed5f30aa01a41f4c9820193a5 Closes-Bug: #1437588 (cherry picked from commit 42727797d379007ebddb51d96959b08c3c80cd9b)
* | | Merge "Fix TypeError exception during cancel stack update" into stable/junoJenkins2015-09-252-3/+27
|\ \ \ | |/ /
| * | Fix TypeError exception during cancel stack updatehuangtianhua2015-09-152-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | TypeError: call() takes exactly 3 arguments(5 given) is raised during cancel stack update, this patch will fix the problem. Change-Id: If85389150a15575d9e01466d950f8c07b8fa2717 Closes-Bug: #1448384 (cherry picked from commit 72403962033d15bfe910eae14f01a4461d1789e9)
* | | Updated from global requirementsOpenStack Proposal Bot2015-09-181-1/+1
|/ / | | | | | | Change-Id: I9a931c9de7c411a1784d8981395e871e2e46dbf6
* | Updated from global requirementsOpenStack Proposal Bot2015-08-221-1/+1
| | | | | | | | Change-Id: I79959dfe890d028ad0ee407d716592f450a77a1a
* | Merge "Catch v3 keystone unauthorized error when creating stack" into ↵Jenkins2015-08-204-8/+32
|\ \ | | | | | | | | | stable/juno
| * | Catch v3 keystone unauthorized error when creating stackEthan Lynn2015-08-184-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If v3 keystone unauthorized error raise during creating stack, then this stack will remaid in status of create_in_progress. This patch modify heat keystoneclient to catch unauthorized error and set stack status to failed. Closes-Bug: #1376213 Closes-Bug: #1450923 Change-Id: I9a34c20fc6ac3ce235aaba4eac25a6d5ceb43f5f (cherry picked from commit dca8e37e651c32aca7224fda208e1241efbf23f2)
* | | Updated from global requirementsOpenStack Proposal Bot2015-08-133-48/+47
|/ / | | | | | | Change-Id: Ide20474871d903f22f9af6c3f27770066d00d9dd
* | Fix the topic and server that the listener client usesAngus Salkeld2015-08-073-3/+6
| | | | | | | | | | | | | | | | | | This was only working for one heat engine as it was sending the listener messages to a topic of "engine_id". Change-Id: Ib542d1ebb85b004f5a67213e678882c5a723dc0e Closes-bug: 1433821 (cherry picked from commit f19c54dd9a906a538b527268b6746daa162da5ad)
* | Add oslo.serialization to heat requirementsSergey Kraynev2015-07-241-0/+1
| | | | | | | | | | | | | | | | | | This patch add oslo.serialization to heat requirements.txt. It's required for patch: Ibd64b3607721487be5b0562cdb54e6c76db51149 where this library is used. Change-Id: If417206bd5f5df892d44db3b899bc87f18510d79 Closes-Bug: #1477908
* | Merge "Add env storing for loaded environments" into stable/junoJenkins2015-06-143-0/+33
|\ \
| * | Add env storing for loaded environmentsPeter Razumovsky2015-06-033-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If env loaded from outer file, there is probability that this outer file will be deleted. So, if template uses some resource with resource registry env, we need to store this env in db. Change-Id: Ib0c191db2dccac6d467a9961062424bc1f924c24 Closes-bug: #1429141 (cherry picked from commit d8fe35eee518036eab7f73aca28cf4d770ae7dc1)
* | | Fix block_device_mapping property validation when using get_attrRabi Mishra2015-06-112-2/+20
| | | | | | | | | | | | | | | | | | Change-Id: I6501395ab458b75ba7d27c8ce9643bd6d18cb203 Closes-Bug: #1463531 (cherry picked from commit 4d2b275358cd010c0ba19697d5e623a1edef3daf)
* | | Add default_client_name in Nova::FloatingIPAssocPeter Razumovsky2015-06-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default_client_name has been missed, so stack fails to delete, if server, from which floating ip association depends, not exist. Change-Id: I01bb91f8afaeb483e1a4bb55653dc3189a62bf12 Closes-bug: #1396982 (cherry picked from commit 898f94347dc011aba7f2cb03b1ff5d384691aeda)
* | | Fix cloud-init Python syntax for Python < 2.6Zane Bitter2015-06-052-10/+26
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The loguserdata.py file gets uploaded to the servers created by Heat to run under cloud-init. Since the default versions of Python installed on the user's server may be very old (e.g. RHEL 5 defaults to Python 2.4), avoid using the octal syntax introduced for Python 3.0 and backported only as far as Python 2.6. (Also avoid the old syntax, which will break on Python 3.x.) Also remove use of the "with" statement from loguserdata.py and part-handler.py. This statement is only available from Python 2.6 on (or in Python 2.5 via "from __future__ import with_statement"). Finally, remove use of the "except ExceptionType as value" syntax for catching exceptions. Again, this was only backported to Python 2.6. Change-Id: I89e86d00993d51e2514b1e589503c6d966909403 Partial-Bug: #1375864 (cherry picked from commit 95ec13c5725ccc19dfe910fe83eb9bc6799d482e)
* | Allow lists and strings for Json parameters via provider resourcesSteven Hardy2015-05-262-2/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have a somewhat bogus internal equivalence between the "json" parameter type and the MAP property type. This is a problem when exposing json parameters via provider resources, because the schema of the exposed property does not exactly match the capabilities of the underlying parameter. Specifically, json parameters can take strings (json serialized list or map), and also lists and maps directly. Currently, we can only pass maps, which means some data, for example a list of maps (which is possible when interacting directly with a json parameter) is not possible when using the same parameter abstracted via a TemplateResource. To work around this add a flag which relaxes the type rules and enables some coercion of map values, only when they're going via a schema derived from a json parameter. Changes required for backport: * Changed import of oslo_serialization.jsonutils to heat.openstack.common.jsonutils. Change-Id: I8eff36c4343a07b644b84aa9f2f74eceeb62b4a9 Closes-Bug: #1420196 (cherry-picked from 413fde3247b804e408a9ea9fd863d85391e326aa)
* | Merge "RandomString physical_resource_id as id not the string" into stable/junoJenkins2015-05-222-1/+26
|\ \
| * | RandomString physical_resource_id as id not the stringSteven Hardy2015-04-302-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If someone choses a string length of over 255 we overflow the DB id field causing an error, so instead use the physical name for the resource_id. The actual string is already stored (encrypted) in the resource_data so it's probably better anyway to refer to the value in one place and just override FnGetRefId to maintain the existing interface behavior. (Combined cherry-pick from Ide8899a2aa0a9fed037835dc46225f52c291ace6 and I233476b8411612350c884c4480a8e2f5cc8c2ab5) Change-Id: I0c55f1fa026de20b096b845e21095e91ac6bf166 Closes-Bug: #1392359
* | | Merge "Updated from global requirements" into stable/junoJenkins2015-05-141-4/+4
|\ \ \
| * | | Updated from global requirementsOpenStack Proposal Bot2015-04-241-4/+4
| |/ / | | | | | | | | | Change-Id: I81eaffda9bf3463b9216430b38df1abf63ae1a9f
* | | Authenticate the domain user with id instead of usernameMiguel Grinberg2015-05-135-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes the authentication process that requests a domain user token provide user_id and password instead of username and password. Authenticating with the user_id is more reliable, as that works even when the username is truncated or modified in any other way before it is passed to Keystone. Conflicts: heat/common/heat_keystoneclient.py Change-Id: I7b2897c2be1e4ad7f55549449b1791991572a7f1 Closes-bug: 1402894 (cherry picked from commit 0ba4dacbe292a182ac4ccd69f1133aa6cdba8045)
* | | Tell stevedore not to force verify requirementsDoug Hellmann2015-05-133-3/+3
|/ / | | | | | | | | | | | | | | | | | | Disable the strict requirements checking in pkg_resources by telling stevedore to bypass it. This avoids issues with devstack configurations where the "wrong" version of a library is installed, even though it is functional. Closes-Bug: #1454572 Change-Id: Idbdbdd2548ad39325d8058eb19ee398f732c2e44
View Lorry Controller Status