Page MenuHomePhabricator

Support for Blubber defaults and/or policies
Closed, ResolvedPublic


A requirement for Blubber config policies or global defaults has been brought up briefly in past Container Cabal meetings but needs further deliberation.

The basic scenario here is that we're looking at having Blubber configuration for each service that makes its way into the container release pipeline. Since Blubber was developed to be general at least in design, there are many config items that are configurable but will likely be the same across projects, the most likely of which is the runs portion of the config which currently looks like this (at least for Mathoid in my local working environment):

  in: /srv/service
  as: runuser
  uid: 666
  gid: 666
    APP_BASE_PATH: /srv/service

Just assuming for this example that /srv/service is the standard path for service application files within containers—but see T169998: RFC: Container path conventions for other possibilities—it's very likely that this entire block of Blubber config will be repeated across all services. There are a few options for solving this:

  1. Allow Blubber to ingest multiple config files, applying them in order (e.g. blubber defaults.yaml application.yaml variant_name).
  2. Allow for explicit global default file to be specified in the config itself (e.g. defaults: http://some.example/default.yaml).
  3. Support policy files that define what config is allowable (though this doesn't solve the duplication of config exactly).
  4. Come up with general-enough default values for this part of the config.
  5. Simply live with the duplication.

Event Timeline

greg added a subscriber: greg.

talked it through and base images seems like plenty.

If there is a need for something like this in the future it would be sufficiently different enough from this task. CLOSING

dduvall claimed this task.
dduvall triaged this task as High priority.

Blubber now has a more secure default permissions scheme (see T187372: Blubber should implement a better file permissions convention) but given the different requirements for test suites and production application processes—the former often needing much more liberal ownership and read/write permission to application directories/files—we're looking into implementing a less secure alternative. We'd like to limit this alternative to just non-production variants and so we again are looking to implement a sane policy system in Blubber.