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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
__________________________________________________________________________
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
