Open Stack

I think this fits into something that I want for optimizing
>>> os-collect-config as well (our in-instance Heat-aware agent). That is
>>> a way for us to wait for notification of changes to Metadata without
>>> polling.
>> Interesting... If I understand correctly that's kinda replacement of 
>> cfn-hup... Do you have a blueprint pointer or something more 
>> specific? While I see the benefits of it, in-instance notifications 
>> is not really what we are looking for. We are looking for a 
>> notification service that exposes an API whereby listeners can 
>> register for Heat notifications. AWS Alarming / CloudFormation has 
>> that. Why not Ceilometer / Heat? That would be extremely valuable for 
>> those who build PaaS-like solutions above Heat. To say it bluntly, 
>> I'd like to suggest we explore ways to integrate Heat with Marconi.
>
> Yeah, I am trying to do a PoC of this now. I'll let you know how
> it goes.
>
> I am trying to implement the following:
>
> heat_template_version: 2013-05-23
> parameters:
>   key_name:
>     type: String
>   flavor:
>     type: String
>     default: m1.small
>   image:
>     type: String
>     default: fedora-19-i386-heat-cfntools
> resources:
>   config_server:
>     type: OS::Marconi::QueueServer
>     properties:
>       image: {get_param: image}
>       flavor: {get_param: flavor}
>       key_name: {get_param: key_name}
>
>   configA:
>     type: OS::Heat::OrderedConfig
>     properties:
>       marconi_server: {get_attr: [config_server, url]}
>       hosted_on: {get_resource: serv1}
>       script: |
>         #!/bin/bash
>         logger "1. hello from marconi"
>
>   configB:
>     type: OS::Heat::OrderedConfig
>     properties:
>       marconi_server: {get_attr: [config_server, url]}
>       hosted_on: {get_resource: serv1}
>       depends_on: {get_resource: configA}
>       script: |
>         #!/bin/bash
>         logger "2. hello from marconi"
>
>   serv1:
>     type: OS::Nova::Server
>     properties:
>       image: {get_param: image}
>       flavor: {get_param: flavor}
>       key_name: {get_param: key_name}
>       user_data: |
>         #!/bin/sh
>         # poll <marconi url>/v1/queues/{hostname}/messages
>         # apply config
>         # post a response message with any outputs
>         # delete request message
>
> The idea here is that each "os::heat::orderedConfig" does the
> following:
> create the following marconi queues:
> <server id>.{request,respones}
> sends the config to the request queue
> the vm then posts responses to the response queue
>
> - each vm/server has a "config" queue (named based on "hosted_on")
> - we can get attributes/outputs from the vm
> - we can depend_on other config resources
> - you can monitor progress externally via marconi
> - you can have properties other than "script" (puppet/chef/..)
> - you could/should have a marconi server running in you infrastructure
>   (I am doing it in a vm for ease of testing).
>
> Is this the kind of thing you are after?
>
No.
The king of thing I am taking about is that:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-notificationconfiguration.html
http://docs.aws.amazon.com/AutoScaling/latest/APIReference/API_DescribeAutoScalingNotificationTypes.html

Which I figured could be supported in Heat with the use Marconi's 
notifications.

Thanks
Patrick

> -Angus
>
>>>
>>>> The second one would be to support a new type of AWS::IAM::User 
>>>> (perhaps
>>>> OS::IAM::User) resource whereby one could pass Keystone credentials to
>>>> be able to specify Ceilometer alarms based on application's specific
>>>> metrics (a.k.a KPIs).
>>>>
>>> It would likely be OS::Keystone::User, and AFAIK this is on the list of
>>> de-AWS-ification things.
>> Great! As I said. It's a blocker for us and really would like to see 
>> it accepted for icehouse.
>>>
>>>> I hope this is making sense to you and can serve as a basis for 
>>>> further
>>>> discussions and refinements.
>>>>
>>> Really great feedback Patrick, thanks again for sharing!
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> -- 
>> Patrick Petit
>> Cloud Computing Principal Architect, Innovative Products
>> Bull, Architect of an Open World TM
>> Tél : +33 (0)4 76 29 70 31
>> Mobile : +33 (0)6 85 22 06 39
>> http://www.bull.com
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
http://www.bull.com