[openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

Jedrzej Nowak jnowak at mirantis.com
Wed Dec 16 11:37:06 UTC 2015


+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 <loles at mirantis.com> wrote:

> Hi Dima,
>
> On Wed, Dec 16, 2015 at 12:03 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
> 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:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Łukasz Oleś
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
--
Warm regards,
Jędrzej Nowak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151216/ef8518a7/attachment.html>


More information about the OpenStack-dev mailing list