Open Stack

I'm hesitant to add a guide mid-release as it bit us pretty hard last
release and we're still reeling from it. However if our crack info
architects see this as a way out of the reorg we have to do anyway, I'm
happy to support it. Can others weigh in on a good plan for this new book?
Is anyone willing to be owner?

Thanks,
Anne


On Sun, Jan 5, 2014 at 1:08 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

>
>
> My 5 cents …. Given we have an image guide book (
> http://docs.openstack.org/image-guide/content/) and Neutron seems way
> more complex than that, I would support a dedicated book for Neutron.
>
>
>
> However, I think there should continue to be chapters in the standard
> guides for Neutron topics which can refer to the new book for details. My
> experience is that part of the problem with understanding OpenStack
> networking is that people get scared at the first hurdle… we should be able
> to get them over the first few before they hit the more complex stuff.
>
>
>
> Tim
>
>
>
> *From:* lorinh at gmail.com [mailto:lorinh at gmail.com]
> *Sent:* 05 January 2014 19:54
> *To:* Andreas Jaeger
> *Cc:* openstack-docs at lists.openstack.org; Alvise Dorigo
> *Subject:* Re: [Openstack-docs] [Openstack-operators] Neutron
> Documentation
>
>
>
> 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
>
>
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
>


-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140105/4f713d10/attachment-0001.html>