<div dir="ltr"><div><div>All,</div><div><br></div><div>Recently we launched a couple new Fuel related projects (fuel_plugin_builder, fuel_agent, fuel_upgrade, etc.). Those projects are written in python and they use different approaches to organizing CLI, configuration, different third party libraries, etc. Besides, we have some old Fuel projects which are also not standardized. </div><div><br></div><div>The idea is to have a set of standards for all Fuel related projects about architecture in general, third party libraries, API, user interface, documentation, etc. When I take a look at any OpenStack project I usually know a priori how project's code is organized. For example, cli is likely based on python cliff library, configuration is based on oslo.config, database layer is based of oslo.db and so on. </div><div><br></div><div>Let's do the same for Fuel. Frankly, I'd say we could take OpenStack standards as is and use them for Fuel. But maybe there are other opinions. Let's discuss this and decide what to do. Do we actually need those standards at all?</div><div><br></div><div>Just to keep the scope narrow let's consider fuelclient project as an example. If we decide something about it, we can then try to spread those decisions on other Fuel related projects.</div><div><br></div><div>0) Standard for projects naming. </div><div>Currently most of Fuel projects are named like fuel-whatever or even whatever? Is it ok? Or maybe we need some formal rules for naming. For example, all OpenStack clients are named python-someclient. Do we need to rename fuelclient into python-fuelclient?</div><div> <br></div><div>1) Standard for an architecture. </div><div>Most of OpenStack services are split into several independent parts (raughly service-api, serivce-engine, python-serivceclient) and those parts interact with each other via REST and AMQP. python-serivceclient is usually located in a separate repository. Do we actually need to do the same for Fuel? According to fuelclient it means it should be moved into a separate repository. Fortunately, it already uses REST API for interacting with nailgun. But it should be possible to use it not only as a CLI tool, but also as a library.  </div><div><br></div><div>2) Standard for project directory structure (directory names for api, db models,  drivers, cli related code, plugins, common code, etc.) </div><div>Do we actually need to standardize a directory structure?</div><div><br></div><div>3) Standard for third party libraries</div><div>As far as Fuel is a deployment tool for OpenStack, let's make a decision about using OpenStack components wherever it is possible.</div><div>3.1) oslo.config for configuring.</div><div>3.2) oslo.db for database layer</div><div>3.3) oslo.messaging for AMQP layer</div><div>3.4) cliff for CLI (should we refactor fuelclient so as to make based on cliff?)</div><div>3.5) oslo.log for logging</div><div>3.6) stevedore for plugins</div><div>etc.</div><div>What about third party components which are not OpenStack related? What could be the requirements for an arbitrary PyPi package?</div><div><br></div><div>4) Standard for testing.<br></div><div>It requires a separate discussion.</div><div><br></div><div>5) Standard for documentation.</div></div><div>It requires a separate discussion.<br></div><div><br></div><br clear="all"><div><div>Vladimir Kozhukalov</div></div>
</div>