ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Beerbower (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-7349) Admin : LDAP Sync API to support sync events
Date Fri, 19 Sep 2014 02:11:33 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tom Beerbower updated AMBARI-7349:
----------------------------------
    Description: 
Revised LDAP_SYNC API Proposal...

The ldap sync event resource contains the information needed to perform an ldap sync.  This
includes the principal type (user, group), the sync type (all, existing, specific), and an
optional set of principal names.  Wildcards will be supported for principal names.  You can
mix and match specs, so it is possible to have an event that syncs all users but specific
groups, for example.

--  Create ldap sync events ...
{code}
POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
{
  "specs" : [
    {
      "principal-type":"users",
      "sync-type":"all"
    },
    {
      "principal-type":"groups",
      "sync-type":"all"
    }
  ]
}


POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
{
  "specs" : [
    {
      "principal-type":"users",
      "sync-type":"existing"
    },
    {
      "principal-type":"groups",
      "sync-type":"existing"
    }
  ]
}

POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
{
  "specs" : [
    {
      "principal-type":"users",
      "names":"fred,joe,admin*",
      "sync-type":"specific"
    },
    {
      "principal-type":"groups",
      "names":"group1,group2,admin*",
      "sync-type":"specific"
    }
  ]
}
{code}

When you create an event it is assigned a unique id.
The response of each post will contain the href to the new ldap sync event resource.  For
example, 
{code}"href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1"{code}
The events are not persisted in the DB.  We will keep them in memory only for now, possibly
with an expiry value.  If there is a need to persist them beyond a stop then we can add the
DB persistence later.

When an event is added, it will be placed on a queue.  Events will be serviced sequentially
(for now we will not handle concurrent syncing).  

Events will be run as they are taken off the queue.  In the future we may add the ability
to schedule events. 


--  Get all of the sync events ...
{code}
GET http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
{
  "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/",
  "items" : [
    {
      "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1",
      "Event" : {
        "id":1
      },
      "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/2",
      "Event" : {
        "id":2
      },
      "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/3",
      "Event" : {
        "id":3
      },
    }
  ]
}
{code}

You can view a specific sync event.

--  Get a specific sync event ...
{code}
GET http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1
{
  "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1/",
  "Event":{
    "id":1,
    "state":"COMPLETE",
    "sync-start-time":"10/12/2004 12:14:26.002"
    "sync-end-time":"10/12/2004 12:15:36.006"
    "users-fetched":200,
    "users-created":12,
    "users-updated":4,
    "users-removed":5,
    "groups-fetched":10,
    "groups-created":3,
    "groups-updated":2,
    "groups-removed":1,
    "membership-fetched":20,
    "membership-created":1,
    "membership-updated":5,
    "specs" : [
      {
        "principal-type":"users",
        "sync-type":"all"
      },
      {
        "principal-type":"groups",
        "sync-type":"all"
      }
    ]
  }
}
{code}

The values for the state property will be PENDING, RUNNING, COMPLETE.  The result values will
be null until the state is COMPLETE.

When an event is COMPLETE, the ldap user / group / member resources of Ambari should have
been updated accordingly.

Note that the results do not show the specific users and groups that were synced, only the
totals.  The specific users and groups touched by the sync can be added if required. 

Also note that this revised proposal removes the LDAP_SYNC resource as a root level service.
 It doesn't seem to be needed to meet the current requirements.  We can add it later, if needed.


  was:

Revised LDAP_SYNC API Proposal...

The ldap sync request resource contains the information needed to perform an ldap sync.  This
includes the principal type (user, group), the sync type (all, existing, specific), and an
optional set of principal names.  Wildcards will be supported for principal names.  You can
mix and match specs, so it is possible to have a request that syncs all users but specific
groups, for example.

--  Create ldap sync requests ...
{code}
POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests
{
  "specs" : [
    {
      "principal-type":"users",
      "sync-type":"all"
    },
    {
      "principal-type":"groups",
      "sync-type":"all"
    }
  ]
}


POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests
{
  "specs" : [
    {
      "principal-type":"users",
      "sync-type":"existing"
    },
    {
      "principal-type":"groups",
      "sync-type":"existing"
    }
  ]
}

POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests
{
  "specs" : [
    {
      "principal-type":"users",
      "names":"fred,joe,admin*",
      "sync-type":"specific"
    },
    {
      "principal-type":"groups",
      "names":"group1,group2,admin*",
      "sync-type":"specific"
    }
  ]
}
{code}

When you create a request it is assigned a unique id.
The response of each post will contain the href to the new ldap sync request resource.  For
example, 
{code}"href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/1"{code}
The requests are not persisted in the DB.  We will keep them in memory only for now, possibly
with an expiry value.  If there is a need to persist them beyond a stop then we can add the
DB persistence later.

When a request is added, it will be placed on a queue.  Requests will be serviced sequentially
(for now we will not handle concurrent syncing).  

Request will be run as they are taken off the queue.  In the future we may add the ability
to schedule requests. 


--  Get all of the sync requests ...
{code}
GET http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests
{
  "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/",
  "items" : [
    {
      "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/1",
      "Request" : {
        "id":1
      },
      "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/2",
      "Request" : {
        "id":2
      },
      "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/3",
      "Request" : {
        "id":3
      },
    }
  ]
}
{code}

