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 with my duties as a Neu
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 a
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 (n
oing 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 like Salva
On Feb 11, 2016, at 12:04 PM, Armando M.
mailto:arma...@gmail.com>> wrote:
On 11 February 2016 at 07:01, John Belamaric
mailto:jbelama...@infoblox.com>> wrote:
It is only internal implementation changes.
That's not entirely true, is it? There are config variables to cha
---
John Belamaric
(240) 383-6963
> On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka 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 choice
> to operators.
>
I
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
a
> 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 me at this point.
>>
>> 1) Do we plan to s
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
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
mailto:spandhe.openst...@gmail.com>> wrote:
Hi folks,
What is the right
I think Gary got auto-corrected:
training = triaging
brace = rbac
On Nov 20, 2015, at 12:41 PM, Armando M.
mailto:arma...@gmail.com>> wrote:
On 19 November 2015 at 23:10, Gary Kotton
mailto:gkot...@vmware.com>> wrote:
Hi,
There are a ton of old and ancient bugs that have not been trained. If
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
>>>
>> 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 case,
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
mailto:spandhe.openst...@
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.
J
Lucky me :)
> On Oct 8, 2015, at 10:19 AM, Andreas Jaeger 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 schedule move
>> in r
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,
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
mailto:mest...@mestery.com>> wrote:
Folks:
In trying to release some networking sub-projects recently, I ran into an issue
[1] wh
Thanks for all your hard work Kyle. Enjoy your more relaxed schedule :)
On Sep 11, 2015, at 5:12 PM, Kyle Mestery
mailto:mest...@mestery.com>> 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 but difficult job, as
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 tag
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.
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" 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 now it
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"
mailto:sorla...@nicira.com>> wrote:
Patch #153236 is introducing pluggable IPAM in the db bas
the time it's done with pre-commit phase, which we break by opening a
>> parent transaction before calling it so the failure handling semantics
>>may
>> be messed up.
>>
>>
>>
>> On Mon, Apr 13, 2015 at 9:48 AM, Carl Baldwin <
>c...@ecbaldwi
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
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" wrote:
>I will not be available to chair or att
On 3/18/15, 9:12 PM, "Sean M. Collins" 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 built-in
support w
On 3/23/15, 11:03 AM, "Salvatore Orlando"
mailto: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 hope I'm not the o
On 3/22/15, 8:05 PM, "Ian Wells"
mailto: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). We have those areas
On 3/21/15, 9:10 AM, "Salvatore Orlando"
mailto: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 solution is probably m
On 3/20/15, 8:31 PM, "Salvatore Orlando"
mailto: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 transaction to fail.
I d
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
On 3/12/15, 2:33 AM, "Carl Baldwin" 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 support it for
On 3/12/15, 12:46 AM, "Carl Baldwin" 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 instances are associa
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
the
On 2/25/15, 10:52 AM, "Carl Baldwin" 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 option 2 below.
>
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
"AnyAdd
From: Salvatore Orlando mailto:sorla...@nicira.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, February 13, 2015 at 8:26 AM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack
From: Salvatore Orlando mailto:sorla...@nicira.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, February 12, 2015 at 8:36 AM
To: OpenStack Development Mailing List
mailto:openstack-dev@lists.openstack.org>>
gt;>
Reply-To: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Date: Thursday, February 5, 2015 at 1:47 AM
To: John Belamaric mailto:jbelama...@infoblox.com>>,
"OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject:
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 mailto:kpr...@yahoo.com>>
Reply-To: Padmanabhan Krishnan mailto:kpr...@yahoo.com>&
x27;t recommend this approach to managing your
IP space.
John
From: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Reply-To: Padmanabhan Krishnan mailto:kpr...@yahoo.com>>
Date: Wednesday, January 28, 2015 at 4:58 PM
To: John Belamaric mailto:jbelama...@infoblox.com>>,
"O
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 change
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 logi
44 matches
Mail list logo
