On 09/19/2016 01:25 PM, Steven Hardy wrote:
On Wed, Sep 14, 2016 at 06:32:07PM +0200, Giulio Fidente wrote:
On 09/14/2016 05:59 PM, Giulio Fidente wrote:
On 09/14/2016 02:31 PM, Steven Hardy wrote:
Related to this is the future of all of the per-role customization
interfaces. I'm thinking these don't really make sense to maintain
long-term now we have the new composable services architecture, and it
would be better if we can deprecate them and move folks towards the
composable services templates instead?
my experience is that the ExtraConfig interfaces have been useful to
provide arbitrary hiera and class includes
I wonder if we could ship by default some roles parsing those parameters?
thinking more about it, the *ExtraConfig interfaces also offer a simple
mechanism to *override* any hiera setting we push via the templates ...
which isn't easy to achieve with roles
a simple short-term solution could be to merge ExtraConfig in the $role
mapped_data, thoughts?
Thanks for the feedback, so yeah I agree there are reasons to keep the
ExtraConfig *parameters* around, or some similar interface.
I probably should have clarified this in my original post, but there are
two types of *ExtraConfig interfaces, the parameters you refer to, which
simply override some hieradata (we probably want to keep this, but it still
means we have ExtraConfig tied the the role (not the service), but
presumably an operator will know what services are deployed on what role).
The second (and more problematic from a containers point of view) is the
ExtraConfig *resources*, where you can pass an arbitrary heat template,
which typically is used to run stuff on the host (which will be impossible,
or at least not useful on an atomic host in a fully containerized
deployment).
I think your concerns are mostly around the ExtraConfig *parameters* thus,
provided we maintain some way to do those hiera overrides, e.g the
documented interfaces for Ceph ExtraConfig can still be used?
hi Steve
ack, my concern is about the way to do hiera overrides and the way to
push additional hiera data for a service
maybe the latter can be implemented with a custom role but that seems
overkilling where the need could be just to push some additional hiera
data for a class; also a custom role would not work nicely to override
hiera settings
as an alternative, we could add a $serviceExtraConfig parameter to every
service and merge it with the heat output; this would work nicely with
containers as well but add some boilerplate code
not sure if there are other ideas?
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
