Open Stack

Could we specify that all Fuel configuration files should include all
allowable
parameters.  The optional parameters can be commented out but being able
to uncomment and populate a parameter is a lot easier than having to find
the
exact name and order.

For bonus points, we could include commentary about when and how to activate
these optional parameters but we could also cover this in the documentation
for
each configuration file.

meg

On Tue, Oct 28, 2014 at 1:08 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

>
>
>> 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 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/20141028/e4783127/attachment.html>