Open Stack

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

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

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.

Steve