<p dir="auto">Greetings,</p>
<p dir="auto">continuation from this problem <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="98657385" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/12134" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/12134/hovercard" href="https://github.com/kubernetes/kubernetes/issues/12134">#12134</a><br>
thanks brendan, after the update, nodes were restarted and all containers started without problems, but there is one thing I am really afraid of my <code class="notranslate">mongodb</code> instances.</p>
<p dir="auto">I'm using this yaml file, just cut the container list.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="apiVersion: v1
kind: ReplicationController
metadata:
  name: mongodb-shard1-controller
spec:
  replicas: 2
  selector:
    name: mongodb-shard1-controller
    version: v0
  template:
    metadata:
      labels:
        name: mongodb-shard1-controller
        version: v0
    spec:
      containers:
      - name: mongodb-node1
        image: gcr.io/app/mongodb3.0.4
        ports:
        - containerPort: 27017
          hostPort: 27031
        env:
          - name: REPL_SET
            value: kube_shard1
        volumeMounts:
          - mountPath: /data/db
            name: db-path
      volumes:
        - name: db-path
          source:
            emptyDir: {}"><pre class="notranslate"><code class="notranslate">apiVersion: v1
kind: ReplicationController
metadata:
  name: mongodb-shard1-controller
spec:
  replicas: 2
  selector:
    name: mongodb-shard1-controller
    version: v0
  template:
    metadata:
      labels:
        name: mongodb-shard1-controller
        version: v0
    spec:
      containers:
      - name: mongodb-node1
        image: gcr.io/app/mongodb3.0.4
        ports:
        - containerPort: 27017
          hostPort: 27031
        env:
          - name: REPL_SET
            value: kube_shard1
        volumeMounts:
          - mountPath: /data/db
            name: db-path
      volumes:
        - name: db-path
          source:
            emptyDir: {}
</code></pre></div>
<p dir="auto">it may not be the best, but I am using it in production. after the nodes restarted, all replica sets of mongodb instances, could not connect on to each other, and other than that, databases are gone. and I could not get it back up w/databases. i don't know where is <code class="notranslate">/data/db</code> gone?</p>
<p dir="auto">I'm using <code class="notranslate">GCP</code>, what is the best practice for database storages?</p>
<p dir="auto">There are currently two different ways of determining request information: <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/apiserver/handlers.go#L264">https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/apiserver/handlers.go#L264</a> and the system of record: <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/apiserver/api_installer.go#L97">https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/apiserver/api_installer.go#L97</a> that actually dispatches the calls.</p>
<p dir="auto">Having two mechanisms for determining what verb/namespace/resource/subresource/etc information on the request means that the authorizer can end up out of sync with reality.  Collapsing the determination of request information to a single spot with a separate authorize call is one way to eliminate the duplication and avoid false authorization matches due to out of sync request information parsing.</p>
<p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/smarterclayton/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/smarterclayton">@smarterclayton</a> I think this would address the problem we're having with subresource policy determinations.</p>