Open Stack

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