> The discussion didn't result in a consensus, but it did revealed a great > number of things to be accounted. I've tried to summarize top-level points > in the etherpad . It lists only items everyone (as it seems to me) agrees > on, or suggested options where there was no consensus. Let me know if i > misunderstood or missed something. The etherpad does not list > advantages/disadvantages of options, otherwise it just would be too long. > Interested people might search the thread for the arguments :-) . > > I've thought it over and I agree with people saying we need to move further. > Savanna needs the agent and I am going to write a PoC for it. Sure the PoC > will be implemented in project-independent way. I still think that Salt > limitations overweight its advantages, so the PoC will be done on top of > oslo.messaging without Salt. At least we'll have an example on how it might > look. > > Most probably I will have more questions in the process, for instance we > didn't finish discussion on enabling networking for the agent yet. In that > case I will start a new, more specific thread in the list.
Hi Dimitri, While I agree that using Salt's transport may be wrong for us, the module system they have is really interesting, and a pretty big ecosystem already. It solved things like system-specific information, and it has a simple internal API to create modules. Redoing something from scratch Openstack-specific sounds like a mistake to me. As Salt seems to be able to work in a standalone mode, I think it'd be interesting to investigate that. Maybe it's worth separating the discussion between how to deliver messages to the servers (oslo.messaging, Marconi, etc), and what to do on the servers (where I think Salt is a great contender). -- Thomas _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev