<div dir="ltr"><div>[top-posting]</div><div><br></div><div>While the flattening / moving work has made huge progress (thanks Dan for driving this effort!), I think it's time to agree if whether or not we backport the deployment directory for now.</div><div><br></div><div>For new services added in Stein, which need to be backported in stable versions, they'll have to be backported with merge conflict & dealt with it.</div><div>For bug fixes in existing services, we'll have to backport to stable branches with small merge conflict but if we backported the deployment directory, I think the conflicts would be bigger since stable branches would miss all the flattening/moving work (IMHO too big to backport).</div><div><br></div><div>So I propose that we<br></div><div><br></div><div>- do not backport deployment directory</div><div>- deal with small merge conflicts when backporting patches in existing services</div><div>- for new stein services, and when backport needed, put them in either docker or puppet directories in rocky and backport to queens eventually.</div><div><br></div><div>Feedback is open.</div><div><br></div><div>Thanks,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 25, 2018 at 6:06 PM Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Oct 17, 2018 at 11:15 AM Alex Schultz <<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>> wrote:<br>
><br>
> Time to resurrect this thread.<br>
><br>
> On Thu, Jul 5, 2018 at 12:14 PM James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>> wrote:<br>
> ><br>
> > On Thu, Jul 5, 2018 at 1:50 PM, Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>> wrote:<br>
> > > Last week I was tinkering with my docker configuration a bit and was a<br>
> > > bit surprised that puppet/services/docker.yaml no longer used puppet to<br>
> > > configure the docker daemon. It now uses Ansible [1] which is very cool<br>
> > > but brings up the question of how should we clearly indicate to<br>
> > > developers and users that we are using Ansible vs Puppet for<br>
> > > configuration?<br>
> > ><br>
> > > TripleO has been around for a while now, has supported multiple<br>
> > > configuration ans service types over the years: os-apply-config,<br>
> > > puppet, containers, and now Ansible. In the past we've used rigid<br>
> > > directory structures to identify which "service type" was used. More<br>
> > > recently we mixed things up a bit more even by extending one service<br>
> > > type from another ("docker" services all initially extended the<br>
> > > "puppet" services to generate config files and provide an easy upgrade<br>
> > > path).<br>
> > ><br>
> > > Similarly we now use Ansible all over the place for other things in<br>
> > > many of or docker and puppet services for things like upgrades. That is<br>
> > > all good too. I guess the thing I'm getting at here is just a way to<br>
> > > cleanly identify which services are configured via Puppet vs. Ansible.<br>
> > > And how can we do that in the least destructive way possible so as not<br>
> > > to confuse ourselves and our users in the process.<br>
> > ><br>
> > > Also, I think its work keeping in mind that TripleO was once a multi-<br>
> > > vendor project with vendors that had different preferences on service<br>
> > > configuration. Also having the ability to support multiple<br>
> > > configuration mechanisms in the future could once again present itself<br>
> > > (thinking of Kubernetes as an example). Keeping in mind there may be a<br>
> > > conversion period that could well last more than a release or two.<br>
> > ><br>
> > > I suggested a 'services/ansible' directory with mixed responces in our<br>
> > > #tripleo meeting this week. Any other thoughts on the matter?<br>
> ><br>
> > I would almost rather see us organize the directories by service<br>
> > name/project instead of implementation.<br>
> ><br>
> > Instead of:<br>
> ><br>
> > puppet/services/nova-api.yaml<br>
> > puppet/services/nova-conductor.yaml<br>
> > docker/services/nova-api.yaml<br>
> > docker/services/nova-conductor.yaml<br>
> ><br>
> > We'd have:<br>
> ><br>
> > services/nova/nova-api-puppet.yaml<br>
> > services/nova/nova-conductor-puppet.yaml<br>
> > services/nova/nova-api-docker.yaml<br>
> > services/nova/nova-conductor-docker.yaml<br>
> ><br>
> > (or perhaps even another level of directories to indicate<br>
> > puppet/docker/ansible?)<br>
> ><br>
> > Personally, such an organization is something I'm more used to. It<br>
> > feels more similar to how most would expect a puppet module or ansible<br>
> > role to be organized, where you have the abstraction (service<br>
> > configuration) at a higher directory level than specific<br>
> > implementations.<br>
> ><br>
> > It would also lend itself more easily to adding implementations only<br>
> > for specific services, and address the question of if a new top level<br>
> > implementation directory needs to be created. For example, adding a<br>
> > services/nova/nova-api-chef.yaml seems a lot less contentious than<br>
> > adding a top level chef/services/nova-api.yaml.<br>
> ><br>
> > It'd also be nice if we had a way to mark the default within a given<br>
> > service's directory. Perhaps services/nova/nova-api-default.yaml,<br>
> > which would be a new template that just consumes the default? Or<br>
> > perhaps a symlink, although it was pointed out symlinks don't work in<br>
> > swift containers. Still, that could possibly be addressed in our plan<br>
> > upload workflows. Then the resource-registry would point at<br>
> > nova-api-default.yaml. One could easily tell which is the default<br>
> > without having to cross reference with the resource-registry.<br>
> ><br>
><br>
> So since I'm adding a new ansible service, I thought I'd try and take<br>
> a stab at this naming thing. I've taken James's idea and proposed an<br>
> implementation here:<br>
> <a href="https://review.openstack.org/#/c/588111/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/588111/</a><br>
><br>
> The idea would be that the THT code for the service deployment would<br>
> end up in something like:<br>
><br>
> deployment/<service>/<specific-service-element>-<implementation>.yaml<br>
<br>
A matter of preference but I can live with this.<br>
<br>
><br>
> Additionally I took a stab at combining the puppet/docker service<br>
> definitions for the aodh services in a similar structure to start<br>
> reducing the overhead we've had from maintaining the docker/puppet<br>
> implementations seperately.  You can see the patch<br>
> <a href="https://review.openstack.org/#/c/611188/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/611188/</a> for an additional example of<br>
> this.<br>
><br>
> Please let me know what you think.<br>
<br>
I'm okay with it in that it consolidates some things (which we greatly<br>
need to do). It does address my initial concern in that people are now<br>
putting Ansible services into the puppet/services directory albeit a<br>
bit heavy handed in that it changes everything (rather than just the<br>
new Ansible services). Understood that you are also eliminating the<br>
"inheritance" from the docker/services to the puppet/services files...<br>
by simply eliminating the Puppet varients. I had hoped to implement a<br>
baremetal Packstack like installer (still somewhat popular) with t-h-t<br>
but there doesn't appear to be anyone in the Packstack camp speaking<br>
up for the idea here. So much for consolidation. There doesn't seem to<br>
be anyone else in TripleO (aside from myself) who wants baremetal so I<br>
guess be gone with it. Opportunity to test on baremetal lost! Like we<br>
discussed we could have easily kept both and used jinja templates to<br>
avoid the "inheritance" across the baremetal(puppet) and<br>
docker/services and thus also minimized our Heat resources which have<br>
grown. There *are* ways to implement this addressing all concerns and<br>
keeping both features. We are choosing not do this however.<br>
<br>
I see people are already +2'ing the patches so it appears to have been<br>
decided. But, Are we going to commit to trying to move all the<br>
existing services to this new format within a release? There are 200<br>
or so t-h-t patches up for review that would likely need rebased. And<br>
yes this will make backports more difficult as well.<br>
<br>
In all this is we are changing our entire directory structure but not<br>
really removing any dependencies. I suppose if we are going to do the<br>
work I'd rather see us drop some dependencies in the process too :/.<br>
Where destructive meets productive is our best investment I think.<br>
<br>
Dan<br>
<br>
><br>
> Thanks,<br>
> -Alex<br>
><br>
> ><br>
> > --<br>
> > -- James Slagle<br>
> > --<br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>