There is an inaccuracy about savanna-conductor role in this document. Now we have no real reasons to make savanna-conductor as an separated service. The main goal of declaring savanna-conductor in this doc is to illustrate that we want to move all db-related operations to the single module that could be used as a separated service (if it’ll be needed in future) and make savanna able to work with db only using this module w/o direct db access. In fact we want only “local” mode for savanna-conductor now.
There are several potential reasons to implement savanna-conductor as a separated service in future. First of all, there are some ideas about provisioning savanna agents to the Hadoop clusters to monitor/manage cluster state, so, we’ll have the same security problem as nova. The second potential reason is that we are planning to advance tasks execution flow in savanna to support long running complex operations that will require additional management such as replying/rollbacking and conductor could be the service that will implement it. Thank you for comment, I’ll update diagram and description to explain that currently there is no need to implement savanna-conductor. Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Jul 23, 2013, at 20:45, Russell Bryant <rbry...@redhat.com> wrote: > On 07/23/2013 12:32 PM, Sergey Lukjanov wrote: >> Hi evereyone, >> >> We’ve started working on upgrading Savanna architecture in version 0.3 to >> make it horizontally scalable. >> >> The most part of information is in the wiki page - >> https://wiki.openstack.org/wiki/Savanna/NextGenArchitecture. >> >> Additionally there are several blueprints created for this activity - >> https://blueprints.launchpad.net/savanna?searchtext=ng- >> >> We are looking for comments / questions / suggestions. >> >> P.S. The another thing that we’re working on in Savanna 0.3 is EDP (Elastic >> Data Processing). > > Just did a quick look ... what's the justification for needing > savanna-conductor? > > In nova, putting db access through nova-conductor was to remove direct > db access from compute nodes, since they are the least trusted part of > the system. I don't see the same concern here. Is there another reason > for this or should you just have api and engine hit the db directly? > > -- > Russell Bryant > > _______________________________________________ > 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
