MAAS

[2.0] Rack Controller interface parsing shouldn't only rely on e/n/i

Bug #1550644 reported by Andres Rodriguez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Critical
Blake Rouse
MAAS 2.0.0

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:~blake-rouse/maas/ip-addr-with-dhclient
Mike Pontillo (community): Approve
Diff: 2330 lines (+953/-970)
16 files modified
src/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)
Andres Rodriguez (andreserl)
Changed in maas:
importance: Undecided → Critical
Revision history for this message
Blake Rouse (blake-rouse) wrote :

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.

Revision history for this message
Mike Pontillo (mpontillo) wrote :

Blake, I like that idea; furthermore, I think we should store the origin of the address, that way in the future if we support other mechanisms of network configuration (networkd, networkmanager, a routing protocol daemon etc) we can figure out which subsystem "owns" the address.

For example, today we would maybe have an "eni" and an "iplink" type; in the future we could have "networkmanager", "networkd", etc.

Revision history for this message
Blake Rouse (blake-rouse) wrote :

+1

Blake Rouse (blake-rouse)
Changed in maas:
status: New → In Progress
assignee: nobody → Blake Rouse (blake-rouse)
milestone: none → 2.0.0
MAAS Lander (maas-lander)
Changed in maas:
status: In Progress → Fix Committed
Andres Rodriguez (andreserl)
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.