[openstack-dev] [TripleO] easily identifying how services are configured

Juan Antonio Osorio Robles jaosorior at redhat.com
Mon Oct 22 11:50:56 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[0], yes? I think it is time to stop
> continuing this method of installation.  Given that I'm not even sure
> 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.
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html
As an advantage to removing baremetal support, our nested stack usage
would be a little lighter and this might actually help out deployment
times and resource usage. I like the idea of going ahead and starting to
flatten the stacks for our services.
>
>> 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?
>
> Thanks,
> -Alex
>
>> --
>> -- James Slagle
>> --
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list