> > 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? > > Agree that we can take openstack standarts as example, but lets not simply copy them and just live with it.
> > 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? > I dont like that fuel is added into every project that we start, correct me if I am wrong but: - shotgun can be self-contained project, and still provide certain value, actually i think it can be used by jenkins in our and openstack gates to copy logs and other info - same for network verification tool - fuel_agent (image based provisioning) can work without all other fuel parts > > 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? > > Well, we need some project, agree on that project structure and then just provide as example during review. We can choose: - fuelclient as cli example (but first refactor it) - fuel-stats as web app example > 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? > In my opinion we should not pick some library just because it is used in openstack, there should be some research and analys, for example: Cli application, there is several popular alternatives to cliff in python community: - https://github.com/docopt/docopt - https://github.com/mitsuhiko/click I personnaly would prefer to use docopt, but click looks good as well. Web frameworks is whole different story, in python community we have mature flask and pyramid, and i dont see any benefits from using pecan.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
