<div dir="ltr">Agree.<div><br></div><div>Install guide is just a start/example, concentrate is better than cover all, for more services we can just provide a good place to let them discoverable, and lfor arger scale, we should use advanced tools such as puppet and ansible</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 6:12 PM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<span class=""><br>
We would love to add all sufficiently mature projects to the installation<br>
guide because it increases visibility and adoption by operators, but we<br>
lack resources to develop a source installation mechanism that retains as<br>
much simplicity as possible for our audience.<br>
</span></blockquote><span class="">
<br>
I think it would be a big mistake to try to create one guide for<br>
installing all OpenStack projects. As you say, testing what we have<br>
now is already a monumental task and impedes your ability to make<br>
changes. Adding more projects, with ever more dependencies and<br>
configuration issues to the work the same team is doing would bury<br>
the current documentation team. So I think focusing on the DefCore<br>
list, or even a smaller list of projects with tight installation<br>
integration requirements, makes sense for the team currently producing<br>
the installation guide.<br>
</span></blockquote>
<br>
Yes, the base install guide should ideally serve as a reference to reach that first step where you have all the underlying services (MySQL, Rabbit) and a base set of functionality (starterkit:compute ?) installed and working. That is where we need high-quality, proactively-checked, easy to understand content.<br>
<br>
Then additional guides (ideally produced by each project team with tooling and mentoring from the docs team) can pick up from that base first step, assuming their users have completed that first step successfully.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Thierry Carrez (ttx)</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>