Open Stack

I have another example, nailgun and UI are bundled in FuelWeb being quite
independent components. Nailgun is python REST API, while UI is HTML/CSS/JS
+ libs. I also support the idea making CLI a separate project, it is
similar to FuelWeb UI, it uses the same REST API. Fuelclient lib is also
good idea, REPL can be separated from command execution logic.

Multiple simple components are usually easier to maintain, bigger
components tend to become complex and tightly coupled.

I also fully support standards of naming files and directories, although it
relates to Python stuff mostly.

Anton Zemlyanov


> 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
> cliff?)
> 3.5) oslo.log for logging
> 3.6) stevedore for plugins
> etc.
> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/682480a9/attachment.html>