yahoo-eng-team team mailing list archive

[Colleen Murphy <colleen@xxxxxxxxxxx>]

We dropped the V2 API, plus refactoring our API controllers to use Flask
means that Flask now can handle all of the view rendering, so this work
is not as important any more. Closing as won't fix, feel free to reopen
if this is something that should be revisited.

** Changed in: keystone
       Status: Triaged => Won't Fix

-- 
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):
  Won't Fix

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