If we have ports without IPs, I don't think we need a placeholder, do we? Wouldn't a port without an IP address be the same thing as a port with a placeholder indicating that it doesn't have an IP address?
On Tue, Feb 3, 2015 at 8:57 AM, John Belamaric <[email protected]> wrote: > Hi Paddu, > > I think this is less an issue of the pluggable IPAM than it is the > Neutron management layer, which requires an IP for a port, as far as I > know. If the management layer is updated to allow a port to exist without a > known IP, then an additional IP request type could be added to represent > the placeholder you describing. > > However, doing so leaves IPAM out of the hands of Neutron and out of the > hands of the external (presumably authoritative) IPAM system. This could > lead to duplicate IP issues since each VM is deciding its own IP without > any centralized coordination. I wouldn't recommend this approach to > managing your IP space. > > John > > From: Padmanabhan Krishnan <[email protected]> > Reply-To: Padmanabhan Krishnan <[email protected]> > Date: Wednesday, January 28, 2015 at 4:58 PM > To: John Belamaric <[email protected]>, "OpenStack Development > Mailing List (not for usage questions)" <[email protected] > > > Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even > when dhcp is disabled > > Some follow up questions on this. > > In the specs, i see that during a "create_port", there's provisions to > query the external source by "Pluggable IPAM" to return the IP. > This works fine for cases where the external source (say, DHCP server) > can be queried for the IP address when a launch happens. > > Is there a provision to have the flexibility of a "late IP assignment"? > > I am thinking of cases, like the temporary unavailability of external IP > source or lack of standard interfaces in which case data packet snooping is > used to find the IP address of a VM after launch. Something similar to late > binding of IP addresses. > This means the create_port may not get the IP address from the > pluggable IPAM. In that case, launch of a VM (or create_port) shouldn't > fail. The Pluggable IPAM should have some provision to return something > equivalent to "unavailable" during create_port and be able to do an > update_port when the IP address becomes available. > > I don't see that option. Please correct me if I am wrong. > > Thanks, > Paddu > > > On Thursday, December 18, 2014 7:59 AM, Padmanabhan Krishnan < > [email protected]> wrote: > > > Hi John, > Thanks for the pointers. I shall take a look and get back. > > Regards, > Paddu > > > On Thursday, December 18, 2014 6:23 AM, John Belamaric < > [email protected]> wrote: > > > Hi Paddu, > > Take a look at what we are working on in Kilo [1] for external IPAM. > While this does not address DHCP specifically, it does allow you to use an > external source to allocate the IP that OpenStack uses, which may solve > your problem. > > Another solution to your question is to invert the logic - you need to > take the IP allocated by OpenStack and program the DHCP server to provide a > fixed IP for that MAC. > > You may be interested in looking at this Etherpad [2] that Don Kehn put > together gathering all the various DHCP blueprints and related info, and > also at this BP [3] for including a DHCP relay so we can utilize external > DHCP more easily. > > [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam > [2] https://etherpad.openstack.org/p/neutron-dhcp-org > [3] https://blueprints.launchpad.net/neutron/+spec/dhcp-relay > > John > > From: Padmanabhan Krishnan <[email protected]> > Reply-To: Padmanabhan Krishnan <[email protected]>, "OpenStack Development > Mailing List (not for usage questions)" <[email protected] > > > Date: Wednesday, December 17, 2014 at 6:06 PM > To: "[email protected]" <[email protected] > > > Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even > when dhcp is disabled > > This means whatever tools the operators are using, it need to make sure > the IP address assigned inside the VM matches with Openstack has assigned > to the port. > Bringing the question that i had in another thread on the same topic: > > If one wants to use the provider DHCP server and not have Openstack's > DHCP or L3 agent/DVR, it may not be possible to do so even with DHCP > disabled in Openstack network. Even if the provider DHCP server is > configured with the same start/end range in the same subnet, there's no > guarantee that it will match with Openstack assigned IP address for bulk VM > launches or when there's a failure case. > So, how does one deploy external DHCP with Openstack? > > If Openstack hasn't assigned a IP address when DHCP is disabled for a > network, can't port_update be done with the provider DHCP specified IP > address to put the anti-spoofing and security rules? > With Openstack assigned IP address, port_update cannot be done since IP > address aren't in sync and can overlap. > > Thanks, > Paddu > > > > On 12/16/14 4:30 AM, "Pasquale Porreca" <[email protected]> > wrote: > > >I understood and I agree that assigning the ip address to the port is > >not a bug, however showing it to the user, at least in Horizon dashboard > >where it pops up in the main instance screen without a specific search, > >can be very confusing. > > > >On 12/16/14 12:25, Salvatore Orlando wrote: > >> In Neutron IP address management and distribution are separated > >>concepts. > >> IP addresses are assigned to ports even when DHCP is disabled. That IP > >> address is indeed used to configure anti-spoofing rules and security > >>groups. > >> > >> It is however understandable that one wonders why an IP address is > >>assigned > >> to a port if there is no DHCP server to communicate that address. > >>Operators > >> might decide to use different tools to ensure the IP address is then > >> assigned to the instance's ports. On XenServer for instance one could > >>use a > >> guest agent reading network configuration from XenStore; as another > >> example, older versions of Openstack used to inject network > >>configuration > >> into the instance file system; I reckon that today's configdrive might > >>also > >> be used to configure instance's networking. > >> > >> Summarising I don't think this is a bug. Nevertheless if you have any > >>idea > >> regarding improvements on the API UX feel free to file a bug report. > >> > >> Salvatore > >> > >> On 16 December 2014 at 10:41, Pasquale Porreca < > >> [email protected]> wrote: > >>> > >>> Is there a specific reason for which a fixed ip is bound to a port on a > >>> subnet where dhcp is disabled? it is confusing to have this info shown > >>> when the instance doesn't have actually an ip on that port. > >>> Should I fill a bug report, or is this a wanted behavior? > >>> > >>> -- > >>> Pasquale Porreca > >>> > >>> DEK Technologies > >>> Via dei Castelli Romani, 22 > >>> 00040 Pomezia (Roma) > >>> > >>> Mobile +39 3394823805 > >>> Skype paskporr > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> [email protected] > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > >-- > >Pasquale Porreca > > > >DEK Technologies > >Via dei Castelli Romani, 22 > >00040 Pomezia (Roma) > > > >Mobile +39 3394823805 > >Skype paskporr > > > >_______________________________________________ > >OpenStack-dev mailing list > >[email protected] > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
