Open Stack

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151014/c0a7a04c/attachment.html>