x/development-proposals
Code Issues Proposed changes

Added Onboarding story with correct template

Browse Source 
Change-Id: I1facfe75dfa28a82384adae639f270067f1bbcbf
This commit is contained in:
jay.kruemcke
2015-08-27 07:30:29 -05:00
committed by Jay Kruemcke
parent 4fbfb35fa8
commit 92a42b6994
1 changed files with 92 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
user-stories/draft/Onboarding.rst Normal file
View File

@@ -0,0 +1,92 @@
============================================
Onboarding Legacy Apps into OpenStack (Pets)
============================================
**Sections in** *italics* **are optional.**
*Problem description*
---------------------
What do you do when you have a 3rd party app in your infrastructure and the 3rd party doesn't know openstack and
how to evaluate/modify their apps ability to be onboarded into OpenStack
* Work from the top of the stack down ­ how do you address stateful apps
* Start with different language/tools (Java, etc) and then walk through the solution stack and identify the points where changes are needed and then how to implement it
* Or consider how to enable the app to still be stateful, but more failure tolerant
* I have a homegrown CRM, how do I port it to OpenStack?
* Partitioning Apps ­ How do you modularize an app so that the front end can be hosted in the cloud and the back end can be housed in the traditional infrastructure.
* This is focused on 3rd party applications: Porting, Rebuilding
* I need to be able to test and validate the on­boarded app at scale!
User Stories
------------
* As the Enterprise IT manager that is deploying an OpenStack cloud alongside my existing infrastructure, I need manage existing virtual machines compute resources.
* As the Enterprise IT manager that is deploying an OpenStack cloud alongside my existing infrastructure, I need to onboard existing block storage into Cinder.
* As the Enterprise IT manager that is deploying an OpenStack cloud alongside my existing infrastructure, I need manage existing virtual machines network resources.
Usage Scenarios Examples
------------------------
1. Managing existing virtualized applications
a. For each physical host in a legacy virtualized server environment, Obtain a
list of all resources (Compute, Memory, Block storage and Network) for each
Virtual Machine b. Create database entries for each virtual machine in the
OpenStack so that each of the legacy VMs are managed though OpenStack services
such as Horizon, Nova, Cinder, Neutron.
Opportunity/Justification
-------------------------
Enterprises with extensive legacy applications would like to manage these
applications using OpenStack services. Due to the nature of the applications and
their value to the business, the onboarding process needs to be non-disruptive
and suitable for use at scale.
The ability to onboard legacy environments is widely desired by any business that
is currently has a legacy IT environment and is using OpenStack to manage new
applications.
Support for onboarding legacy environments in a non-disruptive manner will
greatly increase the adoption of OpenStack.
Related User Stories
--------------------
* https://etherpad.openstack.org/p/kilo-nova-summit-topics
* https://etherpad.openstack.org/p/kilo-cinder-summit-topics
* https://etherpad.openstack.org/p/kilo-neutron-summit-topics
* https://github.com/openstack/cinder-specs/blob/master/specs/kilo/over-subscription-in-thin-provisioning.rst
* https://blueprints.launchpad.net/cinder/+spec/over-subscription-in-thin-provisioning
*Requirements*
--------------
1. Onboarding must be non-disruptive to legacy application environments.
*Gaps*
------
* Cinder API to list all volumes
* Cinder API to add volume to database (current “manage_existing” API requires
too much intrinsic knowledge)
* Nova API to discover VM and all resources associated with it including Memory,
Processor, Block Volumes
* Nova API to add existing VM to OpenStack database
* Neutron API to add network information to OpenStack database
*Affected By*
-------------
None.
*External References*
---------------------
None.
Glossary
========
**Pets** Legacy application workloads that are characterized by stateful
applications that lack of application level redundancy and high value to the
business (contrast with "cattle")
**Cattle** Designed for cloud applications that are characterized by stateless
application design and application redundancy