Page History

Jakub Moscicki

Massimo Lamanna

CERN

Project management

A, R

Committed

Frank Karlitschek

Christian Schmitz

ownCloud Inc.

Project management

A, R

Committed

Charles du Jeu

David Gillard

Contribute to the specifications and development

Rogier Spoor

SURFnet

Contribute to the specifications and development

R, C

Ron Trompert

SURFsara

Contribute to the specifications and development

R, C

Committed

Christoph Herzog

Simon Leinen

SWITCH

Contribute to the specifications and development

R, C

Committed

Guido Aben

David Jericho

AARNet

Contribute to the specifications and development

R, C

Committed

Holger Angenent

Sciebo / Uni Münster

Contribute to the specifications and development

R, C

Committed

David Antoš

CESNET

Contribute to the specifications and development

R, C

Committed

Frederik Orellana

DeIC

Contribute to the specifications and development

R, C

Kurt Bauer

ACOnet

Contribute to the specifications and development

R, C

Christian Kracher

Jari Miettinen

CSC/Funet / EUDAT

Contribute to the specifications and development

R, C

Benedikt Wegmann

Ralph Krimmel

Hrachya Astsatryan

Andranik Hayrapetyan

Wahi

Initiation

Pick up the results on Phase I.

See section 4.2 Deliverable of Phase I. below...

Create the new structure of two WGs:

1. Strategic WG ocm-admin@lists.geant.org
2. Technical WG ocm-tech@lists.geant.org

Assign mailing lists above

All: ocm-all@lists.geant.org

• [ACTION] Christian to send a questionnaire to all known ownCloud instance admins.
• [ACTION] Holger to prepare simple admin instructions on how to check usage and status.

• Repeat the Zurich demo but with more domains and more interesting use cases.
• Demonstrate the interest and if possible the active participation of vendors other than ownCloud Inc.

ownCloud v.8.2 or higher: Uni Münster, Uni Vienna, AARnet, SWITCH, CESNET, GWDG

Others very close: SURFnet, CERN

Pydio  v.x?: ASNET-AM, University of Lausanne (TBC)

Locate other vendors and identify user cases, universities with two products and cross-sharing needs.

18-02-2015 News from Christian:

Pydio will most likely join OCM. They are actually aiming for test implementation by end of March.

16-03-2016

Charles du Jeu and David Gillard from Pydio (https://pydio.com/) joined the OCM project.

Charles, the CEO/CTO of Pydio, confirmed that that are preparing the release of an important dev version, that actually contains the Federated Sharing API implementation. See https://pydio.com/en/community/releases/pydio-core/pydio-core-631-development-release for more info. Pydio is making its best to have this release transformed to a stable one by the end of this month.

Christian Schmitz

Peter Szegedi

29-03-2016 OCM call at 2pm CET

1) Charles (Pydio) demonstrated via screen-share the OCM functionality that has been implemented by Pydio in their software. Federated sharing of files was shown between two local independent instances of Pydio v.6.4.0.(to be released on 30 March) running locally.

Comments:

• Server name and user name must be defined separately. Should work with username@domain@servername (TBC)
• Shared files are kept in a tree separate from the local file tree (this topic is also being discussed by the OCM community)

2) Charles (Pydio) and Frank (ownCloud) also tested the interoperability (technical feasibility) of the OCM protocol implementations between Pydio v.6.4 and ownCloud v.9.0 offline. It was reported successful but yet to be seen...

Charles du Jeu

David Gillard

Frank and Lukas

Multi-vendor OCM validation by the Community

ownCloud - Pydio

1) AARNet (Guido) initiated some initial testing with ASNET-AM (Hrachya)

AARNet (Australia) uses ownCloud and ASNET-AM (Armenia) uses Pydio.

• Results to be seen...

2) More Pydio users and test scenarios to be defined (see 3.1)

• RENATER and University of Lausanne to be contacted...

Guido Aben

Hrachya Astsatryan

Andranik Hayrapetyan

Wahi

Booth demos: ownCloud, Pydio?, Interoperability demo at GÉANT bootkbooth

Lightning talk by Guido Aben: submitted and approved

DEMO IDEAS:

• SURFNet: currently stuck with the Shibboleth issue with ownCloud 8
• CERN: needs ownCloud 9 fully deployed and operational (sharing module is not in maintainable/fixable state as of ownCloud 8)
• Others...

