The email thread with the subject "[RFC] OpenStack Programming Model Framework" from Jan 3rd covered a few ground proposals for OpenStack projects, mainly with a focus on API. I'd like to expand on this a bit more.
I think everyone in is in agreement that each service should default to a REST API except for some end-user communication depending on the service (for example, MySQL or PG protocol for database services). Admin, provisioning, and any other gaps in functionality not encapsulated by these application specific protocols should be filled in via REST calls. There is other common functionality we should consider for OpenStack services. We don't need anything too formal, just a "best practices" document that can change with time. This will hopefully also drive openstack-common projects for chosen languages so we can encourage code sharing between projects (although not required). The main candidates for discussion are: * Authc/authz/access - We had a marathon thread about this the other day, not much more to say. I think there is consensus that auth needs to be pluggable for all services and be flexible enough to accommodate various organizational structures. * Zones and Location URIs for all objects - I think we'll all agree that when working with distributed services, location becomes very import. Issues like bandwidth limitations, latency, and location redundancy are top priority. Swift is already very aware, and work is underway in Nova, but I believe there will be a huge value in making a common location format across services. For example, being able to make requests like "launch a nova instance near this swift object", or if we have a queue and database services, "run these queue workers near a copy of this database". In an effort to keep things simple, I propose we simply assign URIs to all zones and objects across services. These would be dynamic, as objects can move around due to fail-over, rebalancing, and so forth. It would be up to the API consumer to request locations (with some reasonable TTL) before using them. What does this mean for services? Just have a 'location' attribute for every zone and object (Swift object, nova instances, nova volume, ...). The URI does imply a dotted hierarchy in order to perform suffix matching (for example, zone cage1.dc1.north.service.com would match for *.north.service.com requests). We could keep this field completely free-form and make the location generation/matching pluggable, but URIs seem to be pretty ubiquitous. DNS entries for these URIs are possible but not required. * Firehouse - So far we've not discussed this too much, but I think when we did there was agreement that we need it. As more service come into the picture, we want the ability to combine and multiplex our logs, events, billing information, etc. so we can report per account, per service, and so forth. For example, as a user, I want to be able to see the logs or billing events with all entries from all my services (or filter by service), but as a sysadmin I may want to view per service, or per zone. We may have registered handlers to grab certain events for PuSH notifications too. To maintain maximum flexibility across deployments we need keep the interface generic, the payload can be a JSON object or some more efficient serialized message (this can be pluggable). The only required fields are probably: <timestamp> <service> <account_id> <blob> Where <blob> is a list of key/value pairs that handlers can perform routing and processing on. For a logging event, blob may be "priority=ERROR, message=oops!" or "priority=information, message=instance X launched". We can keep things really simple and flexible, relying on a set of documented common attributes that common event producers, routers, and handlers can key in on. Thoughts? -Eric _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
