<div dir="ltr"><div>+1 for Lukasz concerns.<br><br></div>But if we really need operate with "solar resources database" as a kv store, then we could implement service on top of it, It could be then separate project, which would work as separate service. Would it fulfill the requirements ? (we could implement it using some already existing protocol).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 12:06 PM, Lukasz Oles <span dir="ltr"><<a href="mailto:loles@mirantis.com" target="_blank">loles@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dima,<br>
<span class=""><br>
On Wed, Dec 16, 2015 at 12:03 AM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>> wrote:<br>
> Hello folks,<br>
><br>
> This topic is about configuration storage which will connect data sources<br>
> (nailgun/bareon/others) and orchestration. And right now we are developing<br>
> two projects that will overlap a bit.<br>
</span>What 2 projects?<br>
<span class=""><br>
><br>
> I understand there is not enough context to dive into this thread right<br>
> away, but i will appreciate if those people, who participated in design,<br>
> will add their opinions/clarifications on this matter.<br>
><br>
> Main disagreements<br>
> ---------------------------<br>
> 1. configdb should be passive, writing to configdb is someone else<br>
> responsibility<br>
> + simpler implementation, easier to use<br>
> - we will need another component that will do writing, or split this<br>
> responsibility somehow<br>
><br>
> 2. can be used without other solar components<br>
> + clear inteface between solar components and storage layer<br>
> - additional work required to design/refactor communication layer between<br>
> modules in solar<br>
> - some data will be duplicated between solar orchestrator layer and configdb<br>
><br>
> 3. templates for output<br>
> technical detail, can be added on top of solardb if required<br>
</span>Who disagrees with who and about what? It's not clear for me. As far<br>
as I remember we agreed to not use configdb but to use solar "data<br>
resources". Data would be fetched using managers  in the way as you<br>
are doing now in f2s branch.<br>
What is the problem here?<br>
<br>
Regards<br>
<div><div class="h5"><br>
<br>
> Similar functionality<br>
> --------------------------<br>
> 1. Hierachical storage<br>
> 2. Versioning of changes<br>
> 3. Possibility to overwrite config values<br>
> 4. Schema for inputs<br>
><br>
> Overall it seems that we share same goals for both services,<br>
> the difference lies in organizational and technical implementation details.<br>
><br>
> Possible solutions<br>
> ------------------------<br>
> 1. develop configdb and solar with duplicated functionality<br>
> - at least 2 additional components will be added to the picture,<br>
> one is configdb, another one will need to sync data between configdb and<br>
> solar<br>
> - in some cases data in solar and configdb will be 100% duplicated<br>
> - different teams will work on same functionality<br>
> - integration of additional component for fuel will require integration with<br>
> configdb and with solar<br>
> + configdb will be independent from solar orchestration/other components<br>
><br>
> 2. make service out of solardb, allign with configdb use cases<br>
> + solardb will be independent from solar orchestration/other solar<br>
> components<br>
> + integration of fuel component will be easier than in 1st version<br>
> + clarity about components responsibility and new architecture<br>
> - redesign/refactoring communication between components in solar<br>
><br>
> 3. do not use configdb/no extraction of solardb<br>
> - inproc communication, which can lead to coupled components (not the case<br>
> currently)<br>
> + faster implementation (no major changes required for integration with<br>
> fuel)<br>
> + clarity about components responsibility and new architecture<br>
><br>
> Summary<br>
> -------------<br>
> For solar it makes no difference where data will come from: configdb or<br>
> data sources, but in overall fuel architecture it will lead to significant<br>
> complexity increase.<br>
> It would be the best to follow 2nd path, because in long term we don't want<br>
> tightly coupled components, but in nearest future we need to concentrate<br>
> on:<br>
> - integration with fuel<br>
> - implementing policy engine<br>
> - polishing solar components<br>
> This is why i am not sure that we can spend time on 2nd path right now,<br>
> or even before 9.0.<br>
><br>
><br>
><br>
</div></div>> __________________________________________________________________________<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>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Łukasz Oleś<br>
<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>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>--<br></div><div>Warm regards,<br></div>Jędrzej Nowak<br></div></div>
</div>