Add generic grouping of nodes and other groups to Ironic API
We already have some form of grouping mechanism in Ironic known as chassis. This proposal aims to extend/replace chassis with a more flexible grouping approach. Chassis is a physical piece of hardware containing many nodes. It makes sense to group nodes on a per chassis basis to do things like inform scheduler decisions and visualise the the physical location and properties of nodes.
However, there are many more ways in which an ironic consumer may want to model association of nodes. For example in the case where a Rack contains many nodes, or in the case where a Rack contains many Chassis. You could build on top of this to say that multiple racks may all use the same PDU. These are all valuable things to model in Ironic as it helps deployment decisions and allow operators to get a picture of what is happening with their hardware.
In addition to the physical modelling of hardware, it would also be useful to model virtual grouping of nodes. For example failure domains or grouping of nodes based on some extra properties.
Rather than polluting the API with every possible physical piece of kit (rack, chassis, PDU...) we could remove chassis and replace it with a generic group. Each group would have a type such as Chassis or Rack which would be queryable and some associated meta data (or extras). Groups could then contain nodes (like for example in the Chassis case) or it could contain other Groups. Rack -> Chassis -> Node.
Using this approach is far more flexible and allows ironic consumers to model their hardware resource in any which way they like, including modelling virtual groups such as failure domains.
Blueprint information
- Status:
- Not started
- Approver:
- aeva black
- Priority:
- Undefined
- Drafter:
- Martyn Taylor
- Direction:
- Needs approval
- Assignee:
- Martyn Taylor
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Martyn, how do you envision this free-form grouping integrating with Nova? As it stands, Ironic relies on nova-scheduler for placement of instances on nodes. Having strongly-typed groupings will allow Ironic to expose those groupings in a meaningful way. Conversely, loosely-typed groupings are more flexible for the user, but less useful for nova-scheduler. Or have I misunderstood your proposal?
--Devananda, 2013-12-10
Yes this is a good point. I would say that groups are strongly-typed. They have a type field which should be non-modifiable. The scheduler could be implemented in a number of ways to better make placement decisions depending on what we decide here.
I guess the equivalent of having first class group resources (chassis, rack and PDU) in the API, but still keep the flexible API model, would be simply to ship Ironic with default group types. i.e. seed the DB with a number of default or popular groups. A simple scheduler could then rely on these groups being present and make various decisions based on it's knowledge of each group type. However, having the scheduler rely on particular group types does seem that there is some dependency between the scheduler and what the hardware looks like. I'm not sure if this is a good or bad thing?
A slightly more complex, but more flexible alternative (keeping to this proposal) would be to allow the scheduler to inspect information about each group. This information would be stored in the meta-data of each group i.e key-value pairs. The scheduler would associate behaviour with the meta-data rather than on the group type. This way the same group types could be configured to influence scheduler behaviour differently and would allow the scheduler to act upon artbitrary user defined groups such as failure domains. This is really more the way that I had thought this would work. The scheduler would implement a number of behaviours. These would be triggered on by adding the appropriate meta-data to the group.
I know you have a much better understanding of how the scheduler works that I do. Do you have any thoughts or concerns around this?
Thanks
--Martyn, 2013-12-13
In each proposed case, there is a very tight coupling between the groupings modeled in Ironic and nova-scheduler's ability to interpret those groupings in a meaningful way. Strictly-typed groups will add rigidity to the model. Loosely-typed groups will add computational overhead (metadata is inherently more expensive to reason about). Either way, we'll need multiple services to have a common understanding of the group model -- Ironic, Nova, Heat, and Tuskar. This doesn't seem like a decision that can be made in isolation within Ironic. It should be part of the larger discussions around scheduling and resource placement.
Cheers,
--Devananda, 2013-12-13
I agree.
I think the point I was trying to make here, is that there are a number of ways a scheduler could be implemented. We can be smart enough to support flexible groups, strict typing and meta-data, without hindering any ironic performance or usability. This way the scheduler implementation is free to do as it pleases, as well as any other use case for this type of group (such as the DCM one).
Regarding your point about meta-data be difficult to reason about. Whilst I do think this is the case, the meta-data in the potential scheduler solution I proposed above would not be arbitrary. It would be set key-value pairs that the scheduler knows about. I do also think it is reasonable to assume that these groups change infrequently, which means that any scheduler could do some caching and pre-processing of meta-data to increase performance.
But you are right. We don't know what a scheduler would look like right now, so it's hard talk about specifics. I think in Ironic we just need to be as flexible and performant as possible.
Whilst I agree getting feedback from Ironic, Nova, Heat and Tuskar folks would be beneficial. I was hoping that any initial pass on grouping would be simplistic. We already support meta-data and relationships between resources. It is also very easy to extend what we already have to add in a group with a type field. Any extra or more complex functionality coming from requirements from other projects could be easily added as additional data or an extension.
Thanks
-- Martyn, 2013-12-19
