Open Stack

On Fri, Sep 25, 2015 at 11:01 AM, Emilien Macchi <emilien at redhat.com> wrote:
>
>
> 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).
>

I'm generally thinking the opposite of you, I'd actually love to know the
use case for anyone managing more than a few users with Puppet. We have
service users and a few accounts for things like backups, monitoring etc.
Beyond that, the accounts are for actual users and they have to follow an
intake and project creation process that also handles things like networks.
We found this workflow much easier to script with python and it can also be
done without a deploy. This is all handled by a manager after ensuring that
OpenStack is the right solution for them, finding project requirements,
etc. So I think this is what many folks are doing, their user creation
workflow just doesn't mesh with puppet and their puppet deployment process.
 (This also discounts password management, something I don't want to be
doing for users with puppet)



>
> 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]
>

I looked into this when we deployed but could not come up with a great
solution that didn't involve declaring a master node on which keys were
generated. Would be happy to re-investigate or work with someone on this.


>
> * "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
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150927/0dc70888/attachment.html>