[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. Best regards, Pavlo Shchelokovskyy. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Nova-network support
On 07/14/2014 10:38 AM, Pavlo Shchelokovskyy wrote: > 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). That is still the current status from my perspective, at least. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Nova-network support
> From: Pavlo Shchelokovskyy > To: "OpenStack Development Mailing List (not for usage questions)" > > 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. 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. Regards, Thomas > > Best regards, > Pavlo Shchelokovskyy. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2014-January/ > 025824.html___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Nova-network support
On 15/07/14 05:12, Thomas Spatzier wrote: >> From: Pavlo Shchelokovskyy >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> 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