<div dir="ltr">For distributions supporting openstack-config, the neutron chapter in the Havana installation guide already contains limited use of the latter. I suspect we'll standardize on manual configuration in the Icehouse updates for neutron and let the review process determine whether it sticks.<div>
<br></div><div>For distributions supporting alternative configuration methods, particularly openstack-config, I think we should mention them in the appropriate chapter and provide a couple examples showing how to use them. Debconf might take a little more creativity.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 12:19 PM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</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"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Feb 26, 2014 at 1:05 PM, Andreas Jaeger <span dir="ltr"><<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 02/26/2014 06:58 PM, Joe Topjian wrote:<br>
> With those thoughts in mind, here are my $0.02:<br>
><br>
> I frequently work with system administrators new to OpenStack and<br>
> planning to deploy once they learned how to use it. I've worked with<br>
> Ubuntu, Red Hat, and Debian users. I don't try to convince them to pick<br>
> one distro or the other -- that's their decision.<br>
><br>
> In all cases, I always have them focus on editing the various<br>
> configuration files manually. This is for a few reasons:<br>
><br>
> 1. It works across all distros.<br>
> 2. It invokes more of a rote learning mindset, which I find a benefit<br>
> when learning something new. It works, too. By the time the user has<br>
> reached installing the Cinder service, they already know the 3-step<br>
> pattern (install packages, edit config file, restart service), as well<br>
> as have a general idea of where the config file is located and what<br>
> common settings are applied.<br>
> 3. Even when they try to use a "helper" tool such as openstack-config or<br>
> the debconf tool, they always have to go back to manually edit the<br>
> configuration file for some reason or another (typo, option unique to<br>
> their environment, etc).<br>
><br>
> To create a solid foundation for learning OpenStack, I feel the user<br>
> must know their way around the configuration files, so I think the<br>
> installation instructions should be as distro-agnostic and fundamental<br>
> as possible. As stated in Anne's original email, appendixes can be<br>
> created for the distro-specific tools (and even the iniset devstack<br>
> function). It won't be possible to get rid of all conditional markup, as<br>
> each distro has a different way to install packages, restart services, etc.<br>
><br>
> Regarding the supplemental components of the install (RabbitMQ, MySQL,<br>
> etc), I think a standard set of components should be used if they work<br>
> across all distros. I understand that this might come across as<br>
> endorsing the component as the "official" choice of an OpenStack<br>
> installation, but that's not the intent. Instead, the intent is to use a<br>
> standard set of working components in order to focus on the OpenStack<br>
> installation itself. More time can be devoted to documenting the various<br>
> OpenStack installation types (nova-network, neutron, object storage<br>
> only, etc). Short of the AMQP service, I can't think of any other<br>
> service that differs from distro to distro, but I think the idea is<br>
> important.<br>
><br>
> Additionally, once a standard set of components is used, supplemental<br>
> documentation (appendixes?) can be written by experts of different<br>
> components. This allows install guide authors to focus on one set and<br>
> not have to be a "jack of all trades" to support all possible components<br>
> while at the same time tapping the community for experts in other areas.<br>
><br>
> So that's my opinion. I realize it holds little weight as I don't<br>
> contribute as much to docs as I did a few months ago. But I do work<br>
> hands-on with OpenStack every day and frequently meet with people to<br>
> help them get started. These views are a result of my experience.<br>
<br></div></div></blockquote><div><br></div></div></div><div>I think Joe's experience is similar to others I've talked to, especially trainers. So I think this additive approach is great.</div><div class=""><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<br>
</div></div>I have nothing against replacing openstack-config with general<br>
instructions for editing - and placing openstack-config or crudini in an<br>
appendix.<br>
<br>
We can also write the install instructions in a more generic way, so say<br>
for example:<br>
On Ubuntu, install the package "cinder".<br>
On Fedora, openSUSE ... install the package "openstack-cinder".<br>
<br>
And have a distro specific appendix where it's documented that for<br>
installing packages you run on Fedora "yum install $package", on<br>
openSUSE "zypper install $package" ...<br>
The disadvantage is that you cannot copy & paste the complete command-line.<br>
<br></blockquote><div><br></div></div><div>I think we have to keep copy and paste -- based on what I've seen over the years.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Both should reduce some of the conditionals we currently have. I agree<br>
with you that there are differences between distributions and their<br>
packages and we should account for these.<br>
<br>
I really suggest that somebody writes down what exactly is proposed<br>
(incl. instruction on what to change) and perhaps converts a section or<br>
two to see how it looks.<br></blockquote><div><br></div></div><div>Yep, that's what I've asked Phil and Matt and crew to do (convert the neutron chapters for an example). We can continue shaping in the review itself then. </div>
<div><br></div><div>Sorry for any confusion but I do appreciate the hard work going on here!</div><span class="HOEnZb"><font color="#888888"><div>Anne</div></font></span><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
Andreas<br>
--<br>
Andreas Jaeger aj@{<a href="http://suse.com" target="_blank">suse.com</a>,<a href="http://opensuse.org" target="_blank">opensuse.org</a>} Twitter/Identica: jaegerandi<br>
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)<br>
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
<br>
</div><div><div>_______________________________________________<br>
Openstack-docs mailing list<br>
<a href="mailto:Openstack-docs@lists.openstack.org" target="_blank">Openstack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
</div></div></blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
Openstack-docs mailing list<br>
<a href="mailto:Openstack-docs@lists.openstack.org">Openstack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
<br></blockquote></div><br></div>