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 <sba...@redhat.com> wrote on 28/04/2014 23:31:56: > From: Steve Baker <sba...@redhat.com> > To: openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
