Open Stack

I can also assist with developing this book.


On Sun, Jan 5, 2014 at 5:00 PM, Nicholas Chase <nchase at mirantis.com> wrote:

> I'm definitely in agreement on this; the question is whether we can get it
> done.
>
> That said, it's what we're here for, isn't it?
>
> Rather than walking in circles, how about if we make a note in the current
> docs that they're being expanded and link to the expanded version?  Then we
> can make the effort to give the Networking docs the attention they deserve.
>  Let's face it, that really is the hardest, most confusing part about
> making OpenStack work.  If we can conquer that, everything else will look
> easy, and we'll be solving a major, major pain point for operators and
> users.
>
> I know resources are short here, but I think that it's something Nermina
> and I can take on if necessary, especially if we can work with Lorin to get
> the framework and pick his brain.
>
> ----  Nick
>
>
> On 1/5/2014 1:54 PM, lorinh at gmail.com wrote:
>
>> 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
>> <mailto: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>
>>      > <mailto: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 <http://suse.com>,opensuse.org
>>     <http://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
>>     <mailto: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
>>
>>
> _______________________________________________
> 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/4cc9869f/attachment-0001.html>