The OpenStack APIs. George Reese, Senior Distinguished Engineer! 5 November 2013

Transcription

1 The OpenStack APIs George Reese, Senior Distinguished Engineer! 5 November 2013

2 Background Creator of Dasein Cloud! Open Source Java cloud abstraction API ( Interacts with nearly 2 dozen cloud APIs! Author of The Rest API Design Handbook! General critic of the OpenStack APIs since the beginning 2

3 Please keep in mind I believe OpenStack APIs are among the most elegant API suites in the cloud computing world.!! Any criticism has the goal of improving them. 3

4 and the basic premise The primary job of a RESTful API is! to expose all high-level functionality of the system! without bias towards specific use cases! based on abstractions that hide the implementation details and NEVER BREAK CLIENT CODE 4

5 A Brief Tour of the OpenStack APIs 5

6 Overview Not one API, but many APIs! Keystone, Nova, Swift, etc. are all independent APIs! They generally have similar structure! The Swift API is the most dissimilar! (Generally) faithful to RESTful principles! JSON and XML payloads! You pick through content negotiation 6

7 It starts with Keystone Keystone is a service catalog! Two OpenStack environments likely support different services! The service catalog enables you to discover what services a given OpenStack environment supports! Keystone is an identity/auth service! Acts as a secure token service! Authenticates clients and provides tokens! To get started, authenticate 7

8 After Keystone, the service APIs Swift! Nova + extensions! Glance! Cinder! Neutron! Ceilometer! Custom services 8

9 Keystone and the OpenStack Security Model 9

10 POST an authentication payload Endpoint: keystone URI + /tokens!! POST \ v2.0/tokens \ HTTP/1.1 Content-Type: application/json! { auth":{"rax-kskey:apikeycredentials": {"username":"user","apikey":"api_key"}}} 10

11 Response A token to use in any subsequent API calls! A service catalog identifying supported services and versions of those services! {"access": { token": {"id":"lalalalaiwontshowyouhahaha", "expires":" t02:42: :00", "tenant":{"id":"555121","name":"555121"}, "RAX-AUTH:authenticatedBy":["APIKEY"]}, "servicecatalog :[] etc 11

12 Using the token Cache the token and provide it in all service API calls! GET dfw.servers.api.rackspacecloud.com/v2/ TENANT/flavors/detail HTTP/1.1 Content-Type: application/json X-Auth-Token: LALALALAIWONTSHOWYOUHAHAHA Be prepared to re-authenticate 12

13 But there is no standard payload And no discovery process! HP: accesskey/secretkey! Rackspace: username/apikey! Other: username/password! And sometimes you need a tenantid And sometimes you don t! Or sometimes you need the tenantname 13

14 And all the world isn t Keystone Older environments won t have Keystone! Direct Nova or Swift authentication! No a priori mechanism for discovery! Some environments through Essex mix and match! Trick: try both! If the endpoints ends with 1.0 or 1.1, try Nova authentication then Keystone! Otherwise, try Keystone then Nova 14

15 Versioning 15

16 How version negotiation works Keystone provides you with the list of supported services and the list of API versions you can use to interact with those services! Your client can use any supported version to speak with a given service at the endpoint specified 16

17 OpenStack versioning is a living hell Ideally! Keystone should be highly standardized across installations! Keystone should authoritatively identify what services and what versions of the APIs for those services are supported! But! Older versions of Keystone are an absolute mess! There s no fixed version when Keystone works! The same service has many identities in Keystone 17

18 Core, Nova extensions, and custom services 18

19 Supposedly OpenStack supports a core set of APIs with the ability to easily integrate APIs in support of non-core services! ROFL ROFL ROFL ROFL ROFL ROFL ROFL ROFL! ROFL ROFL ROFL ROFL ROFL ROFL ROFL ROFL! ROFL ROFL ROFL ROFL ROFL ROFL ROFL ROFL! ROFL ROFL ROFL ROFL ROFL ROFL ROFL ROFL! ROFL ROFL ROFL ROFL ROFL ROFL ROFL ROFL! ROFL ROFL ROFL ROFL ROFL ROFL ROFL ROFL 19

20 Core API example: Nova Catalog entry! {"name":"cloudservers","endpoints":[{"tenantid":"tenant","publicurl":" servers.api.rackspacecloud.com\/v1.0\/tenant","versioninfo":" servers.api.rackspacecloud.com\/v1.0","versionlist":" servers.api.rackspacecloud.com\/","versionid":"1.0"}],"type":"compute"} Request/response! GET HTTP/1.1 Content-Type: application/json X-Auth-Token: LALALALAIWONTSHOWYOUHAHAHA HTTP/ OK Date: Mon, 04 Nov :48:54 GMT Content-Length: 4156 Content-Type: application/json X-Compute-Request-Id: req-23551d9b f5-ac50-82c09d Server: Jetty(8.0.y.z-SNAPSHOT) {"servers":[{{"status": "ACTIVE", "updated": " T01:45:42Z", "hostid": some_host_id,: "bookmark"}]}, "created": " T01:43:45Z", "tenant_id": "TENANT", "OS-DCF:diskConfig": "AUTO", "accessipv4": " ", "accessipv6": "2001:4800:7810:512:ba57:a687:ff05:5745", "progress": 100, "OS-EXT-STS:power_state":1, /* more stuff not shown */]} 20

21 Non-core API example: Cloud DNS Catalog entry! {"name":"clouddns","endpoints":[{"tenantid":"tenant","publicurl":" dns.api.rackspacecloud.com\/v1.0\/tenant"}],"type":"rax:dns"} Request/response! GET HTTP/1.1 Content-Type: application/json X-Auth-Token: LALALALAIWONTSHOWYOUHAHAHA HTTP/ OK Content-Type: application/json Via: 1.1 Repose (Repose/2.7.0) x-api-version: Content-Length: 248 Date: Mon, 04 Nov :16:08 GMT Server: Jetty(8.0.y.z-SNAPSHOT) {"domains": [{"name":"dasein6483.org","id": ,"comment":"dasein Cloud Test Zone", "updated":" t03:15: ", "created":" t03:15: "}], "totalentries":1} 21

22 Compute extension API example: Nova Volumes Catalog entry: no such thing! Request/response! GET HTTP/1.1 Content-Type: application/json X-Auth-Token: LALALALAIWONTSHOWYOUHAHAHA HTTP/ OK Content-Type: application/json {"volumes": [ { "id": "521752a6-acf6-4b2d-bc7a-119f9148cd8c", "display_name": "vol-001", "display_description": "Another volume.", "size": 30, "volume_type": "289da7f c-9fb4-7db01ec49164", "metadata": {"contents": "junk"}, "availability_zone": "us-east1", "snapshot_id": null, "attachments": [], "created_at": " T20:53:07Z" } 22

23 Problem #1: Nova Volumes -> Cinder OpenStack exposes the implementation of volumes to via the API no abstraction! Programmatically ugly to determine if a cloud has one of the following possible configurations:! Nova volumes! Cinder! Neither! Upgrades pointlessly broke existing code 23

24 Problem #2: FrankenQuantum Nova networks?! Neutron?! Rackspace FrankenQuantum?! private enum QuantumType { NONE, RACKSPACE, NOVA, QUANTUM; public String getnetworkresource() { } } switch( this ) { case QUANTUM: return "/networks"; case RACKSPACE: return "/os-networksv2"; case NOVA: return "/os-networks"; } return null; 24

25 The API War 25

26 The facts about the AWS APIs AWS! has a huge base of proven third-party tools! has never broken deployed client code, ever! is supported in nearly every cloud storage system! is very opinionated in how it models cloud! is an ugly looking, non-restful API! is very complex to mimic in a transparent manner! Resource ID mess! Undocumented behavior 26

27 The facts about the OpenStack APIs The OpenStack APIs! are elegant and largely consistent with each other! have moderate ecosystem support! constantly break client code! are controlled by the OpenStack community! best model OpenStack cloud concepts 27

28 And so We need to support BOTH APIs! The AWS APIs! Give us access to the full range of third-party ecosystem tools! Limit the ways in which we can model cloud computing concepts! Are expensive to support properly! The OpenStack APIs! Give us control over our cloud computing model 28

29 Questions? 29