Open Stack

Hello everyone,

Has any kind of qualitative research been done to determine the end user
needs for the admin guide? In other environments where I was part of such
an effort, we interviewed users at different levels to figure out, first,
what they actually did, and then what knowledge they required. You may be
surprised with what you can find out. In some small environments, a
superuser does most of the work.

Also, performing some sort of editorial review with the end user
representatives might help with content quality and organization.

Still, having a single dynamic knowledge repository for all of the
different system pieces can only empower and not confuse users. You could
see this as a library instead of a guide. There is so much valuable
information that, if properly organized and laid out for quick and easy
navigation, can represent a meaningful discovery. Yes, it would be large,
but the reader will not be lost and can take away whatever they need away
from it.

Thank you!

Nermina


On Thu, Jul 11, 2013 at 11:00 AM, Diane Fleming <diane.fleming at rackspace.com
> wrote:

>   Nice insights, Summer!
>
>  To me, the audiences are:
>
>    - *Operator /deployer*– Plans, installs, configs, deploys, and
>    maintains clouds. Sets up other admin users, and possibly end users.
>    - *Admin users* – created by the operator – creates and manages
>    projects and users, creates and manages images, manages flavors, sets
>    quotas, migrates servers.
>    - *End users* – created by the operator or admin user – sets up
>    security and access for instances, launches and manages instances, manages
>    volumes.
>    - *Application developers and OpenStack contributors* – Developers who
>    write applications that run on top of an OpenStack cloud. Also, can review
>    and contribute to the OpenStack infrastructure, code, and docs.
>
> There is some crossover between the *operator *and* admin user *
> audiences –
>
>  For me, the question is, after we complete the Config Ref, Admin User
> Guide, and End User Guide, *what information are we missing for the
> operator/admin audience?* If we still have missing material, that's what
> should go into the (project-specific) Admin Guides, which can roll up into
> a comprehensive Admin Guide.
>
>   *Diane*
>  *----------------------------------------------*
>  Diane Fleming
>  Software Developer II - US
>  diane.fleming at rackspace.com
> Cell  512.323.6799
> Office 512.874.1260
>  Skype drfleming0227
> Google-plus diane.fleming at gmail.com
>
>   From: Summer Long <slong at redhat.com>
> Date: Wednesday, July 10, 2013 11:23 PM
> To: Anne Gentle <annegentle at justwriteclick.com>, "
> openstack-docs at lists.openstack.org" <openstack-docs at lists.openstack.org>
> Subject: Re: [Openstack-docs] Admin guides and restructure
>
>  Hi Anne,
> I know I don't have street cred yet, but here's my offering.
>
> *Administration Guide / Admin User Guide*
> Am thinking that the biggest problem is one of audience. The restructure
> blueprint says that the 'Administration Guide' is for deployers and not for
> the administrative user. And it says that one of the tasks of a deployer is
> to 'run' the cloud.
> This feels like a mixed target, the deployer doesn't necessarily stick
> around to administer what's been deployed. (Is this definition a result of
> the Ops Guide? That too could be divied up now that the suite is growing.)
>
> With this definition of deployer, of course the Admin guide would be huge,
> including both deployment and management tasks. And is why the Admin Guide
> blueprint is so large, including information on installation and
> configuration in each project chapter.  If you clearly separate the
> audience, I believe there should be only one Administration guide, for the
> person sitting down to manage the beast after it's been deployed.
>
> IMVHO, the Admin User Guide could be the 4.0 Administration Guide (with
> its clear focus on admin tasks), with the next release including the
> broader admin tasks from Nick's specification (security, troubleshooting,
> etc).
>
> *Project Admin Guides / Single Admin Guide*
> If it is at all feasible, I'd keep the project admin guides going. And use
> xi:includes to bring their content into the Administration Guide where
> relevant. There will be inconsistency across project guides, but:
> --They are useful for component-focused issues.
> --Detailed, advanced material can be introduced which might be out of
> place in an overarching admin guide.
> --Dev folk will always be more interested in producing content for their
> own project doc (and then it can be referenced elsewhere).
>
> cheers, Summer
>
>  Summer Long
> OpenStack Documentation
> Engineering Content Services
>
> Red Hat Asia Pacific
> Brisbane, Australia
> slong at redhat.com
>
>  On 07/11/2013 05:21 AM, Anne Gentle wrote:
>
>  Hi all,
>
>
>  I'd like to get feedback about the *administration* portion of our
> documentation refactoring plan [1], which we overlooked when we created the
> original documentation restructuring blueprint.[4]
>
>
>  tl;dr - We need to make a decision about guides for
> administrators/operators going forward. Please review the following
> detailed analysis.
>
>
>  Tom, Diane, Nick, Nermina, I, and others have been reviewing the
> following blueprints for the Havana release:
>
>    - [1] restructure documentation blueprint. Describes a plan to
>    restructure the OpenStack documentation. However it did not address Admin
>    Guides.
>    - [2] modularize admin guide. Recommends a comprehensive
>    administrative guide, with the option of producing smaller project-specific
>    guides.
>    - [3] os-admin-docs. Outlines a comprehensive administration guide
>    that describes everything that an administrator/operator needs to install,
>    deploy, and maintain an OpenStack cluster.
>
>   I have a few concerns about these blueprints, which is why I'd like *more
> eyes please*! To see if we're talking crazy talk. :)
>
>
>  My concerns:
>
>    - We already have smaller admin guides, which are maintained by
>    project teams. The block storage and networking teams are quite active in
>    maintaining their admin guides. However, the object storage and compute
>    teams are not as invested in their admin guides. So there are issues with
>    having smaller, project-directed guides – lack of consistency, content
>    mismatch, and other issues.
>    - The comprehensive administrative guide seems to have the same goals
>    as the existing Operations Guide. In that book sprint, the stated goal was
>    to create a book for new OpenStack cloud operators.
>    - We already hear that the Compute Admin Guide is too long. How can a
>    longer guide really be the answer? Lorin pulled out the Image Management
>    chapter to make the OpenStack Virtual Machine Image Guide, and the
>    config chapter is moving to the new Configuration Reference. We've
>    been gutting the Compute Admin Guide since the Summit to try to slim it
>    into just a Config Ref and an Admin User Guide. So we're hoping that the
>    gutting will result in a set of books, which then coupled with the
>    Operations Guide, is the fresh-minted OpenStack administrator's ticket to
>    success.
>    - The plan for a comprehensive administration guide might not fit with
>    our plans for content modularity and doc ownership.
>
> The end goal of the admin doc restructuring is to make the Operations
> Guide, the Admin Guides, and the Config Reference all work well together.
> We want to avoid redundancy and we want to provide a clear path through the
> documentation. And we must scope this work correctly for the upcoming
> October release date.
>
>
>  *Questions:*
>
>
>  Do we need a large, comprehensive Admin guide (now that I see the
> outline I'm a little daunted)?
>
> Nick: Yes. I know that was the goal of the Ops Guide, but I think it
> landed in a different, and just as vital, spot. I think a comprehensive
> guide makes it possible for someone to avoid getting lost in a sea of
> books, as the guide will, well, guide them through.
>
>
> Should we create an Admin User Guide with Diane's outline [5]?
>
> Nick: Absolutely. What she has planned is a vital look at the essentials.
>
>
>  Does an Admin User Guide eliminate the need for a separate OpenStack
> Administration Guide?
>
> Nick: No. I see it as a progression. start with Diane's book, then pickup
> the guide for more in depth understanding of concepts.
>
>
>  Should we keep the separate Admin Guides per project? (That brings along
> the problem with owners and inconsistency.)
>
> Nick:Yes.the reality is that those owners are sometimes the best at this,
> sometimes not. A guide like this lets us improve where necessary without
> ditching the good stuff.    Remember we are not talking about getting rid
> of the great work you have done (and are doing) . Just the opposite.
>
>
>  Or maybe there is another option or two or eight that we haven't thought
> of?
>
>
>  Thanks for reading this far! We need more opinions and then a decision
> for the path forward.
>
> Thanks,
>
> Anne
>
>
>
>  1
> https://blueprints.launchpad.net/openstack-manuals/+spec/restructure-documentation
>
> 2
> https://blueprints.launchpad.net/openstack-manuals/+spec/modularize-admin-guide
>
> 3 https://blueprints.launchpad.net/openstack-manuals/+spec/os-admin-docs
>
> 4
> https://wiki.openstack.org/w/index.php?title=Blueprint-restructure-documentation&diff=25490&oldid=24528
>
> 5
> https://wiki.openstack.org/wiki/Blueprint-restructure-documentation#OpenStack_Admin_User_Guide
>
>
>  More reference information.
>
>
>  These are the current titles for the admin audience:
>
> OpenStack Block Storage Service Administration Guide
>
> OpenStack Compute Administration Guide
>
> OpenStack Network Service Administration Guide
>
> OpenStack Object Storage Administration Guide
>
> OpenStack Operations Guide
>
> OpenStack High Availability Guide
>
> OpenStack Virtual Machine Image Guide
>
> OpenStack Security Guide
>
>
>  These are the additional titles for Havana under consideration:
>
> Admin User Guide (sourced from End User Guide)
>
> OpenStack Administration Guide (sourced by combining from modular content)
>
>
> _______________________________________________
> Openstack-docs mailing listOpenstack-docs at lists.openstack.orghttp://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/20130711/6af8e28c/attachment-0001.html>