I have this too.
I think systemd ordering is of no use here. What I suspect is happening is NetworkManager starting to start before udev inserts glean-nm@ services.
The issue with network-pre is similar. It does not finish before glean-nm@ starts, but it does finish long after NetworkManager. The explanation I can come up with is the following: network-pre is a passive target, it does not fire until something requests it. glean-nm@ requests it with Wants=network-pre, but at this point NetworkManager is already starting, so its After=network-pre (without Wants, as intended) does not have an effect.
These are pure speculations at this point, but that's all I have.
What I'm considering now to fix Glean is an additional systemd service that will start glean without arguments (i.e. for all interfaces that are already up) very early, maybe explicitly Before=NetworkManager. Since it will be a normal service, not one inserted by udev, the ordering will work correctly.
Oh, and another thing: Glean has a lock that is interface-agnostic (i.e. global). Which means that while it's processing the loopback interface, it cannot be processing real interfaces. This forced serialization may contribute to the slowness.
In the end, we may go down a different path in ironic-python-agent since we may not really want Glean by default, only when configdrive is present. But fixing Glean would be nice anyway.
Dmitry