mogul

---

Everything else I think you might ask for

Table of contents

• sudo lscpu
• sudo dmidecode -t processor
• sudo lspci
• sudo lspci -v

mogul

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,

mogul

bash-3.2$ DATABASE_URL='postgres://username:password@hostname.net:port/dbname'
bash-3.2$ [[ $DATABASE_URL =~ (.*)'://'(.*):(.*)@(.*):(.*)/(.*) ]] && \
DB_USERNAME=${BASH_REMATCH[2]} \
DB_PASSWORD=${BASH_REMATCH[3]} \
DB_HOST=${BASH_REMATCH[4]} \
DB_PORT=${BASH_REMATCH[5]} \
DB_DBNAME=${BASH_REMATCH[6]} env |grep DB_
DB_PORT=port
DB_USERNAME=username
DB_DBNAME=dbname

mogul

Keybase proof

I hereby claim:

• I am mogul on github.
• I am mogul (https://keybase.io/mogul) on keybase.
• I have a public key ASAtYCrWY9q2EPEuzYkCSJ0jHptKVEakdqvrwxMqVmSVBAo

To claim this, I am signing this object:

mogul

var catalog = []brokerapi.Service{
	{
		ID:          clientAccountGUID,
		Name:        "[product]-service-account",
		Description: "Manage [product] service accounts with access to your organization",
		Plans: []brokerapi.ServicePlan{
      {
				ID:          "074e652b-b77b-4ac3-8d5b-52144486b1a3",
				Name:        "space-deployer",
				Description: "An account for continuous deployment, limited to a single space",

mogul

Entities are expected to be autonomic... They should know how to dump/restore themselves. So entities provide effectors for managing dumps. For example, see the effectors in this Minecraft blueprint: https://github.com/johnmccabe/brooklyn-minecraft

A policy would handle the retention schedule by using those exposed effectors. For example, a policy could use the effectors make/keep daily dumps for a month, then roll to weekly/monthly further back.

Entity storage is effectively volatile... we don't want our dumps stored there. For persistence outside the entity itself, the entity needs to know a non-local location to put/get/list the dumps. So the entity can take a blobstore URL+creds as a config value, and use that as its storage, with curl. (Entities can be composed in other blueprints. So maybe you could wrap an entity around the Minecraft example that provides non-local backups using the local dumps it makes.)

Since the config value is passed in, it can cascade from the top of the blueprint, or Brooklyn

mogul

{"contentType":"application/gliffy+json","version":"1.1","metadata":{"title":"untitled","revision":0,"exportBorder":false},"embeddedResources":{"index":0,"resources":[]},"stage":{"objects":[{"x":1154.098214285714,"y":439.51785714285705,"rotation":0,"id":150,"uid":"com.gliffy.shape.basic.basic_v1.default.line","width":100,"height":100,"lockAspectRatio":false,"lockShape":false,"order":86,"graphic":{"type":"Line","Line":{"strokeWidth":1,"strokeColor":"#003068","fillColor":"none","dashStyle":"8.0,8.0","startArrow":0,"endArrow":2,"startArrowRotation":180,"endArrowRotation":180,"ortho":true,"interpolationType":"quadratic","cornerRadius":null,"controlPath":[[5.198598122458179,-2.863094934417802],[-17.94200601359921,-2.863094934417802],[-41.0826101496566,-2.863094934417802],[-64.223214285714,-2.863094934417802]],"lockSegments":{}}},"children":null,"constraints":{"constraints":[],"startConstraint":{"type":"StartPositionConstraint","StartPositionConstraint":{"nodeId":147,"px":0,"py":0.5}},"endConstraint":{"type":"EndPo