(adding the list back)
On 07/06/2018 12:05 PM, Dan Prince wrote:
On Fri, Jul 6, 2018 at 12:03 PM Ben Nemec <openst...@nemebean.com> wrote:
On 07/05/2018 01:23 PM, Dan Prince wrote:
On Thu, 2018-07-05 at 14:13 -0400, James Slagle wrote:
I would almost rather see us organize the directories by service
name/project instead of implementation.
Instead of:
puppet/services/nova-api.yaml
puppet/services/nova-conductor.yaml
docker/services/nova-api.yaml
docker/services/nova-conductor.yaml
We'd have:
services/nova/nova-api-puppet.yaml
services/nova/nova-conductor-puppet.yaml
services/nova/nova-api-docker.yaml
services/nova/nova-conductor-docker.yaml
(or perhaps even another level of directories to indicate
puppet/docker/ansible?)
I'd be open to this but doing changes on this scale is a much larger
developer and user impact than what I was thinking we would be willing
to entertain for the issue that caused me to bring this up (i.e. how to
identify services which get configured by Ansible).
Its also worth noting that many projects keep these sorts of things in
different repos too. Like Kolla fully separates kolla-ansible and
kolla-kubernetes as they are quite divergent. We have been able to
preserve some of our common service architectures but as things move
towards kubernetes we may which to change things structurally a bit
too.
True, but the current directory layout was from back when we intended to
support multiple deployment tools in parallel (originally
tripleo-image-elements and puppet). Since I think it has become clear
that it's impractical to maintain two different technologies to do
essentially the same thing I'm not sure there's a need for it now. It's
also worth noting that kolla-kubernetes basically died because there
wasn't enough people to maintain both deployment methods, so we're not
the only ones who have found that to be true. If/when we move to
kubernetes I would anticipate it going like the initial containers work
did - development for a couple of cycles, then a switch to the new thing
and deprecation of the old thing, then removal of support for the old thing.
Sometimes the old things are a bit longer lived though. And sometimes
the new thing doesn't work out the way you thought they would. Have an
abstraction layer where you can have more than new/old things is
sometimes very useful. I'd had to see us ditch it. Especially since
you can already sort of have the both right now by using the resource
registry files to setup a nice default for everything and gradually
switch to new stuff as your defaults.
I don't know that you lose that ability in either case though. You can
still point your resource registry at the -puppet versions of the
services if you want to do that. The only thing that changes is the
location of the files.
Given that, I don't think there's actually a _huge_ difference between
the two options. I prefer the flat directory just because as I've been
working on designate it's mildly annoying to have to navigate two
separate directory trees to find all the designate-related service
files, but I realize that's a fairly minor complaint. :-)
That being said, because of the fact that the service yamls are
essentially an API for TripleO because they're referenced in user
resource registries, I'm not sure it's worth the churn to move
everything either. I think that's going to be an issue either way
though, it's just a question of the scope. _Something_ is going to move
around no matter how we reorganize so it's a problem that needs to be
addressed anyway.
I feel like renaming every service template in t-h-t as part of
solving my initial concerns around identifying the 'ansible configured
services' is a bit of a sedge hammer though. I like some of the
renaming ideas proposed here too. I'm just not convinced that renaming
*some* templates is the same as restructuring the entire t-h-t
services hierarchy. I'd rather wait and let it happen more naturally I
guess, perhaps when we need to do something more destructive already.
My thought was that either way we're causing people grief because they
have to update their files, but the big bang approach would mean they do
it once and then it's done. Except I realize now that's not true,
because as more things move to ansible the filenames would continue to
change.
Which makes me wonder if we should be encoding implementation details
into the filenames in the first place. Ideally, the interface would be
"I want designate-api, so I set OS::TripleO::Services::DesignateApi:
services/designate-api.yaml". As a user I probably don't care what
technology is used to deploy it, I just want it deployed. Then if/when
we change our default method, it just gets swapped out seamlessly and
there's no need for me to change my configuration.
Obviously we'd still need the ability to have method-specific templates
too, but maybe the default designate-api.yaml could be a symlink to
whatever we consider the primary one. Not sure if that works with
templates in swift though.
Anyway, that's some spaghetti I threw at the wall. I don't know if any
of it will stick.
-Ben
__________________________________________________________________________
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
