Open Stack

On Wed, 10 Apr 2019, Dmitry Tantsur wrote:

> On 4/10/19 1:25 PM, Chris Dent wrote:
>> On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
>>> We would rather have ironic aware that some nodes are reserved for 
>>> internal bookkeeping.
>> 
>> Could you query placement for that "bookkeeping"? That's what
>> placement does.
>> 
>
> It means replacing a short database query with a call to a remote resource 
> with all the associated performance and reliability penalties. Also if 
> someone creates an allocation in Placement directly, we won't have an 
> associated ironic allocation, which is fine, but may be confusing for users. 
> E.g. they see a free node in ironic, but it's actually occupied in Placement.

This gets at some of the general concepts of "how best to use
placement" which are still emerging and evolving and one of the
reasons why I think these threads are useful: We can spend some time
reflecting on that kind of big topic without feeling like it is
wasting precious PTG time.

>From what I've been able to discern with the various ways I've used
placement, it works most easily and effectively when you allow it to
be the single source of truth for inventory and use of that
inventory [1]. This suggests that if you want to optionally use
placement with ironic, then having placement be a one of several
possible backends to the ironic bookkeeping system might be worth
considering.

That said, I'm not sure placement is expensive or risky enough to
not just use (solely) it. Yes, it is another http service and
database but it is super lightweight; easy to install, scale and
manage. If the http service is multi-homed, then there are pretty
much the same network partitioning issues (for talking to the
database) with or without a placement. You could easily choose to
co-locate the placement service (web and database) on the same
host(s) as Ironic.

Note, I'm not trying to twist your arm anything here, just present
options. I recognize that achieving a standalone ironic and then
going and adding a placement to it feels like a step backwards. It
might help to think of placement as a library that happens to be
packaged as an HTTP microservice.

[1] Which, if you're going to have N less than many sources of
truth, it may as well be _one_ to avoid synchronization problems.
Before placement came along I thought (and sometimes still do) that
having a thing which _represents_ a view of the truth (about
inventory) as placement does is overkill if it is possible for
things themselves to represent their own truth, and be event/pubsub
driven about their willingness to accept a workload (instead of
being told by some authority).

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent