Added Onboarding story with correct template
Change-Id: I1facfe75dfa28a82384adae639f270067f1bbcbf
This commit is contained in:
jay.kruemcke
committed by
Jay Kruemcke
Jay Kruemcke
parent
4fbfb35fa8
commit
92a42b6994
92
user-stories/draft/Onboarding.rst
Normal file
92
user-stories/draft/Onboarding.rst
Normal 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 onboarded 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
|
||||||
Reference in New Issue
Block a user