Open Stack

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 <jbelamaric at infoblox.com>
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 <kprad1 at yahoo.com>
> Reply-To: Padmanabhan Krishnan <kprad1 at yahoo.com>
> Date: Wednesday, January 28, 2015 at 4:58 PM
> To: John Belamaric <jbelamaric at infoblox.com>, "OpenStack Development
> Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org
> >
> 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 <
> kprad1 at yahoo.com> 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 <
> jbelamaric at infoblox.com> 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 <kprad1 at yahoo.com>
> Reply-To: Padmanabhan Krishnan <kprad1 at yahoo.com>, "OpenStack Development
> Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org
> >
> Date: Wednesday, December 17, 2014 at 6:06 PM
> To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org
> >
> 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" <pasquale.porreca at dektech.com.au>
> 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 <
> >> pasquale.porreca at dektech.com.au> 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
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> 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
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/26e3ab61/attachment.html>