Add GoogleDrive User Stories

Copied user stories from GoogleDocs format into user-story-template.rst
format and submitting to repo for tracking.

Change-Id: If4f6406594cba63bca8a3431b9d34ffff44a5f3c

user-stories/draft/encryptedstorage.rst

@@ -0,0 +1,98 @@
+Encrypted Storage
+==================
+
+*Problem description*
+---------------------
+Each enterprise has its own data classification strategy. The types of data
+include: financial data, personal data, health data, confidential business
+data, etc. Some enterprise (especially in banking, finance and insurance
+industry) has stringent data requirements in order to be compliant with laws
+and regulations. For example, PCI DSS Requirement 3.4 states that credit card
+personal account number must be rendered unreadable anywhere it is stored
+(including portable digital media, backup media and logs). Applications
+(including database) that interact with these classes of information need to be
+able to specify encrypted storage requirements when the application is launched
+and interacts with some of these classes. The data must be encrypted in motion
+as well as at rest. The application should not require admin privileges to
+access encrypted storage.
+ 
+In addition, proper key management process need to be in place. The keys used
+to encrypt/decrypt the data must be changed on a regular basis and the access
+of keys are restricted to authorized personnel only.
+
+User Stories
+------------
+* As the Enterprise IT Manager, I must ensure the appropriate security for the HR
+department database with employee records that services several department
+applications. I would like to move the database into our companies private cloud
+so I don’t need to maintain the system it currently lives on. However, because of
+the critical nature of the information in the database our company policy does
+not allow this information to reside on any shared system in an unencrypted
+state. To be able to move the database into the private cloud I need to ensure
+that the stored data and all data in transit from/to the VM will be encrypted.
+While the HR Department would love to have improved uptime for their database,
+they are used to having to manually restart/reboot as needed and can live with
+this in the cloud as well.
+
+* I am the Enterprise IT manager for an insurance company. My company maintains a
+database with insurer’s credit card records for annual renewal purpose. Our
+company would like to move the database into our OpenStack private cloud. In
+order to comply with company security policy, government laws and financial
+regulations, I need to ensure that information stored in the private cloud
+(including backup) is encrypted, and the keys used to encrypt the data are
+rotated/changed annually.
+
+Usage Scenarios Examples
+------------------------
+None.
+
+Opportunity/Justification
+-------------------------
+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 option that includes encryption / decryption at the VM
+source.
+*  A method for the application to specify that it requires a block storage
+system that includes encryption / decryption at the VM source.
+* OpenStack services to enforce the storage requirements for the application
+* A method for changing the key used to encrypt/decrypt the data after a specific
+period of time.
+*The database application needs to be able to specify that it needs an encrypted
+storage system that supports encryption / decryption at the VM source, in
+addition to at rest.
+*The storage system must be able to handle both Reads/Writes of persistent
+encrypted block storage in excess of 1TB device to be backed up nightly.
+
+*Gaps*
+------
+**Cinder issues:**
+* The basic storage encryption functionality looks like it may exist, but
+requires admin status. Creating encrypted volumes should not require admin
+status.
+
+*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.
+https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/p
+resentation/encrypted-block-storage-technical-walkthrough
+
+* There is a spec located at: https://wiki.openstack.org/wiki/VolumeEncryption
+for some early work and the current documentation is located at:
+http://docs.openstack.org/juno/config-reference/content/section_create-encrypted-
+volume-type.html where it implies that admin privilege is required.
+
+*External References*
+---------------------
+None.
+
+Glossary
+========
+None.

user-stories/draft/rolebasedaccess.rst

