The keystone team participates in open source internship programs such as Outreachy and Google Summer of Code and welcomes contributions from students and developers of all skill levels. To help with formal applications for work programs or to give casual contributors a taste of what working on keystone is like, we’ve created a few exercises to showcase what we think are valuable development skills.
These exercises are samples, and code produced to solve them should most likely not be merged into keystone. However, you should still propose them to Gerrit to get practice with the code review system and to get feedback from the team. This is a good way to get used to the development workflow and get acquainted with the benefits of working in a collaborative development environment. Also feel free to talk to the keystone team to get help with these exercises, and refer to the contributor documentation for more context on the architecture and contributing guidelines for keystone.
The exercises provide some ideas of what you can do in keystone, but feel free to get creative.
Add a string parameter named nickname
to the Project API. The end result will
be that you can use the new parameter when you create a new project using the
POST /v3/projects API, update the parameter using the PATCH
/v3/projects/{project_id} API, and the value displayed using the GET
/v3/projects/{project_id}.
Refer to the API Change tutorial. In short, you will need to follow these steps:
Create a SQL migration to add the parameter to the database table
(keystone.common.sql.migrations.versions
)
Add a SQL migration unit test (keystone/tests/unit/test_sql_upgrade.py)
Add the parameter to the SQL model for projects
(keystone.resource.backends.sql
)
Add unit tests (keystone/tests/unit/resource/test_backend.py) for the
manager (keystone.resource.core
) to show that the project can be
created and updated with the new parameter using the provider mechanism
Add the parameter to the API schema (keystone.resource.schema
)
Add an API unit test (keystone/tests/unit/test_v3_resource.py)
Document the new parameter in the api-ref
Write an external driver named file
that implements the Project API. The end
result will be that you can set [resource]/driver = file
in keystone.conf
to have keystone load a list of project names from a text file, and querying
keystone for projects will return projects with those names in the default
domain.
Refer to the Developing Keystone Drivers
tutorial. Your driver can start as
an in-tree driver: create a class named Resource
in
keystone/resource/backends/file.py that implements
keystone.resource.backends.base.Resource
. Once you have that working,
break it out into a separate repository and create a Setuptools entrypoint
to allow you to register it with keystone.
Write an auth plugin named hacker
that allows any existing user to
authenticate if they provide a valid username and the password "hax0r"
. The
end result will be that you can add hacker
as an auth method in
[auth]/methods
in keystone.conf, and users will be able to get an
unscoped token using POST /v3/auth/tokens and providing "hacker"
as
the auth method, a valid username as the username, and "hax0r"
as the
password.
Refer to the Authentication Plugins documentation. You should create a class
Hacker
in keystone/auth/plugins/hacker.py that implements
keystone.auth.plugins.base.AuthMethodHandler
. For bonus points, also
add the plugin to keystoneauth so that Python clients can also use this auth
method.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.