Open Stack

John,

Just catching up on things and wanted to provide a couple of thoughts. 

First and foremost, thanks for this. It is very comprehensive and helpful in understanding the Swift capabilities. It is so helpful having the PTL involved in how we are deciding what goes into core.  As mentioned earlier, the next big step is how we test/validate the capability.

The second point would be to ask that you consider what level of capability granularity make sense as we are scoring and evaluating options. I expect many of the capabilities outlined below don’t make sense in isolation. I would guess that there are some basic account functions that are really required for base operation. There are probably others that truly are add-on or separate functions. 

Some refinement of this is helpful on two fronts. First, it reduces the complexity of the analysis. One reason we moved from “voting” on individual tempest tests to focusing on capabilities was to reduce the number of items we are considering down to a more manageable number. Obviously, we don’t want to over do that - but it is helpful where we are reduce. Secondly, we don’t want to end up in a situation where core is unusable because some key capability is left out because in isolation it isn’t elevated to core status because of the criteria system when in reality it can’t be thought in isolation.

For instance, it seem like any base implementation of swift probably needs the *’d items below for accounts to essential operate. (I’m on a limb here because of superficial knowledge of swift - so I could also be completely wrong.) It might make more sense to group all/some of these under a basic “account” capability vs try and score them separately. That was a similar idea to group basic server calls into a generic “compute-server” capability.

Anyway, give it some thought.

Troy

On May 19, 2014, at 4:32 PM, John Dickinson <me at not.mn> wrote:

> Sitting on the plane to Atlanta last week, here's my first draft of a "Swift core capabilities" list:
> 
> account
> --
> user-defined metadata
> *ordered listings on containers, with marker limit, prefix, end_marker
> *aggregate number of containers
> *aggregate number of objects
> *aggregate total bytes used
> independent read and write ACLs
> *json, xml, and plain text listings
> system-level metadata
> *create
> *delete
> domain remap
> cname lookup
> 
> container
> --
> user-defined metadata
> ordered listings of objects, with marker, limit, delimiter, prefix, end_marker
> number of objects
> total bytes used
> independent read and write ACLs
> listing ACLs
> quota usage
> versioned writes of objects
> container sync
> json, xml, and plain text listings
> create
> delete
> CORS
> static website hosting
> domain remap
> cname lookup
> 
> object
> --
> user-defined metadata
> read
> write
> delete
> update metadata
> server-side copy
> dynamic large objects
> static large objects
> tempurl
> bulk upload (ie upload a tar, optionally compressed)
> bulk delete
> single range requests
> multi-range requests
> upload from html form
> time-expiring objects
> 
> system
> --
> crossdomain.xml support
> discoverable constraints
> list storage endpoints
> object name filters
> multiple auth system integration
> middleware extensibility
> healthcheck endpoint
> 
> management
> --
> drive failure transparent to the client
> server failure transparent to the client
> rack (zone) failure transparent to the client
> DC (region) failure transparent to the client
> swift recon
>     async pending
>     replication stats
>     auditor stats
>     updater stats
>     expirer stats
>     unmounted drive check
>     disk usage stats
>     load average stats
>     quarantined data stats
>     socket usage stats
> change capacity with no downtime
> upgrade with no downtime
> statd metric reporting (hundreds of metrics here)
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140527/a3b05b29/attachment.pgp>