Christian Schmitz

Guido Aben

Start collecting organizations and people interested in joining the initiative.

Peter Szegedi

Christian Schmitz

ownCloud to release the first version of the API code and documentation.

DELAYED

Code v.0.002 has been released on 27 July 2015 by ownCloud Inc.

Comments have been provided by CERN.

VC for coordination on 24 August 2015.

• Concluded in the Communique GSec(15)015.

Pre-launch meeting organized by ownCloud on 28 August 2015 in Berlin. Peter (GÉANT), Guido (AARnet) and Kuba (CERN) and others.

• Code v.0.002 released and commented
• Christian as an interim leader
• GÉANT to provide the project framework
  • Find the neutral project lead, co-chairs from the community.
  • Approach other vendors: PowerFolder, W3C, Pydio, Cozy
    
  • Put it in the GÉANT procurement requirements (the support for the API)

NIF/PID to be submitted and mailing list migration to be done.

Kick-off meeting: 22 October, 2015 in Vienna, Austria

The slides of the event can be found here.
password edu221015

Peter Szegedi

Christian Schmitz

DRAFT protocol definition v.0.004 released

OpenCloudMesh = ownCloudMesh

Uni Münster server-to-server sharing (i.e. federated cloud sharing) feature has been demonstrated by Holger to Kuba and Peter.

There was an agreement to

• plan for a new demonstration between two administrative domains, say SURFnet or CERN and Uni Münster.
• collect a list of feature requests related to the function (to be discussed with ownCloud)
• think about trust policies and quality assurances in the context of federated cloud sharing.

Comments from Kuba:

• quality of service: in the current owncloud implementation a remote share enters into the discovery process for synchronization - unstable or poorly-performing remote instance may impact users of the local instance
• authorization: a service manager should be in some control of which cloud instances can issue external shares requests for their users [there is plenty of room for abuse there, in addition this is amplified by the synchronisation of such injected shares on the user’s devices]
• security: it is not clear how secure the federated sharing mechanism currently is under-the-hood
• open protocol: is there a bottom-up interest in OCM being embraced by other sync/share software stacks?

We are looking for volunteers with ownCloud server version v.8 or above to test the feature.

Ron, SURFsara pointed out the the Federated Cloud Sharing feature does not work together with SAML/Shibboleth based authentication. This is a showstopper for a planned SURFdrive - Uni Münster demonstration.

Ticket has been created: https://github.com/owncloud/core/issues/21227

ownCloud is working on a quick work-around. FCS just needs a user name.

Partners to demonstrate Federated Cloud Sharing on 19 January 2016:

• Uni Münster (local users)

h_zimm01@uni-muenster.de@uni-muenster.sciebo.de
a_wilm04@uni-muenster.de@uni-muenster.sciebo.de

• AARnet (remote users)

david.jericho@aarnet.edu.au@cloudstor.aarnet.edu.au/plus
guido.aben@aarnet.edu.au@cloudstor.aarnet.edu.au/plus

• Uni Vienna (remote user)

krachec6@ucloud-test-files.univie.ac.at

Demonstration has been successfully done:

1. Holger at Uni Münster shared a folder with Guido at AARnet (federated cloud sharing).
2. Holger at Uni Münster shared a folder with Andres at Uni Münster (local sharing).
3. Christian at Uni Vienna shared a folder with Holger at Uni Münster (federated cloud sharing).
4. Simon at SWITCH shared a folder and sync files with Holger at Uni Münster (federated cloud sharing).

Holger Angenent

Andreas Wilmer

Ron Trompert

David Jericho

Guido Aben

Christian Kracher

Simon Leinen

19 January 2016

Two main topics have been identified (18 November 2015)

1. Trust policy: What level of trusted relationship is needed to be established and maintained between two administrative cloud domains in order to share files and folders among their users.
2. Quality assurance: What service level assurances are needed to be agreed and verified between two server operators in order to maintain the integrity and scalability of shared files and folder inside or outside of the users' file system.

Mind map (15 January 2016):

Kuba at CERN talked about the open issues and Simon at SWITCH talked about the standardization aspects

(19 January 2016)

Kuba: http://cs3.ethz.ch/presentations/Interoperability/02Moscicki.pdf

