+1 for Lukasz concerns. 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).
On Wed, Dec 16, 2015 at 12:06 PM, Lukasz Oles <[email protected]> wrote: > Hi Dima, > > On Wed, Dec 16, 2015 at 12:03 AM, Dmitriy Shulyak <[email protected]> > wrote: > > Hello folks, > > > > 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. > What 2 projects? > > > > > 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. > > > > Main disagreements > > --------------------------- > > 1. configdb should be passive, writing to configdb is someone else > > responsibility > > + simpler implementation, easier to use > > - we will need another component that will do writing, or split this > > responsibility somehow > > > > 2. can be used without other solar components > > + clear inteface between solar components and storage layer > > - additional work required to design/refactor communication layer between > > modules in solar > > - some data will be duplicated between solar orchestrator layer and > configdb > > > > 3. templates for output > > technical detail, can be added on top of solardb if required > Who disagrees with who and about what? It's not clear for me. As far > as I remember we agreed to not use configdb but to use solar "data > resources". Data would be fetched using managers in the way as you > are doing now in f2s branch. > What is the problem here? > > Regards > > > > Similar functionality > > -------------------------- > > 1. Hierachical storage > > 2. Versioning of changes > > 3. Possibility to overwrite config values > > 4. Schema for inputs > > > > Overall it seems that we share same goals for both services, > > the difference lies in organizational and technical implementation > details. > > > > Possible solutions > > ------------------------ > > 1. develop configdb and solar with duplicated functionality > > - at least 2 additional components will be added to the picture, > > one is configdb, another one will need to sync data between configdb and > > solar > > - in some cases data in solar and configdb will be 100% duplicated > > - different teams will work on same functionality > > - integration of additional component for fuel will require integration > with > > configdb and with solar > > + configdb will be independent from solar orchestration/other components > > > > 2. make service out of solardb, allign with configdb use cases > > + solardb will be independent from solar orchestration/other solar > > components > > + integration of fuel component will be easier than in 1st version > > + clarity about components responsibility and new architecture > > - redesign/refactoring communication between components in solar > > > > 3. do not use configdb/no extraction of solardb > > - inproc communication, which can lead to coupled components (not the > case > > currently) > > + faster implementation (no major changes required for integration with > > fuel) > > + clarity about components responsibility and new architecture > > > > Summary > > ------------- > > For solar it makes no difference where data will come from: configdb or > > data sources, but in overall fuel architecture it will lead to > significant > > complexity increase. > > 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 > > on: > > - integration with fuel > > - implementing policy engine > > - polishing solar components > > This is why i am not sure that we can spend time on 2nd path right now, > > or even before 9.0. > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Łukasz Oleś > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -- Warm regards, Jędrzej Nowak
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
