Open Stack

Lorin,

http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_installing-openstack-compute.html
http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-openstack-compute-basics.html

________________________________________

From: Lorin Hochstein [lorin at nimbisservices.com]
Sent: Monday, February 11, 2013 3:38 AM
To: Atul Jha
Cc: openstack-docs at lists.openstack.org
Subject: Re: [Openstack-docs] Restructuring OpenStack-doc for Grizzly

Hi Atul:


On Wed, Feb 6, 2013 at 2:59 AM, Atul Jha <Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com>> wrote:
Hi All,

I had a suggestion and wanted to put forward.

Currently our complete doc structure looks like this

Installing OS
       -- Contains install information on Ubuntu and Fedora
Running OS
       -- Contains concepts about OS components and install steps as well for Debian/Suse/Ubunu/Fedora to some extent
Developing OS
OS CLI
OS API
Glossary


Will it be good idea to restructure Running OS and Installing OS this way

Installing OS
    -- On Ubuntu
          -- Basic
          -- Advanced

    -- On Redhat/Centos/Fedora
          -- Basic
          -- Advanced
   -- On Other OS
          -- Basic
          -- Advance

Too an extent its already existing, my real concern is with the  "Running OS" part which has overlapping contents as in install instructions.

Keeping Nova/Swift/Quantum guide with conf files and basic concepts behind it and updating it on regular basis will be much better. Lets take compute admin guide for example. I find it like having too much data and to an extent replication of our Install OS components in it.

Compute administration guide
       -- Concept of nova
       -- Architecture
       -- Hypervisor based config change
       -- Available config flags


What do you guys think?

Can you give an example of some content that currently is in the compute admin guide that you think shouldn't be there because of the overlap with the installation manuals?

I'm not opposed to a refactor on principle, but I also worry about users needing to jump around across many different manuals, because the current task they are trying to perform cuts across multiple doc guides. I think some content overlap might be unavoidable. If you could provide some specific examples about content that you recommend be removed from the admin guide, it would help me understand this better.

Take care,

Lorin

--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com<http://www.nimbisservices.com>
http://www.csscorp.com/common/email-disclaimer.php