<div dir="ltr">Comments inline.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 1:42 PM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">The problem with this approach is that we can't manage the interfaces between components without changing the code of 2+ components (i.e. one that provides the data and all that consume it).</div></blockquote><div><br></div><div>I'm not sure if understand you correctly, none of these approaches</div><div>require to change the components, we will have change a single</div><div>place, which is specific data processor.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I also don't like polling model for data processors. In my understanding, components should push their changes through the pipeline. Although this is pure implementation detail and is not really important ATM.</div></div></blockquote><div><br></div><div>We don't have any other choice, we don't control components, configuration</div><div>components are not going to implement Fuel specific logic, so Fuel has</div><div>to pool the data.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The point is that for Solar integration, we still need integration points, and the less of them we have, the more simple the transition is going to be..</div></div></blockquote><div><br></div><div>As described above, there will be a single integration point, data processor.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 11:32 AM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Oleg,<div><br></div><div>I understand the concern, but in case of integration specifically with Solar,</div><div>I don't see any reasons to add ConfigDB, because Solar by itself is a ConfigDB.</div><div>At the same time I would agree that there might be a case, when user uses</div><div>Zookeeper/Puppet Master/CMDB as a data store, in this case we should store</div><div>the data directly in those services, without keeping them in yet another storage.</div><div><br></div><div>So the flow will look like this:</div><div>Components -></div><div>Data get polled by data processors -></div><div>| Solar data processor puts the data into Solar in its format</div><div>| Zookeeper data processor puts the data into Zookeeper in its format</div><div>| Custom CMDB data processor puts the data into CMDB in its own format</div><div><br></div><div>Thanks,</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>The idea behind configdb is that it is independent component that defines data flows between other components of the system. It has no knowledge about those components or specifics of their data. Data formats are defined by components themselves via schemas/templates and can be changed at any time (i.e. don't require code changes).</div><div><br></div><div>Important 'pro' having ConfigDB separate from Solar is that it will simplify transition from current Fuel architecture by breaking it into more definite stages and reducing the number of components Solar have to be integrated with.</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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"><div><div>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></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><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></div></div><span>__________________________________________________________________________<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></blockquote></div><br></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>
</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>
</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>
</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></div>