information/documentation of the filesystem service

731 views
Skip to first unread message

ramonskie

unread,
Apr 17, 2012, 8:40:03 AM4/17/12
to vcap...@cloudfoundry.org
Is there any info about the filesystem service?
because i can´t find any piece of information

https://github.com/cloudfoundry/vcap-services/tree/master/filesystem


Nicholas Kushmerick

unread,
Apr 17, 2012, 7:25:59 PM4/17/12
to vcap...@cloudfoundry.org
This is still a work-in-progress.  The link below is the service gateway, which manages a set of NFS exports; it is basically done.  But the big missing peace is integration with the DEAs where apps actually run.  A prototype of the DEA integration is at https://github.com/cloudfoundry/vcap/commit/c1cff697939216cf291c6c4c3338b37b8dc84c08 but this code is not yet ready for prime time.  We plan to finish this service in the next couple of months.
--
Nick
phone +1.206.293.5186 · skype nicholaskushmerick

Anoop

unread,
Apr 18, 2012, 3:56:02 AM4/18/12
to vcap-dev
Is filesystem service supposed to help all nodes running an app to
access a shared storage ?. If so does it support fuse mounted
filesystems like WebDAV, gluster.

Thanks
Anoop

On Apr 18, 4:25 am, Nicholas Kushmerick <nichol...@rbcon.com> wrote:
> This is still a work-in-progress.  The link below is the service gateway,
> which manages a set of NFS exports; it is basically done.  But the big
> missing peace is integration with the DEAs where apps actually run.  A
> prototype of the DEA integration is athttps://github.com/cloudfoundry/vcap/commit/c1cff697939216cf291c6c4c3...
> this code is not yet ready for prime time.  We plan to finish this
> service in the next couple of months.
>
> On Tue, Apr 17, 2012 at 5:40 AM, ramonskie <ramonmakke...@gmail.com> wrote:
> > Is there any info about the filesystem service?
> > because i can´t find any piece of information
>
> >https://github.com/cloudfoundry/vcap-services/tree/master/filesystem
>
> --
> Nick
> phone +1.206.293.5186 *·* skype nicholaskushmerick

Nicholas Kushmerick

unread,
Apr 18, 2012, 12:12:27 PM4/18/12
to vcap...@cloudfoundry.org
The service will present a persistent filesystem to all instances of all apps that are bound to the service.  The design is not yet nailed down, we may well use FUSE to implement quota, ensure isolation, etc.  But from the perspective of applications, it will be very simple: they'll get a path from VCAP_SERVICES under which they can read/write persistent shared files (just like apps get host/credentials from VCAP_SERVICES to access their other services).

Aliaksei Kliuchnikau

unread,
Apr 18, 2012, 12:30:20 PM4/18/12
to vcap...@cloudfoundry.org
Will the following (pretty common) use case be met with the filesystem service:

User has an existing application that he want to migrate to the Cloud Foundry. He has several writeable folders in his application, for example "/images" and "/videos". Will he be able to create two instances of FileSystem service, bind them to the application and do some configuration in the CF (configure FSS services or something else) so that these 2 folders will be shared across application instances without need to change the application code?

Thanks,
Alex

Patrick Bozeman

unread,
Apr 18, 2012, 2:30:19 PM4/18/12
to vcap...@cloudfoundry.org
Hrmm.. we will have the ability to bind 2 instances of the fs service to an app, but.. we haven't talked about being able to mount them at arbitrary locations.  Our assumption has been that apps that need access to a persistent FS can be relatively easily configured to use user supplied paths, rather than requiring hard coded paths.

We do have the internal infrastructure on the way to support this use case (warnen based containers in the dea), but wasn't something we were planning on doing.

It has been my experience that most apps don't take hard coded paths that start at the system root and that any hard coded paths they might have are at least relative to some top level directory that is configurable.   If I'm misreading your email and you mean something else, please clarify.  Or if I'm way off base about my belief in the configurability of the top level data directory of apps, please show me the error of my ways :)

Aliaksei Kliuchnikau

