Skip to content
This repository has been archived by the owner on Mar 25, 2018. It is now read-only.

OpenStackExtensionsMeeting1

Jump to bottom
jclouds edited this page Jan 31, 2012 · 2 revisions

jclouds OpenStack and extensions API

  • fix server object + move openstack-nova to org.jclouds.labs groupId
  • stable/Diablo (2011.3.1) start version for openstack-nova
  • stable/Essex (2012.1) start version for keystone
  • first priority is keystone service api (potential hack-day monday)
  • what’s needed to get HP cloud available to users (ETA March 3)
  • fishing for an extension to play with and cycle each week or two

Notes on OpenStack releases

  • keystone milestone builds have only been run twice (inc. 2012.1)

  • consider that keystone is required

    • diablo stable uses keystone (not all versions, but latest)
    • essex uses keystone
    • Ubuntu 11.04 UEC default packages make it difficult to deploy nova w/o keystone
    • HP Control services will support some keystone functionality and need to extend the impl

  • extension use cases

    While using jclouds portable ComputeService, we need to establish a load balancer. User’s code could employ a LoadBalancer extension if exists, or revert to setting up an HAProxy cluster Choose between mulitple network extensions available in Nova (Quantum and something else) Provide a convenient way to aggregate extensions known to available on a Nova provider ex. HP Cloud will have a know set of extensions, so users may find it easier to us typed references as opposed to looking up things. (ex. novaClient.getLoadBalancerServices() vs context.findExtension(LoadBalancerServices.class); Test experimental extensions... (ex. load nova jclouds-1.3.0 w/ quantum-1.4.0-SNAPSHOT)

  • how do we deal with “experimental” extensions?

    For example, not all ideas live to production, or rather can change rapidly currently we use sandbox, which isn’t published anywhere we could use a different maven groupId ex. org.jclouds.experimental or sandbox -- this acknowledges that maven artificas stick around forever current approach used for proof point

  • extensions to commands

    ex. server-side filters in an extension which could reduce network calls dramatically check grid jsr (they probably have to deal with this directly as not all grids support ex. distributed exection..) might be a decision point about whether the user would even use the cloud for lack of such support currently, this is hard-coded in a way. ex. listXX ‘strategy’ is subclassed in providers that have a different approach limits are user-filters are opaque and not necessarily passable to the end server as yet

  • how do we decorate (mix/in) existing models? Context: extra namespaced field in get server response "RS-CBS:volumes": [ { "name": "OS", "href": "https://cbs.api.rackspacecloud.com/12934/volumes/19" }, { "name": "Work", "href": "https://cbs.api.rackspacecloud.com/12934/volumes/23" } ]

    currently we do this static. ex AWSRunningInstance vs RunningInstance This implies there’s only 1 weave of extra data bind(RunningInstance.class).to(AWSRunningInstance.class) or similar... assumes we know up-front another way is to produce alternate views of an object currently, we have a similar issue in portability as we have had many discussions about the “provider-specific” object. ex. nodeMetadata.getProviderSpecificObject(); there’s getRaw() somewhere in jsr 107 in rest apis like vCloud, there’s a rel=”alternate” view << should consider tie-in with portable models. ex. lb extenstion may know how to add data to nodemetadata portable object and/or implement a strategy. ex. Server is base type, and an extension can extend this to include more data? how do we do this? lbExtension.render(server).getPublicPool() or.. nodemetadata.getViews().. query

e.g. Server.getExtension(FancyService.class) shortcut for getAvailableExtensions().findFirst { ExtensionMetadata it -> it.hasExtension(FancyService) }

ExtensionMetadata.adaptableTypes()? this could return Server.class? lbExtension.adapt(server) = instanceof LBServer

lbetensionimpl. bind(Function Type<Server, LBServer> to ServerToFancyServerAdapter // in case the user doesn’t know the type they will receive.. (ex. might be handy in implementing portable features like registerNodeOnLBPool.. bind(Function Type<Server, Server> to ServerToFancyServerAdapter

OR: myFancyServer = context.getExtension(ServerToFancyServerAdapter.class).adapt(myServer)

  • considerations for extensions
  • http://docs.openstack.org/api/openstack-compute/1.1/content/Extensions-d1e1444.html
  • similar to how we handle AWSEC2Client vs EC2Client, where some apis are subclasses and others are new or currently unique to the service (ex. IAM was unique to aws-ec2 until eucalyptus 3)
  • not necessarily possible to know about all extensions up front
  • some endpoints will have a subset or no extensions
  • Approach 1: ExtensionMetadata, and generic params define async/sync interfaces
    • we could make a typesafe extension interface ex. ExtensionMetadata<S,A>
    • where S is something like BlockStorageClient and A is BlockStorageAsyncClient
    • discovered by Map<String, ExtensionMetadata<S,A> getAvailableExtensions();
    • could be loaded by NovaClient S findExtension(ExtensionMetadata<S,A> extension); 
    •              or NovaAsyncClient <A> A findExtension<ExtensionMetadata<S,A> extension);

    •     -- for unsafe --          Object findExtensionNamed(String name);

    •                               // better than hiding the unsafe cast (ex. <S> S)

    •                               --- context.utils().injector().getInstance(Class<S> type);
  • Approach 2: Users directly user Extensions, as they are inclusive of both metadata and impl
    • discovered by Map<String, Extension<S,A>> getAvailableExtensions();
    • could be loaded by NovaClient S findExtension(ExtensionMetadata<S,A> extension); 
    •              or NovaAsyncClient <A> A findExtension<ExtensionMetadata<S,A> extension);

    •     -- for unsafe --          <S,A, E extends Extension<S, A>> E findExtensionNamed(String name);
  • how do we load implementations of extensions?
  • on portable use of extensions (i.e. outside Nova-specific classes)
    • could use Extension in a similar fashion for portable functions, ex. LoadBalancer in ComputeService
    • in EC2 for ex. the extension is ElasticLoadBalancer, whereas in vCloud etc, might be F5Service
      • remember even openstack will have multiple competing extensions for the same functionality (ex. network services)
    • the portable abstraction will need to support functional groups such as Firewall, LoadBalancer, etc. and we should think about how these concepts relate and/or can be discovered.
      • balance this against addition meta-complexity

CodeGen/Dynamic use of extensions:

  • there will be extensions that either the user hasn’t loaded an impl for, or one hasn’t been written yet.
  • there’s likely to be a slowing of extension development alongside the increased openstack governance
  • currently, wadl is exposed to help generate or describe structure and operations for REST apis https://wikis.oracle.com/display/Jersey/WADL
  • jersey can render wadl for endpoints and there is a wadl2java tool somewhere
  • wadl generation has similar complex graph risks as similar SOAP tools (should check and see how bad this is)
Clone this wiki locally