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

2014-07-14 Thread Pavlo Shchelokovskyy
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

2014-07-14 Thread Russell Bryant
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

2014-07-14 Thread Thomas Spatzier
> 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

2014-07-16 Thread Steve Baker
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