[openstack-dev] new keystone developer

Dolph Mathews dolph.mathews at gmail.com
Thu Jan 23 14:05:56 UTC 2014


First of all, welcome! As Steve suggested, feel free to ask questions in
#openstack-dev ... it seems there's almost always someone online with deep
knowledge of keystone.

On Wed, Jan 22, 2014 at 8:28 PM, Mario Adessi <mario.adessi at live.com> wrote:

> I'd like to begin contributing to the keystone project.
>
> Keystone, along with all the other major infrastructure components in
> OpenStack, is a rather large project. I've read over the developer
> documentation<http://docs.openstack.org/developer/keystone/#developers-documentation>,
> but was hoping to get help with some questions.
>
> (1) Are there diagrams that describe how various classes, functions, etc.
> interact with one another?
>

I've seen a few in the past, but they tend to get out of date quickly. At a
high level, the application is structured as follows:

  Paste Pipeline -> Routers -> Controllers -> Managers -> Drivers /
Backends (SQL, LDAP, KVS, etc)

And that's been true since the essex release. There are a few code paths
that deviate from this naming convention (such as keystone.auth), but they
follow the same basic pattern regardless. Database migrations have
relatively flat call stacks. Some tests have a rather "challenging"
inheritance hierarchy that we're working to unwind.


>
> (2) What's the best way to debug keystone when editing existing code or
> adding? Tips from those who do this every day would be greatly appreciated.
>

I feel like I'm one of the remaining few that doesn't use any fancy tools.
I write tests, hammer on them repeatedly, and read tracebacks.


>
> (3) Is there a way to import large chunks (or, preferably, all) of
> keystone into iPython? This makes debugging super easy and would fit in
> nicely with my existing workflow with other projects.
>

Sounds like Yuriy has the answer you're looking for here!


>
> (4) Any other tips / tricks to help jumpstart tinkering with code?
>

I always encourage people to jump straight into gerrit and participate in
some code reviews. It's the best way to get a sense of the direction of the
project as it evolves, and at the end of the day, you'll be much better
prepared to produce your own patch(es).


>
> Many thanks.
> -mario
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/5c1fc97a/attachment.html>


More information about the OpenStack-dev mailing list