Updated openstack/openstack
Project: openstack/python-keystoneclient  f942df2f5ffb3762ac5b08f1ce1553296b3a93ae
null
Rename using-api.rst to using-api-v2.rst

Renaming file for consistency, since using-api-v3.rst is being written
there: https://review.openstack.org/#/c/63408

Minor changes have been made to indicate that the file documents the
keystone v2 API.

Change-Id: I694b658a8b59d21615af5d88edc0f7b394ebbe7b
Partial-Bug: #1260527
Updated openstack/openstack
Project: openstack/oslo.messaging  21443273beaa2115f15c441e38dc832ede22ae7e
null
fix test_rabbit for Python 3

Replace range() with list(range()), range() returns a read-only "range" object
in Python 3.

Change-Id: If92e60b426ccbba574e63e1603cc3d7507df6c98
Updated openstack/openstack
Project: openstack/heat  42cd54dcf4f9e89707862fbc4ef0e1c4721a06df
null
Service authorize stack user from provided stack

Currently _authorize_stack_user requires that an EC2
keypair comes from an AccessKey resource (or some other resource
which uses the access_key as its resource_id).

This change avoids the separate db resource lookup, and checks
the provided stack for a resource which has an associated access_key.

This could be an AccessKey resource, or any resource which has
registered an access allowed handler via register_access_allowed_handler.

Additionally, the credential_id does not have to be the AccessKey of a
keypair. credential_id could be any value meaningful to the resource
which registers the handler.

Since resources are lazy loaded, register_access_allowed_handler will not
be called until resources are loaded. This loading is triggered in
access_allowed by accessing the resources property.

One of the objectives of hot-software-config is to reduce the
amount of template scaffolding required to enable software configuration.
This change means that an OS::Nova::Server resource wouldn't need
an associated OS::Heat::AccessPolicy, AWS::IAM::User, AWS::IAM::AccessKey
just so that os-collect-config can poll for metadata changes (note that
the actual change that does this for OS::Nova::Server is pending).

partial blueprint: hot-software-config
Change-Id: I52a12ad3cd750ed724893abcd6dc1084b925c089
Updated openstack/openstack
Project: openstack/ceilometer  d6c7f541d9e5a808ff84b86c7a6cd1cad3465d5a
null
Empty files should no longer contain copyright

Change-Id: Id314cd0ec658cb96cfc50493cd5bab10c2716714
Closes-Bug: #1262424
Updated openstack/openstack
Project: openstack/swift  bc0d233c9d852197cbc9e79ae97f44dca255e14c
null
Move the tests from functionalnosetests

Move the tests from functionalnosetests under functional, so we no
longer have two seperate trees for functional tests. This also drops
the 'nose' name from the directory, so that it doesn't end up with
confusion if we move to testr. Further, since there are no longer two
test runs in .functests, it nows looks very close to the other two.

Change-Id: I8de025c29d71f05072e257df24899927b82c1382
Updated openstack/openstack
Project: openstack/heat  e20b79c81c5e43e61d9c4d4e963206b1808ac364
null
Introduce a way to trace a resource's implementation

We need a way to know whether a resource is really the
same during update. This is driven by TemplateResource
but not totally specific to it.

The problem is:
if you update a template with no changes (except for environment
or files changes) we need to know which resources to update.

This patch adds a "implementation_signature()" method that gives
us a mechanism to keep track of implementation changes like:
- a change in an environment mapping a resource to a new/different implementation
- a change in the content of a TemplateResource

And can distinguish between schema changes (requiring replacement) and
incremental changes (that can be updated in place).

Change-Id: I780074a827e3f51dede47a81f15e29dbe4d08804
Closes-bug: #1254966