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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
