Archive

Archive for the ‘openstack’ Category

OpenStack Austin summit in pictures

 

Heading to OpenStack summit

 

DSC03544.JPG

 

@ Austin Convention Center entrance.

 

DSC03520.JPG

 

@ Austin Convention Center entrance.

 

DSC03558

 

OpenStack crowd.

 

20160425_111058

 

Brand yourself with OpenStack

 

DSC03548.JPG

 

Under OpenStack umbrella. 

 

DSC03524

 

Youngest OpenStack enthusiast

 

20160425_194202

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Keynotes

 

20160425_105048

 

Break out sessions.

 

20160425_140521.jpg

 

@ Break.

 

20160425_170206.jpg

 

@MarketPlace

 

DSC03525

 

Marketplace Theater.

 

DSC03535.JPG

 

ORACLE @ marketplace

 

DSC03538.JPG

 

ubuntu @ marketplace

 

DSC03541.JPG

 

vmware @marketplace

 

DSC03530

 

Mirantis @marketplace

 

DSC03543.JPG

 

 

Advertisements
Categories: openstack, Uncategorized

DevStack Configuration Files

Here are some configuration files for devstack settings [1].

 

localrc

localrc is the old file used to configure DevStack. It is deprecated and has been replaced by local.conf. DevStack will continue to use localrc if it is present and ignore the localrc section in local.conf.. Remove localrc to switch to using the new file. [2]

This file contains  default passwords (for admin, database, rabitmq, etc), IP address settings and setting for services to be installed.

 

stackrc

stackrc is the primary configuration file for DevStack. It contains all of the settings that control the services started and the repositories used to download the source for those services. stackrcsources the localrc section of local.conf to perform the default overrides. [3]

This file contain git location for the repositories to download devstack codes from.

 

openrc

openrc configures login credentials suitable for use with the OpenStack command-line tools. openrc sources stackrc at the beginning (which in turn sources the localrc section of local.conf) in order to pick up HOST_IP and/or SERVICE_HOST to use in the endpoints.  [4]

 

References:

[1] http://docs.openstack.org/developer/devstack/

[2] http://docs.openstack.org/developer/devstack/localrc.html

[3] http://docs.openstack.org/developer/devstack/stackrc.html

[4] http://docs.openstack.org/developer/devstack/openrc.html

Categories: openstack, Uncategorized

Relationship among concepts domain, project, role, user group, user and token in OpenStack Keystone

Domain, project, group, roles, users and token are the terms we use to hear a lot in term of OpenStack. Sometime, the meaning of these terms changes. For example, the semantics of the terms project, tenant, domain keep changing even in the Identity API. In this post, I will try to understand the relationship between these concepts. My understanding is based on the OpenStack Identity API V3[1] and the paper by Bo [7]

Screenshot 2016-03-09 11.56.49

Domain:

Domains are the highest level abstraction for resources and users in an OpenStack environment. Domain can directly contain users, user groups and projects. If there is no domain, Identity V3 API assumes a default domain named ‘default’. Domains can also be considered as namespaces. Domain names must be unique across all domains. 

Projects:

Projects are the second highest abstraction in OpenStack environment. Projects can directly contain user groups or users. Project can also contain resources. Note that, one project can be assigned to at most one domain. 

User groups:

As the name says, user groups are group of users. The advantage of having user groups is that by assigning roles to a user group, all users in the group get permissions of the roles. For example, an user group ‘CS6393’ may contain students in the course. By assigning  roles to ‘CS6393’ all students get access to the permissions of the roles. User group names are not global in OpenStack environment. Group names are unique within the owning domain and a group can be assigned to at most domain. 

Roles:

In OpenStack, permissions to do anything is achieved via assignment to roles. Users or user groups  without any role assigned, can do nothing in the OpenStack environment. As in Role Based access Control (RBAC [2]), role contains permission which is a pair of object-type and operation. For example, create object of type VM or network can be considered as a permission. Note that role name are global in OpenStack environment. In other words, no two role can have the same name.

Users:

