openstack team mailing list archive

[Aimon Bustardo <abustardo@xxxxxxxx>]

Hi, inline:

On 2/9/11 10:38 AM, Eric Day wrote:
> 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.
I have seen another thread on this also "Multi Clusters in a Region ".
the URI based naming makes the most sense here and the actual name is
each child is free-form but must conform to acceptable URI characters
for optional DNS. The hierarchy is location based only in as much as you
make it.. its a hierarchy that you can build with zones and clusters.
This can be in one physical location or many, but it will always be a
collection of servers and services.  The hierarchical URI model fits
this perfectly and adds the benefit of being able to associate DNS with it.


Regards,

Aimon


>
> * 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-- 
Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | aimon@xxxxxx