<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 05 Jan 2014, at 13:52, Andreas Jaeger <<a href="mailto:aj@suse.com">aj@suse.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Alvise,<br><br>I'm sorry to hear about your experiences. I know that the Networking<br>chapter in the Install Guide is not perfect yet and we've improved it<br>over the last couple of months.<br><br>I've copied the documentation team and would like to hear a bit more<br>what exactly was the problem for you - why is it hard to follow? Do you<br>have any proposals on how to improve it?<br><br>Reading your text, I think one suggestion is not to "jump around" where<br>the guides jump to plug-in configuration and back. Anything else?<br></blockquote><div><br></div><div>yes, that’s for sure the main point; a continuous flow of instructions (i.e. commands to issue or files to modify) that are clear about where to execute, should be mandatory. </div><div><br></div><div>In addition. At page 29 (I’m referring to the PDF version <a href="http://docs.openstack.org/havana/install-guide/install/yum/openstack-install-guide-yum-havana.pdf">http://docs.openstack.org/havana/install-guide/install/yum/openstack-install-guide-yum-havana.pdf</a>) I read “Enable Networking”. That chapter talks about nova-network which is, as far as I know, deprecated in Havana, and everybody should definitely use Neutron (am I correct ?). That chapter is clearly misleading because put in mind the idea that one could anyway use the easy nova-network-based networking. I would remove any reference to nova-network at all, and make a better integration of compute node networking setup with Neutron.</div><div><br></div><div>An example of “jumping” is at page 63: “For instructions, see ‘instructions’.” which link to page 64 ("Install and configure the networking plug-ins”). But the are more examples in the rest of the text.</div><div><br></div><div>There’s also another thing not totally clear for me; at page 66 “Warning. You must use at least the No-Op firewall. Otherwise, Horizon […]”. Those "must” and “at least” words are (at least for me) not completely clear in the overall context; in fact above they say “Otherwise, you can choose […] Hybrid OVS-IPTables driver”. Then, can I choose or not ? Or maybe the Hybrid and the No-op must be specified in different places ? but anyway it is not clear.</div><div><br></div><div>Page 67: 4. Return to the OVS general instructions.</div><div>Where ? perhaps step 9 @page 65 ?</div><div>The GOTO/RETURN directives in a “linear” documentation are a little bit “annoying”… at least for me and some other people I know having difficulties to install Neutron (they rely only on Packstack, but I need manual configuration).</div><div><br></div><div>Another unclear thing: page 70, step 5 indicates a jump forward. At the end there’s the bridge adding (br_DATA_INTERFACE), but there’s not indication to modify ifcfg-eth0 and ifcfg-br_DATA_ as before (made on the network node)… And as far as I understand this step should be done.</div><div><br></div><div>Page 71: “If you wish to have a combined controller/compute node follow […]”. Then I can skip this chapter, because I want all neutron services/plugins/agent on the network node, the compute daemon on the compute node, and keystone/glance/nova-api/nova-cert/nova-conductor… on the controller node. And this is what I’ve done (skipping the chapter at page 71). But nova-api cannot communicate, apparently, with neutron. In fact “nova net-list” doesn’t return anything even after net and subnet creation with the neutron command line:</div><div><br></div><div>======================</div><div><div>bash-4.1$ neutron net-show esterna</div><div>+---------------------------+--------------------------------------+</div><div>| Field | Value |</div><div>+---------------------------+--------------------------------------+</div><div>| admin_state_up | True |</div><div>| id | 9b12acfa-4146-4f68-b69d-fb660162ad58 |</div><div>| name | esterna |</div><div>| provider:network_type | vlan |</div><div>| provider:physical_network | physnet1 |</div><div>| provider:segmentation_id | 2 |</div><div>| router:external | True |</div><div>| shared | True |</div><div>| status | ACTIVE |</div><div>| subnets | 27876b6f-7904-42c7-9760-bc46725c4376 |</div><div>| tenant_id | ff95d472eccd428f8c5cc29dcf3014ec |</div><div>+---------------------------+--------------------------------------+</div><div>bash-4.1$ neutron net-update demo-net --shared=True</div><div>Updated network: demo-net</div><div>bash-4.1$ nova net-list</div><div><br></div><div>bash-4.1$ </div><div><br></div><div>======================</div></div><div><br></div><div>For sure I made a mistake, but it easy to make a mistake if the doc is “adventurous” as they admit at the beginning ;-)</div><div><br></div><div>thanks for attention,</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Alvise</div><div><br></div><div>P.S. I’m in hurry, so I’ve to try ASAP the RedHat documentation suggested by Sankarshan. <br> </div><blockquote type="cite"><br>thanks,<br>Andreas<br><br>On 01/05/2014 12:06 PM, Alvise Dorigo wrote:<br><blockquote type="cite">Hi all,<br>I’m here to ask if there’s some “definitive” Neutron installation and configuration guide for RHEL linux distros (ScientificLinux, CentOS, RedHat, Fedora… at least for CentOS) maybe written by some cloud administrator who managed a complete openstack installation/configuration successfully.<br><br>I’m asking this because:<br><br>1. first of all, they wrote on the doc in <a href="http://docs.openstack.org">docs.openstack.org</a>: “this chapter is a bit more adventurous than we would like. We’re working on cleanup […]”.<br>2. Actually following that guide is quite hard and error-prone; for 3 times I wasn’t able to get a virtual instance to come up with the network correctly working. <br><br>For 1., I’ve been seeing that sentence for at least 3 months so I wonder if I can completely trust on that procedure.<br>For 2., I’d need a clear workflow that explain me in a “flat” way what to do and where (controller node, network node, compute node)… and not all the time this appeared completely clear to me, above all because the structure is not flat (must jump around to follow the procedure). Then, for sure I made some mistake during the configuration, but I would charge (a little) that doc with it.<br><br><br>many thanks, and happy new year to you all!<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Alvise<br>_______________________________________________<br>OpenStack-operators mailing list<br><a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br><br></blockquote><br><br>-- <br> Andreas Jaeger aj@{<a href="http://suse.com">suse.com</a>,<a href="http://opensuse.org">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></blockquote></div><br></body></html>