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.

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.

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?

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.

0) Standard for projects naming.
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?

1) Standard for an architecture.
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.

2) Standard for project directory structure (directory names for api, db
models,  drivers, cli related code, plugins, common code, etc.)
Do we actually need to standardize a directory structure?

3) Standard for third party libraries
As far as Fuel is a deployment tool for OpenStack, let's make a decision
about using OpenStack components wherever it is possible.
3.1) oslo.config for configuring.
3.2) oslo.db for database layer
3.3) oslo.messaging for AMQP layer
3.4) cliff for CLI (should we refactor fuelclient so as to make based on
3.5) oslo.log for logging
3.6) stevedore for plugins
What about third party components which are not OpenStack related? What
could be the requirements for an arbitrary PyPi package?

4) Standard for testing.
It requires a separate discussion.

5) Standard for documentation.
It requires a separate discussion.

Vladimir Kozhukalov
OpenStack-dev mailing list

Reply via email to