When it starts the SSVM, I usually see the management server include the bridge names in the command it sends to the agent. If it asks the agent for these, then cloudstack no longer needs the traffic labels when setting up a zone or physical network. If it's not asking the agent (i.e. if they're in the database anywhere), then it's an exercise in manually syncing your own agent values and cloudstack's.
I'm not saying it's bad to break out the agent settings and keep cloudstack from controlling them, just that I understand why it was that way. If this bug fix is implemented, then cloudstack is no longer the canonical source of configuration, and at the very least I hope that there's sufficient checking/logging to point admins to the issue when what they have in their agent.properties doesn't work with how they've configured cloudstack. For the majority of people, they'll just set things up one way, the initial agent.properties will get set up by cloud-setup-agent the first time and that will be it. But I fear that some people are going to change settings in the UI and be surprised when nothing happens. > I think you actually can change the traffic labels on the Agent, it looks up > private.network.device, public and guest and uses those values. > > I however don't know how this goes with migrations, I guess not to well.. I > wouldn't recommend it. > > Wido
