Comment 5 for bug 1444112
Revision history for this message
| Armando Migliaccio (armando-migliaccio) wrote | #5 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
Ok, even though it's true that ML2 ties tightly into the RPC fabric, I am starting to realize that decoupling the two is way more that we can chew in the span of a single bug fix. One could argue that ML2 is indeed not a control plane, as Salvatore pointed out, but this goes way beyond the scope of a bug report.
Having said that, if drivers are interested in learning about security groups events I can see two possible approaches:
1) Modify the ML2 Driver API contract: we could add more methods to [1] to expose the securitygroups artifacts. I believe this is problematic and it feels like feature creep. IMO, ML2 should only be about L2, and it's already bad, IMO, that we expose L3 concepts like subnets. The other drawback is that the change would be pretty invasive for the already crowded ML2 plugin. Furthermore, the change is very heavyweight and smells of spec.
2) Leverage the Registry: we could add notification calls to trigger securitygroups events. This approach has the advantage to be minimally invasive and changes would be limited to adding the proper triggers in the security groups layer so that 'anyone' interested in learning about secgroup events can consume them, regardless of them being mech_drivers, service plugins, or core plugins. No API is to be modified, and we'd only need to extend the registry to be able to handle these new resources. The code has already plenty of examples where the registry is leveraged to dispatch resource events and a number of patches [2,3,4,5] have been proving its effectiveness.
[1] https:/
[2] https:/
[3] https:/
[4] https:/
[5] https:/