Open Stack

I think that OpenStack Networking is complex enough that it warrants a
separate book to describe the concepts in detail.

In particular:
 * Many potential operators don't have enough prior networking experience
to understand all of the underlying concepts
 * You really need to understand how OpenStack actually implements the
networking to be able to do (and debug!) a proper deployment, especially
since so many factors are site-specific

I just created this blueprint for a new guide that focuses specifically on
describing the concepts behind OpenStack Networking:

https://blueprints.launchpad.net/openstack-manuals/+spec/understanding-networking
https://wiki.openstack.org/wiki/Documentation/UnderstandingNetworking

At one point, I was considering writing this book on my own, but if the doc
team feel that this would be a good fit for the official docs, then I think
having it as an official doc is best, especially since I likely don't have
the cycles to get it done on my own.

Do folks think having a separate guide focuses explicitly on Understanding
OpenStack Networking would be a good idea?

Lorin




On Sun, Jan 5, 2014 at 1:43 PM, Andreas Jaeger <aj at suse.com> wrote:

> Alvise,
>
> thanks for your answer.
>
> On 01/05/2014 03:17 PM, Alvise Dorigo wrote:
> >
> > On 05 Jan 2014, at 13:52, Andreas Jaeger <aj at suse.com
> > <mailto:aj at suse.com>> wrote:
> >
> >> Hi Alvise,
> >>
> >> I'm sorry to hear about your experiences. I know that the Networking
> >> chapter in the Install Guide is not perfect yet and we've improved it
> >> over the last couple of months.
> >>
> >> I've copied the documentation team and would like to hear a bit more
> >> what exactly was the problem for you - why is it hard to follow? Do you
> >> have any proposals on how to improve it?
> >>
> >> Reading your text, I think one suggestion is not to "jump around" where
> >> the guides jump to plug-in configuration and back. Anything else?
> >
> > 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?
>
> > 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
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140105/9ec5c313/attachment-0001.html>