[openstack-dev] Saga of servicec discovery (is it needed?)

Joshua Harlow harlowja at fastmail.com
Thu Mar 2 19:12:36 UTC 2017

So this is a general start of a large discussion that is similar to the 
other one I started[1], and this time around I wanted to start this on 
the mailing instead of a spec first approach.

The general question is around something I keep on noticing popping up 
in various projects and worry about what we as a community are doing 
with regard to diversity of implementation (and what can we do to make 
this better).

What seems to be being recreated (in various forms) is that multiple 
projects seem to have a need to store ephemeral data about some sort of 
agent (ie nova and its compute node agents, neutron and its agents, 
octavia and its amphora agents...) in a place that can also track the 
liveness (whether that component is up/down/dead/alive) of that agents 
(in general we can replace agent with service and call this service 

It appears (correct me if I am wrong) the amount of ephemeral metadata 
associated with this agent typically seems to be somewhat minimal, and 
any non-ephemeral agent data should be stored somewhere else (ie a 

I think it'd be great from a developer point of view to start to address 
this, and by doing so we can make operations of these various projects 
and there agents that much easier (it is a real PITA when each project 
does this differently, it makes cloud maintenance procedures that much 
more painful, because typically while doing maintenance you need to 
ensure these agents are turned off, having X different ways to do this 
with Y different side-effects makes this ummm, not enjoyable).

So before I start to go much farther on this (and start to dive into 
what people are doing and why the various implementations exist and 
proposing a cross-project solution, tooz, or etcd, or zookeeper or 
other...) I wanted to get general feedback (especially from the projects 
that have these kinds of implementations) if this is a worthwhile path 
to even try to go down.

IMHO it is, though it may once again require the community as a group to 
notice things are being done differently that are really the same and 
people caring enough to actually want to resolve this situation (in 
general I really would like the architecture working group to be able to 
proactively resolving these issues before they get created, 
retroactively trying to resolve these differences is not a 
healthy/sustainable thing we should be doing).


[1] https://lwn.net/Articles/662140/

More information about the OpenStack-dev mailing list