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.
From what I've been able to discern with the various ways I've used
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. 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