@pmorie @bgrant0607

@erictune @bgrant0607

I think the binding should happen in the kubelet. At what point during the pod lifecycle should the binding happen? Before pod start seems like a good place to start discussion.

Regardless of where/when binding happens, if we think it is a valid use-case to be able to specify the uid or resourceVersion, we need to think through the case where the specific version is unavailable. At the least we should create an event with cause information. I don't think you want the pod to start in this case unless the exact specified version is available.

I have some other comments about status and how this should appear to the user but I'll comment on #4950 with those.

Adding "namespace" to the object reference seems redundant. You're already in a namespace when you're working with a pod. I needed the same thing, though, so I added a defaulting function to assign the pod's namespace to the object reference I am using in my PR.

Object reference namespaces should remain unset when stored so they can be copied to other objects without requiring a change. An object reference without a namespace means "use this namespace" which is not the same as "use the namespace named foo"

What if you don't want to copy the object reference to another object without requiring a change of namespace?

Eric's JSON example above sans namespace:

"source": {
                "secret" : {
                  "target" : {
                      "name": "shh",
                 }
            }

@smarterclayton are you saying this is incorrect? if so, why? Because it seems so like a foreign key here to something in the same namespace, but it doesn't require the user to enter the namespace again in the "target" struct. They are already in the namespace. Meanwhile, you need the namespace in the volume plugin to lookup the Secret.

On Mar 3, 2015, at 12:09 AM, Mark Turansky notifications@github.com wrote:

What if you don't want to copy the object reference to another object without requiring a change of namespace?

Then you should fill out the namespace. But secrets are the last thing you want a user to be accessing across namespaces. And remember, secrets are subordinate to the service account, which means that an initializer still has to do that mapping. It may be that secrets are forced to be a lookup to the namespace of the pod (not a default).
Eric's JSON example above sans namespace:

"source": {
"secret" : {
"target" : {
"name": "shh",
}
}
@smarterclayton are you saying this is incorrect? if so, why? Because it seems so like a foreign key here to something in the same namespace, but it doesn't require the user to enter the namespace again in the "target" struct. They are already in the namespace. Meanwhile, you need the namespace in the volume plugin to lookup the Secret.

Then the pod namespace should be made available to the volume plugin.
—
Reply to this email directly or view it on GitHub.

@erictune There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here.

/sig node
/sig api-machinery

Issues go stale after 90d 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

/remove-lifecycle stale
/lifecycle frozen

see also #22368

/close
pretty much no activity in more than two years, and is not very clear what the next steps are.
Feel free to re-open once we have clearly actionable items on kubelet side

@fromanirh: Closing this issue.