Jump to: navigation, search

Difference between revisions of "Valet"

m
m (Motivation)
Line 19: Line 19:
 
This leads to the following tenets:
 
This leads to the following tenets:
  
* Be infrastructure ''agnostic'' and resource ''inclusive''.
+
* Be infrastructure ''agnostic''.
 +
* Be resource ''inclusive''.
 
* Be ''holistic''.
 
* Be ''holistic''.
 
* Be ''data-driven''.
 
* Be ''data-driven''.

Revision as of 20:24, 4 October 2017

Valet

Valet (noun):

  1. A cloud infrastructure-agnostic, resource-inclusive, holistic, data-driven 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.
  • 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 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, in a holistic manner, and in consideration of an entire application vs. one resource at a time.

Code and Presentations

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.

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.)


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


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 near future, it may be moved to a separate branch, or possibly moved back to att-comdev on GitHub. Either way, the code will remain open and available for perusal.

Get Involved

Step 0: Read and uphold the OpenStack Foundation Community Code of Conduct.

The unofficial PTL is Joe D'Andrea (@jdandrea).

IRC

The developers use IRC channel #openstack-valet on FreeNode for development discussion.

Meetings

Weekly meetings are to begin in October 2017.

Mailing List

Discussions about Valet occur on the openstack-dev mailing list. Please use the tag [Valet] 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 "Valet/" added to the OpenStack Wiki will be listed here.