[openstack-dev] [Heat] Nova-network support

Pavlo Shchelokovskyy pshchelokovskyy at mirantis.com
Mon Jul 14 14:38:57 UTC 2014


Hi Heaters,

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).

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:

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.)

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).

If we agree that such improvements make sense, I will gladly put myself to
implement these changes.

Best regards,
Pavlo Shchelokovskyy.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140714/ea702d9c/attachment.html>


More information about the OpenStack-dev mailing list