Re: [openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation
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
Re: [openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation
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? Steve __ 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
Re: [openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation
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? while to move in a more container-aware condition we could probably have some $serviceExtraConfig param mapped into each service? -- 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
Re: [openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation
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? -- 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
[openstack-dev] [TripleO] *ExtraConfig, backwards compatibility & deprecation
Hi all, I wanted to draw attention to this patch: https://review.openstack.org/#/c/367295/ As part of the custom-roles work, I had to break backwards compatibility for the OS::TripleO::AllNodesExtraConfig resource. I'm not happy about that, but I couldn't find any way to avoid it if we want to allow existing roles to be optional (such as removing the *Storage role resources from the deployment completely). The adjustments for any out-of-tree users should be simple, and I'm planning to write a script to help folks migrate but we'll need to document this in the release notes/docs (I'll write these). 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? In particular, when moving to a fully containerized deployment using an atomic host image, configuration of the host directly via these interfaces will no longer be possible, so it will be necessary to get folks onto the composable services interfaces ahead of such a move (as these will fit much better with a container based deployment): https://review.openstack.org/#/c/330659/ What do folks think about this? I suspect there's going to be some work required to achieve it, but a first step would be to convert all the in-tree ExtraConfig examples to the new format & update the docs to show how customizations via composable services would work. Then later we can update the docs & mark these interfaces deprecated (during Ocata). Any thoughts appreciated, thanks! Steve __ 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
