Fixes RST headings for rendering
The previous template had multiple sections at the top heading level which filled the rendered specs page with sub-sections. This change leaves only one main heading and reformats other sections with section and sub-section headings. This change includes fixes to the template and all merged user stories. Change-Id: Ib1fb08b1e67896a6f160b1b1649fadfc29b947e6
This commit is contained in:
Shamail Tahir
Yih Leong Sun
parent
274d418330
commit
5d31a35ead
|
|
@ -5,26 +5,26 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
Problem description
|
||||
-------------------
|
||||
+++++++++++++++++++
|
||||
Operators of OpenStack environments lack a reliable source to find answers to
|
||||
commonly encountered issues. The current ask.openstack.org site is not broadly
|
||||
functional or well contributed to by the broader community.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
A workable community knowledge base is a critical component of any successful
|
||||
software. Even more so in free open-source projects. Having a simple place for
|
||||
operators to go to acquire the collective community knowledge on a given topic
|
||||
will significantly reduce the barrier to entry to utilizing OpenStack.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
*As an Operator, I want to be able to quickly find reliable answers to common
|
||||
operational issues and questions so that I can continue to support my users
|
||||
*As an Operator, I want to ask an uncommon question in a community forum and
|
||||
|
|
@ -35,7 +35,7 @@ a notion to the popularity of previous answers so that I can continue to support
|
|||
my users
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
1. Common Question Usage - OpenStack Operator
|
||||
a. Go to common question repository
|
||||
b. Search for error code, topic, api call, etc
|
||||
|
|
@ -50,21 +50,21 @@ Usage Scenarios Examples
|
|||
f. Add support for answer if it resolves issue
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Requirements
|
||||
============
|
||||
++++++++++++
|
||||
None.
|
||||
|
||||
External References
|
||||
===================
|
||||
+++++++++++++++++++
|
||||
None.
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
=======================================
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
None.
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
*Problem Definition*
|
||||
--------------------
|
||||
++++++++++++++++++++
|
||||
A canonical property of an IaaS system like OpenStack is “capacity on demand”. Users expect to be able to allocate new resources via UI or API whenever needed, and to release them when the need ends. By supporting a large number of users, pooling resources, and maintaining some excess capacity, the cloud service provider (CSP) presents the illusion of infinite capacity.
|
||||
|
||||
In practice, of course, the resources are not infinite, and the CSP must institute measures to manage capacity so that resource exhaustion is minimized. This is generally done by imposing a cap or quota on the resources that a particular project may consume, and by managing the relationship between the available physical resources and the aggregate quotas for all projects. When a project requires more resources than its assigned quota, the user is generally required to submit a request, generally requiring human approval. The CSP may reject the request, or delay it until sufficient capacity is available. When the request is approved, the quota for the project is modified to reflect the new limit.
|
||||
|
|
@ -19,7 +19,7 @@ Other CSPs have introduced a number of mechanisms to provide them with flexibili
|
|||
One common factor in all these processes is that they do not reflect temporal variations in resource usage. Yet in many cases the user knows how their usage is going to vary over time, and such information would be useful to the CSP who needs to decide how to handle each request. It might also facilitate the automation of some of the processing. The following user stories capture the possibilities here.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. Use this section to give opportunity details that support why
|
||||
.. pursuing these user stories would help address key barriers to adoption or
|
||||
|
|
@ -32,10 +32,10 @@ Opportunity/Justification
|
|||
None.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
.. This section is mandatory. You may submit multiple
|
||||
.. user stories in a single submission as long as they are inter-related and can be
|
||||
.. associated with a single epic and/or function. If the user stories are
|
||||
|
|
@ -74,7 +74,7 @@ User Stories
|
|||
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. In order to explain your user stories, if possible, provide an example in the
|
||||
.. form of a scenario to show how the specified user type might interact with the
|
||||
|
|
@ -92,7 +92,7 @@ Usage Scenarios Examples
|
|||
TBD
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. If there are related user stories that have some overlap in the problem domain or
|
||||
.. that you perceive may partially share requirements or a solution, reference them
|
||||
|
|
@ -101,7 +101,7 @@ Related User Stories
|
|||
This Use Case is related to the Infinite Elasticity use case. The latter focuses on testing the capability of an OpenStack cloud to handle large-scale capacity requests.
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
++++++++++++++
|
||||
.. This section is optional. It might be useful to specify
|
||||
.. additional requirements that should be considered but may not be
|
||||
.. apparent through the user story and usage examples. This information will help
|
||||
|
|
@ -121,7 +121,7 @@ This Use Case is related to the Infinite Elasticity use case. The latter focuses
|
|||
* It will also require a rich monitoring, notification, and visualization system, so that both user and CSP have accurate and timely data about the behavior of the system.
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
.. This section is optional.
|
||||
.. Please use this section to add references for standards or well-defined
|
||||
.. mechanisms. You can also use this section to reference existing functionality
|
||||
|
|
@ -132,7 +132,7 @@ This Use Case is related to the Infinite Elasticity use case. The latter focuses
|
|||
None.
|
||||
|
||||
*Rejected User Stories / Usage Scenarios*
|
||||
=========================================
|
||||
-----------------------------------------
|
||||
.. This is optional
|
||||
.. Please fill out this section after a User Story has been submitted as a
|
||||
.. cross project spec to highlight any user stories deemed out of scope of the
|
||||
|
|
@ -141,7 +141,7 @@ None.
|
|||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
.. This section is optional.
|
||||
.. It is highly suggested that you define any terms,
|
||||
.. abbreviations that are not commonly used in order to ensure
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
-------------------
|
||||
|
||||
Problem Definition
|
||||
------------------
|
||||
++++++++++++++++++
|
||||
Each operator of an OpenStack cloud needs the ability to clean up the OpenStack
|
||||
database of objects which have been deleted. Currently a new record is created in
|
||||
the OpenStack database when an object (project, user, VM, network, volume, swift
|
||||
|
|
@ -41,28 +41,25 @@ in the outcome of my proof of concept and cloud functionality.
|
|||
database so that I can complete my upgrade in the allocated down time.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
DB hygiene is required for handling OpenStack performance, operational and
|
||||
upgrade issues. This ensures that historical records of deleted items are not
|
||||
impacting operational performance and such deleted items are not polluted by
|
||||
upgrades.
|
||||
|
||||
User Cases
|
||||
==========
|
||||
----------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
WIP
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
WIP
|
||||
|
||||
|
||||
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
Nova specs:
|
||||
* https://review.openstack.org/#/c/184645/
|
||||
* https://review.openstack.org/#/c/184637/
|
||||
|
|
@ -72,7 +69,7 @@ Cinder blueprint:
|
|||
* https://blueprints.launchpad.net/cinder/+spec/db-cleanup
|
||||
|
||||
Requirements
|
||||
============
|
||||
++++++++++++
|
||||
* Operator should be able to specify which policy to apply for deleted objects
|
||||
* Operator should be able to specify which policy to apply for different tenants
|
||||
and sub-tenants.
|
||||
|
|
@ -81,13 +78,13 @@ other persistent storage for a specific interval duration; Policy 2 - Remove
|
|||
the records from database permanently.
|
||||
|
||||
External References
|
||||
===================
|
||||
+++++++++++++++++++
|
||||
None.
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
=======================================
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
None.
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
*Problem Definition*
|
||||
--------------------
|
||||
++++++++++++++++++++
|
||||
Enterprises typically have their own data classification strategies. The types
|
||||
of data stored typically include (but are not limited to): financial, personal,
|
||||
health, and confidential business data. Some enterprises (especially finance and
|
||||
|
|
@ -29,14 +29,14 @@ to encrypt/decrypt the data must be rotated on a regular basis and the access of
|
|||
keys are restricted to authorized personnel only.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
* As the Enterprise IT Manager, I must ensure the appropriate security for the
|
||||
HR Department database containing employee records that services several
|
||||
applications. I would like to migrate the database into our company's
|
||||
|
|
@ -58,18 +58,17 @@ User Stories
|
|||
at rest, and that keys used to encrypt the data are rotated annually.
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
None.
|
||||
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
* An application needs to be able to specify networking requirements
|
||||
* An application needs to be able to specify workload isolation requirements
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
|
||||
++++++++++++++
|
||||
* A block & object storage solution that enables encryption/decryption at the
|
||||
instance source
|
||||
* A block & object storage solution that enables encryption/decryption for
|
||||
|
|
@ -84,11 +83,11 @@ Related User Stories
|
|||
instance, in addition to at rest.
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
None.
|
||||
|
||||
*Gaps*
|
||||
======
|
||||
++++++
|
||||
**Cinder issues:**
|
||||
* The storage encryption functionality exists, but requires admin status.
|
||||
Creating encrypted volumes should not require admin status.
|
||||
|
|
@ -106,7 +105,7 @@ however, this does not solve for in flight data.
|
|||
|
||||
|
||||
*Affected By*
|
||||
=============
|
||||
+++++++++++++
|
||||
* At the Hong Kong summit there was `a talk`_ on barbican/cinder/nova for this
|
||||
type of functionality. Don’t know if it was successfully integrated into
|
||||
OpenStack yet.
|
||||
|
|
@ -116,11 +115,11 @@ however, this does not solve for in flight data.
|
|||
encryption (at rest).
|
||||
|
||||
*Rejected User Stories / Usage Scenarios*
|
||||
=========================================
|
||||
-----------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
* Data in Flight - Data in transit between an instance and storage system
|
||||
* Data at Rest - Data stored persistently on a storage system
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
-------------------
|
||||
|
||||
Problem Definition
|
||||
------------------
|
||||
++++++++++++++++++
|
||||
As a deployer of an OpenStack cloud I have to provide a specific network
|
||||
configuration file to my network security team in order to enable appropriate
|
||||
traffic to my cloud. At the moment I have to cobble together this configuration
|
||||
|
|
@ -18,14 +18,14 @@ generate the bulk of this information as part of the deployment process or from
|
|||
an available OpenStack service on demand.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
* As a deployer, I want to be able to access a configuration description that I
|
||||
can provide to my network security team to properly configure any external
|
||||
firewalls so that my users can quickly begin accessing the cloud.
|
||||
|
|
@ -34,7 +34,7 @@ User Stories
|
|||
have minimal effort required to appropriately configure the firewall
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
1. Cloud Deployer
|
||||
a. Deploy cloud using deployment configuration
|
||||
b. Access templated firewall configuration from OpenStack service
|
||||
|
|
@ -42,21 +42,21 @@ Usage Scenarios Examples
|
|||
d. Network security team easily interprets configuration and configures FW
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Requirements
|
||||
============
|
||||
++++++++++++
|
||||
None.
|
||||
|
||||
External References
|
||||
===================
|
||||
+++++++++++++++++++
|
||||
None.
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
=======================================
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
None.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem description
|
||||
===================
|
||||
-------------------
|
||||
|
||||
This use case is specifically about deploying the Perimeta Session Border
|
||||
Controller (SBC) Virtual Network Function (VNF) from Metaswitch Networks in
|
||||
|
|
@ -14,10 +14,12 @@ OpenStack.
|
|||
|
||||
Perimeta, like other SBCs, sits on the edge of a service provider's network and
|
||||
polices SIP and RTP (i.e. VoIP) control and media traffic passing over both
|
||||
* the access network between end-users and the core network
|
||||
* the trunk network between the core and another service provider.
|
||||
|
||||
::
|
||||
* the access network between end-users and the core network
|
||||
* the trunk network between the core and another service provider
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
Access + SP A core + Trunk + SP B core
|
||||
network | network | network | network
|
||||
| | |
|
||||
|
|
@ -63,7 +65,7 @@ does not mean this can be disabled at a host scope, or just because Perimeta
|
|||
uses SR-IOV or DPDK it does not mean that all VMs on that host must do so.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
|
||||
Although this user story is specifically about Perimeta, it is more generally
|
||||
representative of the issues involved in deploying in OpenStack any VNF
|
||||
|
|
@ -72,17 +74,17 @@ elements rather than more generic issues like orchestration and high
|
|||
availability (HA).
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
|
||||
* As a communication service provider, I want to deploy a highly available,
|
||||
high scale, high performance Session Border Controller on OpenStack to police
|
||||
VoIP traffic at the edge of my network.
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
|
||||
The Perimeta Session Border controller from Metaswitch Networks is a
|
||||
Telco-grade implementation of a Session Border Controller designed to run
|
||||
|
|
@ -90,12 +92,12 @@ either on generic PC hardware or virtualized, running on OpenStack and other
|
|||
clouds, providing high availability, high scale and high performance.
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
|
||||
None.
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
++++++++++++++
|
||||
|
||||
The problem statement above leads to the following requirements.
|
||||
|
||||
|
|
@ -201,17 +203,17 @@ The problem statement above leads to the following requirements.
|
|||
VLAN aware VMs: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
|
||||
None.
|
||||
|
||||
*Rejected User Stories / Usage Scenarios*
|
||||
=========================================
|
||||
-----------------------------------------
|
||||
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
|
||||
**NFV**
|
||||
Network Functions Virtualization, the vision of deploying telecoms functions
|
||||
|
|
|
|||
|
|
@ -22,10 +22,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
*Problem Definition*
|
||||
--------------------
|
||||
++++++++++++++++++++
|
||||
.. This section is optional.
|
||||
.. Please use it to provide additional details (if available) about your user story
|
||||
.. (if warranted) for further expansion for clarity. A detailed description of the
|
||||
|
|
@ -50,7 +50,7 @@ infrastructure you would like to manage with OpenStack
|
|||
host and the virtual machines running on the host
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. Use this section to give opportunity details that support why
|
||||
.. pursuing these user stories would help address key barriers to adoption or
|
||||
|
|
@ -77,10 +77,10 @@ Support for onboarding legacy environments in a non-disruptive manner
|
|||
will greatly increase the adoption of OpenStack.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
.. This section is mandatory. You may submit multiple
|
||||
.. user stories in a single submission as long as they are inter-related and can be
|
||||
.. associated with a single epic and/or function. If the user stories are
|
||||
|
|
@ -109,7 +109,7 @@ User Stories
|
|||
machines network resources without disrupting those virtual machines
|
||||
|
||||
Usage Scenario Examples
|
||||
------------------------
|
||||
+++++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. In order to explain your user stories, if possible, provide an example in the
|
||||
.. form of a scenario to show how the specified user type might interact with the
|
||||
|
|
@ -135,7 +135,7 @@ Usage Scenario Examples
|
|||
Neutron.
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. If there are related user stories that have some overlap in the problem domain or
|
||||
.. that you perceive may partially share requirements or a solution, reference them
|
||||
|
|
@ -150,7 +150,7 @@ Related User Stories
|
|||
* https://blueprints.launchpad.net/cinder/+spec/over-subscription-in-thin-provisioning
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
++++++++++++++
|
||||
.. This section is optional. It might be useful to specify
|
||||
.. additional requirements that should be considered but may not be
|
||||
.. apparent through the user story and usage examples. This information will help
|
||||
|
|
@ -200,7 +200,7 @@ Example: Self service provisioning initiated in OpenStack Horizon would
|
|||
result in the new VMs also showing up in vCenter
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
.. This section is optional.
|
||||
.. Please use this section to add references for standards or well-defined
|
||||
.. mechanisms. You can also use this section to reference existing functionality
|
||||
|
|
@ -211,7 +211,7 @@ result in the new VMs also showing up in vCenter
|
|||
None.
|
||||
|
||||
*Rejected User Stories / Usage Scenarios*
|
||||
=========================================
|
||||
-----------------------------------------
|
||||
.. This is optional
|
||||
.. Please fill out this section after a User Story has been submitted as a
|
||||
.. cross project spec to highlight any user stories deemed out of scope of the
|
||||
|
|
@ -220,7 +220,7 @@ None.
|
|||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
.. This section is optional.
|
||||
.. It is highly suggested that you define any terms,
|
||||
.. abbreviations that are not commonly used in order to ensure
|
||||
|
|
|
|||
|
|
@ -6,16 +6,16 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
-------------------
|
||||
|
||||
Problem Definition
|
||||
-------------------
|
||||
++++++++++++++++++
|
||||
OpenStack doesn’t have a hierarchical permission structure that allows an
|
||||
Operator to assign different permissions for different activities or access to
|
||||
resources to different users.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
Role Based Access is a basic Enterprise requirement. This capability enables
|
||||
Enterprise IT Managers to set read and write permissions to different elements
|
||||
of the IT infrastructure for different people/positions in the organization.
|
||||
|
|
@ -23,26 +23,24 @@ Enterprise security requires separate access UI/ API for Network, Security,
|
|||
Storage management, User Management, and Instance management.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
* As a cloud operator I want to enable my team to be able to see all Admin
|
||||
level alerts, but not to be able to change their status. That requires review
|
||||
and approval by the IT manager.
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
None.
|
||||
|
||||
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Requirements
|
||||
============
|
||||
++++++++++++
|
||||
|
||||
* Enterprise security requires separate access UI/ API for Network, Security,
|
||||
Storage management, User Management, and Instance management.
|
||||
|
|
@ -57,7 +55,7 @@ Requirements
|
|||
superuser problem (newly created role inherit these rights)
|
||||
|
||||
External References
|
||||
===================
|
||||
+++++++++++++++++++
|
||||
From looking at other solutions, generally there are 3 immutable system roles:
|
||||
administrator, read-only, no-access. With support for specifying roles on
|
||||
objects and their hierarchy. There is a notion of "folder", data center, host,
|
||||
|
|
@ -67,12 +65,8 @@ the role that permits the complex action must contain the full set of necessary
|
|||
privileges. For example launching a VM needs access to the datastore, OS images
|
||||
files, disks, ability to create them and/or read an existing one etc.
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
=======================================
|
||||
None.
|
||||
|
||||
Gaps
|
||||
====
|
||||
++++
|
||||
**Keystone**
|
||||
|
||||
* Need to add a new role.
|
||||
|
|
@ -98,6 +92,10 @@ Gaps
|
|||
* Further Horizon today is "pulling" the policy files to determine which
|
||||
buttons/links exposed to users to guide them down the correct path.
|
||||
|
||||
Glossary
|
||||
========
|
||||
Rejected User Stories / Usage Scenarios
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
--------
|
||||
None.
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ Cross Project Spec - `Under Review <https://review.openstack.org/290977>`_
|
|||
User Story Tracker - `Rolling Upgrades Tracker <https://github.com/openstack/openstack-user-stories/tree/master/tracker/rolling-upgrades.json>`_
|
||||
|
||||
Problem description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
Problem Definition
|
||||
--------------------
|
||||
++++++++++++++++++
|
||||
OpenStack operators often shy away from upgrading or updating OpenStack due to
|
||||
concerns about the intrusiveness of upgrades. This prohibits operators from
|
||||
realizing the complete value of their OpenStack cloud, specifically their
|
||||
|
|
@ -21,7 +21,7 @@ to improve their support for non-disruptive updates and upgrades, they are not
|
|||
specifically covered in this document.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
This is a large reason why enterprises fail to gain the full value of their
|
||||
OpenStack cloud. **Upgrades and updates have never been easy and in many
|
||||
environments require extended downtime of both the control and dataplane.**
|
||||
|
|
@ -30,10 +30,10 @@ Fixing upgrades and updates would clear up many concerns which limit OpenStack
|
|||
adoption today.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
* As a Cloud User, I want to experience a stable, regularly updated and
|
||||
upgraded OpenStack platform in order to utilize new features, bug fixes and
|
||||
security enhancements, so that my cloud development experience is
|
||||
|
|
@ -60,7 +60,7 @@ User Stories
|
|||
timing, dependencies, and which services would be impacted.
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
1. Successful upgrade
|
||||
a. Cloud Operator schedules OpenStack upgrade to latest release
|
||||
b. Cloud Operator can be assured that API will perform as expected from a
|
||||
|
|
@ -91,15 +91,15 @@ Usage Scenarios Examples
|
|||
c. Cloud Users are unaffected by the reboots
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Requirements
|
||||
=============
|
||||
++++++++++++
|
||||
None.
|
||||
|
||||
Gaps
|
||||
====
|
||||
++++
|
||||
Upgrades today require downtime in the data plane, network connectivity and
|
||||
often control plane.
|
||||
|
||||
|
|
@ -246,17 +246,17 @@ capable of performing a rolling upgrade.
|
|||
* Status - Implemented
|
||||
|
||||
External References
|
||||
===================
|
||||
+++++++++++++++++++
|
||||
* `Dan Smith's Upgrade Blog Series <http://www.danplanet.com/blog/tag/nova-upgrade-details/>`_
|
||||
* `Rolling Upgrades Project Meta Data Tag <https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-rolling-upgrade.rst>`_
|
||||
* `Grenade - OpenStack Upgrade Test Harness <https://wiki.openstack.org/wiki/Grenade>`_
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
=======================================
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
* **Control Plane** Hosts or infrastructure which operate OpenStack services
|
||||
(e.g. nova-api)
|
||||
* **Data Plane** Infrastructure instances created by cloud users on an
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
-------------------
|
||||
|
||||
Problem Definition
|
||||
------------------
|
||||
++++++++++++++++++
|
||||
Cloud Operators are often confronted with the need to perform what if scenarios
|
||||
on proposed compute and block storage schedulers tweaks. As such they often
|
||||
want to have access to a scheduler simulator, to make a series of "virtual"
|
||||
|
|
@ -17,16 +17,16 @@ requests given a specific scheduler configuration to see if the resulting
|
|||
virtual machine load matches their expected or desired outcome.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
This user story is valuable to cloud operators because it allows them to tune
|
||||
the scheduler without having to run the configurations in real world
|
||||
environments.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
* As a cloud operator, I want to be able to simulate my cloud's scheduler with
|
||||
a variety of virtual machine request loads under a given scheduler
|
||||
configuration in order to determine the optimal configuration for my desired
|
||||
|
|
@ -37,7 +37,7 @@ User Stories
|
|||
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
1. Operator Runs Simulator
|
||||
a. Operator defines scheduler configuration
|
||||
b. Operator defines request load
|
||||
|
|
@ -47,21 +47,21 @@ Usage Scenarios Examples
|
|||
f. Operator determines if result is optimal and if not adjusts configuration
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
None.
|
||||
|
||||
Requirements
|
||||
============
|
||||
++++++++++++
|
||||
None.
|
||||
|
||||
External References
|
||||
===================
|
||||
+++++++++++++++++++
|
||||
None.
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
=======================================
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
None.
|
||||
|
|
|
|||
|
|
@ -1,40 +1,41 @@
|
|||
Security / Policy Enforcement for Enterprise IT
|
||||
==========================
|
||||
===============================================
|
||||
Cross Project Spec - None
|
||||
|
||||
User Story Tracker - None
|
||||
|
||||
Problem Description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
*Problem Definition*
|
||||
--------------------
|
||||
++++++++++++++++++++
|
||||
Many enterprise has stringent security requirements and the security policy
|
||||
must be enforced by IT security. Such security policy must be enforced and applied to
|
||||
all compute resources hosted in the enterprise environment.
|
||||
must be enforced by IT security. Such security policy must be enforced and
|
||||
applied to all compute resources hosted in the enterprise environment.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
TBD.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
* As an Enterprise IT security policy maker, I need to ensure that all compute
|
||||
resources must adhere to the security policy as defined by the IT security
|
||||
department so that the cloud resources are compliant to enterprise rules and
|
||||
regulations.
|
||||
* As an Enterprise IT security administrator, I have to create multiple security
|
||||
policy for different corporate department or division. All cloud resources
|
||||
provisioned for that particular department or division must be applied with
|
||||
relevant security policy. Such policy (e.g firewall rules) cannot be removed
|
||||
by the cloud users. A cloud users may add additional rules but cannot remove
|
||||
any rules as defined by the IT security administrator.
|
||||
resources must adhere to the security policy as defined by the IT security
|
||||
department so that the cloud resources are compliant to enterprise rules and
|
||||
regulations.
|
||||
|
||||
* As an Enterprise IT security administrator, I have to create multiple
|
||||
security policy for different corporate department or division. All cloud
|
||||
resources provisioned for that particular department or division must be
|
||||
applied with relevant security policy. Such policy (e.g firewall rules)
|
||||
cannot be removed by the cloud users. A cloud users may add additional rules
|
||||
but cannot remove any rules as defined by the IT security administrator.
|
||||
|
||||
Usage Scenarios Examples
|
||||
------------------------
|
||||
++++++++++++++++++++++++
|
||||
The Enterprise IT needs to enforce a corporate-wide or division-wide firewall
|
||||
policy and rules. This firewall (or security group) must be applied to all
|
||||
compute resources of a project/tenant within that division. This policy is
|
||||
|
|
@ -46,31 +47,32 @@ predefined rules. This security group must be automatically applied to all VM
|
|||
whenever the VM is launched by the cloud users and cannot be removed.
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
None.
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
++++++++++++++
|
||||
In order to support this user story, we need:
|
||||
* A method for security administrator to create a
|
||||
firewall or security policy and be able to enforce such policy to different
|
||||
project tenant.
|
||||
* A mechanism to automatically attached the fireall or
|
||||
security policy to each network/VM created by the cloud users within the
|
||||
project tenant.
|
||||
* The rules defined in such fireall/security policy can only
|
||||
be modified by the security administrator and must not be removed or modified
|
||||
by cloud users. This might requires "role-based access control" to specific
|
||||
type of resources and actions.
|
||||
|
||||
* A method for security administrator to create a firewall or security policy
|
||||
and be able to enforce such policy to different project tenant.
|
||||
|
||||
* A mechanism to automatically attached the fireall or security policy to
|
||||
each network/VM created by the cloud users within the project tenant.
|
||||
|
||||
* The rules defined in such fireall/security policy can only be modified by
|
||||
the security administrator and must not be removed or modified by cloud
|
||||
users. This might requires "role-based access control" to specific type of
|
||||
resources and actions.
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
TBD.
|
||||
|
||||
*Rejected User Stories / Usage Scenarios*
|
||||
=========================================
|
||||
-----------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
TBD.
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
*Problem Definition*
|
||||
--------------------
|
||||
++++++++++++++++++++
|
||||
This use case is about deploying a virtual IMS core as an NFV function in
|
||||
OpenStack. It replaces the version previously uploaded to the TelcoWG
|
||||
repository [1].
|
||||
|
|
@ -41,7 +41,7 @@ The requirements that such an orchestrator places on OpenStack are not
|
|||
addressed in this use case.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
|
||||
Although this user story is specifically about deploying the Project
|
||||
Clearwater virtual IMS core, it is more generally representative of the
|
||||
|
|
@ -50,17 +50,17 @@ plane Virtual Network Function (VNF) deployed as a series of load-balanced
|
|||
stateless N+k pools.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
|
||||
* As a communication service provider, I want to deploy a highly available,
|
||||
high scale, high performance virtual IMS core on OpenStack to provide my core
|
||||
Voice-over-IP service.
|
||||
|
||||
Usage Scenario Examples
|
||||
------------------------
|
||||
+++++++++++++++++++++++
|
||||
|
||||
Project Clearwater [3] is an open-source implementation of an IMS core
|
||||
designed to run in the cloud and be massively scalable. It provides
|
||||
|
|
@ -68,12 +68,12 @@ P/I/S-CSCF functions together with a BGCF and an HSS cache, and includes a
|
|||
WebRTC gateway providing interworking between WebRTC & SIP clients.
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
|
||||
None.
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
++++++++++++++
|
||||
|
||||
The problem statement above leads to the following requirements.
|
||||
|
||||
|
|
@ -114,15 +114,19 @@ The problem statement above leads to the following requirements.
|
|||
MZ.
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
|
||||
* [1] https://review.openstack.org/#/c/179142/
|
||||
* [2] https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem
|
||||
* [3] http://www.projectclearwater.org
|
||||
* [4] http://www.projectclearwater.org/technical/clearwater-architecture/
|
||||
|
||||
Rejected User Stories / Usage Scenarios
|
||||
---------------------------------------
|
||||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
|
||||
* NFV - Networks Functions Virtualisation, see http://www.etsi.org/technologies-clusters/technologies/nfv
|
||||
* IMS - IP Multimedia Subsystem
|
||||
|
|
|
|||
|
|
@ -22,10 +22,10 @@ Cross Project Spec - None
|
|||
User Story Tracker - None
|
||||
|
||||
Problem description
|
||||
====================
|
||||
-------------------
|
||||
|
||||
*Problem Definition*
|
||||
--------------------
|
||||
++++++++++++++++++++
|
||||
.. This section is optional.
|
||||
.. Please use it to provide additional details (if available) about your user story
|
||||
.. (if warranted) for further expansion for clarity. A detailed description of the
|
||||
|
|
@ -37,7 +37,7 @@ Problem description
|
|||
None.
|
||||
|
||||
Opportunity/Justification
|
||||
-------------------------
|
||||
+++++++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. Use this section to give opportunity details that support why
|
||||
.. pursuing these user stories would help address key barriers to adoption or
|
||||
|
|
@ -50,10 +50,10 @@ Opportunity/Justification
|
|||
None.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
---------
|
||||
|
||||
User Stories
|
||||
------------
|
||||
++++++++++++
|
||||
.. This section is mandatory. You may submit multiple
|
||||
.. user stories in a single submission as long as they are inter-related and can be
|
||||
.. associated with a single epic and/or function. If the user stories are
|
||||
|
|
@ -68,7 +68,7 @@ User Stories
|
|||
None.
|
||||
|
||||
Usage Scenario Examples
|
||||
------------------------
|
||||
+++++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. In order to explain your user stories, if possible, provide an example in the
|
||||
.. form of a scenario to show how the specified user type might interact with the
|
||||
|
|
@ -86,7 +86,7 @@ Usage Scenario Examples
|
|||
None.
|
||||
|
||||
Related User Stories
|
||||
====================
|
||||
++++++++++++++++++++
|
||||
.. This section is mandatory.
|
||||
.. If there are related user stories that have some overlap in the problem domain or
|
||||
.. that you perceive may partially share requirements or a solution, reference them
|
||||
|
|
@ -95,14 +95,14 @@ Related User Stories
|
|||
None.
|
||||
|
||||
*Requirements*
|
||||
==============
|
||||
++++++++++++++
|
||||
.. This section is optional. It might be useful to specify
|
||||
.. additional requirements that should be considered but may not be
|
||||
.. apparent through the user story and usage examples. This information will help
|
||||
.. the development be aware of any additional known constraints that need to be met
|
||||
.. for adoption of the newly implemented features/functionality. Use this section
|
||||
.. to define the functions that must be available or any specific technical
|
||||
.. requirements that exist in order to successfully support your use case. If there
|
||||
.. to define tahe functions that must be available or any specific technical
|
||||
.. requirementsthat exist in order to successfully support your use case. If there
|
||||
.. are requirements that are external to OpenStack, note them as such. Please
|
||||
.. always add a comprehensible description to ensure that people understand your
|
||||
.. need.
|
||||
|
|
@ -114,7 +114,7 @@ None.
|
|||
None.
|
||||
|
||||
*External References*
|
||||
=====================
|
||||
+++++++++++++++++++++
|
||||
.. This section is optional.
|
||||
.. Please use this section to add references for standards or well-defined
|
||||
.. mechanisms. You can also use this section to reference existing functionality
|
||||
|
|
@ -125,7 +125,7 @@ None.
|
|||
None.
|
||||
|
||||
*Rejected User Stories / Usage Scenarios*
|
||||
=========================================
|
||||
-----------------------------------------
|
||||
.. This is optional
|
||||
.. Please fill out this section after a User Story has been submitted as a
|
||||
.. cross project spec to highlight any user stories deemed out of scope of the
|
||||
|
|
@ -134,7 +134,7 @@ None.
|
|||
None.
|
||||
|
||||
Glossary
|
||||
========
|
||||
--------
|
||||
.. This section is optional.
|
||||
.. It is highly suggested that you define any terms,
|
||||
.. abbreviations that are not commonly used in order to ensure
|
||||
|
|
|
|||
Loading…
Reference in New Issue