On 09/21/2015 12:20 PM, Emilien Macchi wrote: > Hi, > > Puppet OpenStack group would like to know your feedback about using > puppet-keystone module. > > Please take two minutes and feel the form [1] 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, > > [1] http://goo.gl/forms/eiGWFkkXLZ >
So after 5 days, here is a bit of feedback (13 people did the poll [1]): 1/ Providers Except for 1, most of people are managing a few number of Keystone users/tenants. 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"": See http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/enabling-federation.html * "Management of fernet keys": nothing *yet* in our roadmap AFIK, adding it in our backlog [2] * "Support for hybrid domain configurations (e.g. using both LDAP and built in database backend)": http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html * "Full v3 API support (depends on other modules beyond just puppet-keystone)": http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html * "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 [3] 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 [4] 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 the answers) * "(...) 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 about that. * "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 [5]. * "Currently does not handle deployment of hybrid domain configurations." Ditto: http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html 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 the poll. [1] https://docs.google.com/forms/d/1Z6IGeJRNmX7xx0Ggmr5Pmpzq7BudphDkZE-3t4Q5G1k/viewanalytics [2] https://trello.com/c/HjiWUng3/65-puppet-keystone-manage-fernet-keys [3] http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/master-policy.html [4] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069147.html [5] https://bugs.launchpad.net/puppet-keystone/+bug/1493450 -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
