Native in-instance tools to replace cfntools

Registered by Steve Baker

We need to provide a collection of tools to replace functionality currently provided by heat-cfntools.

These tools will need to interact with heat via the native REST API. An alternative authentication mechanism to the current AWS signed messages will be required.

cfn-push-stats is considered out of scope for this blueprint, as equivalent functionality can be provided by ceilometer's tools.

Functionality for the new tools will include the following:
1. fetch metadata for this instance (cfn-init, cfn-hup)
2. fetch metadata for another resource (cfn-get-metadata)
3. post new metadata for another resource (cfn-signal)

For 1. there will end up being a number of tools which act on the fetched metadata. These tools are beyond the scope of this blueprint, and will possibly include:
- legacy support for AWS::CloudFormation::Init sections
- os-config-applier/os-refresh-config
- puppet/chef invocation
- a new native heat instance provisioning tool

Blueprint information

Status:
Complete
Approver:
Steven Hardy
Priority:
High
Drafter:
Steve Baker
Direction:
Approved
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Good progress
Milestone target:
None
Started by
Steve Baker
Completed by
Steve Baker

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/native-in-instance-tools,n,z

Addressed by: https://review.openstack.org/32354
    Implement metadata update REST API call.

(SpamapS/clint-fewbar)
I have split this up into three blueprints. I do not have any interest in the bootstrap-config blueprint as TripleO uses custom images exclusively. I may pick up native-tools-signals soon if I cannot achieve what I need with simple curl commands to the API. I am unassigning myself from this blueprint and will recommend that it be dropped from havana unless the other two pieces are picked up.

(stevebaker) I've kicked this to next

(shardy) Who's working on this atm? stevebaker/SpamapS please can you set the assignee as appropriate, thanks :)

(stevebaker) This is a meta-blueprint now, so it won't have an assignee and it can be marked implemented when its dependencies are implemented.

(stevebaker) I'm obsoleting this, hot-software-config provides an alternative approach.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.