Comment 9 for bug 1513981

@Kyle,

>> "This is leaking out details of the physical topology into an entity of the logical model."

I don't see this as "leaking out". I don't think there is anything wrong with storing physical network details in the database. As Carl said, a lot of companies, mostly large deployments don't use SDN. So the physical network architecture is actually the only information they have, and they need to be able to use it.

Currently we are solving this problem by making calls to external services that actually store the data, or put some hacks and embed some of information in the the name, etc. But we cant use any of that for scheduling. It will be extremely inefficient and won't scale.

I think it will be really great if Neutron can become the source of truth for this information.

@Doug,

>> "If you just wanted to store extra info, you can derive from the ref today and add your own alembic/db class."

That would be our last option, of course. The problem is, we do have our own database and our own IPAM driver, there is chance that, in future, a lot of our use cases won't make it to the community. Of course, its not an excuse and we will do everything to not let that happen, but own DB is always a short cut. Please consider that we are not exactly a vendor. A lot of our requirements come from scale. If its useful to others, we would like to know that. If we are doing something wrong, we would like to know that as well.

>> "Is this new info expected to be available via an API?"

Not necessary. We can leave it upto the drivers to use it or ignore it.