Open Stack

On 05 Jan 2014, at 19:43, Andreas Jaeger <aj at suse.com> wrote:

> Alvise,
> 
> thanks for your answer.
> 
> On 01/05/2014 03:17 PM, Alvise Dorigo wrote:
>> 
>> 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. 
> 
> The guide was planned to support different plug-ins but only supports a
> single one - and therefore some things are done a bit awkward.
> 
>> In addition. At page 29 (I’m referring to the PDF
>> version http://docs.openstack.org/havana/install-guide/install/yum/openstack-install-guide-yum-havana.pdf)
>> 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.
> 
> A lot of people still use nova-network. There's a note "If you need the
> full software-defined networking stack, see Chapter 9, Install the
> Networking service.", should we make that more prominent?
> 

I think so; and so also for other aspects of the installation/configuration procedure.

Thanks,

	A.

>> 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.
>> 
>> 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.
>> 
>> Page 67: 4. Return to the OVS general instructions.
>> Where ? perhaps step 9 @page 65 ?
>> 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).
>> 
>> 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.
>> 
>> 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:
>> 
>> ======================
>> bash-4.1$ neutron net-show esterna
>> +---------------------------+--------------------------------------+
>> | Field                     | Value                                |
>> +---------------------------+--------------------------------------+
>> | admin_state_up            | True                                 |
>> | id                        | 9b12acfa-4146-4f68-b69d-fb660162ad58 |
>> | name                      | esterna                              |
>> | provider:network_type     | vlan                                 |
>> | provider:physical_network | physnet1                             |
>> | provider:segmentation_id  | 2                                    |
>> | router:external           | True                                 |
>> | shared                    | True                                 |
>> | status                    | ACTIVE                               |
>> | subnets                   | 27876b6f-7904-42c7-9760-bc46725c4376 |
>> | tenant_id                 | ff95d472eccd428f8c5cc29dcf3014ec     |
>> +---------------------------+--------------------------------------+
>> bash-4.1$ neutron net-update demo-net --shared=True
>> Updated network: demo-net
>> bash-4.1$ nova net-list
>> 
>> bash-4.1$ 
>> 
>> ======================
>> 
>> For sure I made a mistake, but it easy to make a mistake if the doc is
>> “adventurous” as they admit at the beginning ;-)
>> 
>> thanks for attention,
>> 
>> Alvise
>> 
>> P.S. I’m in hurry, so I’ve to try ASAP the RedHat documentation
>> suggested by Sankarshan. 
> 
> Andreas
> -- 
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126