Open Stack

On 7/6/18 7:02 PM, Ben Nemec 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.
> 
> That being said, because of the fact that the service yamls are 
> essentially an API for TripleO because they're referenced in user

this ^^

> 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.

[tl;dr] I can foresee reorganizing that API becomes a nightmare for 
maintainers doing backports for queens (and the LTS downstream release 
based on it). Now imagine kubernetes support comes within those next a 
few years, before we can let the old API just go...

I have an example [0] to share all that pain brought by a simple move of 
'API defaults' from environments/services-docker to 
environments/services plus environments/services-baremetal. Each time a 
file changes contents by its old location, like here [1], I had to run a 
lot of sanity checks to rebase it properly. Like checking for the 
updated paths in resource registries are still valid or had to/been 
moved as well, then picking the source of truth for diverged old vs 
changes locations - all that to loose nothing important in progress.

So I'd say please let's do *not* change services' paths/namespaces in 
t-h-t "API" w/o real need to do that, when there is no more alternatives 
left to that.

[0] https://review.openstack.org/#/q/topic:containers-default-stable/queens
[1] https://review.openstack.org/#/c/567810

> 
> -Ben
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando