[2.5] Machine subnet links removed after release after deployment using bridge_all=true

Bug #1792409 reported by Mike Pontillo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
High
Mike Pontillo

Bug Description

I used a command like the following to deploy a machine, using the bridge_all option so that MAAS would know about the bridge interfaces:

    maas admin machine deploy xy1z23 user_data="$(base64 ~/userdata -w 0)" bridge_all=true

This worked fine for the deployment, but when the machine was released, the bridge was removed along with its subnet link. Thus, subsequent deployments did not work, because the node was "not connected to a network".

Related branches

summary: - [2.5] Machine subnet links removed after release when deployed using
+ [2.5] Machine subnet links removed after release after deployment using
bridge_all=true
Revision history for this message
Mike Pontillo (mpontillo) wrote :

After further testing I can't reproduce this, so marking Incomplete for now.

Changed in maas:
status: Triaged → Incomplete
Revision history for this message
Mike Pontillo (mpontillo) wrote :

Reproduced the issue; it only happens after a failed deployment.

Changed in maas:
status: Incomplete → Triaged
Revision history for this message
Mike Pontillo (mpontillo) wrote :

Further information: if I use the "Abort" action while in "Deploying" state, and /then/ release, I see this problem.

Changed in maas:
milestone: 2.5.0beta2 → 2.5.0rc1
Changed in maas:
assignee: nobody → Mike Pontillo (mpontillo)
Revision history for this message
Mike Pontillo (mpontillo) wrote :

Reproduced with the following sequence:

 - maas $PROFILE machine deploy $SYSTEM_ID bridge_all=true
 - Use "Abort" action in the UI when the machine transitions to "deploying" state
 - Use "Release" action after the machine powers off

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

After adding some logging in models/node.py (release_interface_config()) and models/signals/interfaces.py (delete_related_ip_addresses()), this seems to be a race condition - possibly in the Django result cache. (That is, it seems to be a race condition because it doesn't happen every time this sequence of steps is followed.) However, I tried some hacks to try to invalidate the _result_cache, but it had no effect.

Changed in maas:
status: Triaged → Fix Committed
Changed in maas:
milestone: 2.5.0rc1 → 2.5.0beta4
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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