Support using a trunk port for node networking#948
Conversation
Locked behind the use_trunk flag. Unless this is set to true, the default networking is used.
MoteHue
force-pushed
the
support-trunk-ports
branch
from
ccde789 to
51e4a78
Compare
|
Open question: I've included this in compute_fixed_image too, but I don't know if there's actually any point in this? Is there any need to use trunk points with virtual machines? |
| default = null | ||
| } | ||
|
|
||
| variable "trunk_subport_network_id" { |
There was a problem hiding this comment.
Potentially make this a list of networks?
There was a problem hiding this comment.
Yep, that's the top in my improvements list.
There's still room for improvements here, these were just outside the scope of my initial support:
- Supporting multiple subports in the trunk
I've only written enough here to cover the scope of the client work. Would be happy to extend this on R&D time if we decide it's the best use of my time. Could be a follow-up PR?
There was a problem hiding this comment.
Fair - I missed that comment! Do have consider the module interface potentially changing though: string -> list. Meaning people have to update their config.
There was a problem hiding this comment.
I think that's a really good point, we shouldn't merge until we're happy with that interface. So then it becomes a site-specific fix (= site deals with changes from upstream merge) rather than everyone having to deail with changes.
|
TODO: hosts.yml needs to include the trunk subnet details for the node networks |
Whether the instance is a VM or BM has nothing to do with whether you're using the fixed or mutable image version of the instance, so yes its needed on both. |
3 participants
Locked behind the use_trunk flag. Unless this is set to true, the default networking is used.
I did want to do away with the use_trunk flag and just have it determined from the other vars being set, but it wasn't happy with that.
There's still room for improvements here, these were just outside the scope of my initial support:
Would also be great to support one shared definition that can be used by mutliple node groups, no idea if this is doable though.