<div dir="ltr">Hi Dmitry,<div><br></div><div>I also don't think that we should duplicate the data in configdb,</div><div>because in this case there will be +2 additional interfaces which</div><div>will require to covert the data into configdb and after that from</div><div>configdb to Solar, which seems redundant overhead.</div><div><br></div><div>But we should be able to put the data directly to user's</div><div>CMDB/ZooKeeper/Puppet Master/etc.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello folks,<div><br></div><div>This topic is about configuration storage which will connect data sources (nailgun/bareon/others) and orchestration. And right now we are developing two projects that will overlap a bit.</div><div><br></div><div>I understand there is not enough context to dive into this thread right away, but i will appreciate if those people, who participated in design, will add their opinions/clarifications on this matter.</div><div><div><br></div><div>Main disagreements</div><div>---------------------------</div><div>1. configdb should be passive, writing to configdb is someone else responsibility</div><div>+ simpler implementation, easier to use</div><div>- we will need another component that will do writing, or split this responsibility somehow</div><div><br></div><div>2. can be used without other solar components</div><div>+ clear inteface between solar components and storage layer</div><div>- additional work required to design/refactor communication layer between modules in solar</div><div>- some data will be duplicated between solar orchestrator layer and configdb</div><div><br></div><div>3. templates for output</div><div>technical detail, can be added on top of solardb if required</div><div><br></div><div>Similar functionality</div><div>--------------------------</div><div>1. Hierachical storage</div><div>2. Versioning of changes</div><div>3. Possibility to overwrite config values</div><div>4. Schema for inputs</div><div><br></div><div>Overall it seems that we share same goals for both services,</div><div>the difference lies in organizational and technical implementation details.</div><div><br></div><div>Possible solutions</div><div>------------------------</div><div>1. develop configdb and solar with duplicated functionality</div><div>- at least 2 additional components will be added to the picture,</div><div>one is configdb, another one will need to sync data between configdb and solar</div><div>- in some cases data in solar and configdb will be 100% duplicated</div><div>- different teams will work on same functionality</div><div>- integration of additional component for fuel will require integration with</div><div>configdb and with solar</div><div>+ configdb will be independent from solar orchestration/other components</div><div><br></div><div>2. make service out of solardb, allign with configdb use cases</div><div>+ solardb will be independent from solar orchestration/other solar components</div><div>+ integration of fuel component will be easier than in 1st version</div><div>+ clarity about components responsibility and new architecture</div><div>- redesign/refactoring communication between components in solar</div><div><br></div><div>3. do not use configdb/no extraction of solardb</div><div>- inproc communication, which can lead to coupled components (not the case currently)</div><div>+ faster implementation (no major changes required for integration with fuel)</div><div>+ clarity about components responsibility and new architecture</div><div><br></div><div>Summary</div><div>-------------</div><div>For solar it makes no difference where data will come from: configdb or</div><div>data sources, but in overall fuel architecture it will lead to significant</div><div>complexity increase.</div><div>It would be the best to follow 2nd path, because in long term we don't want tightly coupled components, but in nearest future we need to concentrate</div><div>on:</div><div>- integration with fuel</div><div>- implementing policy engine</div><div>- polishing solar components</div><div>This is why i am not sure that we can spend time on 2nd path right now,</div><div>or even before 9.0.</div></div><div><br></div><div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>