On Mon, Dec 9, 2013 at 10:41 AM, Steven Dake <sd...@redhat.com> wrote:
> On 12/09/2013 09:41 AM, David Boucha wrote: > > On Sat, Dec 7, 2013 at 11:09 PM, Monty Taylor <mord...@inaugust.com>wrote: > >> >> >> On 12/08/2013 07:36 AM, Robert Collins wrote: >> > On 8 December 2013 17:23, Monty Taylor <mord...@inaugust.com> wrote: >> >> >> > >> >> I suggested salt because we could very easily make trove and savana >> into >> >> salt masters (if we wanted to) just by having them import salt library >> >> and run an api call. When they spin up nodes using heat, we could >> easily >> >> have that to the cert exchange - and the admins of the site need not >> >> know _anything_ about salt, puppet or chef - only about trove or >> savana. >> > >> > Are salt masters multi-master / HA safe? >> > >> > E.g. if I've deployed 5 savanna API servers to handle load, and they >> > all do this 'just import', does that work? >> > >> > If not, and we have to have one special one, what happens when it >> > fails / is redeployed? >> >> Yes. You can have multiple salt masters. >> >> > Can salt minions affect each other? Could one pretend to be a master, >> > or snoop requests/responses to another minion? >> >> Yes and no. By default no - and this is protected by key encryption and >> whatnot. They can affect each other if you choose to explicitly grant >> them the ability to. That is - you can give a minion an acl to allow it >> inject specific command requests back up into the master. We use this in >> the infra systems to let a jenkins slave send a signal to our salt >> system to trigger a puppet run. That's all that slave can do though - >> send the signal that the puppet run needs to happen. >> >> However - I don't think we'd really want to use that in this case, so I >> think they answer you're looking for is no. >> >> > Is salt limited: is it possible to assert that we *cannot* run >> > arbitrary code over salt? >> >> In as much as it is possible to assert that about any piece of software >> (bugs, of course, blah blah) But the messages that salt sends to a >> minion are "run this thing that you have a local definition for" rather >> than "here, have some python and run it" >> >> Monty >> >> > > Salt was originally designed to be a unified agent for a system like > openstack. In fact, many people use it for this purpose right now. > > I discussed this with our team management and this is something > SaltStack wants to support. > > Are there any specifics things that the salt minion lacks right now to > support this use case? > > > David, > > If I am correct of my parsing of the salt nomenclature, Salt provides a > Master (eg a server) and minions (eg agents that connect to the salt > server). The salt server tells the minions what to do. > That is the default setup. The salt-minion can also run in standalone mode without a master. > This is not desirable for a unified agent (atleast in the case of Heat). > > The bar is very very very high for introducing new *mandatory* *server* > dependencies into OpenStack. Requiring a salt master (or a puppet master, > etc) in my view is a non-starter for a unified guest agent proposal. Now > if a heat user wants to use puppet, and can provide a puppet master in > their cloud environment, that is fine, as long as it is optional. > > A guest agent should have the following properties: > * minimal library dependency chain > Salt only has a few dependencies * no third-party server dependencies > As mentioned above, the salt-minion can run without a salt master in standalone mode * packaged in relevant cloudy distributions > The Salt Minion is packaged for all major (and many smaller) distributions. RHEL/EPEL/Debian/Ubuntu/Gentoo/FreeBSD/Arch/MacOS There is also a Windows installer. > In terms of features: > * run shell commands > * install files (with selinux properties as well) > * create users and groups (with selinux properties as well) > * install packages via yum, apt-get, rpm, pypi > * start and enable system services for systemd or sysvinit > * Install and unpack source tarballs > * run scripts > * Allow grouping, selection, and ordering of all of the above operations > Salt-Minion excels at all the above > > Agents are a huge pain to maintain and package. It took a huge amount of > willpower to get cloud-init standardized across the various distributions. > We have managed to get heat-cfntools (the heat agent) into every > distribution at this point and this was a significant amount of work. We > don't want to keep repeating this process for each OpenStack project! > I agree. It's a lot of work. The SaltStack organization has already done the work to package for all these distributions and maintains the packages. > > Regards, > -steve > > > Regards, Dave
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev