Open Stack

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.

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.

-Ben