unread,
May 7, 2012, 9:05:29 AM5/7/12
to vcap...@cloudfoundry.org
Our team is planning to provide CloudFoundry PaaS service and we have found two main use cases when FSS should be mounted at the arbitrary locations:
1. We believe that the target audience for FSS would be an existing applications (mainly written in PHP). It may happen that:
  a) Application is written without usage of DRY principle and there may be cases when it will require a lot of work to rewrite filesystem access code so that it will use folders names provided by the CloudFoundry platform.
  b) Application is written with usage of 3rd-party libraries. These libraries may write to the pre-defined locations and it might be hard/impossible to change these locations from the client code. For example this is the case with some PHP CMS.
2. If someone want to auto-migrate (I mean automatically prepare application for provisioning into cloudfoundry) many existing applications from another hosting to the CF cloud (or maybe provide auto-migration service to the cloudfoundry users), then it will require significantly more automation work (or sometimes will be impossible taking into account item 1.b).

Also, in my opinion, it looks more natural from the user perspective to set folder name for FSS service and then mount this folder to the application. What do you think?

Actually we were planning to create FSS from scratch until we found out that someone is already working on this feature. Also, we would like to provide FSS on top of GlusterFS instead of nfs, thus we need to write additional "FSS provisioning adapter". How can we join the development effort for this feature? Are there any public git branch and/or tasks list available?

Best regards,
Alex

Patrick Bozeman

unread,
May 7, 2012, 2:09:03 PM5/7/12
to vcap...@cloudfoundry.org, Nicholas Kushmerick
I'm not very familiar with the details of the PHP CMS ecosystem.  Can you point me to an example of 1A or B that uses hard coded paths that can't be configured via config files?

The approach Nick's team is taking for fss should allow for any FS that provides posix fs semantics.  This work is in its infancy and Nick can provide more details.

Aliaksei Kliuchnikau

unread,
May 24, 2012, 9:57:34 AM5/24/12
to vcap...@cloudfoundry.org
Hi,

I am not experienced in PHP too, but I talked with senior PHP developers and investigated several CMS solutions and found that they rarely provide ability to change writable folders. They usually store uploads in the predefined writable folders, some CMS also write config and temporary files required for proper CMS operation. These folders must be made writable in order to ensure proper application operation in the CF.

For example PyroCMS requires /uploads, /system/cms/config and some other folders to be writable, Drupal will need to write into /sites/default folder.

Pagoda (one of the major players in PaaS for PHP) gracefully solved the shared file storage problem. They provide ability to specify writable folders in the Boxfile YAML (analog to our manifest.yml):

web1:

 shared_writable_dirs: [/dirA, /dirB]

I believe this is the approach we should adapt for CloudFoundry FSS implementation.

Jeremy Voorhis

unread,
Sep 5, 2012, 7:44:33 PM9/5/12
to vcap...@cloudfoundry.org
I personally think Pagoda's solution is decent. One idea I have toyed with personally is creating mountpoints on the DEA in a sibling directory and providing an optional configuration mechanism to create symlinks on deploy. (Alternatively, apps could create these symlinks themselves at init).

One issue that comes to mind is the diversity of config file formats in staging plugins, i.e. cloudfoundry.yml for Rails and cloudfoundry.json for NodeJS. Unifying these configs and settling on cloudfoundry.yml, and using it for this sort of configuration, seems like one reasonable solution.

Albert

unread,
Sep 7, 2012, 12:38:17 PM9/7/12
to vcap...@cloudfoundry.org
was wondering if the feature was being tracked anywhere publicly. 

we'd like to integrate this feature once ready (or contribute to getting it there). a rough timeline would be helpful for planning. 

i took the unofficial patch for a spin and was curious about at a few bits:
  - for multiple droplets on the same dea, i'm assuming each droplet would get it's own mountpoint to the same physical share (with each droplet having it's own unique path to access the same share). 
  - mountpoints will eventually need to be cleaned up. if droplets share-nothing this should be trivial. 
  - what are the plans for credentialed access?
  - would it be possible instead to have the agent lazy mount the root of an nfs backend once, and then chown/symlink/etc for each droplet?

Nicholas Kushmerick

unread,
Sep 7, 2012, 1:00:33 PM9/7/12
to vcap...@cloudfoundry.org
these are all great comments/suggestions.  as you can see, the filesystem service implementation is very incomplete.  we will finish it after the new DEA is ready.  the new DEA will run each app in a dedicated container.  so the answer to your question about credentialed access is that the filesystems will be isolated from one another because each container will have access only to the filesystem service iinstances that are bound to the container's app.
Reply all
Reply to author
Forward
0 new messages