Minutes 2021 05 27

SNIA Cloud Storage Technical Working Group

Meeting Minutes, 2021-05-27

1. IP Statement:

“You are hereby informed that, under the SNIA IP Policy, your presence at this meeting may obligate you and/or your company/organization with respect to any of the work items of the SNIA Cloud Storage TWG.”

2. Attendance

Attendees: See Causeway listing

Guests: None

3. Agenda review

No changes to agenda

4. Previous meeting minutes review and approval

N/A - No minutes from last meeting

5. Work on agenda and meeting minute templates

Decision is to keep agendas and minutes on Github's "wiki" feature in addition to Causeway, in order to provide accessibility for regularly attending guests.

We will use the previous week's agenda/minutes as a template for the next week's agenda/minutes.

PDFs will be created and uploaded to Causeway to satisfy the new SNIA requirements for agendas and minutes.

Wiki pages have been created for this week's agenda and minutes.

6. Discussion re. approaches to container/object duality changes

https://github.com/SNIA/CDMI-spec/issues/248

Summary of the problem

• One of CDMIs goals is to provide a superset data representation of common storage data representations (e.g. file, object, etc), such that it has utility for date mobility. Specifically, if a storage system has a way to represent data that cannot be easily represented in CDMI, this makes data interchange with that system difficult.
• A concrete example of this is that S3 is a key/value store, not a hierarchical store. Thus, when S3 is used to emulate a hierarchical store, object names are permitted that are forbidden in CDMI.
• E.g. ".", "..", "/", "../?/*", etc.
• In order to allow CDMI to represent these objects, we need to relax the restrictions that prevent these objects from existing, while still providing compatibility with hierarchical storage systems.
• This is an enabler required to fully support S3 exports (https://github.com/SNIA/CDMI-spec/issues/283).

Previous discussion

• In previous years, we have called this issue "container/object duality", since we can have a situation where in one system, it is a container, while in another system, it is a data object.
• The current proposal on the table is to allow containers to also be data objects, depending on how it is accessed (indicated by the Media Type)
• This means that only applications that need to store data in containers or access data in containers need to know how to do so.

Investigation

Most fields in CDMI Container Objects and CDMI Data Objects are common.

The following fields are only found in Container Objects:

"exports" : {},
"childrenrange" : "0­-4",
"children" : [ ... ]

The following fields are only found in Data Objects:

"mimetype" : "text/plain",
"valuerange" : "0-­33",
"valuetransferencoding" : "utf­8",
"value" : "Second version of this Data Object"

In addition, data objects and container objects have some storage system metadata items that are different:

"cdmi_size" : "34",

Plus versioning metadata.

In the proposal, CDMI objects can contain either or both of these fields, but only the appropriate fields are accepted/returned based on the media type selected.

So if an object "/test/" is accessed as a container (which is the default, due to trailing slash), container object fields would be returned. However, if "/test/" was accessed using the media type of "application/cdmi­-object", data object fields would be returned. At no time would an external user see both data object and container object fields in the same request.

• Container objects, when accessed as data objects, would have the following defaults: valuerange of 0-0, a mimetype of application/octet-­stream, a valuetransferencoding of base64, and an empty value string.
• Data objects, when accessed as container objects, would have the following defaults: childrenrange of 0-0, an empty children array, and an empty exports object.

Further discussion will continue in the next meeting

7. Prepare agenda for next meeting
8. Summary of any planned major votes at next meeting
9. Adjournment