Open Stack

Hi Steve,

I have added something to the design summit etherpad at [1] based on this
ML discussion so far. I removed some items from my initial post since they
seem to be resolved. I copied more concrete points from this thread into
other items. Please have a look and edit as needed.

[1] https://etherpad.openstack.org/p/juno-summit-heat-sw-orch

Regards,
Thomas

Steve Baker <sbaker at redhat.com> wrote on 28/04/2014 23:31:56:

> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org
> Date: 28/04/2014 23:32
> Subject: Re: [openstack-dev] [Heat] Design summit preparation - Next
> steps for Heat Software Orchestration
>
> 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.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>