All-in-one managed data volume

[pmorie]

This issue is to aggregate opinions and indications of interest in a single volume that handles all types of 'managed' data, such as:

1. Secrets
2. ConfigMaps
3. Downward API
4. Service Links

One possible API for such a volume might look like:

name: my-mega-dir
items:
  - configMapName: my-config-map
    files:
      - key: config
        file: myapp.conf
  - secretName: my-secret
    files:
      - key: password
        file: path/passwd.txt
  - downwardAPI: 
      apiVersion: v1
      fieldPath: metadata.name
    file: myapp.name.txt

Forking issue from discussion that started here: #18586 (comment)

[thockin]

I know it was spawned from something I said, but I haven't yet heard anyone ask for this.

[pmorie]

@thockin I don't think anyone wants it, and I don't think it's a great idea for us to do anymore either, shall I close?

[pmorie]

I'm reopening this because I've gotten requests for it.

cc @kubernetes/sig-apps

[thockin]

Other options in this vein:

• allow multiple ConfigMaps or Secrets to be mounted into a single dir
  (overlay style)
• allow a ConfigMapVolumeSource to pull multiple ConfigMap inputs (repeats
  for Secret)
• provide a configurable sidecar container that can consume arbitrary
  inputs and synthesize a result directory
• build a linkfarm volume that acts as a table-of-contents of symlinks into
  other volumes

On Wed, Sep 7, 2016 at 8:44 AM, Paul Morie notifications@github.com wrote:

Reopened #19762 #19762.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#19762 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOkVbKhHW7s52Td0QFv4KPT-rJTZks5qntvlgaJpZM4HGUSQ
.

[erictune]

What is the problem that this is solving? Is it helping the user by making the config less verbose when the same object is referenced several times? Or is it making the implementation in kubelet/runtime easier by restricting they ways that files-in-objects can be combined into files-in-chroots.

[thockin]

It is allowing the user to express something they can not easily express
today, which is a directory full of files that come from disparate
sources. I think we might be able to do even better, though, with some
sort of "merge" volume.

Imagine a volume that first recreates the directory on which it is being
mounted, and then adds in links to other places.

I could say:

• mount secret foo on /foo
• mount config bar on /bar
• merge "/etc" with "/foo/mysecret.txt as foo.txt" and "/bar/myconfig.conf
  as bar.conf"

I thin this would actually solve the problems people really have. Need to
prototype and work out details.

On Tue, Sep 20, 2016 at 11:26 AM, Eric Tune notifications@github.com
wrote:

What is the problem that this is solving? Is it helping the user by making
the config less verbose when the same object is referenced several times?
Or is it making the implementation in kubelet/runtime easier by restricting
they ways that files-in-objects can be combined into files-in-chroots.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#19762 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVCt4IcSvsmSUr7LG4PE56exxx9d-ks5qsCVvgaJpZM4HGUSQ
.

[bgrant0607]

Proposal is open: #35313

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[thockin]

We now have ProjectedVolumeSource