Merge "[contributor] Changes the persona names to gender-neutral names."
This commit is contained in:
Jenkins
Gerrit Code Review
commit
3d0588cb60
|
|
@ -55,11 +55,11 @@ Ensure workflows provide enough information for users to drive the decision-
|
|||
making process. We recommend referring to the OpenStack personas when
|
||||
designing and creating. The personas are:
|
||||
|
||||
* :ref:`arnie-infrastructure-arch`
|
||||
* :ref:`carlos-cloud-ops`
|
||||
* :ref:`doug-domain-operator`
|
||||
* :ref:`pei-project-owner`
|
||||
* :ref:`alan-app-developer`
|
||||
* :ref:`infrastructure-arch`
|
||||
* :ref:`cloud-ops`
|
||||
* :ref:`domain-operator`
|
||||
* :ref:`project-owner`
|
||||
* :ref:`app-developer`
|
||||
|
||||
Specific use case interfaces vary based on the individual use case.
|
||||
For example, a GUI may be appropriate to launch 1-x of the same instance, but
|
||||
|
|
|
|||
|
|
@ -31,14 +31,15 @@ on their specific contribution.
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
ux-personas/arnie-infrastructure-arch.rst
|
||||
ux-personas/carlos-cloud-ops.rst
|
||||
ux-personas/doug-domain-operator.rst
|
||||
ux-personas/pei-project-owner.rst
|
||||
ux-personas/alan-app-developer.rst
|
||||
ux-personas/infrastructure-arch.rst
|
||||
ux-personas/cloud-ops.rst
|
||||
ux-personas/domain-operator.rst
|
||||
ux-personas/project-owner.rst
|
||||
ux-personas/app-developer.rst
|
||||
|
||||
.. The original SVG copy of this figure is available in
|
||||
in the same directory
|
||||
in the same directory.
|
||||
|
||||
.. figure:: figures/persona-ecosystem.png
|
||||
:align: center
|
||||
:width: 100%
|
||||
|
|
@ -59,7 +60,7 @@ Nikishi University - research
|
|||
|
||||
At Nikishi university, each cloud user can potentially assume all personas'
|
||||
roles. Although typically each individual specializes in two or more of the
|
||||
roles. The Infrastructure Architect and the Cloud Operations roles
|
||||
roles. The Infrastructure Architect and the Cloud Operator roles
|
||||
could be assumed by a single individual. Similarly, the Domain Operations and
|
||||
Project Owner roles could be merged. This organizational model has a low
|
||||
staffing budget and is concerned with capital expenditure causing them to
|
||||
|
|
@ -84,7 +85,7 @@ CNBB Securities - large enterprise
|
|||
At CNBB Securities, the company's large organization chart represents each of
|
||||
the personas. Depending on the company's culture of collaboration, the
|
||||
personas could interact as if they were part of a single entity. However,
|
||||
usually the Cloud Operations and the Infrastructure Architect interact as
|
||||
usually the Cloud Operator and the Infrastructure Architect interact as
|
||||
service providers with the other personas. The personas within CNBB
|
||||
Securities look for a fast implementation and are responsible for the
|
||||
operations capital expenditure. The implementation has no customization and
|
||||
|
|
|
|||
|
|
@ -1,80 +0,0 @@
|
|||
.. _alan-app-developer:
|
||||
|
||||
============================
|
||||
Alan - application developer
|
||||
============================
|
||||
|
||||
Alan develops and deploys cloud applications but does not necessarily know
|
||||
much about the underlying infrastructure of the cloud.
|
||||
|
||||
Cloud applications are defined as:
|
||||
|
||||
* Applications built using OpenStack SDKs or APIs
|
||||
* Applications deployed on top of OpenStack using Application Catalog
|
||||
service, Orchestration service, or any 3rd-party deployment or
|
||||
management tools
|
||||
* PaaS and container solutions running on top of OpenStack
|
||||
|
||||
The cloud instances Alan consumes can use various OpenStack projects.
|
||||
Alan does not know the project names and goals, and has never
|
||||
been to an OpenStack Summit.
|
||||
|
||||
Alan wishes to deploy his applications to the cloud without issues and to
|
||||
receive warnings about any issues with the applications before tickets start
|
||||
coming. Whenever an issue arises during deployment or testing, Alan is
|
||||
grateful for clear uncomplicated notices. Such notices allow him to resolve
|
||||
the issues before customers become frustrated. Alan values a consistent API
|
||||
that makes his development future-proof and backwards-compatible.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Alan performs the following tasks frequently:
|
||||
|
||||
* Development: Develops cloud-based applications with various requirements.
|
||||
|
||||
* Management: Controls and changes all aspects of compute instances and file
|
||||
storage.
|
||||
|
||||
* Testing: Tests developed applications before deploying them. Performs the
|
||||
tests in one or multiple cloud instances.
|
||||
|
||||
* Deployment: Deploys his applications to one or multiple cloud instances.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Alan spends very little to no time researching OpenStack. He does not care
|
||||
how the cloud instances he uses were installed, as long as they work exactly
|
||||
as he expects and the needed APIs do not change unexpectedly. He does not
|
||||
control what tool is used to install and maintain the cloud instances.
|
||||
However, he determines the requirements for those cloud instances.
|
||||
Any changes made to the APIs greatly impact Alan's work.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Alan might be required to
|
||||
assume some roles and responsibilities of a Domain Operator or a Cloud
|
||||
Operator. Within a larger organization, like CNBB Securities, Alan will
|
||||
likely not work alone on an application. Multiple application developers
|
||||
would need to access a single cloud to develop, test, and deploy the same
|
||||
application, making user control a requirement for the cloud.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Alan's main concern are the APIs available to him. Alan will not interact
|
||||
directly with OpenStack, save in rare cases or within small organizations.
|
||||
Therefore, changes to the GUI and CLI are not relevant to Alan. On the other
|
||||
hand, even the tiniest changes in APIs have a high impact on his application
|
||||
development.
|
||||
|
||||
Alan assumes that the cloud has the resources his applications need. If the
|
||||
cloud does not have the resources, Alan expects the cloud to let him know
|
||||
what resources are missing in such a way, that he can ask a Cloud or Domain
|
||||
operator to add those resources. Alan will not add the resources himself.
|
||||
Therefore, ensure that notifications are clear and do not require any
|
||||
advanced knowledge of OpenStack to identify the issues.
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
.. _app-developer:
|
||||
|
||||
=============================
|
||||
Quinn - application developer
|
||||
=============================
|
||||
|
||||
Quinn develops and deploys cloud applications but does not necessarily know
|
||||
much about the underlying infrastructure of the cloud.
|
||||
|
||||
Cloud applications are defined as:
|
||||
|
||||
* Applications built using OpenStack SDKs or APIs
|
||||
* Applications deployed on top of OpenStack using Application Catalog
|
||||
service, Orchestration service, or any 3rd-party deployment or management
|
||||
tools
|
||||
* PaaS and container solutions running on top of OpenStack
|
||||
|
||||
The cloud instances Quinn consumes can use various OpenStack projects. Quinn
|
||||
does not know the project names and goals, and has never been to an OpenStack
|
||||
Summit.
|
||||
|
||||
Quinn wishes to deploy applications to the cloud without issues and to
|
||||
receive warnings about any issues with the applications before tickets start
|
||||
coming. Whenever an issue arises during deployment or testing, Quinn is
|
||||
grateful for clear uncomplicated notices. Such notices allow Quinn to resolve
|
||||
the issues before customers become frustrated. Quinn values a consistent API
|
||||
that makes Quinn's development future-proof and backwards-compatible.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Quinn performs the following tasks frequently:
|
||||
|
||||
* Development: Develops cloud-based applications with various requirements.
|
||||
|
||||
* Management: Controls and changes all aspects of compute instances and file
|
||||
storage.
|
||||
|
||||
* Testing: Tests developed applications before deploying them. Performs the
|
||||
tests in one or multiple cloud instances.
|
||||
|
||||
* Deployment: Deploys applications to one or multiple cloud instances.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Quinn spends very little to no time researching OpenStack. Quinn does not
|
||||
care how the cloud instances used were installed, as long as they work
|
||||
exactly as expected and the needed APIs do not change unexpectedly. Quinn
|
||||
does not control what tool is used to install and maintain the cloud
|
||||
instances. However, Quinn determines the requirements for those cloud
|
||||
instances. Any changes made to the APIs greatly impact Quinn's work.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Quinn might be required
|
||||
to assume some roles and responsibilities of a Domain Operator or a Cloud
|
||||
Operator. Within a larger organization, like CNBB Securities, Quinn will
|
||||
likely not work alone on an application. Multiple application developers
|
||||
would need to access a single cloud to develop, test, and deploy the same
|
||||
application, making user control a requirement for the cloud.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Quinn's main concern are the APIs available. Quinn will not interact directly
|
||||
with OpenStack, save in rare cases or within small organizations. Therefore,
|
||||
changes to the GUI and CLI are not relevant to Quinn. On the other hand, even
|
||||
the tiniest changes in APIs have a high impact on Quinn's application
|
||||
development.
|
||||
|
||||
Quinn assumes that the cloud has the resources the applications need. If the
|
||||
cloud does not have the resources, Quinn expects the cloud to let inform what
|
||||
resources are missing in such a way, that Quinn can ask a Cloud or Domain
|
||||
operator to add those resources. Quinn will not add the resources.
|
||||
Therefore, ensure that notifications are clear and do not require any
|
||||
advanced knowledge of OpenStack to identify the issues.
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
.. _arnie-infrastructure-arch:
|
||||
|
||||
================================
|
||||
Arnie - infrastructure architect
|
||||
================================
|
||||
|
||||
Arnie is responsible for the strategy and road-map for his company's cloud.
|
||||
He identifies reasons to compel management to adopt OpenStack for production
|
||||
environments. The two reasons that would deter Arnie from recommending
|
||||
OpenStack are frequent instabilities, non-deterministic errors, the inability
|
||||
to create an environment, and missing documentation. Similarly to the domain
|
||||
operator, Arnie needs to know about any outage conditions that may occur on
|
||||
both testing and production environments.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Arnie performs the following tasks very frequently:
|
||||
|
||||
* Decision making: Considers adoption of OpenStack based on financial,
|
||||
strategic, architecture, and security advantages.
|
||||
|
||||
* Hardware configurations: Determines if a hardware configuration
|
||||
suits the requirements of a cloud instance and if an OpenStack solution
|
||||
running on such hardware is the best possible option.
|
||||
|
||||
* User experience: Considers application developers, the development
|
||||
processes, and the end users when recommending and installing cloud
|
||||
instances.
|
||||
|
||||
* Cloud planing: Defines and plans the cloud while considering hardware,
|
||||
platform choices, services, and scale.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Arnie spends a lot of time reading and researching information about
|
||||
OpenStack and other cloud technologies. He has attended more than one
|
||||
OpenStack summit and contributes solutions to the community regularly. He
|
||||
values OpenStack and is committed to drive adoption. His priority, however,
|
||||
is a fully functional and stable cloud that fulfills all of his requirements.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Arnie might be required
|
||||
to assume some roles and responsibilities of a Cloud Operator or, more
|
||||
rarely, a Domain Operator. Within a larger organization, like CNBB
|
||||
Securities, Arnie's tasks are performed by the team planing and implementing
|
||||
the cloud instances.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Arnie's main concern is the cloud's architecture. Arnie interacts directly
|
||||
with OpenStack and has probably developed any pieces that he needed. Your
|
||||
development targets Arnie if it makes any changes to the way clouds are
|
||||
implemented and deployed. Any new features, fixes, and limitations are
|
||||
important to him.
|
||||
|
||||
If your development modifies the scope, implementation, and usage of
|
||||
OpenStack ensure to take Arnie into consideration.
|
||||
|
|
@ -1,18 +1,18 @@
|
|||
.. _carlos-cloud-ops:
|
||||
.. _cloud-ops:
|
||||
|
||||
=========================
|
||||
Carlos - cloud operations
|
||||
=========================
|
||||
======================
|
||||
Rey - cloud operations
|
||||
======================
|
||||
|
||||
Carlos is involved in installing, operating, using, and updating the
|
||||
OpenStack cloud services. Carlos ensures that the cloud is up and running. He
|
||||
must fix any issues as soon as possible. Collaborating with unskilled IT
|
||||
personnel is very challenging for Carlos.
|
||||
Rey is involved in installing, operating, using, and updating the OpenStack
|
||||
cloud services. Rey ensures that the cloud is up and running and must fix any
|
||||
issues as soon as possible. Collaborating with unskilled IT personnel is very
|
||||
challenging for Rey.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Carlos performs the following tasks very frequently:
|
||||
Rey performs the following tasks very frequently:
|
||||
|
||||
* Installation: Installs and configures OpenStack clouds often with the help
|
||||
of the Infrastructure Architect.
|
||||
|
|
@ -28,41 +28,41 @@ Carlos performs the following tasks very frequently:
|
|||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Carlos spends some time every day searching for information on the OpenStack
|
||||
website. He has attended the OpenStack Summit once. He uses any tool he finds
|
||||
useful in operating the cloud. His previous role as a Linux system
|
||||
administrator influenced his decision to use OpenStack.
|
||||
Rey spends some time every day searching for information on the OpenStack
|
||||
website and has attended the OpenStack Summit once. Rey uses any useful tool
|
||||
in operating the cloud. Rey's previous role as a Linux system administrator
|
||||
influenced the decision to use OpenStack.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
company, Carlos might be required to assume some of the responsibilities of
|
||||
company, Rey might be required to assume some of the responsibilities of
|
||||
both the Infrastructure Architect and the Domain Operator. Within a larger
|
||||
company, multiple individuals could perform subsets of Carlos's tasks. For
|
||||
company, multiple individuals could perform subsets of Rey's tasks. For
|
||||
example, one person could be in charge of installing and updating the cloud
|
||||
instances, while another could be in charge of monitoring operations and
|
||||
usage, and yet another person could be in charge of solving issues. In
|
||||
Carlos's organization, he is responsible for all of these tasks.
|
||||
Rey's organization, Rey is responsible for all of these tasks.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
When your development affects the behavior of the cloud instances, you should
|
||||
consider Carlos as your target audience. Will your development change how the
|
||||
consider Rey as your target audience. Will your development change how the
|
||||
cloud is accessed, configured, monitored, or setup? Is your development
|
||||
changing the GUI, for example, the horizon dashboard? Carlos is unlikely to
|
||||
changing the GUI, for example, the horizon dashboard? Rey is unlikely to
|
||||
use :abbr:`CLI (Command-Line Interface)` to administer and track the cloud
|
||||
instances but is likely to use CLI to install and update them.
|
||||
|
||||
Before submitting your code, think of the use cases that Carlos would follow.
|
||||
For example: Is it easy to use? Will Carlos get feedback when the task is
|
||||
Before submitting your code, think of the use cases that Rey would follow.
|
||||
For example: Is it easy to use? Will Ray get feedback when the task is
|
||||
complete? Are the changes in configuration reversible? How is the tracked
|
||||
information displayed? How long will the operation take?
|
||||
|
||||
Finally, consider that Carlos is a highly skilled system administrator with a
|
||||
Finally, consider that Rey is a highly skilled system administrator with a
|
||||
deep knowledge of OpenStack but with little time for long, complex research.
|
||||
Therefore, your solutions for Carlos must be quick to implement but do not
|
||||
Therefore, your solutions for Rey must be quick to implement but do not
|
||||
need to shy away from complex OpenStack components, as long as they provide
|
||||
all the information needed within the solution itself.
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
.. _domain-operator:
|
||||
|
||||
========================
|
||||
Taylor - domain operator
|
||||
========================
|
||||
|
||||
Taylor manages the relationship with the cloud services provider. This
|
||||
includes managing quotas, number of users, applicable policies, and support
|
||||
tickets. Taylor does not have any major concerns about the underlying
|
||||
infrastructure of the cloud and ensures that the :abbr:`SLA (Service-Level
|
||||
Agreement)` is followed.
|
||||
|
||||
Taylor needs to know about any outages, both scheduled and unscheduled.
|
||||
Unscheduled outages cause a lot of problems for Taylor, as ideally there
|
||||
would never be an unscheduled outage.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Taylor performs the following tasks very frequently:
|
||||
|
||||
* Managing quotas: Defines the amount of resources that the cloud service
|
||||
provider must supply and ensures that those resources are being effectively
|
||||
used.
|
||||
|
||||
* Managing users: Defines the number of users with access to the cloud
|
||||
services. They manages the access and rights of users for the entire cloud
|
||||
services.
|
||||
|
||||
* Ensuring SLA compliance: Monitors the various policies and support tickets
|
||||
to ensure that the agreed terms are being fulfilled.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Taylor spends no time researching OpenStack. It is likely that Taylor does
|
||||
not even know that the cloud service provider uses OpenStack and does not
|
||||
care how the cloud instances are run, as long as they run without unexpected
|
||||
outages. Taylor expects to be provided with adequate monitoring tools. Adding
|
||||
and removing users from the provided cloud services should be as easy as
|
||||
possible, in Taylor's opinion.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Taylor might be required
|
||||
to assume some roles and responsibilities of a Cloud Operator or a Project
|
||||
Owner. Within a larger organization, like CNBB Securities, Taylor's tasks are
|
||||
performed by the team managing the cloud services provider.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Taylor's main concern are the cloud outages. Taylor will not interact
|
||||
directly with OpenStack, save in rare cases or within small organizations.
|
||||
Therefore, changes that affect the stability and reliability of the cloud
|
||||
services are Taylor's greatest concern.
|
||||
|
||||
Taylor assumes that the cloud services provider will supply adequate
|
||||
monitoring and user management tools. Taylor expects the cloud to notify the
|
||||
current status of the cloud in such a way, that Taylor can ask the provider
|
||||
to solve it as quickly as possible. Taylor will not fix the problems
|
||||
directly. Therefore, ensure that error notifications are clear and do not
|
||||
require any advanced knowledge of OpenStack to identify the issues.
|
||||
|
||||
If your development modifies the user management of the cloud, ensure to take
|
||||
Taylor into consideration. User management should be as simple as possible
|
||||
and it should not require deep knowledge about OpenStack.
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
.. _doug-domain-operator:
|
||||
|
||||
======================
|
||||
Doug - domain operator
|
||||
======================
|
||||
|
||||
Doug manages the relationship with the cloud services provider. This includes
|
||||
managing quotas, number of users, applicable policies, and support tickets.
|
||||
He does not have any major concerns about the underlying infrastructure of
|
||||
the cloud. He ensures that the :abbr:`SLA (Service-Level Agreement)` is
|
||||
followed.
|
||||
|
||||
Doug needs to know about any outages, both scheduled and unscheduled.
|
||||
Unscheduled outages cause a lot of problems for Doug, as ideally there would
|
||||
never be an unscheduled outage.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Doug performs the following tasks very frequently:
|
||||
|
||||
* Managing quotas: Defines the amount of resources that the cloud service
|
||||
provider must supply and ensures that those resources are being effectively
|
||||
used.
|
||||
|
||||
* Managing users: Defines the number of users with access to the cloud
|
||||
services. He manages the access and rights of users for the entire cloud
|
||||
services.
|
||||
|
||||
* Ensuring SLA compliance: Monitors the various policies and support tickets
|
||||
to ensure that the agreed terms are being fulfilled.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Doug spends no time researching OpenStack. It is likely that he does not even
|
||||
know that the cloud service provider uses OpenStack. He does not care how the
|
||||
cloud instances are run, as long as they run without unexpected outages. He
|
||||
expects to be provided with adequate monitoring tools. Adding and removing
|
||||
users from the provided cloud services should be as easy as possible, in his
|
||||
opinion.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Doug might be required to
|
||||
assume some roles and responsibilities of a Cloud Operator or a Project
|
||||
Owner. Within a larger organization, like CNBB Securities, Doug's tasks are
|
||||
performed by the team managing the cloud services provider.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Doug's main concern are the cloud outages. Doug will not interact directly
|
||||
with OpenStack, save in rare cases or within small organizations. Therefore,
|
||||
changes that affect the stability and reliability of the cloud services are
|
||||
his greatest concern.
|
||||
|
||||
Doug assumes that the cloud services provider will supply him adequate
|
||||
monitoring and user management tools. Doug expects the cloud to let him know
|
||||
the current status of the cloud in such a way, that he can ask the provider
|
||||
to solve it as quickly as possible. Doug will not fix the problems himself.
|
||||
Therefore, ensure that error notifications are clear and do not require any
|
||||
advanced knowledge of OpenStack to identify the issues.
|
||||
|
||||
If your development modifies the user management of the cloud, ensure to take
|
||||
Doug into consideration. User management should be as simple as possible and
|
||||
it should not require deep knowledge about OpenStack.
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
.. _infrastructure-arch:
|
||||
|
||||
=================================
|
||||
Adrian - infrastructure architect
|
||||
=================================
|
||||
|
||||
Adrian is responsible for the strategy and road-map for his company's cloud
|
||||
and identifies reasons to compel management to adopt OpenStack for production
|
||||
environments. The reasons that would deter Adrian from recommending OpenStack
|
||||
are frequent instabilities, non-deterministic errors, the inability to create
|
||||
an environment, and missing documentation. Similarly to the domain operator,
|
||||
Adrian needs to know about any outage conditions that may occur on both
|
||||
testing and production environments.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Adrian performs the following tasks very frequently:
|
||||
|
||||
* Decision making: Considers adoption of OpenStack based on financial,
|
||||
strategic, architecture, and security advantages.
|
||||
|
||||
* Hardware configurations: Determines if a hardware configuration
|
||||
suits the requirements of a cloud instance and if an OpenStack solution
|
||||
running on such hardware is the best possible option.
|
||||
|
||||
* User experience: Considers application developers, the development
|
||||
processes, and the end users when recommending and installing cloud
|
||||
instances.
|
||||
|
||||
* Cloud planing: Defines and plans the cloud while considering hardware,
|
||||
platform choices, services, and scale.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Adrian spends a lot of time reading and researching information about
|
||||
OpenStack and other cloud technologies. Adrian has attended more than one
|
||||
OpenStack summit and contributes solutions to the community regularly. Adrian
|
||||
values OpenStack and is committed to drive adoption. Adrian's priority,
|
||||
however, is a fully functional and stable cloud that fulfills all of his
|
||||
requirements.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Adrian might be required
|
||||
to assume some roles and responsibilities of a Cloud Operator or, more
|
||||
rarely, a Domain Operator. Within a larger organization, like CNBB
|
||||
Securities, Adrian's tasks are performed by the team planing and implementing
|
||||
the cloud instances.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Adrian's main concern is the cloud's architecture. Adrian interacts directly
|
||||
with OpenStack and has probably developed any pieces that were needed. Your
|
||||
development targets Adrian if it makes any changes to the way clouds are
|
||||
implemented and deployed. Any new features, fixes, and limitations are
|
||||
important to Adrian.
|
||||
|
||||
If your development modifies the scope, implementation, and usage of
|
||||
OpenStack ensure to take Adrian into consideration.
|
||||
|
|
@ -1,19 +1,19 @@
|
|||
.. _pei-project-owner:
|
||||
.. _project-owner:
|
||||
|
||||
===================
|
||||
Pei - project owner
|
||||
Wei - project owner
|
||||
===================
|
||||
|
||||
Pei manages projects by adding or removing project members' access to the
|
||||
cloud instance. Pei does not know the underlying infrastructure nor the
|
||||
OpenStack projects involved. Pei's main concern is to have enough resources
|
||||
available to support her projects. Therefore, if a project runs out of quota,
|
||||
she does not want to have to wait for the operators to raise it.
|
||||
Wei manages projects by adding or removing project members' access to the
|
||||
cloud instance. Wei does not know the underlying infrastructure nor the
|
||||
OpenStack projects involved. Wei's main concern is to have enough resources
|
||||
available to support Wei's projects. Therefore, if a project runs out of
|
||||
quota, Wei does not want to have to wait for the operators to raise it.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
|
||||
Pei performs the following tasks very frequently:
|
||||
Wei performs the following tasks very frequently:
|
||||
|
||||
* Managing access: adds and removes project members' access to OpenStack
|
||||
resources.
|
||||
|
|
@ -27,40 +27,40 @@ Pei performs the following tasks very frequently:
|
|||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Pei does not know or care about whether OpenStack is being used for the cloud
|
||||
instance her projects use or not. Her concern is to have the resources she
|
||||
needs when she needs them. If her requests for additional resources take too
|
||||
long to be fulfilled she will start looking for alternatives until the needs
|
||||
of her projects are met.
|
||||
Wei does not know or care about whether OpenStack is being used for the cloud
|
||||
instance that the projects use or not. Wei's concern is to have enough
|
||||
resources whenever they are needed. If Wei's requests for additional
|
||||
resources take too long to be fulfilled, Wei will start looking for
|
||||
alternatives until the project's needs are met.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
company, Pei might be required to assume some of the responsibilities of the
|
||||
company, Wei might be required to assume some of the responsibilities of the
|
||||
the Domain Operator or maybe even the Cloud Operator. In this case, the
|
||||
persona does not need to submit requests to manage the cloud's resources but
|
||||
can rather make the changes needed.
|
||||
|
||||
Within a larger organization, multiple individuals could be performing Pei's
|
||||
Within a larger organization, multiple individuals could be performing Wei's
|
||||
tasks. For example, each project could have a different person as a project
|
||||
owner and the company could have several projects.
|
||||
|
||||
Whatever the case, it is highly likely that Pei is an experienced application
|
||||
Whatever the case, it is highly likely that Wei is an experienced application
|
||||
developer as well. See the information pertaining to the application
|
||||
developer persona here: :ref:`alan-app-developer`
|
||||
developer persona here: :ref:`app-developer`
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
When your development affects the behavior of the capacity of cloud
|
||||
instances, you should consider Pei as an interested party. Ensuring that
|
||||
instances, you should consider Wei as an interested party. Ensuring that
|
||||
changes to the capacity of cloud instances can occur as easily and as quickly
|
||||
as possible certainly has a positive impact on Pei's work, for example.
|
||||
However, Pei does not perform those changes in capacity herself.
|
||||
as possible certainly has a positive impact on Wei's work, for example.
|
||||
However, Wei does not perform those changes in capacity directly.
|
||||
|
||||
Finally, consider that Pei is a highly skilled developer with little
|
||||
Finally, consider that Wei is a highly skilled developer with little
|
||||
knowledge of OpenStack and with little time for long, complex research.
|
||||
Therefore, your solutions for Pei must be focused on enabling others to
|
||||
Therefore, your solutions for Wei must be focused on enabling others to
|
||||
provide the needed resources as quickly as possible.
|
||||
Loading…
Reference in New Issue