Open Stack

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

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev