Re: [openstack-dev] [Neutron] Stepping down from core

Carl, Thank you for all your great work over the years. Sorry to see you go. John > On Nov 17, 2016, at 1:42 PM, Carl Baldwin wrote: > > Neutron (and Openstack), > > It is with regret that I report that my work situation has changed such that > I'm not able to keep up

[openstack-dev] [release][neutron][ipam][networking-infoblox] networking-infoblox 2.0.2

I am happy to announce that we have released version 2.0.2 of the Infoblox IPAM driver for OpenStack. This driver uses the pluggable IPAM framework delivered in Neutron's Liberty release, enabling the use of Infoblox for allocating subnets and IP addresses, and automatically creating DNS zones

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

I was on vacation last week so I am just seeing this now. I agree that now that we are in Newton we should just remove the non-pluggable code and move forward with the migration. John __ OpenStack Development Mailing List

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

the port is going to land, we cannot allocate an IP address for > it. Also, IPAM will need to somehow be aware of segments. We have > proposed a host / segment mapping which could be transformed to a host > / subnet mapping for IPAM purposes. > > I wanted to get the opinion of folks

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

--- John Belamaric (240) 383-6963 > On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > What’s the user visible change in behaviour after the switch? If it’s only > internal implementation change, I don’t see why we want to leave the choi

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Feb 11, 2016, at 12:04 PM, Armando M. <arma...@gmail.com<mailto:arma...@gmail.com>> wrote: On 11 February 2016 at 07:01, John Belamaric <jbelama...@infoblox.com<mailto:jbelama...@infoblox.com>> wrote: It is only internal implementation changes.

[openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

Hi all, Back in November, there was a discussion [1] on the mailing list around release:independent projects, which was wrapped up by Thierry in [2]. However, I have a couple lingering questions that have come up. In networking-infoblox, we have a 1.0.0 version of our driver that we released

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

> On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote: > > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar wrote: >> I am trying to bring more attention to [1] to make final decision on >> approach to use. >> There are a few point that are not 100% clear for

Re: [openstack-dev] [Openstack] [Neutron] [Docs] Definition of a provider Network

Yes, I think of it as: A provider network in OpenStack is simply a record specifying the necessary details of the underlying infrastructure so that OpenStack can utilize it. The actual networking services (layer 2 and 3 forwarding, for example) are provided by the infrastructure and configured

Re: [openstack-dev] [neutron][ipam][devstack] How to use IPAM reference in devstack

It currently only supports greenfield deployments. See [1] - we plan to build a migration in the Mitaka time frame. John [1] https://bugs.launchpad.net/neutron/+bug/1516156 On Nov 23, 2015, at 8:05 PM, Shraddha Pandhe > wrote:

Re: [openstack-dev] [Neutron] Bug update

I think Gary got auto-corrected: training = triaging brace = rbac On Nov 20, 2015, at 12:41 PM, Armando M. > wrote: On 19 November 2015 at 23:10, Gary Kotton > wrote: Hi, There are a ton of old and

Re: [openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

>>> >> All new features must go to master only. Your master should always be >> tested and work with neutron master (meaning, your master should target >> Mitaka, not Liberty). >> >>> We have a very similar situation in networking-infoblox to what Neil was saying about Calico. In our

[openstack-dev] [release][neutron][ipam][networking-infoblox] networking-infoblox 1.0.0

I am happy to announce that we have released version 1.0.0 of the Infoblox IPAM driver for OpenStack. This driver uses the pluggable IPAM framework delivered in Neutron's Liberty release, enabling the use of Infoblox for allocating subnets and IP addresses. More information and the code may be

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

If you have custom data you want to keep for your driver, you should create your own database tables to track that information. For example, the reference driver creates its own tables to track its data in ipam* tables. John On Nov 4, 2015, at 3:46 PM, Shraddha Pandhe

Re: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and Alcatel-Lucent VitalQIP

Hi Maruti, Yes, it is still ongoing, without a first release yet. We expect to release a 1.0 driver very soon that will support a single network view shared by all tenants. A later version will include the ability to map tenants and/or specific subnets to various network views at runtime.

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

I can write something up on the pluggable IPAM configuration for the Advanced Configuration section. How does the docs release schedule move in relation to the code release? I need an idea of when this needs to be done in order to make sure I'll have the time. John On Oct 7, 2015, at 8:11 PM,

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Lucky me :) > On Oct 8, 2015, at 10:19 AM, Andreas Jaeger <a...@suse.com> wrote: > > On 2015-10-08 16:07, John Belamaric wrote: >> I can write something up on the pluggable IPAM configuration for the >> Advanced Configuration section. How does the docs release s

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

Kyle, I have taken care of this for networking-infoblox. Please let me know if anything else is necessary. Thanks, John On Sep 30, 2015, at 2:55 PM, Kyle Mestery > wrote: Folks: In trying to release some networking sub-projects recently, I ran

Re: [openstack-dev] [neutron] PTL Non-Candidacy

Thanks for all your hard work Kyle. Enjoy your more relaxed schedule :) On Sep 11, 2015, at 5:12 PM, Kyle Mestery > wrote: I'm writing to let everyone know that I do not plan to run for Neutron PTL for a fourth cycle. Being a PTL is a rewarding

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

This implies an IP allocation request that passes something other than a network/port to the IPAM subsystem. What I forgot to mention in my previous email is that proposal #2 is basically a feature we are planning for our custom IPAM driver (without the routing piece). We allow arbitrary

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

