Code review comment for lp://qastaging/~raxnetworking/nova/bare_bones_melange

> I agree with Devin, perhaps it should be a facet of ./nova/network, just like
> quantum is.
Quantum is a standalone service. There is a network manager that integrates with Quantum (and Melange).
>
> This does, however, beg the following questions:
> 1. should it continue to use it's own database, or should the tables merge
> with the nova db? Wouldn't this make migrations easier and remove a lot of the
> duplication of sqlalchemy infrastructure?
>
> 2. this adds a new HTTP service, which implies this is a new API just for the
> networking aspect of nova ... shouldn't networking just be a new facet of OS
> API? /network/<foo>/... In which case, shouldn't novaclient be the tool for
> accessing it?
>
The original thought is that OpenStack would benefit from an IPAM service that was shared across many components. There could be significant benefit to having a single IPAM service that works across zones or hands out IPs across compute, load balancers, firewall-as-a-service or any other IP-based services. We wanted to start with tight Nova integration because that should be the primary user in the near term. But, I worry that deeper integration would lead to yet-another-IPAM project down the line or a messy separation effort. That's why there is the level of separation in the present implementation