yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

(The description below was originally provided by Jamie Lennox as a
blueprint)

Keystone has an unusual way of rendering objects that are used in
responses.

1) The objects are returned directly from the driver layer, some links
injected at the controller and then returned to the user. This means the
backend driver has full control over the representation of objects. This
is really bad form and doesn't help for people who are implementing
their own drivers because they are capable of accidentally polluting the
output and then relying on it.

2) The Controllers handle the links generation - however, there are more
controllers than types. For example Projects are handled from the
regular projects urls, auth urls, catalog urls and federation urls. To
make this rendering work you then need to import the base projects
controller into all these other places so that they can work. In some
cases, this is done as a subclass which makes this harder. These could
each be individual views that know how to render a project and then used
where appropriate.

3) Because of the direct link from backend to user representation, it
imposes a v3 representation on the objects in the database. These two
things should not be equivalent. There is information that should be
added and removed from objects before they are saved to the database and
this direct representation means you have to have a lot of care. This
also means there are a number of places that are doing a v3_to_v2
conversion - which should really just be 2 different representations of
the same model.

4) Again because of the direct representation it is really difficult to
audit the expected output of a resource. Often the authoritative source
of what a resource looks like is the SQL Alchemy resource.

5) If we go down the micro version path this negotiation gets
complicated and all mixed up with the representation layer.

We should remove response rendering from the controllers in favour of a
views layer that is purely about rendering. This is a very standard
pattern in web services.

** Affects: keystone
     Importance: Wishlist
         Status: Triaged

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

** Changed in: keystone
   Importance: Undecided => Wishlist

** Description changed:

+ (The description below was originally provided by Jamie Lennox as a
+ blueprint)
+ 
  Keystone has an unusual way of rendering objects that are used in
  responses.
  
  1) The objects are returned directly from the driver layer, some links
  injected at the controller and then returned to the user. This means the
  backend driver has full control over the representation of objects. This
  is really bad form and doesn't help for people who are implementing
  their own drivers because they are capable of accidentally polluting the
  output and then relying on it.
  
  2) The Controllers handle the links generation - however, there are more
  controllers than types. For example Projects are handled from the
  regular projects urls, auth urls, catalog urls and federation urls. To
  make this rendering work you then need to import the base projects
  controller into all these other places so that they can work. In some
  cases, this is done as a subclass which makes this harder. These could
  each be individual views that know how to render a project and then used
  where appropriate.
  
  3) Because of the direct link from backend to user representation, it
  imposes a v3 representation on the objects in the database. These two
  things should not be equivalent. There is information that should be
  added and removed from objects before they are saved to the database and
  this direct representation means you have to have a lot of care. This
  also means there are a number of places that are doing a v3_to_v2
  conversion - which should really just be 2 different representations of
  the same model.
  
  4) Again because of the direct representation it is really difficult to
  audit the expected output of a resource. Often the authoritative source
  of what a resource looks like is the SQL Alchemy resource.
  
  5) If we go down the micro version path this negotiation gets
  complicated and all mixed up with the representation layer.
  
  We should remove response rendering from the controllers in favour of a
  views layer that is purely about rendering. This is a very standard
  pattern in web services.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1815972

Title:
  RFE: Use views effectively

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  (The description below was originally provided by Jamie Lennox as a
  blueprint)

  Keystone has an unusual way of rendering objects that are used in
  responses.

  1) The objects are returned directly from the driver layer, some links
  injected at the controller and then returned to the user. This means
  the backend driver has full control over the representation of
  objects. This is really bad form and doesn't help for people who are
  implementing their own drivers because they are capable of
  accidentally polluting the output and then relying on it.

  2) The Controllers handle the links generation - however, there are
  more controllers than types. For example Projects are handled from the
  regular projects urls, auth urls, catalog urls and federation urls. To
  make this rendering work you then need to import the base projects
  controller into all these other places so that they can work. In some
  cases, this is done as a subclass which makes this harder. These could
  each be individual views that know how to render a project and then
  used where appropriate.

  3) Because of the direct link from backend to user representation, it
  imposes a v3 representation on the objects in the database. These two
  things should not be equivalent. There is information that should be
  added and removed from objects before they are saved to the database
  and this direct representation means you have to have a lot of care.
  This also means there are a number of places that are doing a v3_to_v2
  conversion - which should really just be 2 different representations
  of the same model.

  4) Again because of the direct representation it is really difficult
  to audit the expected output of a resource. Often the authoritative
  source of what a resource looks like is the SQL Alchemy resource.

  5) If we go down the micro version path this negotiation gets
  complicated and all mixed up with the representation layer.

  We should remove response rendering from the controllers in favour of
  a views layer that is purely about rendering. This is a very standard
  pattern in web services.

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