[2.0] Rack Controller interface parsing shouldn't only rely on e/n/i
Bug #1550644 reported by
Andres Rodriguez
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
Critical
|
Blake Rouse |
Bug Description
I tested lastest trunk and noticed that the cluster had correctly parsed e/n/i, however, I had various other interfaces that had not being manually configured on e/n/i.
I now believe that the cluster controller should not only parse e/n/i, but should also parse ip addr and look for those interfaces not reflected on e/n/i, but had been manually added without the use of e/n/i.
Related branches
lp://staging/~blake-rouse/maas/ip-addr-with-dhclient
- Mike Pontillo (community): Approve
-
Diff: 2330 lines (+953/-970)16 files modifiedsrc/maasserver/models/node.py (+46/-0)
src/maasserver/models/tests/test_node.py (+24/-3)
src/provisioningserver/networks.py (+15/-15)
src/provisioningserver/plugin.py (+7/-7)
src/provisioningserver/pserv_services/networks_monitoring_service.py (+9/-9)
src/provisioningserver/pserv_services/tests/test_networks_monitoring_service.py (+17/-16)
src/provisioningserver/rpc/clusterservice.py (+1/-1)
src/provisioningserver/rpc/tests/test_clusterservice.py (+3/-3)
src/provisioningserver/tests/test_networks.py (+17/-17)
src/provisioningserver/tests/test_plugin.py (+7/-7)
src/provisioningserver/utils/dhclient.py (+67/-0)
src/provisioningserver/utils/network.py (+104/-195)
src/provisioningserver/utils/ps.py (+67/-0)
src/provisioningserver/utils/tests/test_dhclient.py (+113/-0)
src/provisioningserver/utils/tests/test_network.py (+265/-697)
src/provisioningserver/utils/tests/test_ps.py (+191/-0)
Changed in maas: | |
importance: | Undecided → Critical |
Changed in maas: | |
status: | New → In Progress |
assignee: | nobody → Blake Rouse (blake-rouse) |
milestone: | none → 2.0.0 |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
There is no issue with doing this now. The issue comes about when we allow a user to modify interfaces. The goal of parsing /etc/network/ interfaces is to allow a user to be able to modify an interface and /etc/network/ interfaces be updated. What you are suggesting would place the interface into the database but in the future we would have no way to edit those interfaces. We need to not only think about what we have now, but also how it will work in the future when that feature is added on.
What might be a good idea is to add "editable" field to the Interface model. Interfaces that do not appear in "/etc/network/ interfaces" should have "editable" set to False and interfaces in /etc/network/ interfaces would be set to True. This would allow us to add the editable later. I think that might be a good idea.