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.ade...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev