Open Stack

On Monday, September 29, 2014, Julien Danjou <julien at danjou.info> wrote:

> On Mon, Sep 29 2014, Jay Pipes wrote:
>
> > Any objection to me taking up the work? Was there any associated
> blueprint for
> > it?
>
> As said on IRC, go ahead. There's no blueprint associated AFAIK. :)
>
> --
> Julien Danjou
> /* Free Software hacker
>    http://julien.danjou.info */
>

There is of course a benefit to having more options for deployers to
utilize for the token persistence, especially if we solve complaints about
the current token systems in the process.

A couple thoughts:

I highly recommend making this a dogpile backend (KVS) in keystone. It
should help eliminate a bunch of the harder bits of code since it will use
the KVS house keeping code for the indexes (same way it works in memcache
or the in-memory dict backend).

The big issue you're going to run into is locking. The indexes need to have
a distributed lock that guarantees that each index is read/updated/released
atomically (similar to the SQL transaction). The way memcache and redis
handle this is by trying to add a record that is based on the index record
name and if that "add" fails (already exists) we assume the referenced
record is locked. We automatically timeout the lock after a period of time.

I am also curious what the performance profile of swift-as-a-token-backend
will look like. You are adding a large amount of overhead to the request
(in theory) as the swift call is another http request. And depending on how
swift is running, may require more token request work (tokens, especially
v2.0 since he token is is in the body must be considered secure data, and
therefore should not be directly accessible to the world at large), keeping
security concerns in mind.

There are some other cool ideas this can lead to, but let's talk about the
reality and limitations (and how we solve those issues) for our current use
cases before we dive into the next steps.

The first thing we will need is (of course) a spec for keystone. Let's try
and get the spec proposed soon so we can ensure that we get anything that
needs to land in kilo through the door earlier in the cycle.

Cheers,
Morgan

Sent via mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140929/8d8a198b/attachment.html>