Difference between revisions of "Solum/AdditionalUserFacingScenarios"

Revision as of 17:44, 28 October 2013

The following stories represent important scenarios gleaned from development and customer interactions for Red Hat OpenShift. These are described from the three perspectives - developers being introduced to an ALM flow, developers and admins running real managed applications, and administrative and operational characteristics of the system. These are only intended to assist in discussing concrete scenarios and should be considered subordinate to the actual Solum Roadmap. There are additional gaps in the flow - these are simply the items that have the highest importance.

The separation of new developers from experienced developers below is primarily to frame the minimal concepts that are required to interact with the system, vs. the concepts that the system provides in order to deliver significant value. We believe it should be possible to build a system that satisfies both sets of users, but that targetting simple client flows for specific onboarding tasks is a core requirement of the system in order to expose a large audience of developers to ALM.

Onboarding a new developer [O]

1. Create a simple web application that contains a template of source code that returns at least a simple web page without further user input.
2. Create a simple web application using source code I have present for my own application
   1. Alt: create a simple web application using a repository provided via the internet
3. Create a preconfigured web application that has code but is functional with minimal web interactions (Drupal, Wordpress, other CMS are good examples)

Developing proficiency / moving to production [M]

All above scenarios target developers who are fairly unfamiliar with the capabilities and extents of the platform. It should be possible to perform the following actions afterwards:

1. Add a simple, built in database to the application that "just works"
   1. Alt: openstack dbaas trove, mongohq, redis aaS
   2. Alt: provisioned as a resource alongside the application web code
   3. Alt: use an existing db in a data center, dbaas, or other vendor
2. Make a code change and see the application change
3. Scale the application out to two or more instances and have implicit high availability
4. Make a code change, and see that the application remains available
5. Add some code to the repo that will be executed during the build process - generate assets, move files, link contents, build elements, etc
6. Add a continuous integration system to the application - see my next commited change start a build and then deploy my new code
7. Add a custom domain name alias to my application.

Experienced developers and production flow [P]

At this point the developer is fairly familiar with the system, and may be reacting to the defaults they chose up front.

1. They may want to recreate (clone/fork) their application to transition to an alternative data solution such as a SaaS or complex scalable db.
2. They may want to change the "flavor" of their deployment units or their database
3. They will want to rollback to a previous deployment that they have made.
4. They will want to make online migrations of database schemas during deployments
   1. Alt: they will want to reverse those schema changes (manually or otherwise) during a rollback
   2. Alt: they will want certain frameworks to do these upgrades automatically if possible
5. They want to snapshot the transactional state of their application (repo, container config and images, and stateful storage) preferably online, but offline as well
6. They will want to be notified of security updates available for their chosen frameworks. Updates with negligible risk will be automatically updated
   1. Alt: owners can elect to defer functional (or security) upgrades for significant intervals
7. They will want to collaborate on a single application via source control and management functions
8. They will want to move deployments from one environment to another
   1. Alt: they will want to create new environments that mimic existing configurations
   2. Alt: they will want to establish pull models where possible (more restrictive trust flow)

Administration and operational characteristics [A]

The remaining scenarios target developers or system administrators with specific needs and an assumed high level of familiarity with the system.

1. An administrator can prepare and roll out a security upgrade in a controlled, highly available manner to all affected applications.
2. An administrator can prepare and roll out a functional upgrade in a controlled and highly available manner to all affected applications.
   1. Alt: individual applications may opt out of these upgrades for a limited period of time.
   2. Alt: the health of the applications during upgrade is monitored - negative health changes skip that upgrade safely
3. An administrator can alter container characteristics (environment, cgroup settings, quota) in a targeted way and expect those to persist with the container.
4. An application can span multiple projects and tenants for advanced fine grained control over actions for different types of users - developers, release engineers
5. The system can achieve densities of hundreds of active containers on appropriately sized hosts
6. The system is able to stop (idle) and transparently start (wake) containers in response to external tcp traffic, and tolerate thousands of stopped containers present on a host
7. The system is designed to handle tens of millions of applications
8. The system and the tools around it work well for users with access to hundreds of applications