[openstack-dev] [TripleO] easily identifying how services are configured
bdobreli at redhat.com
Thu Oct 25 15:15:39 UTC 2018
On 10/19/18 8:04 PM, Alex Schultz wrote:
> On Fri, Oct 19, 2018 at 10:53 AM James Slagle <james.slagle at gmail.com> wrote:
>> On Wed, Oct 17, 2018 at 11:14 AM Alex Schultz <aschultz at redhat.com> wrote:
>> > Additionally I took a stab at combining the puppet/docker service
>> > definitions for the aodh services in a similar structure to start
>> > reducing the overhead we've had from maintaining the docker/puppet
>> > implementations seperately. You can see the patch
>> > https://review.openstack.org/#/c/611188/ for an additional example of
>> > this.
>> That patch takes the approach of removing baremetal support. Is that
>> what we agreed to do?
> Since it's deprecated since Queens, yes? I think it is time to stop
> continuing this method of installation. Given that I'm not even sure
My point and concern retains as before, unless we fully dropped the
docker support for Queens (and downstream LTS released for it), we
should not modify the t-h-t directory tree, due to associated
maintenance of backports complexity reasons
> the upgrade process even works anymore with baremetal, I don't think
> there's a reason to keep it as it directly impacts the time it takes
> to perform deployments and also contributes to increased complexity
> all around.
>  http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html
>> I'm not specifically opposed, as I'm pretty sure the baremetal
>> implementations are no longer tested anywhere, but I know that Dan had
>> some concerns about that last time around.
>> The alternative we discussed was using jinja2 to include common
>> data/tasks in both the puppet/docker/ansible implementations. That
>> would also result in reducing the number of Heat resources in these
>> stacks and hopefully reduce the amount of time it takes to
>> create/update the ServiceChain stacks.
> I'd rather we officially get rid of the one of the two methods and
> converge on a single method without increasing the complexity via
> jinja to continue to support both. If there's an improvement to be had
> after we've converged on a single structure for including the base
> bits, maybe we could do that then?
More information about the OpenStack-dev