Open Stack

Hi Steve,

Thanks a lot for the detailed response.

On Mon, Feb 15, 2016 at 2:15 PM, Steven Hardy <shardy at redhat.com> wrote:

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

Turns out my assumption that undercloud client be used
for overcloud resources as well was not accurate and as you
mentioned it is only there for developer convenience, so we
are good. No special use-case as long as we all on the same
page.


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

Great. That clarifies it very well.


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

I think we are good. The whole point was based on an assumption, which in
this
case is rather there only for developer convenience.

I think it's clear that overcloud and undercloud  are not supposed to mix
in this sense
and Neutron sub-projects or Neutron capabilities in the overcloud is
available within the scope.
This was the first of the kind in the tripleO world and therefore the
confusion.

Thanks a lot, Steve. I think we can close on this thread.
Fawad


>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160215/1a4160b6/attachment.html>