<div dir="ltr">Hi Heaters,<div><br></div><div>I would like to start a discussion about Heat and nova-network. As far as I understand nova-network is here to stay for at least 2 more releases [1] and, even more, might be left indefinitely as a viable simple deployment option supported by OpenStack (if anyone has a more recent update on nova-network deprecation status please call me out on that).</div>

<div><br></div><div>In light of this I think we should improve our support of nova-network-based OpenStack in Heat. There are several topics that warrant attention:</div><div><br></div><div>1) As python-neutronclient is already set as a dependency of heat package, we need a unified way for Heat to "understand" what network service the OpenStack cloud uses that does not depend on presence or absence of neutronclient. Several resources already need this (e.g. AWS::EC2::SecurityGroup that currently decides on whether to use Neutron or Nova-network only by a presence of VPC_ID property in the template). This check might be a config option but IMO this could be auto-discovered on heat-engine start. Also, when current Heat is deployed on nova-network-based OpenStack, OS::Neutron::* resources are still being registered and shown with "heat resource-type-list" (at least on DevStack that is) although clearly they can not be used. A network backend check would then allow to disable those Neutron resources for such deployment. (On a side note, such checks might also be created for resources of other integrated but not bare-minimum essential OpenStack components such as Trove and Swift.)</div>

<div><br></div><div>2) We need more native nova-network specific resources. For example, to use security groups on nova-network now one is forced to use AWS::EC2::SecurityGroup, that looks odd when used among other OpenStack native resources and has its own limitations as its implementation must stay compatible with AWS. Currently it seems we are also missing native nova-network Network, Cloudpipe VPN, DNS domains and entries (though I am not sure how admin-specific those are).</div>

<div><br></div><div>If we agree that such improvements make sense, I will gladly put myself to implement these changes.</div><div><br></div><div>Best regards,</div><div>Pavlo Shchelokovskyy.</div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html">http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html</a></div>

</div>