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