[Openstack-operators] [puppet] feedback request about puppet-keystone
emilien at redhat.com
Fri Sep 25 17:01:59 UTC 2015
On 09/21/2015 12:20 PM, Emilien Macchi wrote:
> Puppet OpenStack group would like to know your feedback about using
> puppet-keystone module.
> Please take two minutes and feel the form  that contains a few
> questions. The answers will help us to define our roadmap for the next
> cycle and make Keystone deployment stronger for our users.
> The result of the forms should be visible online, otherwise I'll make
> sure the results are 100% public and transparent.
> Thank you for your time,
>  http://goo.gl/forms/eiGWFkkXLZ
So after 5 days, here is a bit of feedback (13 people did the poll ):
Except for 1, most of people are managing a few number of Keystone
I would like to know if it's because the current implementation (using
openstackclient) is too slow or just because they don't need to do that
(they use bash, sdk, ansible, etc).
2/ Features you want
* "Configuration of federation via shibboleth":
WIP on https://review.openstack.org/#/c/216821/
* "Configuration of federation via mod_mellon":
Will come after shibboleth I guess.
* "Allow to configure websso"":
* "Management of fernet keys":
nothing *yet* in our roadmap AFIK, adding it in our backlog 
* "Support for hybrid domain configurations (e.g. using both LDAP and
built in database backend)":
* "Full v3 API support (depends on other modules beyond just
* "the ability to upgrade modules independently of one another, like we
do in production - currently the puppet dependencies dictate the order
in which we do upgrades more than the OpenStack dependencies":
During the last Summit, we decided  as a community that our modules
branches will only support the OpenStack release of the branch.
ie: stable/kilo supports OpenStack 2015.1 (Kilo). Maybe you can deploy
Juno or Liberty with it, but our community does not support it.
To give a little background, we already discussed about it  on the ML.
Our interface is 100% (or should be) backward compatible for at least
one full cycle, so you should not have issue when using a new version of
the module with the same parameters. Though (and indeed), you need to
keep your modules synchronized, specially because we have libraries and
common providers (in puppet-keystone).
AFIK, OpenStack also works like this with openstack/requirements.
I'm not sure you can run Glance Kilo with Oslo Juno (maybe I'm wrong).
What you're asking would be technically hard because we would have to
support old versions of our providers & libraries, with a lot of
backward compatible & legacy code in place, while we already do a good
job in the parameters (interface).
If you have any serious proposal, we would be happy to discuss design
and find a solution.
3/ What we could improve in Puppet Keystone (and in general, regarding
* "(...) but it would be nice to be able to deploy master and the most
recent version immediately rather than wait. Happy to get involved with
that as our maturity improves and we actually start to use the current
version earlier. Contribution is hard when you folk are ahead of the
game, any fixes and additions we have are ancient already":
I would like to understand the issues here:
do you have problems to contribute?
is your issue "a feature is in master and not in stable/*" ? If that's
the case, that means we can do a better job in backport policy.
Something we already talked each others and I hope our group is aware
* "We were using keystone_user_role until we had huge compilation times
due to the matrix (tenant x role x user) that is not scalable. With
every single user and tenant on the environment, the catalog compilation
increased. An improvement on that area will be useful."
I understand the frustration and we are working on it .
* "Currently does not handle deployment of hybrid domain configurations."
I liked running a poll like this, if you don't mind I'll take time to
prepare a bigger poll so we can gather more and more feedback, because
it's really useful. Thanks for that.
Discussion is open on this thread about features/concerns mentioned in
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-operators