Excerpts from Georgy Okrokvertskhov's message of 2013-09-30 11:44:26 -0700: > Hi, > > I am working on the OpenStack project Murano which actually had to solve > the same problem with software level orchestration. Right now Murano has a > DSL language which allows you to define a workflow for a complex service > deployment. > Murano uses Heat for infrastructure managements and actually there is a > part of DSL language which allows you to generate Heat template for > deployment. > > This is a native to OpenStack project written in Python following all > OpenStack community rules. Before creating Murano we evaluated different > software orchestrators like SaltStack, Chef and Puppet+mcollective. All of > them have capabilities for software management but all of them are not > native to OpenStack. I think it will be quite reasonable to have something > under full control of OpenStack community then use something which is not > native (even in programming language) to OpenStack. > > Here is a link to the project overview: > https://wiki.openstack.org/wiki/Murano/ProjectOverview > > Right now Murano is concentrated on Windows services management but we also > working on Linux Agent to allow Linux software configuration too. >
Hi! We've written some very basic tools to do server configuration for the OpenStack on OpenStack (TripleO) Deployment program. Hopefully we can avert you having to do any duplicate work and join forces. Note that configuring software and servers is not one job. The tools we have right now: os-collect-config - agent to collect data from config sources and trigger commands on changes. [1] os-refresh-config - run scripts to manage state during config changes (run-parts but more structured) [2] os-apply-config - write config files [3] [1] http://pypi.python.org/pypi/os-collect-config [2] http://pypi.python.org/pypi/os-refresh-config [3] http://pypi.python.org/pypi/os-apply-config We do not have a tool to do run-time software installation, because we are working on an image based deployment method (thus building images with diskimage-builder). IMO, there are so many good tools already written that get this job done, doing one just for the sake of it being OpenStack native is a low priority. However, a minimal thing is needed for Heat users so they can use it to install those better tools for ongoing run-time configuration. cfn-init is actually pretty good. Its only crime other than being born of Amazon is that it also does a few other jobs, namely file writing and service management. Anyway, before you run off and write an agent, I hope you will take a look at os-collect-config and considering using it. For the command to run, I recommend os-refresh-config as you can have it run a progression of config tools. For what to run in the configuration step of os-refresh-config, cfn-init would work, however there is a blueprint for a native interface that might be a bit different here: https://blueprints.launchpad.net/heat/+spec/native-tools-bootstrap-config > When do you have a meeting for HOT software configuration discussion? I > think we can add value here for Heat as we have already required components > for software orchestration with full integration with OpenStack and > Keystone in particular. Heat meets at 2000 UTC every Wednesday. TripleO meets at 2000 UTC every Tuesday. Hope to see you there! _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
