Bug 973301 - Technical Review: Quantum deployment using PackStack
Technical Review: Quantum deployment using PackStack
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Getting_Started_Guide (Show other bugs)
3.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.0
Assigned To: Stephen Gordon
ecs-bugs
: Documentation, Triaged
Depends On: 973314
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-11 12:08 EDT by Stephen Gordon
Modified: 2014-08-03 19:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-03 19:50:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 Stephen Gordon 2013-06-11 12:32:22 EDT
(In reply to Stephen Gordon from comment #0)
> > * 4.2 13e - Replace "DHCP plugin" with "DHCP agent".
> 
> ACK

Raised Bug # 973314, PackStack actually displays DHCP plugin.
Comment 3 Stephen Gordon 2013-06-11 12:38:41 EDT
Description sans internal link:

> > Hi Bob,
> > 
> > Yes that's the correct location, I have just pushed an updated version of
> > the ICG through brew to ensure the version on the stage includes some
> > Quantum related updates I made Friday.
> 
> Steve,
> 
> Notes from a very quick review of the Getting Started Guide:
> 
> * 2.1.3 - I'm not sure disabling NetworkManager is required. I have not
> done that in my setups. Someone else from the quantum team should
> confirm this is needed, and I wouldn't mind knowing why its needed.

The documentation bugs that this change originated from is here:

https://bugzilla.redhat.com/show_bug.cgi?id=967366
https://bugzilla.redhat.com/show_bug.cgi?id=967367

The packstack bug where I also queried this is here:

https://bugzilla.redhat.com/show_bug.cgi?id=967369

> * 2.2.3 - This section on storage configuration starts talking about
> packstack before its been mentioned. I think we need to introduce and
> describe the role of packstack in chapter 1.

ACK

> * 4 - I'd list 3 methods for running packstack here, all-in-one,
> interactively, and non-interactively.

ACK

> * 4.2 - We need an upfront discussion of the decisions that need to be
> made, at least for the networking service. We need to explain the choice
> between quantum and nova networking, how its selected, and then
> throughout the section show which options apply to nova vs quantum
> networking. With quantum, we need to similarly cover the choice of
> plugins and which options apply to each plugin. Also, for quantum (or
> nova's VlanManager), we need to at least mention the need for a switch
> that trunks a range of VLANs if doing a multi-node deployment.

Acknowledged, but I think this is an area where we are really struggling for traction. It's easier to say "contrast Nova vs Quantum" than it is to actually do it.

> * 4.2 13a - I think the network namespace usage defaults to Y (and
> ideally this option should be removed/hidden in packstack)

It didn't at the time, I believe it's supposed to be changed (if it hasn't already).

> * 4.2 13d - They probably need to know to set external bridge to empty
> if using a provider network for an external network.
> 
> * 4.2 13e - Replace "DHCP plugin" with "DHCP agent".

ACK

> * 4.2 13h - Need to explain that the gre tenant network type isn't
> available, and that local doesn't provide cross-node connectivity, so
> vlan is the only usable option for multi-node setups.

ACK

> * 4.2 13i - This is supposed to be about configuring
> network_vlan_ranges, but currently says something about "openvswitch
> plugins".

ACK

> * 4.2 14 - What is a "client server"???

The server on to which the client tools are deployed. I note that the only place the phrase appears is in the literal output from PackStack, has this changed?

> * 7.1 This section is supposed to be about CLI, but talks about logging
> into the dashboard.

ACK
 
> > We're really running down to the wire on this stuff and I know it still
> > needs some work. In particular these networking related bugs are still
> > open against the ICG:
> > 
> >     https://bugzilla.redhat.com/show_bug.cgi?id=928038
> 
> This is the 4.2 13h-13j section. Didn't see you were waiting for info
> from me on this. We need to work through it.
> 
> >     https://bugzilla.redhat.com/show_bug.cgi?id=950662
> 
> This is nova networking specific, but related to what I mention above
> regarding upfront discussion in section 4.2.
> 
> >     https://bugzilla.redhat.com/show_bug.cgi?id=911917
> 
> 
> I'm not sure how critical this is in the getting started guide.
> Packstack seems to be more focused on new deployments than any of the
> management activities for an existing deployment (adding/removing nodes,
> upgrading versions) let alone changing quantum plugins. It might make
> sense to include Gary's info in the installation/config guide, unless
> there is a concerted effort to address version upgrades as part of the
> getting started guide in 3.0.

As per the lead in paragraph these bugs pertain to the Install and Config Guide, it wasn't clear from the original email that you would only be looking at the Getting Started Guide initially.

> > 
> > Any additional feedback is more than welcome. I also think there is more
> > post-deployment documentation (or updates to PackStack) required in the
> > Getting Started Guide. The way it is written currently assumed that once
> > networking was deployed by PackStack the user would have a functional
> > networking setup to start launching and connecting virtual machines to but
> > based on what has been delivered this is not the case [1]. We need a
> > concrete list of steps to ensure we get this right.
> 
> I think Summer has drafted something here, and I'll try to review it as
> soon as possible. Seems to me that adding networks, subnets, and routers
> in quantum is similar to adding tenants and users in keystone. Are these
> all being added to the getting started guide?

I think the difference is that PackStack delivers a usable Keystone configuration with a user and tenant that can be used out of the box so further action isn't strictly required to avoid user frustration. This is a stark contrast to the Quantum configuration delivered out of the box which requires some work to achieve the kind of networking setup users expect - especially if they have previously used PackStack to deploy Nova networking - resulting in threads like this one:

    http://openstack.redhat.com/forum/discussion/196/quantum-basic-setup#Item_1
Comment 4 Stephen Gordon 2013-06-11 15:03:15 EDT
(In reply to Stephen Gordon from comment #3)
> > * 2.2.3 - This section on storage configuration starts talking about
> > packstack before its been mentioned. I think we need to introduce and
> > describe the role of packstack in chapter 1.

Raised bug # 973327 for this issue.

> > * 4.2 - We need an upfront discussion of the decisions that need to be
> > made, at least for the networking service. We need to explain the choice
> > between quantum and nova networking, how its selected, and then
> > throughout the section show which options apply to nova vs quantum
> > networking. With quantum, we need to similarly cover the choice of
> > plugins and which options apply to each plugin. Also, for quantum (or
> > nova's VlanManager), we need to at least mention the need for a switch
> > that trunks a range of VLANs if doing a multi-node deployment.

Raised bug # 973339 for this issue.

> > * 4.2 13a - I think the network namespace usage defaults to Y (and
> > ideally this option should be removed/hidden in packstack)
> 
> It didn't at the time, I believe it's supposed to be changed (if it hasn't
> already).

Confirmed that this is now on by default in PackStack and switched it to Y.

> > * 4.2 13d - They probably need to know to set external bridge to empty
> > if using a provider network for an external network.

Updated to indicate this is the case, although given the lack of provider network documentation in this guide not sure this alone is enough.

> > * 4.2 13e - Replace "DHCP plugin" with "DHCP agent".

Raised a bug to get PackStack corrected and updated to use DHCP agent in the guide.

> > * 4.2 13h - Need to explain that the gre tenant network type isn't
> > available, and that local doesn't provide cross-node connectivity, so
> > vlan is the only usable option for multi-node setups.

Added text explaining the available options/recommendations.

> > * 4.2 14 - What is a "client server"???

Made a minor update here but ultimately this is the text PackStack displays, the description in the text already covered this in my opinion.

> > * 7.1 This section is supposed to be about CLI, but talks about logging
> > into the dashboard.

Removed this errant section.
Comment 5 Stephen Gordon 2013-06-11 15:04:40 EDT
Also raised bug # 973346 - Quantum configuration values should have examples. That leaves:

> * 4 - I'd list 3 methods for running packstack here, all-in-one,
> interactively, and non-interactively.

> * 4.2 13i - This is supposed to be about configuring
> network_vlan_ranges, but currently says something about "openvswitch
> plugins".
Comment 6 Stephen Gordon 2013-06-13 09:19:18 EDT
Change merged.
Comment 7 Bruce Reeler 2013-06-14 02:00:16 EDT
(In reply to Stephen Gordon from comment #5)
> Also raised bug # 973346 - Quantum configuration values should have
> examples. That leaves:
> 
> > * 4 - I'd list 3 methods for running packstack here, all-in-one,
> > interactively, and non-interactively.

This has also been corrected in Getting Started Guide.

Note You need to log in before you can comment on or make changes to this bug.