Hi,
As some of you may know, I have a weekly meeting with some of the Red
Hat folks who are out in the field using TripleO to deploy OpenStack at
customer sites. The past couple of weeks have been particularly
interesting, so I thought I'd take a moment to disseminate the comments
to the broader developer community. I'll try to keep it from getting
too wall-of-texty, but no promises. :-)
Here goes:
* There was interest in using split stack to avoid having to use
TripleO's baremetal provisioning. I let them know that technically
split stack was possible in Newton and that further usability
improvements were coming in Ocata and Pike. Keep in mind that for many
of these companies Newton is still a new shiny thing that they're
looking to move onto, so even though this functionality seems like it's
been around for a long time to us that isn't necessarily the case in the
field.
* Some concerns around managing config with TripleO were raised,
specifically two points: 1) Stack updates can cause service outages,
even if you're just looking to change one minor config value in a single
service. 2) Stack updates take a long time. 45 minutes to apply one
config value seems a little heavy from a user perspective.
For 1, I did mention that we had been working to reduce the number of
spurious service restarts on update. 2 is obviously a little trickier.
One thing that was requested was a mode where a Puppet step doesn't get
run unless something changes - which is the exact opposite of the
feedback we got initially on TripleO. Back then people wanted a stack
update to assert state every time, like regular Puppet would. There
probably weren't enough people in this discussion to take immediate
action on this, but I thought it was an interesting potential change in
philosophy. Also it drives home the need for better performance of
TripleO as a whole.
* For large scale deployments there was interest in leveraging the
oslo.messaging split RPC/notifications. Initially just separate Rabbit
clusters, but potentially in the future completely different drivers
that better suit the two different use cases. Since this is something I
believe operators are already using in the field, it would be good to
get support for it in TripleO. I suggested they file an RFE, and I went
ahead and opened a wishlist bug upstream:
https://bugs.launchpad.net/tripleo/+bug/1693928
And although I have a bunch more, I'm going to stop here in an attempt
to avoid complete information overload. I'll send another email (or
two...) another day with some of the other topics that came up.
Thanks.
-Ben
__________________________________________________________________________
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
