Bug 1303011

Can you detail the situations under which an API is required?

The long term vision for this sort of function is sync would be run inside a ScheduledJob on the cluster inside of a container containing the openshift binaries and whatever sync tools an admin wanted.

    oc new-build gitrepository_containing_sync_defaults openshift/origin --name ldapsync
    oc run --image ldapsync --every=4hr ldapsync-job

We are only likely to build APIs that enable a wide range of integrations, vs making it easier for a local admin to synchronize their specific LDAP groups.  We also generally do not create APIs that front very long running operations, since there are better ways to model those operations (as the above mentioned "job").

(In reply to Clayton Coleman from comment #1)
> Can you detail the situations under which an API is required?
> 
> The long term vision for this sort of function is sync would be run inside a
> ScheduledJob on the cluster inside of a container containing the openshift
> binaries and whatever sync tools an admin wanted.
> 
>     oc new-build gitrepository_containing_sync_defaults openshift/origin
> --name ldapsync
>     oc run --image ldapsync --every=4hr ldapsync-job
> 
> We are only likely to build APIs that enable a wide range of integrations,
> vs making it easier for a local admin to synchronize their specific LDAP
> groups.  We also generally do not create APIs that front very long running
> operations, since there are better ways to model those operations (as the
> above mentioned "job").

Our Organisation AD is very big. 

So to synchronize ALL AD groups to Openshift is not an option and overkill from resource point of view.

So on each team/project onboard to the platform they provide AD groups as a pre-requisite to our central orchestration/management portal. 

Portal itself goes and queries Openshift to create projects and provision all accesses for the team. In this case because we don't do all AD synchronization, groups does not exist in openshift to provision/rolebind access to. 

In this case flow would be:
Central orchestration portal does:
1. Creates project on Openshift.
2. Execute ldapsync for particular project/team ad groups to enable them in Openshift. 
3. executes Rolebinding for groups on project.
4. Set quotas on projects. 

After all this we will execute ldap sych for existing groups as a scheduled task.

But initialy we need to be able to say to "say" to openshift: "Please sync this group only from this AD only, and this is group DN". (We have more than 2 AD to sync with too)

Syncing individual groups is already supported by the LDAP sync mechanism, Is it not acceptable to create specific LDAP sync configurations and run the `oadm groups sync` command in order to sync the specific groups you require?

The request here is to be able to so LDAP sync without the "oadm" tool so that this can be done, say, from a dedicated pod serving some custom workflow.

Using one of the provided Docker images containing the OpenShift client tools, this can already be done. 

If a namespace is created for which the service account has permissions to alter groups, a pod in that namespace with the OpenShift client tools could run the sync as you describe. 

The namespace would have to be protected, as anyone with edit permission on the namespace would have escalation powers by leveraging the service account's permissions.

A scheduled job could be set up to run this pod at a predetermined interval, etc. 

I will try to build an example system that does this in order to demonstrate the concept.