Open Stack

On 16.12.2015 00:03, Dmitriy Shulyak 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.
> 
> 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.

Comments inline, aligned with the case "A" described in the meeting
minutes [0]. Although, there was no clear view of *what* the config db
shall do and how to find its place for the cases A/B/C. Perhaps we
should describe it in the next design meeting.

[0]
https://etherpad.openstack.org/p/solar-minisummit-fuel-integration-architecture

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

Data resources shall fill the configdb by results of the fetched data
shaped by data processors aka serializers. The shaping process assumes
applying of all versioning and schema transformations knowledge required
to convert data from external sources into expected end state to make it
consumable by the Policy Engine.

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

Solar Data Resources may contain its own state perhaps. But I cannot see
how this would fit into the very basics of Solar Resource Management.
How to connect them each over and generic resources then? Anyway, a
solar resource just cannot be used without other solar components.

> 
> 3. templates for output
> technical detail, can be added on top of solardb if required
> 
> 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

Bering in mind that data resources shall fill the config db, that'd make
a little sense.

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


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando