Storage provisioning

[csarven]

Currently the Protocol does not describe the interface for storage provisioning.

Should there be an interface to provision storages?

What information is needed to create, update, delete or recover a storage? For example, owners, memory quota, availability, performance requirements, preservation strategy, and possibly initial data rights and processors..

What are the security considerations?

Who can provision a storage?

---

Currently servers provide one or more storages in an implementation defined way. Ditto tracking the owners of a storage.

The current definition of "owner" in the Protocol confines owner to a storage. The owners of a storage can't create other storages or delete their own storage, or have additional means to control or configure a storage.

[elf-pavlik]

IMO this could stay implementation-specific for now. When something gets defined in the future, I think Authorizon Agent we are specifying in interop spec, would implement the client-side part.

[acoburn]

We probably need a bit more implementation experience before specifying this endpoint, but it would be good to clarify some expectations.

Some initial thoughts based on implementation experience:

• There needs to be a discovery mechanism for this endpoint; how else does a client know where to send the request?
• While a user may supply a desired name for the storage, it is ultimately up to the server to provision a Pod at a certain URL. (The "Slug" header may be a nice mechanism for this)
• A server may want to constrain the number of storages a particular user can provision
• A server may want to constrain which agents are able to provision a storage
• The only hard requirement (IMO) is the Pod owner, which can be derived from an access token; everything else could be provided via optional parameters. For systems that bundle WebID, Pod and Identity Provider in a single system, making use of access tokens is both harder (a WebID resource may not exist yet) and easier (everything exists in a single system)
• POST seems like the obvious choice here (that is how we have implemented this endpoint)
• If a user's WebID is separate from the storage(s) provisioned by a server, it is useful for a user to have a mechanism to fetch a listing of those storage URLs that have been provisioned.
• The mechanism for de-provisioning a Pod needs careful consideration -- it cannot simply be an endpoint that any arbitrary app can call

[dmitrizagidulin]

+1 to not tackling this yet. Nowhere near ready to standardize.

[NSeydoux]

+1 that this is is something to consider on the long term. It may be to some degree a duplicate of #152, or at least it's related to this issue, but I created it a long while ago so the ecosystem has changed quite a bit since then, and not as much as my understanding of it, so it's to consider with a pinch of salt ^^

[justinwb]

From an implementation standpoint, my organization's software currently has to maintain special support for storage provisioning for each server type. This is not ideal, and likely to become more problematic over time. +1 to tackling this, but I agree that it doesn't have to be top priority yet.

[csarven]

Meta: I've created this issue with the understanding that this feature may need to be described, and to get a sense from the group about it. Thanks to all for responding / confirming.

As for its priority, there was nothing about its urgency or whether all the related requirements are worked out - understanding that is part of the process. (I thought the set of questions and the issue label would be a hint). There are many issues that hang around until the time is right - waiting for other dependencies/questions to be addressed, implementation experience backed by legitimate use cases, demonstrable use, having people with relevant expertise working on it, and so on.

We seem to share the value of implementation experience - taking the comments on this issue as proof FWIW: immediately vocal about not spec'ing yet - but at other times some of us insist on prematurely redesigning everything with zero implementation experience to show or even the slightest interest to implement anything.