Wow, a lot to digest in these threads. If I can summarize my understanding of the two proposals. Let me know whether I get this right. There are a couple problems that need to be solved: a. Scheduling based on host reachability to the segments b. Floating IP functionality across the segments.

Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty?

Hi Erik, Infoblox is also interested in this functionality, and we may be able to help out as well. Thanks, John On 5/8/15, 1:23 PM, Jay Pipes jaypi...@gmail.com wrote: On 05/08/2015 09:29 AM, Erik Moe wrote: Hi, I have not been able to work with upstreaming of this for some time now. But

Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?

I agree, we should amend it to not run pluggable IPAM as the default for now. When we decide to make it the default, the migration scripts will be needed. John On 5/5/15, 1:47 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: Patch #153236 is introducing pluggable

Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring

(VM gets new port bound to a compute host where a fip namespace needs to spring in to existence). Carl On Mon, Apr 13, 2015 at 10:24 AM, John Belamaric jbelama...@infoblox.com wrote: Thanks Pavel. I see an additional case in L3_NAT_dbonly_mixin, where it starts the transaction

Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring

Thanks Pavel. I see an additional case in L3_NAT_dbonly_mixin, where it starts the transaction in create_router, then eventually gets to create_port: create_router (starts tx) -self._update_router_gw_info -_create_gw_port -_create_router_gw_port -create_port(plugin) So that also would

Re: [openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow

Carl, I did want to discuss the refactoring for IPAM but we can do it over the ML. Looks like Salvatore didn't have a chance to play with it over the weekend, so I will be looking at it today (hopefully). John On 4/8/15, 11:26 AM, Carl Baldwin c...@ecbaldwin.net wrote: I will not be available

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On 3/22/15, 8:05 PM, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: Seems to me that an address pool corresponds to a network area that you can route across (because routing only works over a network with unique addresses and that's what an address pool does for you).

Re: [openstack-dev] [Neutron] IPAM reference driver status and other stuff

On 3/23/15, 11:03 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: Whether is a big deal or a failure it depends on one's expectation. If the expectation is to enable external IPAM backends, then I agree that this is not a big deal. However, my expectation (and I

Re: [openstack-dev] [Neutron] IPAM reference driver status and other stuff

On 3/20/15, 8:31 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: As the IPAM driver is called in NeutronDbPluginV2, this call happens while another transaction is typically in progress. Initiating a separate session within the IPAM driver causes the outer

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On 3/21/15, 9:10 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: If we feel a need for specifying the relative position of gateway address and allocation pools when creating a subnet from a pool which will pick a CIDR from its prefixes, then the integer value

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

On 3/18/15, 9:12 PM, Sean M. Collins s...@coreitpro.com wrote: My hope is that either the new IPAM subsystem for subnet allocations would provide this, or that a small API extension could paper over some of the sharper edges. In IPAM we have added this concept of a subnet request. The

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

Here is a compromise option. The pluggable IPAM will be optionally enabled in Kilo. We could introduce the restriction, but only when pluggable IPAM is enabled. Support for having a tenant with overlapping IP space, along with pluggable IPAM would wait until Liberty, when we can fully implement

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On 3/12/15, 12:46 AM, Carl Baldwin c...@ecbaldwin.net wrote: When talking with external IPAM to get a subnet, Neutron will pass both the cidr as the primary identifier and the subnet_id as an alternate identifier. External systems that do not allow overlap can Recall that IPAM driver

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On 3/12/15, 2:33 AM, Carl Baldwin c...@ecbaldwin.net wrote: John, I think our proposals fit together nicely. This thread is about allowing overlap within a pool. I think it is fine for an external IPAM driver to disallow such overlap for now. However, the reference implementation must

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

This has been settled and we're not moving forward with it for Kilo. I agree tenants are an administrative concept, not a networking one so using them for uniqueness doesn't really make sense. In Liberty we are proposing a new grouping mechanism, as you call it, specifically for the purpose of

Re: [openstack-dev] [Neutron] db-level locks, non-blocking algorithms, active/active DB clusters and IPAM

On 2/25/15, 10:52 AM, Carl Baldwin c...@ecbaldwin.net wrote: Wondering if Kilo should just focus on creating the interface which will allow us to create multiple implementations and swap them out during the Liberty development cycle. Hopefully, this could include even something like your

Re: [openstack-dev] [Neutron] Update on DB IPAM driver

Put it in this way, it also makes sense. But I think I need to see it translated in code to figure it out properly. Anyway, this is something which pertains the base classes rather than the reference driver. I think from the perspective of the reference driver we should just raise if a

Re: [openstack-dev] [Neutron] Update on DB IPAM driver

From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, February 13, 2015 at 8:26 AM To: OpenStack Development Mailing

Re: [openstack-dev] [Neutron] Update on DB IPAM driver

From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, February 12, 2015 at 8:36 AM To: OpenStack Development Mailing

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com Date: Thursday, February 5, 2015 at 1:47 AM To: John Belamaric jbelama...@infoblox.commailto:jbelama...@infoblox.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

recommend this approach to managing your IP space. John From: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com Date: Wednesday, January 28, 2015 at 4:58 PM To: John Belamaric jbelama...@infoblox.commailto:jbelama

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

indicating that it doesn't have an IP address? On Tue, Feb 3, 2015 at 8:57 AM, John Belamaric jbelama...@infoblox.commailto:jbelama...@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

Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server

We have a spec for implementing a DHCP relay agent [1], which would enable this. We have implemented this, but it's not upstream (yet!). You would have to download our adapter [2] and dissect it to get the code from there, which may be pretty painful, because the package includes lots of

Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled

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