Users are the active entity in the OpenStack system who can consume resources. Users are assigned to role to be able to carry on their activity. Users without any role, cannot do anything in the system, though it is possible to have users without any roles assigned to them.

Tokens:

Tokens are like sessions/subjects acting on behalf of users. Basically, a token provide a stricter scope for a user. For example, if a user is assigned to two different projects ‘project1’ and ‘project2’, in a token a user can choose which project to work on. Similarly, token also provide scope for domains. Usually, a token can either be scoped for a project or a domain but not both.

Reference:

[1] http://developer.openstack.org/api-ref-identity-v3.html

[7] http://profsandhu.com/confrnc/misconf/p131-zhang.pdf

To be continued.

OpenStack Developer Starter Guide

February 29, 2016 Leave a comment

In this post, I will show the steps for becoming an OpenStack developer. At the end of this post, you expect to see some of your commit in OpenStack Review system (gerrit).

Without going details, I will clarify some terminologies.

Launchpad:

Launchpad is a single sign on system by ubuntu. By signing in Launchpad, a developer potentially signs in most required places.  Launchpad is available at:  https://login.launchpad.net/OaKOEDqhQjGmfa1O/+decide

 

Unassigned bugs of all OpenStack projects, blueprints   are also available in OpenStack launchpad. For example, to see unassigned bugs and blueprint of OpenStack Identity (Keystone) service visit https://launchpad.net/keystone. After, bugs are assigned to somebody they are shown in Gerrit.

 

Screenshot 2016-03-07 18.54.00

Keystone Launchpad showing latest reported bug and blueprints

 

Gerrit

Gerrit is a free, web-based team code collaboration tool. OpenStack (OS) uses this for the code review process. All most every reviews in OS goes through this. Gerrit is available here: https://review.openstack.org/#/dashboard/self. After, a developer is assigned to a bug/blueprint and the development and review is on progress, it is shown in gerrit review system.

 

Jenkins:

Jenkins is an open source continuous integration tool.

 

The summary of the flow to complete the logistics for submitting code is kinda as follows.
openstart-developer-starter

Steps for registering as a new developer

To be continued.

Categories: openstack, Uncategorized

Create a new database table and use it from OpenStack Keystone

For my research project, I came across a scenario where I need to store certain new policies  in Keystone and need to access it from Swift. I take the challenges for implementing this in OpenStack in two subproblems.

 

 

  1. Create and store policies in a new table in OpenStack Keystone
  2. Pass the policies as token data and receive them in OpenStack Swift.

 

For the 2nd part of the problem I had another blog post. Find it here. In this post, I tickle the first problem.

 

I visualize creating and storing policies as a OpenStack Keystone table into four small problems as

  1. Create a new database table (lets name it labac. Yes, I am assuming keystone is using mysql as backend)
  2. Create a python class (say LabacObj) to perform CRUD operations on the table.
  3. Add methods to interact with the LabacObj objects
  4. Recipe is ready. How to serve the dinner.

 

Create a new Database Table:

To have some basic idea on how OpenStack use mysql table in backend see this post. Nonetheless, where I am reiterating the steps.

 

 

mysql -u root # log into mysql databases for OpenStack

show databases; # it shows all OpenStack tables.

use keystone; # use specific Keystone database

show tables; # show all tables in keystone database

# Now I add a new table called labac.

create table labac (id varchar(64), project_id varchar(64), policy varchar(256))

# insert values in the newly created table.

insert into labac(project_id, policy) values(1,100,”first policy”);

insert into labac(project_id, policy) values(1,100,”second policy”);

insert into labac(project_id, policy) values(1,100,”third policy”);

 

 

lets see some screenshots. This completes our first part of our problem.

 

 

Screenshot 2015-12-08 16.25.59

 

 

Screenshot 2015-12-08 16.26.19

 

 

Screenshot 2015-12-08 16.26.47

 

Create Python class to handle the new database:

Keystone (and all other OpenStack services) use wrapper python class to access a database table. So, we do this too. To manage User, Roles, Domain, Project and other resources (Trust, Token and so on)  keystone database has one (or more) table for each of them. These tables are managed by various internal APIs inside keystone.

 

 

