Updated openstack/openstack
Project: openstack/requirements  fde324efaf57decd1a33dc61bb1f5f9e93f4d79b
null
Switch to SQLAlchemy 0.9

After SQLAlchemy-migrate has been fixed for SQLAlchemy 0.9,
and after the last problem (with Keystone) has been fixed,
we finally can switch to SQLAlchemy 0.9. It is important we
do the switch to SQLAlchemy 0.9.x ASAP, because that is what
distributions (eg: at least Debian) are using. This also
ensure we avoid any future mistakes if we do the gating with
SQLAlchemy 0.9.

This patch sets the cap from <=0.8.99 to <=0.9.99.

Change-Id: I9d2a9e0526359fa1e97df250a63f71496d47367a
Updated openstack/openstack
Project: openstack/heat  36ff79a47cf4c28e9c5efb5ed045bbb3cca6bfec
null
OS::Nova::Server support for software config

Changes to OS::Nova::Server to deliver all
currently available SoftwareDeployment metadata to the server
via os-collect-config polling.

user_data_format has a new option SOFTWARE_CONFIG, and adds
behavours in SOFTWARE_CONFIG specific code paths.

metadata property is overridden to query available config
data every time metadata is accessed.

This resource now extends StackUser but the user and keypair are only created
for SOFTWARE_CONFIG. os-collect-config uses the keypair to poll for metadata
changes. An access_allowed handler is registered so that cfn metadata polling
gets authorised against this resource.

access_allowed simply limits access to the current resource, which seems
appropriate since this resource created the user.

nova_utils.build_userdata has become aware of user_data_format
SOFTWARE_CONFIG, so it only includes the cloud-init attachments
which os-collect-config actually needs.

partial blueprint: hot-software-config

Change-Id: Iaff98a471132f97db3adce301a61068d0770b540
Updated openstack/openstack
Project: openstack/heat  c92aa9b5c564e4140d36efbb0dc13e639310c655
null
Server property for software config transport

Setting a value for software_config_transport will change the configured
transport which is used to get software config metadata to the server.

The default value POLL_SERVER_CFN allows the current behaviour of using
an EC2 keypair signed request to poll for metadata changes.

The new value POLL_SERVER_HEAT will allow heatclient (or equivalent) to
fetch metadata for the server resource via a standard native API resource-show
request.

os-collect-config is configured with the (currently fictional) heat_server_poll
collector and provided with credentials which can be used to get a valid auth token.

The next most likely transport is one which polls the deployments metadata API
directly. Hopefully in the future there will be non-polling based transports.

Change-Id: Ib6fd76ef58e2b8e11b62d127e1df654254cd15ec