<div dir="ltr"><div><div>Could we specify that all Fuel configuration files should include all allowable<br></div>parameters.  The optional parameters can be commented out but being able<br>to uncomment and populate a parameter is a lot easier than having to find the<br>exact name and order.<br><br></div>For bonus points, we could include commentary about when and how to activate<br>these optional parameters but we could also cover this in the documentation for<br>each configuration file.<br><br>meg<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 1:08 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div>Agree that we can take openstack standarts as example, but lets not simply copy them and just live with it.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div>I dont like that fuel is added into every project that we start, correct me if I am wrong but:</div><div>- 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</div><div>  to copy logs and other info</div><div>- same for network verification tool</div><div>- fuel_agent (image based provisioning) can work without all other fuel parts</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div>Well, we need some project, agree on that project structure and then just provide as example during review.</div><div>We can choose:</div><div>- fuelclient as cli example (but first refactor it)</div><div>- fuel-stats as web app example</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></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></div></blockquote><div>In my opinion we should not pick some library just because it is used in openstack, there should be some research and analys,</div><div>for example:</div><div>Cli application, there is several popular alternatives to cliff in python community:</div><div>- <a href="https://github.com/docopt/docopt" target="_blank">https://github.com/docopt/docopt</a></div><div>- <a href="https://github.com/mitsuhiko/click" target="_blank">https://github.com/mitsuhiko/click</a><br></div><div>I personnaly would prefer to use docopt, but click looks good as well.</div><div>Web frameworks is whole different story, in python community we have mature flask and pyramid, </div><div>and i dont see any benefits from using pecan.</div><div> </div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>