On Thu, Oct 25, 2018 at 11:26 AM Alex Schultz <aschu...@redhat.com> wrote: > > On Thu, Oct 25, 2018 at 9:16 AM Bogdan Dobrelya <bdobr...@redhat.com> wrote: > > > > > > 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 > > > > 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 > > > > This is why we have duplication of things in THT. For environment > files this is actually an issue due to the fact they are the end user > interface. But these service files should be internal and where they > live should not matter. We already have had this in the past and have > managed to continue to do backports so I don't think this as a reason > not to do this clean up. It feels like we use this as a reason not to > actually move forward on cleanup and we end up carrying the tech debt. > By this logic, we'll never be able to cleanup anything if we can't > handle moving files around.
Yeah. The environment files would contain some level of duplication until we refactor our plan storage mechanism to use a plain old tarball (stored in Swift still) instead of storing files in the expanded format. Swift does not support softlinks, but a tarball would and thus would allow us to de-dup things in the future. The patch is here but it needs some love: https://review.openstack.org/#/c/581153/ Dan > > I think there are some patches to do soft links (dprince might be able > to provide the patches) which could at least handle this backward > compatibility around locations, but I think we need to actually move > forward on the simplification of the service definitions unless > there's a blocking technical issue with this effort. > > Thanks, > -Alex > > > > 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 > > > > > >> 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 > > > > > > -- > > Best regards, > > Bogdan Dobrelya, > > Irc #bogdando > > > > __________________________________________________________________________ > > 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 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 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
