How to stop quantum assigning IP for the port

If u don't want quantum to assign IPs, you should not use quantum at all. why not just create a network API which just return NULL networks?

The reality is that a lot of enterprises have existing infrastructure that they want to selectively plumb into quantum. On any given provider network or flat network I may only want Quantum to give me L2 connectivity and turn over the IPAM to an existing DHCP server. It doesn't look to me like that is something easily supported by Quantum, particularly by the OVS plugin. This is not an off-the-wall question, I am hearing people wanting to support this use case in their private cloud. In this scenario, things like security groups may be harder to enforce since Quantum may not know the IP address that is handed out by the external DHCP server. There may be some challenges to building in support for this use case, but let's not dismiss it. Saying "you should not use quantum at all" seems a little over-the-top.

Is there any follow up on this? I fully agree with Ryan here...
The way I would expect this to work is, either be able to create a network without subnet, and plug the VM to it. I would expect quantum to provide only L2, and do not try to enforce any security group related stuff.
Or basically the same stuff but with subnet with DHCP disabled.
I would prefer the first option, since subnet requires allocation pool to be defined, which might introduce unnecessary confusion, since I don't want quantum to handle IPs in any way..

This IMHO makes great sense with provider networks (not exclusively) , since I really don't see a point for quantum to mess around with IPs when I'm trying to map/link virtual network to a physical one (where supposedly other services like DHCP/DNS are already running).

Another use case I have is when we are using openstack as a training environment. Of course there are limited resources in such cloud, so we ask the users to create snapshot and delete all their VMs once they are finished with trainings/testing. Problem is, that if they have any kind of static network configuration (for whatever reason - it is a training/testing env.) and they boot up the snapshot later, it simply does not work, since they have been most likely assigned new IP (even though their static network settings matched the pre-assigned IP from the time of first boot).

We have circumvent this by a very dirty hack, where we just disabled the antispoof protection for the source IP (MAC is still enforced), but as you might see, IP is still assigned and shown in eg. horizon, just not enforced.