Open Stack

Hey Evgeniy.

This is awesome news1 I believe that microservices is way to go.
Despite the fact that them bring a set of classical problems (e.g.
duplication of domain entities) we will win more than loose. :)

If there will be any specs or design meetings, please send me invite -
I'd gladly join discussions.

Thanks,
Igor




On Wed, Oct 14, 2015 at 5:30 PM, Evgeniy L <eli at mirantis.com> wrote:
> Hi,
>
> We are starting Fuel modularization POC activity which is basically in one
> sentence
> can be explained as "Use Fuel without Fuel", it means that we want to
> provide
> for a user a way to use some good things from Fuel, without entire master
> node and
> other parts which user doesn't need.
>
> Currently we have monolithic system which includes every aspect of
> deployment
> logic, those components tightly coupled together, and there are few persons
> who understand all the interactions between components.
>
> As a result of modularization we will get the next benefits:
> 1. reusability of components
> 1.1. it will lead to more components consumers (users)
> 1.2. better integration with the community (some community projects might
>        be interested in using some parts of Fuel)
> 2. components decoupling will lead to clear interfaces between components
> 2.1. so it will be easier to replace some component
> 2.2. it will be easier to split the work between teams and it will help
> scale teams in
>        a much more efficient way
>
> Here are some thing which naturally can be used separately:
> * network configuration (is a part of POC)
> * advanced partitioning/provisioning (is a part of POC)
> * discovery mechanism (ironic-inspector?)
> * power management (ironic?)
> * network verification
> * diagnostic snapshot
> * etc
>
> The main purpose of POC is to try to make partly working system to figure
> out the
> scope of work which we will have to do upstream in order to make it
> production ready.
>
> Here are few basic component-specific ideas:
>
> Advanced partitioning/provisioning
> * split provisioning into two independent actions partitioning and
> provisioning
>   (currently we have a single call which does partitioning, provisioning,
>    post provisioning configuration)
> * figure out the data format (currently it's too Fuel and Cobbler specific)
>
> Network configuration
> * CRUD api on any entity in the system (in Fuel not all of the data are
> exposed via api,
>   so user has to go and edit entries in db manually)
> * no constraints regarding to network topology (in Fuel there are a lot of
> hardcoded
>   assumptions)
>
> Node hardware discovery
> * should be able to support different source drivers at the same time
>    (csv file, fuel-nailgun-agent, CMDB, dhcp, cobbler etc)
> * versioning of HW information (required for life cycle management)
> * notification about changes in hardware or about node statuses
>   (required for life cycle management)
>
> Common requirements for components:
> * every component must follow OpenStack coding standards when
>   we start working upstream after POC (so there shouldn't be a question
>   what to use pecan of flask)
> * Fuel specific interfaces should be implemented as drivers
> * this one is obvious, but currently one of the most problematic parts in
> Fuel,
>   HW gets changed, interface can be replaced, disk can be removed,
>   component should have a way to handle it
>
> Technically speaking, we want to have separate services for every component,
> it is one of the technical ways to force components to have clear
> interfaces.
>
> Other architecture decision which we want to try to solve is extendability,
> currently we have a problem that all of the logic which is related to
> deployment
> data is hardcoded in Nailgun. Plugins should be able to retrieve any data it
> needs from the system, in order to perform plugin deployment, these data
> should
> be retrieved using some interface, and we already have interface where we
> can
> provide stability and versioning, it's REST API. So basically deployment
> should
> consist of two steps first is to retrieve all required data from any source
> it needs,
> and after that send data to the nodes and start deployment.
>
> If you have any questions/suggestion don't hesitate to ask.
>
> Thanks,
>
> __________________________________________________________________________
> 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
>