Valet

Valet
IMPORTANT: Please note that OpenStack Valet is presently on hold.

Valet (noun):


 * 1) A cloud infrastructure-agnostic, resource-inclusive, application-focused, data-driven resource Placement Service.
 * 2) A person employed to park cars.

Motivation
At present, Valet is an unofficial OpenStack-related project in the proverbial "exploratory phase."

The motivation behind Valet is threefold:


 * Hybrid infrastructures are a thing: Many resources such as Servers, Volumes, Routers, Containers, Bare Metal, Acceleration, etc., exist across different infrastructures.
 * All roads lead to the application: Applications such as VNFs are ultimately dynamic collections of resources with a topology and interrelated constraints.
 * Data mining begets intelligence: Potentially any shared resource will have useful measurements that aren’t strictly apportioned, such as real-time utilization.

This leads to the following tenets:


 * Be infrastructure agnostic.
 * Be resource inclusive.
 * Be holistic (application-focused).
 * Be data-driven.

Aspirationally, then, Valet optimizes a cloud application's resource placements across hybrid cloud infrastructures, aided by real-time cloud measurements, while simultaneously meeting QoS requirements. Valet also does this in a holistic manner, that is, in consideration of an entire application's resources and constraints vs. placing one resource at a time.

Valet is not meant to be Gantt 2.0. Valet does not compete with existing OpenStack projects like the Nova Placement API, Blazar, Watcher, and others. Rather, Valet expects to leverage these and other OpenStack services, as well as equivalents in cloud infrastructures like Kubernetes.

OpenStack Valet
The present iteration (distinguished as OpenStack Valet) is being developed entirely in the open, starting from scratch. It will begin with document-driven development of architecture, APIs, and so on. Fully transparent community participation—be it discussion, brainstorming, and/or collaboration—is welcomed and encouraged.

As a first step, a specific use case with three or four milestones is being proposed, aligned with all the project tenets, so as to have an initial Minimum Viable Product (MVP). Watch this space for details.

Pending open discussion, revision, and consensus on the initial use case, document-driven development will begin in earnest. This includes a document addressing the representation of related resources, architectural diagrams illustrating relationships with other projects as though they already exist, an API, command-line syntax, and usage examples matching the use case.

AIC Valet
The first iteration of Valet was written for AIC (AT&T Integrated Cloud). AIC Valet was open sourced and added to GitHub under att-comdev in December 2016. It was moved to openstack in May 2017.

Code, bugs, and changes are available for perusal via the following links. (Be aware that AIC Valet has no DevStack component or out-of-the-box installation experience.)


 * Source
 * Storyboard (bugs, blueprints, et. al)
 * Valet changes

A presentation on AIC Valet was given at the Newton Summit:


 * OpenStack Newton Summit Presentation (Austin, TX, 27 April 2016)
 * Presentation Slides (PDF)

AIC Valet is distinct from OpenStack Valet. It is provided here for historical context and as inspiration for ongoing discussion. At the present time, AIC Valet is in the master branch of the OpenStack Valet repository. In the future, it is expected to move elsewhere, most likely back to att-comdev on GitHub, so that the code will remain open and available for perusal.

Get Involved
Step 0:


 * Read and uphold the OpenStack Foundation Community Code of Conduct.
 * Read and follow the OpenStack Project Team Guide. (While OpenStack Valet is not an official OpenStack project, the project is being led with this guide in mind.)

The unofficial PTL is Joe D'Andrea.

IRC
The developers use IRC channel  on FreeNode for development discussion.

Meetings
Weekly meetings have yet to formally begin.

Mailing List
Discussions about Valet occur on the openstack-dev mailing list. Please use the tag  in the subject line for new threads.

Comments and Advice
While at the Denver PTG, motivation for OpenStack Valet was shared with experienced OpenStack developers, project team leaders, and foundation staff. Herewith, in no particular order, is a compilation of comments and advisement following those discussions. Consider this a philosophical foundation for the development of Valet going forward.


 * Cloud infrastructures need to be more NFV and app aware in general.
 * Keep asking: What is the fundamental concept that makes Valet not just better but a no-brainer?
 * Seek out ever more use cases, lest Valet turn into a case of “solutions chasing problems.”
 * No matter what happens, Valet is worth exploring because other things will be improved along the way.
 * Coming at Valet "from above" vs. within a particular OpenStack project is a worthwhile approach.
 * Keep asking where the pain points are. Keep questioning why Valet exists at all, why it’s doing what it’s doing.
 * Establish and enforce boundaries. Be conservative in the content Valet produces, and liberal in what it accepts.
 * Do not wait for a production v1.0 version. Be aspirational and open first. Start with document-driven design. Socialize and iterate.
 * Strive for intuitiveness and a delightful user experience. Ultimately, Valet is not an end unto itself, only a means to an end.
 * Don’t rush. Take the time to measure twice, cut once. Heed Brooks’ Law.
 * Keep Valet as decoupled from other projects as possible. Provide an API and a means for infrastructure projects to voluntarily participate in the ecosystem.
 * In keeping Valet resource-inclusive, consider dealing in “resource archetypes” (similar to the normative types in TOSCA) that are not tied down to any one infrastructure.
 * Do not reinvent any wheels. Other projects are allies, not competitors.
 * Focus. Start with one specific use case. Do not take over the world. Set 3-4 milestones to get a MVP.
 * Look at two infrastructures from the outset (e.g., OpenStack and Kubernetes). This forces the issue of thinking in terms of hybrids.
 * Begin with aspirational doc-driven development. No code. It’s ok if it’s rough. Write and revise it all in the public eye.
 * Create architectural diagrams that show the relationships with other projects as though they already exist.
 * Write a discussion document addressing the representation of related resources (e.g., Heat templates, TOSCA, Helm, Terraform, ...).
 * Do not perform any inventory discovery. Assume the input contains all the info Valet will need.
 * Keep folks on various OpenStack teams apprised of progress. Publish to the OpenStack Wiki (hey, that's this site!).
 * Start weekly meetings on IRC so folks have a place to convene. Keep IRC “office doors" open.

With thanks to: Pete Birley, Jonathan Bryce, Chris Dent, Gautam Divgi, Chris Hoge, Kaustubh Joshi, Ed Leafe, Sean McGinnis, Masahito Muroi, Jay Pipes, Sampath Priyankara, Lauren Sell, Adam Spiers, Davanum Srinivas, Ildikó Váncsa, Ian Wells.

Related Projects
The following projects are of potential interest with regard to Valet:


 * Apache Mesos: Distributed systems kernel
 * Blazar: Reservation-as-a-Service for OpenStack
 * Cinder: OpenStack Block Storage service
 * Docker Swarm: Docker-native clustering system
 * Gantt: OpenStack Scheduler-as-a-Service (defunct)
 * Heat: OpenStack Orchestration service
 * OpenStack Helm: OpenStack deployment via Helm
 * Kubernetes: Container Orchestration
 * Magnum: Container Orchestration Engines as first class OpenStack resources
 * Nova: OpenStack Compute service
 * OPNFV: Development and evolution of NFV components across open source ecosystems
 * Tacker: OpenStack NFV orchestration
 * Terraform: Infrastructure as code
 * TOSCA: Topology and Orchestration Specification for Cloud Applications
 * Watcher: Resource optimization service for multi-project OpenStack-based clouds

Subpages
Any subpages with a prefix of  added to the OpenStack Wiki will be listed here.