Simon: http://cs3.ethz.ch/presentations/Interoperability/04Leinen.pdf

Jakub Moscicki

Simon Leinen

All

Open API v.1.0 documented and released at least in BETA version with the intention to come up v.2.0 vendor agnostic version (IETF WG)

Cloud Services for Synchronization and Sharing (CS3) Workshop

ETH Zürich, Switzerland; January 18-19 2016

http://cs3.ethz.ch/program.html

Slides and presentation/demo materials are available!

              Praying for OCM to work...

Peter Szegedi

Christian Schmitz

Kuba Moscicki

Simon Leinen

Set of recommendations:

Integration with Macaroons

• authz/authn: Google macaroons (http://research.google.com/pubs/pub41892.html)

Cloud user lookup service

• Need @ a @ simple @ username @ structure
• endpoint discovery: DNS

David:

• Rather than trying to implement a meta-data or negotiation server, why don't we just use the NAPTR/SRV DNS RR method I proposed late last year? Multiple records, one for each protocol, makes discovery and announcement very easy, and allows the sites to use different endpoints for different protocols as suited.
  Something akin to:

  _standard._opencloudmesh._tcp.cloudstor.aarnet.edu.au. SRV 0 0 5009 ocm.cloudstor.aarnet.edu.au.

  _quic._opencloudmesh._udp.cloudstor.aarnet.edu.au.     SRV 0 0 5009 quic.cloudstor.aarnet.edu.au.

  _ftp._opencloudmesh._tcp.cloudstor.aarnet.edu.au.      SRV 0 0 5011 ocm.cloudstor.aarnet.edu.au.

  ...and so on. Discovery and compatibility is known by simple DNS query, and dynamically configurable using existing standards and tools. Supporting new protocols becomes a server side issue, rather than having to make any additional software aware.

Protocol negotiation handshake

Holger:

• What would you think of a signaling mechanism, comparable to the handshake when handling the method for an encrypted connection? We think of something like: Server A asks server B for a connection and offers WebDAV and CMIS and asks server B which of these it likes. Server B speaks only WebDAV so they agree to use this. Of course it is clear that now it could happen that both servers do not offer a matching method. But the acceptance threshold to participate at OCM could be lowered since only the signaling would be mandatory.

David:

• At least if the mandate was WebDAV for the most basic method, that would be the lowest barrier to entry. WebDAV has been around since 1996, and it really doesn't extend existing HTTP that far, there's no real excuse for not implementing it. A technical person is able to talk to a service using telnet/netcat/socat and do sharing functions manually, as well as making it simple to do these things programmatically using curl. Metadata against the query is also trivial, because HTTP/(1.1|2) support headers that can be used to carry all the relevant information.

• Caching should be a secondary consideration, because it's a non-trivial activity to get right (consider HTTP caching and HTTP 304 return codes). Our primary concern is fast transfer, reliable transfer, and having people join in. In the case of many small files, many alternate protocols allow streaming, batching or the like, akin to the old days of asking a ftp server for a tar of a directory.

Security and Trust

• Trusted curcle of servers vs. open internet policy
• Verification of architectures and deployments up to a community standard. DeiC's Smashbox idea
• More admin features are in 9.0 also better addressing and web popup. Shibboteh ticket.

• pass-through: data is pumped from server B to the client A via server A (as currently available)
• server-cache: as mentioned by Holger (comes with potential consistency&refresh mechanism issues to be addressed)
• client redirect: as mentioned by Paul Millar (would affect the current usability model of ownCloud)

Pick a preferred home for standardization

• IETF??? - Simon to give a thought

All the recommendations have been fed into the Phase II initiation phase.

The OCM team agreed to continue and split into two working groups (WGs):

1. Strategic policy and standardization oversee WG
2. Technical protocol definition and implementation WG

The key objective of the Strategic WG will be to reach the ultimate "Open Cloud Mesh standard" and to oversee (not overdrive) the Technical WG making sure that the open API design principles are properly addressed. The key objective of the Technical WG will be to deliver one or more working prototypes of OCM and to provide (not force) input to the Strategic WG making sure that their assumptions are realistic.

The detailed objectives and key results of the Phase II will be determined in the initiation phase.

Phase I is considered to be CLOSED.

News item: http://www.geant.org/News_and_Events/Pages/OpenCloudMesh.aspx