I guess annotation would be better suitable for oc and other clients to
issue queries, doesn't it?
According to kubernets docs [1] it was designed for cases like this.

[1]
https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/annotations.md
Em 02/03/2016 21:59, "Derek Carr" <[email protected]> escreveu:

> Right... So you really need an immutable field in metadata or something
> similar, or an annotation field that is overridden on every create/update
> during admission.
>
> On Wednesday, March 2, 2016, Mateus Caruccio <
> [email protected]> wrote:
>
>> Hi Derek.
>> I'm building a billing backend based on container and pvc usage.
>> The system is going to track any interesting activity (create and delete)
>> by watching the corresponding endpoints and store it in a document database
>> (mongodb or similar).
>> One important point is that users should not be able to tamper this
>> identifier, i.e. "oc edit pod/somepod".
>>
>> --
>> Mateus Caruccio / Master of Puppets
>> GetupCloud.com - Eliminamos a Gravidade
>>
>> On Wed, Mar 2, 2016 at 9:27 PM, Derek Carr <[email protected]> wrote:
>>
>>> This is not a bad idea to do in admission control as part of the
>>> namespace existence check.
>>>
>>> Can you elaborate a little more what you are trying to build around the
>>> feature to see if there is anything else that would be required?  I am not
>>> sure it should be an annotation versus a field in metadata, i.e.
>>> metadata.namespaceUid or something similar.
>>>
>>> Thanks,
>>>
>>> On Wednesday, March 2, 2016, Mateus Caruccio <
>>> [email protected]> wrote:
>>>
>>>> Is there any way to tie resources (pod, pvc, secrets, bc, etc) to it's
>>>> belonging namespace without looking for namespace's lifetime?
>>>>
>>>> Today I can do it by watching and recording the create and delete
>>>> events for a namespace, then associate any resources to that namespace, but
>>>> it doesn't seams to be the best approach. Namespaces can be destroyed and
>>>> recreated by a different user with same name.
>>>>
>>>> I'm looking for something like automatically adding an annotation
>>>> containing namespace's uid to all resources created inside it (some sort of
>>>> primary key), as soon as the resource is created.
>>>>
>>>>
>>>> --
>>>> Mateus Caruccio / Master of Puppets
>>>> GetupCloud.com - Eliminamos a Gravidade
>>>>
>>>
>>
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to