Re: Default Service Account Names

2017-07-17 Thread Devan Goodwin 
On Mon, Jul 17, 2017 at 10:07 AM, Jordan Liggitt  wrote:
> An export should include custom image pull or push secrets added to the
> namespace and included in the service account's imagePullSecrets list.

I will change approach here to make sure we include all service
accounts and their associated secrets, with some potential merge logic
on import.

Somewhat leads into another discussion we're having, but is it
reasonable to recreate the project separately (potentially with a
different name in another cluster), then import objects into it,
rather than trying to include the project and rolebinding info in the
template/objectlist itself? It felt safer to do this when we're
talking about long term archival, differing OpenShift versions, and
moving clusters/projects.

Thanks for the feedback all.

>
> On Mon, Jul 17, 2017 at 8:04 AM, Clayton Coleman 
> wrote:
>>
>> Also, if you exported a set of service accounts, assumption is that a new
>> one can be added at any time (to all namespaces), which means you already
>> have to handle merging them when you restore.
>>
>> On Mon, Jul 17, 2017 at 7:45 AM, Michail Kargakis 
>> wrote:
>>>
>>> What if someone has granted extra access to one of the default service
>>> accounts? Custom deployments (and I imagine builds too)
>>> may not work w/o granting extra permissions, depending on what the
>>> deployer/builder is actually doing.
>>>
>>> On Mon, Jul 17, 2017 at 1:31 PM, Devan Goodwin 
>>> wrote:

 I've been working on project archival for online, with regard to
 service accounts we may need to export those created manually by the
 user, and skip those created automatically by OpenShift when we
 created the project.

 There does not appear to be any information on those service accounts
 to identify that it was automatically created by OpenShift:

 - apiVersion: v1
   imagePullSecrets:
   - name: deployer-dockercfg-t2ckf
   kind: ServiceAccount
   metadata:
 creationTimestamp: 2017-07-12T14:48:19Z
 name: deployer
 namespace: myproject


 Is assuming the service accounts with names "builder", "deployer", and
 "default" a stable set we could count on for skipping during an
 export?

 Would it be acceptable to start adding an annotation to these service
 accounts similar to what we do for secrets that are attached to those
 SAs?

   kind: Secret
   metadata:
 annotations:
   kubernetes.io/created-by: openshift.io/create-dockercfg-secrets

 Perhaps in this case "openshift.io/default-service-accounts"?
 (suggestions welcome)

 If so, is there any established precedent for migrating pre-existing
 builder/deployer/default SAs to add the annotation during an upgrade?

 Thanks!

 Devan

 ___
 dev mailing list
 dev@lists.openshift.redhat.com
 http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>>
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Default Service Account Names

2017-07-17 Thread Clayton Coleman 
Asked another way - why not export them?

On Mon, Jul 17, 2017 at 7:31 AM, Devan Goodwin  wrote:

> I've been working on project archival for online, with regard to
> service accounts we may need to export those created manually by the
> user, and skip those created automatically by OpenShift when we
> created the project.
>
> There does not appear to be any information on those service accounts
> to identify that it was automatically created by OpenShift:
>
> - apiVersion: v1
>   imagePullSecrets:
>   - name: deployer-dockercfg-t2ckf
>   kind: ServiceAccount
>   metadata:
> creationTimestamp: 2017-07-12T14:48:19Z
> name: deployer
> namespace: myproject
>
>
> Is assuming the service accounts with names "builder", "deployer", and
> "default" a stable set we could count on for skipping during an
> export?
>
> Would it be acceptable to start adding an annotation to these service
> accounts similar to what we do for secrets that are attached to those
> SAs?
>
>   kind: Secret
>   metadata:
> annotations:
>   kubernetes.io/created-by: openshift.io/create-dockercfg-secrets
>
> Perhaps in this case "openshift.io/default-service-accounts"?
> (suggestions welcome)
>
> If so, is there any established precedent for migrating pre-existing
> builder/deployer/default SAs to add the annotation during an upgrade?
>
> Thanks!
>
> Devan
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Default Service Account Names

2017-07-17 Thread Devan Goodwin 
I've been working on project archival for online, with regard to
service accounts we may need to export those created manually by the
user, and skip those created automatically by OpenShift when we
created the project.

There does not appear to be any information on those service accounts
to identify that it was automatically created by OpenShift:

- apiVersion: v1
  imagePullSecrets:
  - name: deployer-dockercfg-t2ckf
  kind: ServiceAccount
  metadata:
creationTimestamp: 2017-07-12T14:48:19Z
name: deployer
namespace: myproject


Is assuming the service accounts with names "builder", "deployer", and
"default" a stable set we could count on for skipping during an
export?

Would it be acceptable to start adding an annotation to these service
accounts similar to what we do for secrets that are attached to those
SAs?

  kind: Secret
  metadata:
annotations:
  kubernetes.io/created-by: openshift.io/create-dockercfg-secrets

Perhaps in this case "openshift.io/default-service-accounts"?
(suggestions welcome)

If so, is there any established precedent for migrating pre-existing
builder/deployer/default SAs to add the annotation during an upgrade?

Thanks!

Devan

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev