yahoo-eng-team team mailing list archive

[Morgan Fainberg <morgan.fainberg@xxxxxxxxx>]

This functionality already exists within the API. It is not well
documented - but in essence for many entity-types you can pass arbitrary
attribute/value pairs in the update/create process and store them within
the entity.

Largely this has been discussed as something we would like to *stop*
supporting because it makes for clearly validating the inputs to the API
very difficult (and allows for an unbounded dataset to be added anywhere
these entities accept it). You can see in the dictbase (the link you
provided shows inheritance from DictBase object:
https://github.com/openstack/keystone/blob/8fb62f7b0edff8aecd12f4a3eaffe742b29a40db/keystone/common/sql/core.py#L121-L153
)

In short, yes you can do this, however not all backends supported by
Keystone support this well (nor uniformly).

- Marking as invalid as this functionality largely already exists (we
lack good "statuses" for cases like this in LaunchPad and don't have an
"already exists" status to use)

** Changed in: keystone
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1390922

Title:
  storing extra attributes of user in keystone

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  Hi there,

  I am working on a rails app which provides some functionality on top
  of OpenStack and I want to use keystone for authentication as I don't
  like to have user information in multiple places. Now, the problem is
  that I can not store more information about user other than id, name,
  domain_id, password, enabled, and default_project_id*. I was wondering
  if you be interested in having implamentation of a key-value pair for
  user to store extra information. If yes, I would like to work on it.

  It can be really helpful for projects like ours to avoid storing user
  information in multiple places. In the simplest scenario, extra
  information can be stored as a json (or yaml or whatever) in a text
  column. Or to keep it more SQL-ish, it can be implemented with entity-
  attribute-value pattern.

  *https://github.com/openstack/keystone/blob/8fb62f7b0edff8aecd12f4a3eaffe742b29a40db/keystone/identity/backends/sql.py#L32

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1390922/+subscriptions