<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>Multiple simple components are usually easier to maintain, bigger components tend to become complex and tightly coupled.</div><div><br></div><div>I also fully support standards of naming files and directories, although it relates to Python stuff mostly.</div><div><br></div><div>Anton Zemlyanov</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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>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><br></div><div>4) Standard for testing.<br></div><div>It requires a separate discussion.</div><div><br></div><div>5) Standard for documentation.</div></div><div>It requires a separate discussion.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><br clear="all"><div><div>Vladimir Kozhukalov</div></div>
</font></span></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></div>