[openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

Steve Baker sbaker at redhat.com
Mon Apr 28 21:31:56 UTC 2014


On 29/04/14 01:41, Thomas Spatzier wrote:
> Excerpts from Steve Baker's message on 28/04/2014 01:25:29:
>
>> I'm with Clint on this one. Heat-engine cannot know the true state
>> of a server just by monitoring what has been polled and signaled.
>> Since it can't know it would be dangerous for it to guess. Instead
>> it should just offer all known configuration data to the server and
>> allow the server to make the decision whether to execute a config
>> again. I still think one more derived input value would be useful to
>> help the server to make that decision. This could either be a
>> datestamp for when the derived config was created, or a hash of all
>> of the derived config data.
> So as I said in another note, I agree that the this seems best handled in
> the in-instance tool and the Heat engine, or the resource should probably
> not have any new magic. If there is some additional state property that the
> resource maintains, and the in-instance tool handles it, that should be
> fine. I think what is important, is that users who want to use existing
> automation scripts do not have to implement much logic for interpreting
> that additional "flag", but that we handle it in the generic hook
> invocation logic.
>
> Can you elaborate more on what you have in mind with the additional derived
> input value?
>
Heat needs to give the hook or the config script enough information to
know whether that *particular* combination of config script + input
values has been executed on that server. It could do this by providing
the timestamp or the hash of the derived config, then this piece of
information can be compared with some local state on the server to
decide whether to run the config again. Actually the hash could be
calculated on the server too, so the hash could be calculated in
55-heat-config then consumed by the hook or config script.
>>
>> For this design session I have my own list of items to discuss:
>> #4.1 Maturing the puppet hook so it can invoke more existing puppet
> scripts
>> #4.2 Make progress on the chef hook, and defining the mapping from
>> chef concepts to heat config/inputs/outputs
>> #4.3 Finding volunteers to write hooks for Salt, Ansible
>> #5.1 Now that heatclient can include binary files, discuss enhancing
>> get_file to zip the directory contents if it is pointed at a directory
>> #5.2 Now that heatclient can include binary files, discuss making
>> stack create/update API calls multipart/form-data so that proper
>> mime data can be captured for attached files
>> #6.1 Discuss options for where else metadata could be polled from (ie,
> swift)
>> #6.2 Discuss whether #6.1 can lead to software-config that can work
>> on an OpenStack which doesn't allow admin users or keystone domains
>> (ie, rackspace)
> #4.1 thru #4.3 are important and seem straight forward and more about
> finding people to do it. If there are design issues to be figured out,
> maybe we can do it offline via the ML.
>
> #5.1 and #5.2 are really interesting and map to use cases we have also seen
> internally. Is there a size limit for the binaries? Would this also cover,
> e.g. sending small binaries like a wordpress install tgz instead of doing a
> yum based install? Or would the latter be something to address via #6
> below?
>
> #6 looks very interesting as well. We also thought about using swift not
> only for metadata but also for sharing installables to instances in cases
> where direct download from the internet, for example, is not possible.
We'll just have to try it to find out were the limits are, but in
general I would assume the following:
* user_data limited to about 16k total, so anything bigger than that
needs to go in the deployment input_values
* practically speaking, a binary could go in a deployment input value or
a swift object resource (which doesn't exist yet) to be passed to the
deployment input value by url
* The default heat.conf max_template_size=524288, so to avoid this limit
binaries should be put into swift outside the scope of heat, and passed
into the template as a parameter URL.




More information about the OpenStack-dev mailing list