[openstack-dev] [tripleO][Neutron] Appropriate location for networking-* pythonclient extensions

Steven Hardy shardy at redhat.com
Mon Feb 15 09:15:21 UTC 2016

On Mon, Feb 15, 2016 at 12:26:13AM +0500, Fawad Khaliq wrote:
>    Hi Triple-O folks,
>    I am trying to understand how the notion of overcloud and undercloud would
>    play with the Neutron subprojects. Neutron has sub-projects like
>    networking-l2gw [1], networking-bgpvpn [2] etc, which have their own
>    python-neutronclient CLI extensions [3][4] in their respective
>    repositories and packages. 
>    I assume it is recommended and it is a common usage that undercloud
>    python-neutronclient is also used to access the overcloud resources via
>    overload RC files/credentials.

Can you describe the use-case here a little bit please?

The reason I ask is that (outside of developer usage and maybe operator
validation) I *don't* think it's recommended that the undercloud be used to
routinely access overcloud services.

The reason being that giving someone access to the undercloud allows them
access to a bunch of services which are used for administrator/operator
actions on your deployed cloud -you would never want tenants of your
deployed cloud to have access to any undercloud services, it's strictly for
admin/operator usage.

>     Now, since these CLI extensions are not
>    part of Neutron packages and in some cases only supposed to be part of the
>    overcloud, how would you recommend installation of the
>    python-neutronclient CLI extensions for these sub-projects? 
>    I was thinking that a particular overcloud installation and it's
>    respective neutronclient extensions (from subprojects) be installed on the
>    "recommended" location, which in this case is the undercloud client
>    node(s).

The deployment of the required pieces for overcloud nodes is handled via
puppet, but for the undercloud I think right now it'd be a case of
documentation, e.g a list of packages you have to install if $extension is
enabled on deployment.

We do use puppet for undercloud configuration, but it's a much more
opinionated and less pluggable than the overcloud implementation (this is
deliberate, ref the more restricted usage described above).

>    Please advise how can we proceed with this. The goal is to understand the
>    location for these overcloud CLI extensions so it is intuitive for the
>    users of the system and not have silent failures by introducing separate
>    clients for undercloud (base Neutron install) and overcloud(base Neutron
>    install + subprojects). 

I think this is highly environment specific - the point of clients is that
they can be installed anywhere and be used to interact with your deployed
(over) cloud services.

I can imagine an enterprise environment where you have e.g a metapackage
that defines dependencies such that all clients relevant/required for your
private cloud are installed.  Or a standard VM image that contains them,

But in reality, a user might only want/need a subset of the clients
if e.g they only want to interact with nova or something, we have no way to
know that when deploying the cloud.  Thus client-side configuration is not
in-scope for TripleO right now, we're primarily concerned with deployment
and management of the server-side components, e.g the actual OpenStack

As mentioned above, the fact that you can source the overcloudrc on the
undercloud and interact with overcloud services is mostly a developer
convenience - I'd think carefully before making assumptions around that
access model, particularly for production environments as I'd guess there
are security and availability issues with such an approach.


More information about the OpenStack-dev mailing list