Interfaces: Assignments - refactor to MVC for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
Interfaces: Assignments - refactor to MVC for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
Interfaces: Assignments - refactor to MVC for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
Interfaces: Assignments - work in progress for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
Interfaces: Assignments - work in progress for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
Interfaces: Assignments - work in progress for https://github.com/opnsense/core/issues/9945
In order to migrate the interface assignments, we need to think of a way to use the differently named xml nodes for interfaces (wan, lan, ..) into something that closely resembles a standard model implementation.
Since we can't match these nodes in our statically defined model xmls, the main idea is to flush all via an in-memory model with a separate load [construct] and save hook [serializeToConfig].
The next challenge is to "stash" updates and wait for "apply" in certain cases, for this we add a temporary database holding the changes which are synced after the actual system change has happend (pending_action, pending_if). When succesfully applied, the apply function cleans up the final stage of the configuration to make everything consistent again.
This database is a simple single json encoded file named /tmp/.interfaces.todo