@@ -0,0 +1,85 @@
+Role Based Access
+=================
+
+*Problem description*
+---------------------
+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.
+
+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.
+
+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.
+Enterprise security requires separate access UI/ API for Network, Security,
+Storage management, User Management, and Instance management.
+
+Related User Stories
+--------------------
+None.
+
+*Requirements*
+--------------
+* Enterprise security requires separate access UI/ API for Network, Security,
+Storage management, User Management, and Instance management.
+* Includes grouping actions into roles, assign roles to users, create hierarchy
+of roles, etc.
+* OpenStack includes an enforcement piece of access control, but no management
+piece.
+* Very important that admin type roles need to be tested thoroughly because of
+the code bleed-in where actions are exposed if  "is-admin".
+* As we expand the roles need some tool that can report out on what access the
+newly defined role has - want to make sure you don’t inadvertently create a
+superuser problem (newly created role inherit these rights)
+
+*Gaps*
+------
+**Keystone**
+* Need to add a new role.
+* Modify code that makes checks such as context admin, is-admin.
+**All Projects**
+* Need to review code in other projects to find hardcoded reference to Admin and
+replace them with Keystone references.
+* Modify the policy.json file to use this new role. Add test cases to confirm
+behavior is as expected. Code in all projects need to be searched for is-admin
+type tests and code modified to ensure that admin-read-only is tested as
+necessary.
+* One approach: Expose the policy.json files of each of the projects via horizon
+and allow it to be modified.
+* May need a bug to fix such as: is-admin evaluations to use only roles in the
+code,  towards making policy.json the true controller.
+**Horizon**
+*To expose policy.json via Horizon will need to be allowed to only cloud-admins,
+and any change checked for syntactic correctness at the least.
+* Further Horizon today is "pulling" the policy files to determine which
+buttons/links exposed to users to guide them down the correct path.
+
+*Affected By*
+-------------
+None.
+
+*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, VMs on a
+host, disk etc. Some actions are sort of atomic -- create a disk. While others
+encompass multiple steps, needing a variety of privileges. Thus 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.
+
+Glossary
+========
+None.

user-stories/draft/serviceseparation.rst

@@ -0,0 +1,71 @@
+OpenStack Service Separation
+============================
+
+*Problem description*
+---------------------
+We need separation between services to mitigate for library conflicts. This way 
+instead of doing "openstack upgrade" we can do "nova upgrade" today, "neutron 
+upgrade" tomorrow and on, and that approach simplifies things tremendously, 
+because potential fallback is both easy and fast, and impact is much lower.
+
+Biggest problems in upgradeable deployments are dependencies and speed of 
+upgrade. Dependencies means, in case of shared libraries, several services might 
+require same library, but often at different versions between major openstack 
+releases. This will cause conflicts, and require us to do “all or nothing” 
+upgrade. Sometimes we would like to use several maintenance windows to upgrade 
+our deployment one service at the time. Also, we want this maintenance windows to 
+be as short as possible, hence speed of deployment changes.
+
+User Stories
+------------
+* As an OpenStack Operator, I select services to upgrade based upon the new 
+features that have been implemented and bugs fixed. This will lead to different 
+versions of Services running together my deployment. Different Services will be 
+using different versions of system and 3rd party libraries.
+
+Usage Scenarios Examples
+------------------------
+* Containers are new way to deploy microservices. Ever heard of Docker? Who
+didn’t? We want to utilize containers flexibility, speed of deployment, and most
+importantly, separation of services. With each service having its own library
+base, we don’t have conflicts, and we can upgrade just one service at the time
+without disruption of others.
+ 
+* Kolla is project which does exactly that – containerize your openstack
+services. By using Kolla you can utilize flexible container to be configured in a
+way you ran your services for years, or, for those who want to start openstack
+adventure, quick and easy way to set up production ready upgradable openstack
+using ansible.
+
+Opportunity/Justification
+-------------------------
+None.
+
+Related User Stories
+--------------------
+None.
+
+*Requirements*
+--------------
+* Ability to upgrade 1 OpenStack service, without having to upgrade all OpenStack
+services
+* Maintain overall system reliability when only 1 Service is upgraded
+* Minimal or no downtime during upgrade
+
+*Gaps*
+------
+None currently known.
+
+*Affected By*
+-------------
+Real value can be realized using TripleO to deploy Kolla-based OpenStack. With
+TripleO’s  baremetal and config management, and Kolla containers, deploying large
+scale, upgradable, production ready OpenStack becomes an achievable use case.
+
+*External References*
+---------------------
+None.
+
+Glossary
+========
+None.