Open Stack

On 15/07/14 05:12, Thomas Spatzier wrote:
>> From: Pavlo Shchelokovskyy <pshchelokovskyy at mirantis.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at 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