Horizon makes the "primary project" field mandatory while it's optional in python-keystoneclient. we discussed this in SUSE:
> > if a "primary project" is mandatory in the web interface, it should be in the
> > command line as well. or vice versa.
> Actually... why?
because consistency. because with the current state of things you are heading
for a steady stream (ok, just a trickle but steady anyway) of users asking this
question. the web ui makes it seem like the "primary project" is something
crucial, and then the command line makes clear that it's actually superfluous,
and since the user does not know (at the beginning) which it is, s/he'll be
wondering: is it a bug in keystone(1)? am i going to screw something up
horribly if i create a user with no tenantId? you'll have to document it,
people will miss the documentation and ask support anyway...
> Looking at the keystone and keystoneclient code, it's indeed
> not mandatory to provide a primary project when creating a user. But that
> doesn't mean that the webui should follow this: the webui is a simplified view
> of OpenStack and doesn't allow everything OpenStack allows.
we have one product with different interfaces. (perceived) complexity of the
overall system goes *up* as the interfaces diverge. asymmetry increases
cognitive load. also, simplified means "a subset of" to me, and you can't
change the "primary project" using keystone(1), Horizon is disjoint, maybe
complementary, but not simplified.
Consistency sounds good to me.
From the pure UI side, it looks like this could simply be a matter of calling the default option "No default project", give it a specific fake id and check for that before attempting to update the default project.
https:/
We'll also need to update the user_update() API call to avoid always trying to update the default tenant no matter what:
https:/