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 <e...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