You can view a specific sync request.

--  Get a specific sync request ...
{code}
GET http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/1
{
  "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-requests/1/",
  "Request":{
    "id":1,
    "state":"COMPLETE",
    "sync-start-time":"10/12/2004 12:14:26.002"
    "sync-end-time":"10/12/2004 12:15:36.006"
    "users-fetched":200,
    "users-created":12,
    "users-updated":4,
    "users-removed":5,
    "groups-fetched":10,
    "groups-created":3,
    "groups-updated":2,
    "groups-removed":1,
    "membership-fetched":20,
    "membership-created":1,
    "membership-updated":5,
    "specs" : [
      {
        "principal-type":"users",
        "sync-type":"all"
      },
      {
        "principal-type":"groups",
        "sync-type":"all"
      }
    ]
  }
}
{code}

The values for the state property will be PENDING, RUNNING, COMPLETE.  The result values will
be null until the state is COMPLETE.

When a request is COMPLETE, the ldap user / group / member resources of Ambari should have
been updated accordingly.

Note that the results do not show the specific users and groups that were synced, only the
totals.  The specific users and groups touched by the sync can be added if required. 

Also note that this revised proposal removes the LDAP_SYNC resource as a root level service.
 It doesn't seem to be needed to meet the current requirements.  We can add it later, if needed.



> Admin : LDAP Sync API to support sync events
> --------------------------------------------
>
>                 Key: AMBARI-7349
>                 URL: https://issues.apache.org/jira/browse/AMBARI-7349
>             Project: Ambari
>          Issue Type: Task
>            Reporter: Tom Beerbower
>            Assignee: Tom Beerbower
>             Fix For: 1.7.0
>
>
> Revised LDAP_SYNC API Proposal...
> The ldap sync event resource contains the information needed to perform an ldap sync.
 This includes the principal type (user, group), the sync type (all, existing, specific),
and an optional set of principal names.  Wildcards will be supported for principal names.
 You can mix and match specs, so it is possible to have an event that syncs all users but
specific groups, for example.
> --  Create ldap sync events ...
> {code}
> POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
> {
>   "specs" : [
>     {
>       "principal-type":"users",
>       "sync-type":"all"
>     },
>     {
>       "principal-type":"groups",
>       "sync-type":"all"
>     }
>   ]
> }
> POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
> {
>   "specs" : [
>     {
>       "principal-type":"users",
>       "sync-type":"existing"
>     },
>     {
>       "principal-type":"groups",
>       "sync-type":"existing"
>     }
>   ]
> }
> POST http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
> {
>   "specs" : [
>     {
>       "principal-type":"users",
>       "names":"fred,joe,admin*",
>       "sync-type":"specific"
>     },
>     {
>       "principal-type":"groups",
>       "names":"group1,group2,admin*",
>       "sync-type":"specific"
>     }
>   ]
> }
> {code}
> When you create an event it is assigned a unique id.
> The response of each post will contain the href to the new ldap sync event resource.
 For example, 
> {code}"href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1"{code}
> The events are not persisted in the DB.  We will keep them in memory only for now, possibly
with an expiry value.  If there is a need to persist them beyond a stop then we can add the
DB persistence later.
> When an event is added, it will be placed on a queue.  Events will be serviced sequentially
(for now we will not handle concurrent syncing).  
> Events will be run as they are taken off the queue.  In the future we may add the ability
to schedule events. 
> --  Get all of the sync events ...
> {code}
> GET http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events
> {
>   "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/",
>   "items" : [
>     {
>       "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1",
>       "Event" : {
>         "id":1
>       },
>       "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/2",
>       "Event" : {
>         "id":2
>       },
>       "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/3",
>       "Event" : {
>         "id":3
>       },
>     }
>   ]
> }
> {code}
> You can view a specific sync event.
> --  Get a specific sync event ...
> {code}
> GET http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1
> {
>   "href" : "http://c6401.ambari.apache.org:8080/api/v1/ldap-sync-events/1/",
>   "Event":{
>     "id":1,
>     "state":"COMPLETE",
>     "sync-start-time":"10/12/2004 12:14:26.002"
>     "sync-end-time":"10/12/2004 12:15:36.006"
>     "users-fetched":200,
>     "users-created":12,
>     "users-updated":4,
>     "users-removed":5,
>     "groups-fetched":10,
>     "groups-created":3,
>     "groups-updated":2,
>     "groups-removed":1,
>     "membership-fetched":20,
>     "membership-created":1,
>     "membership-updated":5,
>     "specs" : [
>       {
>         "principal-type":"users",
>         "sync-type":"all"
>       },
>       {
>         "principal-type":"groups",
>         "sync-type":"all"
>       }
>     ]
>   }
> }
> {code}
> The values for the state property will be PENDING, RUNNING, COMPLETE.  The result values
will be null until the state is COMPLETE.
> When an event is COMPLETE, the ldap user / group / member resources of Ambari should
have been updated accordingly.
> Note that the results do not show the specific users and groups that were synced, only
the totals.  The specific users and groups touched by the sync can be added if required. 
> Also note that this revised proposal removes the LDAP_SYNC resource as a root level service.
 It doesn't seem to be needed to meet the current requirements.  We can add it later, if needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message