<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>