Screenshot 2015-12-08 16.39.06

 

 

For example, inside token controller (see figure above), we can see assignment_api, catalog_api, identity_api, resource_api and so on. Of them, identity_api handles “user” table and methods involving users (and some of project, domains and so on). On the other hand, resource_api handles domain table, project table. I choose my newly create labac table to be handled by resource_api. So, I add an interface object in the resource_api. I modified the following file in order to do it

 

 

/opt/stack/keystone/keystone/resource/backends/sql.py

 

 

Screenshot 2015-12-08 16.45.43

 

 

As we can see LaBAC class in the above figure, is a python obj to handle to labac table. Data type and size of the columns in the table should be reflected in the python class.

Add interface methods for CRUD operations:

The interface methods for CRUD operation is added in the same file. Following screenshot show how to query all the policy from the table for a given project_id.

 

 

Screenshot 2015-12-08 16.48.13

 

 

Additionally, we need to update a new method in the interface of the resource_api which is at the following file

 

 

/opt/stack/keystone/keystone/resource/core.pyScreenshot 2015-12-08 16.51.32

 

Serve your recipe: 

By this time we have done enough for creating labac mysql table, python object and CRUD methods. In this case, I need to retrieve these policies and pass them  at the time of creating/verifying token. So, I add them in the following file

 

 

/opt/stack/keystone/keystone/token/providers/common.py

 

 

 

Screenshot 2015-12-08 16.57.00

 

 

and this is the place where I can add new values to be passed to keystone token. In my case, I am passing “lebac_policy” and its value is coming from the labac table as you can see I call resouce_api and my CRUD method from here.

🙂

 

Categories: openstack, Uncategorized

Pass custom info as part of OpenStack Keystone token

December 7, 2015 1 comment

It happened to happen that with OpenStack Keystone token I need to pass additional information besides standard token info. For the sake of clarity lets assume that at the time of creating and passing a fresh token from keystone besides standard token info,  I need to pass an additional (key,value) pair (‘—Test—‘ , ‘Testing’). For my case, I was storing a custom policy with keystone for each user. So when a user, request for a token, the token contains the policy.

 

In order to accomplish this, I did following change in the process of creating a v2_authorization_token in following file

#assuming my keystone service is installed in /opt/stack

/opt/stack/keystone/keystone/token/providers/common.py 

The issue_v2_token() method after adding custom token info looks likeScreenshot 2015-12-07 17.34.17

Here “token_data” contains all the data that are passed as the token. Note the method _get_token_id(token_data)   this method encrypts the token data and pass the token data as token_id of the token. Note that, our custom line should be above the method of _get_token_id(token_data) (which is in line 491).

Now, how do we check we have actually passed additional token info ?  In my case, I need this additional token data in OpenStack Swift service. Lets dive into how we make this sure from OpenStack Swift.

 

Screenshot 2015-12-07 17.49.46

Swift Proxy-server pipeline (location: /etc/swift/proxy-server.conf)

In OpenStack Swift service pipeline (figure above), authtoken is the middlewire where we can check the token_data returned from the keystone. In my system authtoken middlewire is located in

 /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token/__init__.py

 

Screenshot 2015-12-07 17.57.30 

I added the following line (line no: 583 in the above figure) to see if data returned by the keystone token contains the  injected information.

 

self._LOG.debug(user_token)

 

I further want this additional token data to be available Swift-proxy server and Swift Object server. In order to do that I need to make sure authtoken middlewire pass this in the correct format.

 

In fact, in the same file of the authtoken middlewire,   _build_user_headers() method builds custom header that would be available in all the Swift services. So, I add following additional line 

 

rval[‘X—-TEST—–‘] = token_info[‘–TEST–‘]

 

Screenshot 2015-12-07 18.10.29

Now, I can get this extra header in all the services (Object server, account server, container server etc) of OpenStack Swift.

 

Categories: openstack, Uncategorized