Open Stack

On Tue, 16 Aug 2016, Alex Xu wrote:

> There are two solutions in my mind
> 1. There aren't different dependence for traits, that is easy. The
> validation API in the placement engine API is enough.
> 2. There are different dependence for traits. We need API for compute node
> report those dependence. This isn't easy, we need model the dependence in
> the placement engine. This sounds like Chris will hate this way :)

If you're talking about me here, "hate" is probably a bit too strong
of a term. Maybe "get sad"?

In any case my dislike is not with the idea of putting the capabilities
behind an API that can be accessed by a multitude of clients. That
seems like a good idea. It removes some dependencies and allows some
dynamism in the collection and management of traits. That is important
to allow.

What I dislike is the idea of including it in the placement service.
We should have a standalone traits service (for which the placement
service is one of the multitude of clients). I know people get
stressed about having yet another service running but if we continue
with the standard service evolution trend the placement service is
going to end up being yet another monolith in the OpenStack stack.
It should do one thing well and compose with other services to
satisfy use cases.

We should have a traits service. It should be very simple. It should
be amenable to simple caching for performance boosting and should be
easy to scale horizontally. If people want it to use the same
database as the placement engine, that's fine but it should be
its own process and ideally it's own code repo.

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent