On 15/07/14 05:12, Thomas Spatzier wrote: >> From: Pavlo Shchelokovskyy <pshchelokovs...@mirantis.com> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: 14/07/2014 16:42 >> Subject: [openstack-dev] [Heat] Nova-network support >> >> 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. An OS::Nova::SecurityGroup would be welcome. This may be the only gap for non-admin and non-esoteric nova-networking resources.
> I think those improvements do make sense, since neutron cannot be taken as > a given in each environment. > > Ideally, we would actually have a resource model that abstract from the > underlying implementation, i.e. do not call out neutron or nova-net but > just talk about something like a FloatingIP which then gets implemented by > a neutron or nova-net backend. Currently, binding to either option has to > be explicitly defined in templates, so in the worst case one might end up > with two complete separate definitions of the same thing. > That said, I know that it will probably be hard to come up with an > abstraction for everything. I also know that provider templates could also > partly solve the problem today, but many users probably do not know how to > apply them. > Some level of abstraction could also help to make some changes in > underlying API transparent to templates. > Anyway, I wanted to throw out the idea of some level of abstraction and see > what the reactions are. > For security groups OS::Nova::SecurityGroup could be that abstraction since nova proxies to neutron when required. For floating IPs I would like to see the networks property on OS::Nova::Server become much richer so that all port and floating IP properties can be specified inline with the server rather than in separate resources. Having a subset of properties here which work on both nova-networking and neutron seems reasonable. This isn't on my radar but I would happily help anyone who wants to take this on. cheers _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev