<div dir="ltr">Hi Steve,<div><br></div><div>Thanks a lot for the detailed response. </div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Feb 15, 2016 at 2:15 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Feb 15, 2016 at 12:26:13AM +0500, Fawad Khaliq wrote:<br>
>    Hi Triple-O folks,<br>
>    I am trying to understand how the notion of overcloud and undercloud would<br>
>    play with the Neutron subprojects. Neutron has sub-projects like<br>
>    networking-l2gw [1], networking-bgpvpn [2] etc, which have their own<br>
>    python-neutronclient CLI extensions [3][4] in their respective<br>
</span>>    repositories and packages. <br>
<span class="">>    I assume it is recommended and it is a common usage that undercloud<br>
>    python-neutronclient is also used to access the overcloud resources via<br>
>    overload RC files/credentials.<br>
<br>
</span>Can you describe the use-case here a little bit please?<br></blockquote><div><br></div><div>Turns out my assumption that undercloud client be used</div><div>for overcloud resources as well was not accurate and as you<br></div><div>mentioned it is only there for developer convenience, so we</div><div>are good. No special use-case as long as we all on the same</div><div>page.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The reason I ask is that (outside of developer usage and maybe operator<br>
validation) I *don't* think it's recommended that the undercloud be used to<br>
routinely access overcloud services.<br>
<br>
The reason being that giving someone access to the undercloud allows them<br>
access to a bunch of services which are used for administrator/operator<br>
actions on your deployed cloud -you would never want tenants of your<br>
deployed cloud to have access to any undercloud services, it's strictly for<br>
admin/operator usage.<br></blockquote><div> </div><div>Great. That clarifies it very well. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>     Now, since these CLI extensions are not<br>
>    part of Neutron packages and in some cases only supposed to be part of the<br>
>    overcloud, how would you recommend installation of the<br>
</span>>    python-neutronclient CLI extensions for these sub-projects? <br>
<span class="">>    I was thinking that a particular overcloud installation and it's<br>
>    respective neutronclient extensions (from subprojects) be installed on the<br>
>    "recommended" location, which in this case is the undercloud client<br>
>    node(s).<br>
<br>
</span>The deployment of the required pieces for overcloud nodes is handled via<br>
puppet, but for the undercloud I think right now it'd be a case of<br>
documentation, e.g a list of packages you have to install if $extension is<br>
enabled on deployment.<br>
<br>
We do use puppet for undercloud configuration, but it's a much more<br>
opinionated and less pluggable than the overcloud implementation (this is<br>
deliberate, ref the more restricted usage described above).<br>
<span class=""><br>
>    Please advise how can we proceed with this. The goal is to understand the<br>
>    location for these overcloud CLI extensions so it is intuitive for the<br>
>    users of the system and not have silent failures by introducing separate<br>
>    clients for undercloud (base Neutron install) and overcloud(base Neutron<br>
</span>>    install + subprojects). <br>
<br>
I think this is highly environment specific - the point of clients is that<br>
they can be installed anywhere and be used to interact with your deployed<br>
(over) cloud services.<br>
<br>
I can imagine an enterprise environment where you have e.g a metapackage<br>
that defines dependencies such that all clients relevant/required for your<br>
private cloud are installed.  Or a standard VM image that contains them,<br>
etc.<br>
<br>
But in reality, a user might only want/need a subset of the clients<br>
if e.g they only want to interact with nova or something, we have no way to<br>
know that when deploying the cloud.  Thus client-side configuration is not<br>
in-scope for TripleO right now, we're primarily concerned with deployment<br>
and management of the server-side components, e.g the actual OpenStack<br>
cloud.<br>
<br>
As mentioned above, the fact that you can source the overcloudrc on the<br>
undercloud and interact with overcloud services is mostly a developer<br>
convenience - I'd think carefully before making assumptions around that<br>
access model, particularly for production environments as I'd guess there<br>
are security and availability issues with such an approach.<br></blockquote><div><br></div><div>I think we are good. The whole point was based on an assumption, which in this</div><div>case is rather there only for developer convenience. </div><div><br></div><div>I think it's clear that overcloud and undercloud  are not supposed to mix in this sense</div><div>and Neutron sub-projects or Neutron capabilities in the overcloud is available within the scope.</div><div>This was the first of the kind in the tripleO world and therefore the confusion. </div><div><br></div><div>Thanks a lot, Steve. I think we can close on this thread. </div><div>Fawad</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>