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

Ben Nemec openstack at nemebean.com
Fri Jul 6 17:35:00 UTC 2018


(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 <openstack at 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



More information about the OpenStack-dev mailing list