Cloud/Cloud PRD

Fedora Cloud Product PRD

About this Document

This PRD (Product Requirements Document) is an evolving document, created by the Fedora Cloud SIG Working Group as part of the process for designing the Fedora Cloud product. The framework for the PRD itself is currently in a draft state.

The actual governance of this document, and whether or not it is “fixed” at a certain point in time or able to evolve (in the form of updating progress, etc.) is still to be determined.

Authors

Contributors to this document include:

• Robyn Bergeron

Reviewers & Contributors

The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact.

• Your name here!

Community Information

The Fedora Cloud SIG is one of many teams within the Fedora Project.

The Cloud SIG mailing list is located here.

Minutes and logs from IRC meetings related to the development of this document should be listed here as the document evolves.

Approval History

Over time, it is expected that this document will undergo various rounds of review, approval, and editing; in the future, it may be rewritten for different releases of Fedora.

While one can review the history of a wiki document (by clicking the "history" tab), it is useful to provide explicit indicators of any major format changes, approvals, or indications of it being in a “final” state, in a list that can allow someone to quickly see that all of the prescribed layers of approval have occured.

• October 28, 2013: Initial Draft of template.
• FutureDate: Approval by SomeGroup; link to any pertinent mail announcement and/or meeting minutes

Tracking of Progress

This document contains numerous descriptions of use cases, descriptions of feature sets to address the use cases, and the requirements to enable those features. It is expected that numerous requirements, better known as “changes” in the Fedora change process, or known even more simply as “packages,” may combine to address those use cases and feature sets. Thus, as a single release, or even series of releases, undergoes development, it is useful to easily track how an entire use case or feature set may be progressing.

While Fedora uses the Changes Process to track changes in the distribution, those changes are typically described as details of changes to a specific package, or the introduction of a specific package, rather than as a piece of a larger feature set.

This document could possible be used to do any or a number of the following things:

• Provide a secondary location where changes are tracked (which seems like a lot of overhead to me)
• Provide a location where overall Feature Progress is tracked, via periodic cross-checking against Change pages; this could be either in a standalone section, or simply attached to each Feature description.
• Scope out how features are expected to progress over a number of releases.
• None of these things.

When we more fully determine how to most efficiently track progress, the pointer to where that tracking is done, and/or the description of or process by which we do the tracking is formalized, should be documented in this section in lieu of what is currently written here.

Document Purpose and Overview

Document Structure

Overview of what each section in the PRD (should) contains.

Release/Product Overview

Product Objectives

Overview of product goes here.

Delivery Mechanisms

How we deliver the product. This has two facets:

Where to obtain

(FTP, website, AWS, etc.)

Delivery Format

(Images of various types, containers, etc.) Note that delivery format is likely covered in more depth in other sections as well.

User Profiles, Goals, and Primary Use Cases

Still working out some logic on this section. But forging ahead with what I have for the moment.

Goal of this section is to provide insight into either or both of:

• Primary Use Cases: What are the situations / environments in which we expect a Fedora Cloud Product to be used
• User Profiles and Goals: This is more like “personas” work, or could be done as “user stories” (more along the lines of agile, see http://en.wikipedia.org/wiki/User_story )

... and then ensure that for each type of user or use case, we have features/changes that make the Fedora Cloud product useful.

User Profiles

User Profile #1

1. User Goals

What are this user's main goal in using this product?

1. Common Tasks

What are the user's main tasks they need to accomplish with the product?

Primary Use Cases

Primary Use Case #1

• Problem Being Solved / Goal needing to be achieved
• Assumptions
• Workflow

Secondary Use Cases

Because cloud is “cloudy,” sometimes the cloud product requirements may be dependent on enablement in other Fedora products. Additionally, there may be open source projects with which we desire compability.

Note that some of these secondary use cases may overlap with primary use cases. (Or this section may be entirely rolled into that section; TBD.)

IaaS environments

Ensure that the Fedora Server product can serve as a platform for the following IaaS projects, or at least that the Fedora Cloud product can be used as a guest/VM/image with those services. For projects that are not currently packaged within Fedora/EPEL, we may need to locate a kind person to ensure testing.

Development environments

Fedora should be a useful, productive environment for developers writing code to be executed in a cloud environment.

Simple Deployment of code to from dev to production

As a developer, I want to ensure that my code is easily deployable from my development environment to a production environment, without encountering issues of non-compatibility. Example: A feature described as “Improved deployment of code to a cloud” might be fully described in the Features section, and as a result, Vagrant might be listed as a requirement in the non-functional requirements section, and cross-coordinated with the workstation working group. There are likely numerous other requirements as well.

Development as part of a team

As a member of a development team, I would like to develop in an environment where code can go through unit or functional testing, and be approved or accepted by other members of the team. Example: A feature described as “Continuous Integration platform” may be listed in the Features section, and the various tools available to implement would be enumerated and described in the “non-functional requirements” section, and cross-coordinated with the server working group.

Development using libraries not included in the distribution

As a developer, my toolchain includes libraries or dependencies on other packages using libraries not in the Fedora distribution, and I may be developing for distributions not limited to Fedora.

Example: A feature described as “Portable code” (REALLY POOR DESCRIPTION, sorry) may be listed in the Features section, and “Software Collections” might be listed as a requirement.

Note that this may have some cross-over with a possible additional story/use case, “Deployment of code using libraries not included in the distribution.”

Features

Features here address the primary and secondary use cases, product or secondary objectives, market opportunities from above.

Features should be described as “what it enables” (poor description for now as I flesh out something better or someone else comes up with it!) - more of a story / solution description, rather than “package XYZ” - the features (the ways to meet a user's objectives?) each likely consist of more than one package/enhancement, and those packages should be detailed in the “Detailed requirements” section of this document, and each of those detailed requirements should refer back to which feature it supports.

Feature #1

Feature description should be described in the line saying “Feature #1/2/etc.”. Describe the feature in more detail, specifically addressing how it addresses user scenarios, primary or secondary use cases / objectives of the product.

Use a table to indicate the following items: Priority (Must, Should, NTH) Citation of use cases addressed

As work continues and specific detailed requirements are developed, reference the detailed requirements within this document helping to fulfill this feature. This helps to ensure awareness around “do we still have a feature if some of the detailed requirements are not fulfilled, and thus are not able to address the specific use case needs / user objectives.”

Detailed Requirements

Supporting packages / work required for the product itself to function to address the use cases above. Non-functional requirements (i.e.: requirements outside the scope of how it actually works / solves problems) are addressed in a later section.

Note that this section does not have to be filled out in detail to the extent that a “Change” would require (per the Changes process in Fedora.)

Requirement #1 (Short Description of Requirement)

Feature(s) Addressed

Refer to which previously described Features, Use Cases this requirement helps to fulfill.

Priority

Must, should, NTH

Effort required

High, Medium, Low

Major Dependencies

Any major dependencies, including things that may require any cross-working-group coordination, should be called out here. Any process changes required within Fedora should be documented here as well.

Testing

Level of testing required; is it a blocker to release? Is the testing automate-able?

Other Documentation

• Existing BZ:
• Upstream webpage / wiki page / github page(s):

Non-functional requirements

These are the requirements needed that are not necessarily part of implementation of the product itself, but are still required as part of either making the product more attractive/useful, compatibility requirements for a user's workflow (ie: “works with Puppet,”) or things needing to be done/coordinated in other areas of the project (in other working groups?) to ensure a well-rounded solution.

For each, as was done with Features in a previous section, we should call out some additional information, assuming doing so makes sense for the requirement:

• Priority (Must, Should, NTH)
• Effort required
• Major dependencies / Process Changes needed
• Stakeholders/Owners
• Existing Documentation: BZ #, pointers to upstream project docs

Image Creation

How to create images. Do not be shocked if there are 48 ways to do this. Also: not sure if we want to include containers in this section.

Creation of “official” Fedora Project images

New images. Updated images (ie: providing newer images for a release that have updates already included) might also be included here?

Documentation

Open Source Projects documentation

Ensuring that Fedora is well-represented, up-to-date in other open source project documentation...

Support Requirements

Supported (platforms?)

Virtualization types? Container types?