<div dir="ltr">Hi Everyone,<div><br></div><div>I'm interested in any information around determining the supported feature set for individual OpenStack installations. Our product works with multiple cloud providers, and with the great stability and usability improvements in Havana and Icehouse, we've seen a lot of the installations we work with migrate forward. Today we see grizzly being phased out, Havana seeing pretty good use, and Icehouse being adopted.  The improvements in Juno, Kilo and beyond seem likely to continue to push this trend, but it also seems likely we will see a lot of installations stick with what works.</div>
<div><br></div><div>Just between Grizzly and Icehouse we have some pretty significant variances in how we need to work with the API.  The progression of Neutron as a replacement/alternative for Nova networking and the introduction of Projects are two areas that require a lot more than just calling a different API endpoint.</div>
<div><br></div><div>Up to this point, we find ourselves individually picking out support features, but as the feature matrix grows and cross-dependencies develop, this seems likely to become overwhelming. From our perspective it will be critical to define a restricted set of minimally-supported-feature-sets (i.e. "Icehouse with Neutron networking" vs "Icehouse with Nova networking"), and it would go a long way if OpenStack itself maintained at least a list of such recommended "baselines" and ideally exposed the available baseline through the API in a more direct manner than querying for each individual feature.<br clear="all">
<div><br></div><div>Is there any existing work/plans/thoughts in this area?</div><div><br></div><div>Is this something that would be seen as valuable to usability or a hindrance to experimentation and development?</div><div>
<br></div>-- <br><div dir="ltr">Andrew Mann<div>DivvyCloud Inc.</div><div><a href="http://www.divvycloud.com" target="_blank">www.divvycloud.com</a></div></div>
</div></div>