Skip to content

Instantly share code, notes, and snippets.

@mogul

mogul/notes.md

Last active May 15, 2020 04:13
Show Gist options
  • Save mogul/b8865f4786700dd4824c352e6da8ecda to your computer and use it in GitHub Desktop.
Save mogul/b8865f4786700dd4824c352e6da8ecda to your computer and use it in GitHub Desktop.
Download ZIP
Volume Services and Drupal notes
Raw
notes.md

Context from here:

The NFS volume service appears to be going unsupported. We've decided to remove this experimental service, though we anticipate adding a volume service based on AWS EFS once the FedRAMP JAB authorizes AWS EFS in AWS' GovCloud region.

I've got additional context to provide for both volume services and Drupal.

Historical notes on volume services:

  • The experimental NFS volume service was made available to help customers who needed a durable local filesystem test that their app would work with Cloud Foundry volume services. (See the diff in the PR referenced above.)

  • The NFS broker was always somewhat janky. It didn't create volumes on demand, but rather required an out-of-band communication of a manually-created volume name from the operators to the customer. The customer then specified that "secret" volume name in their create-service request. Not a great operator or customer experience!

  • In customer discussions, the service was offered with the caveat that we were basically waiting for AWS to get EFS through FedRAMP so we could broker that instead of NFS. Last July, the answer to one of our requests didn't give us confidence that the nfs-volume-release was getting much attention, and we didn't really want to be NFS admins if we didn't have to be. That's when we removed the description of the NFS service from the website, and according to Slack Hilary removed cg-deploy-volume-services in September. We figured we'd revisit efs-volume-release when EFS made it through FedRAMP. Heck we even made some PRs to efs-volume-release in anticipation.

  • So what of the efs-volume-release? Well, in August it was put into the cloudfoundry-attic GitHub org... Not a good sign! Both cloud.gov and the UK PaaS team asked about the state of the efs-volume-release in the CF Slack at that time. In addition to that thread, one of the telling posts in the channel was:

    currently nfs-volume-release, smb-volume-release and efs-volume-release are all developed and tested by the volume services team in our pipelines. Although, efs is not under active development per se, there is a cost to maintaining it in our pipelines and if we don't do that that time can be devoted to nfs and smb instead.

  • So ostensibly the nfs-volume-release got more steam starting then. Their PM later said

Another option for EFS would be that we could move it into couldfoundry-community instead of cloudfoundry-attic, if any of you is willing to take on maintenance for it. If you're interested in that avenue, let me know and I can talk to the lawyers about getting the IP moved.

  • So, the EFS broker is there for the forking/owning, but it'll need ongoing maintenance and testing. Beware!
  • This is the volume release team's charter, which has since been updated, and it makes it very clear that their focus now is on ensuring that NFS and SMB volume services continue to work as CF moves over onto k8s.
  • The PM, @julian-hj, has been saying that he welcomes any feedback or discussions with potential users of volume services; from the doc it's clear takeup has been pretty low.

Historical notes on Drupal:

  • The drupal8 example with the s3fs plugin is not bad, but it could be much better. In the time since it was written, there's now an officially supported Composer path for deploying Drupal as well.
  • True of Drupal in general and not just the sample we wrote, Drupal doesn't lend itself well to being version-controlled because a lot of the content and config are in the database even after S3 is used to replace local files. Also as Ron noted, many customers are not coming from clean-sheet Drupal deployments, so assisting them with a smoother path for migrating from what they have into a deployment like the sample is needed.
  • I investigated this a lot and eventually came across Tome. Tome is fundamentally a way to make a full dump and restore of a Drupal deployment, including files and DB content/config, themes, etc. A few things this enables:
    • You can export from a non-cloud.gov, non-S3 Drupal deployment and import into a cloud.gov-savvy Drupal deployment.
    • You can commit the dump to version control between exports and imports.
    • You can use Drupal for local authoring of a checkout of the export from git before committing it back.
    • You can generate a static export of the site suitable for deploying with the staticfile buildpack or Federalist.
  • In other words, Tome acts as a swiss army knife which enables several different options for migrating/deploying Drupal into cloud.gov or Federalist. (Also, the author seems pretty relaxed and is likely pretty open to micropurchase requests for features if needed.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment