canonical / sdcore-upf-operator

Machine Charm for the SD-Core User Plane Function (UPF).
https://charmhub.io/sdcore-upf
Apache License 2.0
0 stars 0 forks source link

Changing UPF interfaces waits until next refresh status event #12

Closed markbeierl closed 6 months ago

markbeierl commented 7 months ago

I accidentally used the unconfigured host interfaces instead of the vlan wrapped interfaces for deploying the upf. Host interfaces are as follows:

10: enp8s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1c:fd:08:7c:71:2c brd ff:ff:ff:ff:ff:ff
18: enp8s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1c:fd:08:7c:71:2d brd ff:ff:ff:ff:ff:ff
...
27: vlan.1202@enp8s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1c:fd:08:7c:71:2c brd ff:ff:ff:ff:ff:ff
    inet 10.202.0.10/16 brd 10.202.255.255 scope global vlan.1202
       valid_lft forever preferred_lft forever
    inet6 fe80::1efd:8ff:fe7c:712c/64 scope link 
       valid_lft forever preferred_lft forever
28: vlan.1203@enp8s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1c:fd:08:7c:71:2d brd ff:ff:ff:ff:ff:ff
    inet 10.203.0.10/16 brd 10.203.255.255 scope global vlan.1203
       valid_lft forever preferred_lft forever
    inet6 fe80::1efd:8ff:fe7c:712d/64 scope link 
       valid_lft forever preferred_lft forever

The UPF was deployed using access-interface-name=enp8s0f0 and core-interface-name=enp8s0f1. This correctly resulted in messages in the debug-log:

unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log No IPv4 address found for interface enp8s0f1
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log IP address for interface enp8s0f1 is empty
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log Core network interface enp8s0f1 is not valid

I ran the following:

juju config sdcore-upf access-interface-name=vlan.1202 core-interface-name=vlan.1203

The charm did not change until about 2 minutes later, when this appeared in the juju debug-log

unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log Pushed file /var/snap/sdcore-upf/common/upf.json
unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log Pushed upf.json config file
unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log Starting configuration of the `bessd` service
unit-sdcore-upf-0: 14:09:56 INFO unit.sdcore-upf/0.juju-log Service `bessd` configured
unit-sdcore-upf-0: 14:09:56 INFO unit.sdcore-upf/0.juju-log UPF service started

Not sure if that is due to refresh status, or something else, but either way, the charm did not act on the change when the event occurred.

markbeierl commented 7 months ago

Possible reason. Here is a debug-log replay:

unit-sdcore-upf-0: 14:00:06 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log No IPv4 address found for interface enp8s0f0
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log IP address for interface enp8s0f0 is empty
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log Access network interface enp8s0f0 is not valid
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log No IPv4 address found for interface enp8s0f1
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log IP address for interface enp8s0f1 is empty
unit-sdcore-upf-0: 14:04:07 WARNING unit.sdcore-upf/0.juju-log Core network interface enp8s0f1 is not valid
unit-sdcore-upf-0: 14:04:07 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)
unit-sdcore-upf-0: 14:09:16 INFO unit.sdcore-upf/0.juju-log Default route does not exist
unit-sdcore-upf-0: 14:09:16 INFO unit.sdcore-upf/0.juju-log Route to  via  created/updated successfully
unit-sdcore-upf-0: 14:09:16 INFO unit.sdcore-upf/0.juju-log RAN route does not exist
unit-sdcore-upf-0: 14:09:16 INFO unit.sdcore-upf/0.juju-log Route to 10.204.0.0/16 via  created/updated successfully
unit-sdcore-upf-0: 14:09:16 INFO unit.sdcore-upf/0.juju-log Iptables rule does not exist
unit-sdcore-upf-0: 14:09:16 INFO unit.sdcore-upf/0.juju-log Iptables rule for ICMP port-unreachable packets created.
unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log UPF snap installed
unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log Pushed file /var/snap/sdcore-upf/common/upf.json
unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log Pushed upf.json config file
unit-sdcore-upf-0: 14:09:54 INFO unit.sdcore-upf/0.juju-log Starting configuration of the `bessd` service
unit-sdcore-upf-0: 14:09:56 INFO unit.sdcore-upf/0.juju-log Service `bessd` configured
unit-sdcore-upf-0: 14:09:56 INFO unit.sdcore-upf/0.juju-log UPF service started
unit-sdcore-upf-0: 14:09:56 INFO unit.sdcore-upf/0.juju-log No `fiveg_n4` relations found.
unit-sdcore-upf-0: 14:09:56 INFO juju.worker.uniter.operation ran "config-changed" hook (via hook dispatching script: dispatch)
unit-sdcore-upf-0: 14:09:57 INFO unit.sdcore-upf/0.juju-log Default route does not exist
unit-sdcore-upf-0: 14:09:57 INFO unit.sdcore-upf/0.juju-log Route to  via  created/updated successfully
unit-sdcore-upf-0: 14:09:57 INFO unit.sdcore-upf/0.juju-log RAN route does not exist
unit-sdcore-upf-0: 14:09:57 INFO unit.sdcore-upf/0.juju-log Route to 10.204.0.0/16 via  created/updated successfully
unit-sdcore-upf-0: 14:10:00 INFO unit.sdcore-upf/0.juju-log UPF snap installed
unit-sdcore-upf-0: 14:10:00 INFO unit.sdcore-upf/0.juju-log Starting configuration of the `bessd` service
unit-sdcore-upf-0: 14:10:00 INFO unit.sdcore-upf/0.juju-log Service `bessd` configured
unit-sdcore-upf-0: 14:10:01 INFO unit.sdcore-upf/0.juju-log UPF service started
unit-sdcore-upf-0: 14:10:01 INFO unit.sdcore-upf/0.juju-log No `fiveg_n4` relations found

A guess is that the configure script is running waiting for 5 minutes to time out, so while the config changed event did get fired (14:09:56), it was delayed due to the configure script holding up all activity on the charm and only allowing the event to fire after it timed out.

markbeierl commented 7 months ago

image Even after correcting the interfaces, it looks like bessd cannot be configured if the initial deployment was done incorrectly