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

[John Belamaric]

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 Neutron core reviewer, L3 
> lieutenant, and drivers team member. My participation has dropped off 
> considerably since Newton was released and I think it is fair to step down 
> and leave an opening for others to fill. There is no shortage of talent in 
> Neutron and Openstack and I know I'm leaving it in good hands.
> 
> I will be more than happy to come back to full participation in Openstack and 
> Neutron in the future if things change again in that direction. This is a 
> great community and I've had a great time participating and learning with you 
> all.
> 
> Well, I don't want to drag this out. I will still be around on IRC and will 
> be happy to help out where I am able. Feel free to ping me.
> 
> Carl
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 and records in 
Infoblox.

The driver is compatible with both Liberty and Mitaka.

This version contains important bug fixes and some feature enhancements and is 
recommended for all users.

More information and the code may be found at the networking-infoblox Launchpad 
page [1], or PyPi [2]. Bugs may also be reported on the same page.

[1] https://launchpad.net/networking-infoblox
[2] https://pypi.python.org/pypi/networking-infoblox

We are continuing to develop this driver to offer additional functionality, so 
please do provide any feedback you may have.

Thank you,

John
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

Hi Carl,

Sorry for the slow reply.

I think that both of these can be solved with the existing interface, by 
expanding the different types of "request" objects. Right now, we have very 
basic and limited requests: SpecificSubnet, AnySubnet. There is no reason we 
can't create a subnet request that includes tag (or host or segment) 
information that can be used by the existing IPAM driver methods. If the tag is 
an optional refinement, then the request type can subclass the existing 
AnySubnet request; otherwise, the request would need to be rejected by the 
driver.

Each driver can deliver its own factory for converting create_subnet (etc.) API 
requests into IPAM request objects. Thus, each driver can decide whether it 
supports some incoming request type or not. This same mechanism that applies to 
subnet also applies to IPs.

One thing we may want to consider, though, is discoverability of these 
capabilities. We have this now for extensions in general, of course. But in 
this case, we would want to be able to discover whether or not the IPAM driver 
supports this functionality, before enabling the use of the routed segments 
feature. As far as I know, we don't today provide a way to discover whether a 
particular feature works with a particular plugin or other extension. That is, 
I don't think we allow extensions to specify that they are dependent on other 
specific extensions, do we?

John

> On Mar 11, 2016, at 6:15 PM, Carl Baldwin <c...@ecbaldwin.net> wrote:
> 
> Hi,
> 
> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
> 
> This spec proposes a new association between network segments and
> subnets.  This affects how IPAM needs to work because until we know
> where 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 like Salvatore, John Belamaric,
> and you (if you interested) on this.  How will this affect the
> interface to pluggable IPAM and how can pluggable implementations can
> accommodate this change.  Obviously, we wouldn't require
> implementations to support it but routed networks wouldn't be very
> useful without it.  So, those implementations would not be compatible
> when routed networks are deployed.
> 
> Another related topic was brought up in the recent Neutron mid-cycle.
> We talked about adding a service type attribute to to subnets.  The
> reason for this change is to allow operators to create special subnets
> on a network to be used only by certain kinds of ports.  For example,
> DVR fip namespace gateway ports burn a public IP for no good reason.
> This new feature would allow operators to create a special subnet in
> the network with private addressing only to be used by these ports.
> 
> Another example would give operators the ability to use private
> subnets for router external gateway ports if shared SNAT is not needed
> or doesn't need to use public IPs.
> 
> These are two ways in which subnets are taking on extra
> characteristics which distinguish them from other subnets on the same
> network.  That is why I lumped them together in to one thread.
> 
> Carl
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

---
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 choice 
> to operators.
> 

It is only internal implementation changes. 


>> The other aspect is the deprecation process. If you add the switch into the 
>> DB migration path then the whole deprecation becomes superseded as the old 
>> IPAM logic should be abandoned immediately after that. But perhaps the other 
>> way of looking at it is that we should make an exception in the deprecation 
>> process.
>> 
>> Salvatore
>> 
>> On 11 February 2016 at 00:19, Carl Baldwin <c...@ecbaldwin.net> wrote:
>> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <arma...@gmail.com> wrote:
>> > Technically we can make this as sophisticated and seamless as we want, but
>> > this is a one-off, once it's done the pain goes away, and we won't be doing
>> > another migration like this ever again. So I wouldn't over engineer it.
>> 
>> Frankly, I was worried that going the other way was over-engineering
>> it.  It will be more difficult for us to manage this transition.
>> 
>> I'm still struggling to see what makes this particular migration
>> different than other cases where we change the database schema and the
>> code a bit and we automatically migrate everyone to it as part of the
>> routine migration.  What is it about this case that necessitates
>> giving the operator the option?
>> 
>> Carl
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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.

That's not entirely true, is it? There are config variables to change and it 
opens up the possibility of a scenario that the operator may not care about.


If we were to remove the non-pluggable version altogether, then the default for 
ipam_driver would switch from None to internal. Therefore, there would be no 
config file changes needed.


John


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 few months ago, and it is maintained in a the stable/liberty branch. We just 
released 2.0.0 out of master, but 2.0.0 is compatible with Liberty and Mitaka. 
So, from a branching perspective, is it permissible to push all the 2.0.0 
changes into stable/liberty? Those would be largely functional changes, not 
simple bug fixes. If not, should we even *have* a stable/liberty branch? 

The primary reason this is important is to ensure that users and distributors 
pull the correct version of the driver. The 1.0.0 version is pretty limited and 
we definitely want the 2.0.0 to be the one packaged with Liberty distributions. 
So, ideally we would be able to push all the 2.0.0 code into stable/liberty 
since it is completely compatible - that would make it simple for distributors 
to get the right driver.

John


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78676
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

> 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 switch all current clouds to pluggable ipam
>> implementation in Mitaka?
> 
> I think our plan originally was only to deprecate the non-pluggable
> implementation in Mitaka and remove it in Newton.  However, this is
> worth some more consideration.  The pluggable version of the reference
> implementation should, in theory, be at parity with the current
> non-pluggable implementation.  We've tested it before and shown
> parity.  What we're missing is regular testing in the gate to ensure
> it continues this way.
> 

Yes, it certainly should be at parity, and gate testing to ensure it would be 
best.

>> yes -->
>> Then data migration can be done as alembic_migration and it is what
>> currently implemented in [2] PS54.
>> In this case during upgrade from Liberty to Mitaka all users are
>> unconditionally switched to reference ipam driver
>> from built-in ipam implementation.
>> If operator wants to continue using build-in ipam implementation it can
>> manually turn off ipam_driver in neutron.conf
>> immediately after upgrade (data is not deleted from old tables).
> 
> This has a certain appeal to it.  I think the migration will be
> straight-forward since the table structure doesn't really change much.
> Doing this as an alembic migration would be the easiest from an
> upgrade point of view because it fits seamlessly in to our current
> upgrade strategy.
> 
> If we go this way, we should get this in soon so that we can get the
> gate and others running with this code for the remainder of the cycle.
> 

If we do this, and the operator reverts back to the non-pluggable version,
then we will leave stale records in the new IPAM tables. At the very least,
we would need a way to clean those up and to migrate at a later time.

>> no -->
>> Operator is free to choose whether it will switch to pluggable ipam
>> implementation
>> and when. And it leads to no automatic data migration.
>> In this case operator is supplied with script for migration to pluggable
>> ipam (and probably from pluggable ipam),
>> which can be executed by operator during upgrade or at any point after
>> upgrade is done.
>> I was testing this approach in [2] PS53 (have unresolved issues in it
>> for now).
> 
> If there is some risk in changing over then this should still be
> considered.  But, the more I think about it, the more I think that we
> should just make the switch seamlessly for the operator and be done
> with it.  This approach puts a certain burden on the operator to
> choose when to do the migration and go through the steps manually to
> do it.  And, since our intention is to deprecate and remove the
> non-pluggable implementation, it is inevitable that they will have to
> eventually switch anyway.
> 
> This also makes testing much more difficult.  If we go this route, we
> really should be testing both equally.  Does this mean that we need to
> set up a whole new job to run the pluggable implementation along side
> the old implementation?  This kind of feels like a nightmare to me.
> What do you think?
> 

Originally (as I mentioned in the meeting), I was thinking that we should not 
automatically migrate. However, I see the appeal of your arguments. Seamless is 
best, of course. But if we offer going back to non-pluggable, (which I think we 
need to at this point in the Mitaka cycle), we probably need to provide a 
script as mentioned above. Seems feasible, though.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 independently.

John

> On Jan 19, 2016, at 4:32 AM, Neil Jerram  wrote:
> 
> On 19/01/16 07:36, Andreas Scheuring wrote:
>> Hi everybody, 
>> 
>> I stumbled over a definition that explains the difference between a
>> Provider network and a self service network. [1] 
> 
> I've also spent time trying to understand this, so am happy to offer
> that understanding here (for checking?)...
> 
> I believe the _definition_ of a 'provider' network is that it is a
> network provisioned by the cloud operator - as opposed to 'tenant'
> networks that are provisioned by non-admin tenants aka users aka projects.
> 
> (I've not seen the term 'Self service' before, but presumably it means
> what I'm calling 'tenant'.
> 
> Corollaries - but not strictly part of the definition - are that:
> 
> - Provider networks typically 'map more closely' in some sense onto the
> cloud's underlying physical network than tenant networks do.  The
> 'provider' API extension - which is usually limited by policy to
> operators only, and hence can only be used with provider networks -
> allows the operator to specify that mapping, for example which VLAN to
> map on to.  Tenant networks are typically implemented with additional
> layers of encapsulation, in comparison with provider networks, in order
> to allow many tenant networks to coexist on the same compute hosts and
> yet be isolatable from each other.
> 
> - Provider networks typically use the real IP address space, whereas
> tenant networks typically use private IP address space so that multiple
> tenant networks can use the same IP addresses.
> 
> The network that is on the external side of a Neutron Router has its
> router:external property True, and also has to be a provider network. 
> Floating IPs come from a subnet that is associated with that provider
> network.
> 
> It's possible to attach VMs directly to a provider network, as well as
> to tenant networks.
> 
>> 
>> To summarize it says:
>> - Provider Network: primarily uses layer2 services
> 
> I don't know what this means.  All networks have a layer 2 somewhere.
> 
>> and vlan segmentation
> 
> Yes, but they don't have to.  A provider network can be 'flat', which
> means that its VM interfaces are bridged onto one of the physical
> interfaces of the compute host (and it is assumed that all hosts'
> physical interfaces are themselves bridged together).  So then any VLAN
> that a VM used would be trunked through the physical network.
> 
>> and cannot be used for advanced services (fwaas,..)
> 
> (I didn't know that, but OK.)
> 
>> - Self-service Network: is Neutron configured to use a overlay network
> 
> Grammar?
> 
>> and supports advanced services (fwaas,..)
>> 
>> 
>> But my understanding is more like this:
>> - Provider Network: The Openstack user needs information about the
>> underlying network infrastructure to create a virtual network that
>> exactly matches this infrastructure. 
> 
> Agreed, if s/user/operator/ and s/virtual//.  OpenStack _users_ cannot
> create provider networks, and I wouldn't call a provider network 'virtual'.
> 
> 
>> 
>> - Self service network: The Openstack user can create virtual networks
>> without knowledge about the underlaying infrastructure on the data
>> network. This can also include vlan networks, if the l2 plugin/agent was
>> configured accordingly.
> 
> Agreed.
>> 
>> 
>> Did the meaning of a provider network change in the meantime, or is my
>> understanding just wrong?
>> 
>> Thanks!
>> 
>> 
>> 
>> 
>> [1]
>> http://docs.openstack.org/liberty/install-guide-rdo/overview.html#id4
>> 
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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:

Hi folks,

What is the right way to use ipam reference implementation with devstack? When 
setup devstack, I didnt have the setting
 ipam_driver = internal

I changed it afterwards. But now when I try to create a port, I get this error:

2015-11-23 21:23:00.078 ERROR neutron.ipam.drivers.neutrondb_ipam.driver 
[req-e6b5ed3c-9fb0-4c0b-a5b9-c8fdecea0cf0 admin 
82e842f0f1b548c28f11be231744ee24] IPAM subnet referenced to Neutron subnet 
a1ddebd1-e63b-41af-a1d3-d5611da46f7e does not exist

MariaDB [neutron]> select * from ipamsubnets;
Empty set (0.00 sec)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 ancient bugs that have not been trained. If you guys 
have some time then please go over them. In most cases some are not even bugs 
and are just questions. I have spent the last few days going over and training 
a few.
Over the last two days a number of bugs related to Neutron RBAC have been 
opened. I have created a new tag called ‘brace’. Kevin can you please take a 
look. Some may be bugs, others may be edge cases that we missed in the review 
process and others may be a mis understanding of the feature.

What does brace mean? That doesn't seem very intuitive.

Are you suggesting to add one to cover 'access control' in general?

Thanks for helping out!

[1] 
http://docs.openstack.org/developer/neutron/policies/bugs.html#proposing-new-tags



A luta continua
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

>>> 
>> 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, we needed the framework for pluggable IPAM to 
produce our driver. We are now targeting Liberty, but based on the above our 
plan is:

1) Release 1.0 from master (soon)
2) Create stable/liberty based on 1.0
3) Continue to add features in master, but *maintain compatibility with 
stable/liberty*.

It is important that our next version works with stable/liberty, not just 
master/Mitaka.

John



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 found at the networking-infoblox Launchpad 
page [1]. Bugs may also be reported on the same page.

[1] https://launchpad.net/networking-infoblox

We are continuing to develop this driver to offer additional functionality, so 
please do provide any feedback you may have.

Thank you,

John


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 
> wrote:

Hi folks,

I have a small question/suggestion about IPAM.

With IPAM, we are allowing users to have their own IPAM drivers so that they 
can manage IP allocation. The problem is, the new ipam tables in the database 
have the same columns as the old tables. So, as a user, if I want to have my 
own logic for ip allocation, I can't actually get any help from the database. 
Whereas, if we had an arbitrary json blob in the ipam tables, I could put any 
useful information/tags there, that can help me for allocation.

Does this make sense?

e.g. If I want to create multiple allocation pools in a subnet and use them for 
different purposes, I would need some sort of tag for each allocation pool for 
identification. Right now, there is no scope for doing something like that.

Any thoughts? If there are any other way to solve the problem, please let me 
know



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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. 

John

> On Oct 30, 2015, at 12:51 PM, Kamat, Maruti Haridas  
> wrote:
> 
> Hi Pavel,
> 
> Thanks for the information.
> 
> I was also looking at Infoblox driver at 
> https://github.com/openstack/networking-infoblox
> 
> Is implementation of Infoblox driver still going on? 
> 
> Thanks,
> Maruti
> 
> 
> -Original Message-
> From: Pavel Bondar [mailto:pbon...@infoblox.com] 
> Sent: Friday, October 30, 2015 6:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
> Alcatel-Lucent VitalQIP
> 
> Hi Maruti,
> 
> For now only Pluggable IPAM interface with reference IPAM driver were 
> released, and I am working on implementing IPAM driver for Infoblox.
> 
> But I am not aware about existense of IPAM drivers from BlueCat or Alcatel.
> If you want to investigate with pluggable IPAM more you can start with IPAM 
> Interface and reference IPAM driver. They can be found under [1].
> 
> [1] https://github.com/openstack/neutron/tree/master/neutron/ipam
> 
> Thanks,
> Pavel
> 
> From: Kamat, Maruti Haridas 
> Sent: Thursday, October 29, 2015 8:24 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and 
> Alcatel-Lucent VitalQIP
>   
> 
> Hi
>  
> I am exploring IPAM feature in OpenStack Neutron. In particular, I wanted to 
> look at the IPAM drivers for BlueCat Networks' (Proteus) and Alcatel-Lucent's 
> VitalQIP.
>  
> If someone can provide me with pointers, it would be of great help.
>  
> Thanks,
> Maruti
>  
>  
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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, Edgar Magana 
> wrote:

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

Edgar Magana
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 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.
> 
> 
> The Networking Guide is continuously updated, so you can write anytime ;)
> 
> Andreas
> -- 
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>   HRB 21284 (AG Nürnberg)
>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 into an issue 
[1] where I couldn't release some projects due to them not being registered on 
pypi. I have a patch out [2] which adds pypi publishing jobs, but before that 
can merge, we need to make sure all projects have pypi registrations in place. 
The following networking sub-projects do NOT have pypi registrations in place 
and need them created following the guidelines here [3]:

networking-calico
networking-infoblox
networking-powervm

The following pypi registrations did not follow directions to enable 
openstackci has "Owner" permissions, which allow for the publishing of packages 
to pypi:

networking-ale-omniswitch
networking-arista
networking-l2gw
networking-vsphere

Once these are corrected, we can merge [2] which will then allow the 
neutron-release team the ability to release pypi packages for those packages.

Thanks!
Kyle

[1] 
http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
[2] https://review.openstack.org/#/c/229564/1
[3] 
http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 but difficult job, as Morgan 
recently put it in his non-candidacy email [1]. But it goes further than that 
for me. As Flavio put it in his post about "Being a PTL" [2], it's a full time 
job. In the case of Neutron, it's more than a full time job, it's literally an 
always on job.

I've tried really hard over my three cycles as PTL to build a stronger web of 
trust so the project can grow, and I feel that's been accomplished. We have a 
strong bench of future PTLs and leaders ready to go, I'm excited to watch them 
lead and help them in anyway I can.

As was said by Zane in a recent email [3], while Heat may have pioneered the 
concept of rotating PTL duties with each cycle, I'd like to highly encourage 
Neutron and other projects to do the same. Having a deep bench of leaders 
supporting each other is important for the future of all projects.

See you all in Tokyo!
Kyle

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 tagging of subnets with meta-data in our backend. We 
plan to enable the user to utilize this information when making an IPAM request 
via a custom IPAM request type. However it would be a two step process - use 
the meta-data to find the network then use the network to get the IP.




As a (gulp) third alternative, we should consider that the front network here 
is in essence a layer 3 domain, and we have modeled layer 3 domains as address 
scopes in Liberty. The user is essentially saying give me an address that is 
routable in this scope - they don't care which actual subnet it gets allocated 
on. This is conceptually more in-line with [2] - modeling L3 domain separately 
from the existing Neutron concept of a network being a broadcast domain.

Again, the issue is that when you ask for an address you tend to have quite a 
strong opinion of what that address should be if it's location-specific.



An alternative that gives you more control than using an address scope would be 
to use a subnet pool. The more I think about this, it seems to me in that in 
this particular use case, all we are talking about is a grouping of subnets. 
This leads me to think tying it to subnet pools rather than to a network, 
because you can group subnets arbitrarily (though a given subnet can be in only 
one pool).

The issue is the often arbitrary and overloaded use of the word network. This 
has already been defined as an L2 broadcast domain so I am not sure it is a 
good idea to change that at this time.


Fundamentally, however we associate the segments together, this comes down to a 
scheduling problem.

It's not *solely* a scheduling problem, and that is my issue with this 
statement (Assaf has been saying the same).  You *can* solve this *exclusively* 
with scheduling (allocate the address up front, hope that the address has space 
for a VM with all its constraints met) - but that solution is horrible; or you 
can solve this largely with allocation where scheduling helps to deal with pool 
exchaustion, where it is mainly another sort of problem but scheduling plays a 
part.


Fair enough.


John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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. I am not sure I am clear on 
this one but it sounds like you want the routers attached to the segments to 
advertise routes to the specific floating IPs. Presumably then they would do 
NAT or the instance would assign both the fixed IP and the floating IP to its 
interface?

In Proposal 1, (a) is solved by associating segments to the front network via a 
router - that association is used to provide a single hook into the existing 
API that limits the scope of segment selection to those associated with the 
front network. (b) is solved by tying the floating IP ranges to the same front 
network and managing the reachability with dynamic routing.

In Proposal 2, (a) is solved by tagging each network with some meta-data that 
the IPAM system uses to make a selection. This implies an IP allocation request 
that passes something other than a network/port to the IPAM subsystem. This 
fine from the IPAM point of view but there is no corresponding API for this 
right now. To solve (b) either the IPAM system has to publish the routes or the 
higher level management has to ALSO be aware of the mappings (rather than just 
IPAM).

To throw some fuel on the fire, I would argue also that (a) is not sufficient 
and address availability needs to be considered as well (as described in [1]). 
Selecting a host based on reachability alone will fail when addresses are 
exhausted. Similarly, with (b) I think there needs to be consideration during 
association of a floating IP to the effect on routing. That is, rather than a 
huge number of host routes it would be ideal to allocate the floating IPs in 
blocks that can be associated with the backing networks (though we would want 
to be able to split these blocks as small as a /32 if necessary - but avoid 
it/optimize as much as possible).

In fact, I think that these proposals are more or less the same - it's just in 
#1 the meta-data used to tie the backing networks together is another network. 
This allows it to fit in neatly with the existing APIs. You would still need to 
implement something prior to IPAM or within IPAM that would select the 
appropriate backing network.

As a (gulp) third alternative, we should consider that the front network here 
is in essence a layer 3 domain, and we have modeled layer 3 domains as address 
scopes in Liberty. The user is essentially saying give me an address that is 
routable in this scope - they don't care which actual subnet it gets allocated 
on. This is conceptually more in-line with [2] - modeling L3 domain separately 
from the existing Neutron concept of a network being a broadcast domain.

Fundamentally, however we associate the segments together, this comes down to a 
scheduling problem. Nova needs to be able to incorporate data from Neutron in 
its scheduling decision. Rather than solving this with a single piece of 
meta-data like network_id as described in proposal 1, it probably makes more 
sense to build out the general concept of utilizing network data for nova 
scheduling. We could still model this as in #1, or using address scopes, or 
some arbitrary data as in #2. But the harder problem to solve is the 
scheduling, not how we tag these things to inform that scheduling.

The optimization of routing for floating IPs is also a scheduling problem, 
though one that would require a lot more changes to how FIP are allocated and 
associated to solve.

John

[1] https://review.openstack.org/#/c/180803/
[2] https://bugs.launchpad.net/neutron/+bug/1458890/comments/7




On Jul 21, 2015, at 10:52 AM, Carl Baldwin 
c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote:


On Jul 20, 2015 4:26 PM, Ian Wells 
ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote:

 There are two routed network models:

 - I give my VM an address that bears no relation to its location and ensure 
 the routed fabric routes packets there - this is very much the routing 
 protocol method for doing things where I have injected a route into the 
 network and it needs to propagate.  It's also pretty useless because there 
 are too many host routes in any reasonable sized cloud.

 - I give my VM an address that is based on its location, which only becomes 
 apparent at binding time.  This means that the semantics of a port changes - 
 a port has no address of any meaning until binding, because its location is 
 related to what it does - and it leaves open questions about what to do when 
 you migrate.

 Now, you seem to generally be thinking in terms of the latter model, 
 particularly since the provider network model you're talking about fits 
 there.  But then you say:

Actually, both.  For example, GoDaddy assigns each vm an ip from the location 
based address 

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

[John Belamaric]

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 now it looks like I may make another attempt. Who else is interested
 in this, as a user or to help contributing? If we get some traction we
 can have an IRC meeting sometime next week.

Hi Erik,

Mirantis has interest in this functionality, and depending on the amount
of work involved, we could pitch in...

Please cc me or add me to relevant reviews and I'll make sure the right
folks are paying attention.

All the best,
-jay

 *From:*Scott Drennan [mailto:sco...@nuagenetworks.net]
 *Sent:* den 4 maj 2015 18:42
 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] [neutron]Anyone looking at support for
 VLAN-aware VMs in Liberty?

 VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I
 don't see any work on VLAN-aware VMs for Liberty.  There is a
 blueprint[1] and specs[2] which was deferred from Kilo - is this
 something anyone is looking at as a Liberty candidate?  I looked but
 didn't find any recent work - is there somewhere else work on this is
 happening?  No-one has listed it on the liberty summit topics[3]
 etherpad, which could mean it's uncontroversial, but given history on
 this, I think that's unlikely.

 cheers,

 Scott

 [1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

 [2]: https://review.openstack.org/#/c/94612

 [3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics



 
_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 IPAM in the db base plugin class, and 
default to it at the same time, I believe.

If the consensus is to default to IPAM driver then in order to satisfy grenade 
requirements those migrations scripts should be run. There should actually be a 
single script to be run in a one-off fashion. Even better is treated as a DB 
migration.

However, the plan for Kilo was to not turn on pluggable IPAM for default. Now 
that we are targeting Liberty, we should have this discussion again, and not 
take for granted that we should default to pluggable IPAM just because a few 
months ago we assumed it would be default by Liberty.
I suggest to not enable it by default, and then consider in L-3 whether we 
should do this switch.
For the time being, would it be possible to amend patch #153236 to not run 
pluggable IPAM by default. I appreciate this would have some impact on unit 
tests as well, which should be run both for pluggable and traditional IPAM.

Salvatore

On 4 May 2015 at 20:11, Pavel Bondar 
pbon...@infoblox.commailto:pbon...@infoblox.com wrote:
Hi,

During fixing failures in db_base_plugin_v2.py with new IPAM[1] I faced
to check-grenade-dsvm-neutron failures[2].
check-grenade-dsvm-neutron installs stable/kilo, creates
networks/subnets and upgrades to patched master.
So it validates that migrations passes fine and installation is works
fine after it.

This is where failure occurs.
Earlier there was an agreement about using pluggable IPAM only for
greenhouse installation, so migrate script from built-in IPAM to
pluggable IPAM was postponed.
And check-grenade-dsvm-neutron validates greyhouse scenario.
So do we want to update this agreement and implement migration scripts
from built-in IPAM to pluggable IPAM now?

Details about failures.
Subnets created before patch was applied does not have correspondent
IPAM subnet,
so observed a lot of failures like this in [2]:
Subnet 2c702e2a-f8c2-4ea9-a25d-924e32ef5503 could not be found
Currently config option in patch is modified to use pluggable_ipam by
default (to catch all possible UT/tempest failures).
But before the merge patch will be switched back to non-ipam
implementation by default.

I would prefer to implement migrate script as a separate review,
since [1] is already quite big and hard for review.

[1] https://review.openstack.org/#/c/153236
[2]
http://logs.openstack.org/36/153236/54/check/check-grenade-dsvm-neutron/42ab4ac/logs/grenade.sh.txt.gz

- Pavel Bondar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

 notifications
will be sent for you automagically. That's the simplest approach, I
haven't thought this through
and I'm sure there will be issues but it should be possible. We're still
left with questions such
as: What happens if I commit a mega-transaction and then all (Or even
more complicated, one) of
the notifications fails, but this isn't a new problem.


 First, it's a recipe for the cherished lock wait timeout deadlocks
because
 create_port makes yielding calls. These are awful to troubleshoot and
are
 pretty annoying for users (request takes ~60 seconds and then blows up).

 Second, create_port in ML2 expects the transaction to be committed to
the DB
 by 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...@ecbaldwin.net mailto:c...@ecbaldwin.net  wrote:


 Have we found the last of them? I wonder. I suppose any higher level
 service like a router that needs to create ports under the hood (under
 the API) will have this problem. The DVR fip namespace creation comes
 to mind. It will create a port to use as the external gateway port
 for that namespace. This could spring up in the context of another
 create_port, I think (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 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 need to be unwound.
 
  On 4/13/15, 10:44 AM, Pavel Bondar 
pbon...@infoblox.com mailto:pbon...@infoblox.com  wrote:
 
 Hi,
 
 I made some investigation on the topic[1] and see several issues on
this
 way.
 
 1. Plugin's create_port() is wrapped up in top level transaction for
 create floating ip case[2], so it becomes more complicated to do IPAM
 calls outside main db transaction.
 
 - for create floating ip case transaction is initialized on
 create_floatingip level:
 create_floatingip(l3_db)-create_port(plugin)-create_port(db_base)
 So IPAM call should be added into create_floatingip to be outside db
 transaction
 
 - for usual port create transaction is initialized on plugin's
 create_port level, and John's change[1] cover this case:
 create_port(plugin)-create_port(db_base)
 
 Create floating ip work-flow involves calling plugin's create_port,
 so IPAM code inside of it should be executed only when it is not
wrapped
 into top level transaction.
 
 2. It is opened question about error handling.
 Should we use taskflow to manage IPAM calls to external systems?
 Or simple exception based model is enough to handle rollback actions
on
 third party systems in case of failing main db transaction.
 
 [1] https://review.openstack.org/#/c/172443/
 [2] neutron/db/l3_db.py: line 905
 
 Thanks,
 Pavel
 
 On 10.04.2015 21:04,
openstack-dev-requ...@lists.openstack.org
mailto:openstack-dev-requ...@lists.openstack.org wrote:
  L3 Team,
 
  I have put up a WIP [1] that provides an approach that shows the ML2
 create_port method refactored to use the IPAM driver prior to
initiating
 the database transaction. Details are in the commit message - this is
 really just intended to provide a strawman for discussion of the
 options. The actual refactor here is only about 40 lines of code.
 
  [1] https://review.openstack.org/#/c/172443/
 
 
  Thanks,
  John
 
 
 
___
___
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  
_
_
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
_
_
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Kevin Benton

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

[John Belamaric]

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 need to be unwound.

On 4/13/15, 10:44 AM, Pavel Bondar pbon...@infoblox.com wrote:

Hi,

I made some investigation on the topic[1] and see several issues on this
way.

1. Plugin's create_port() is wrapped up in top level transaction for
create floating ip case[2], so it becomes more complicated to do IPAM
calls outside main db transaction.

- for create floating ip case transaction is initialized on
create_floatingip level:
create_floatingip(l3_db)-create_port(plugin)-create_port(db_base)
So IPAM call should be added into create_floatingip to be outside db
transaction

- for usual port create transaction is initialized on plugin's
create_port level, and John's change[1] cover this case:
create_port(plugin)-create_port(db_base)

Create floating ip work-flow involves calling plugin's create_port,
so IPAM code inside of it should be executed only when it is not wrapped
into top level transaction.

2. It is opened question about error handling.
Should we use taskflow to manage IPAM calls to external systems?
Or simple exception based model is enough to handle rollback actions on
third party systems in case of failing main db transaction.

[1] https://review.openstack.org/#/c/172443/
[2] neutron/db/l3_db.py: line 905

Thanks,
Pavel

On 10.04.2015 21:04, openstack-dev-requ...@lists.openstack.org wrote:
 L3 Team,
 
 I have put up a WIP [1] that provides an approach that shows the ML2
create_port method refactored to use the IPAM driver prior to initiating
the database transaction. Details are in the commit message - this is
really just intended to provide a strawman for discussion of the
options. The actual refactor here is only about 40 lines of code.
 
 [1] https://review.openstack.org/#/c/172443/
 
 
 Thanks,
 John


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 to chair or attend the L3 sub team meeting
tomorrow.  Are others okay with canceling the meeting?  Let me know if
you have something to discuss.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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).  We have those areas and we use 
NAT to separate them (setting aside the occasional isolated network area with 
no external connections).  But NAT doesn't separate tenants, it separates 
externally connected routers: one tenant can have many of those routers, or one 
router can be connected to networks in both tenants.  We just happen to 
frequently use the one external router per tenant model, which is why address 
pools *appear* to be one per tenant.  I think, more accurately, an external 
router should be given an address pool, and tenants have nothing to do with it.

I think conflating address pools with routable space is a mistake. To me, this 
is the concept of address scope which I see as distinct from pool. For 
example, a single shared routable space may have several pools, each a /8 which 
is owned by a specific tenant. This is something that I would like to see in 
Liberty, making a the concept of an address scope a first class concept. 
Routers would be able to attach only to networks within the same scope, unless 
NAT was applied.

John
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 hope I'm not the only one), was to disentangle 
IPAM logic from the API request processing code. In this way 3rd party backend 
transactions would have been executed independently of the database operation 
for processing the API request. Also, this would have enabled us to integrate 
tools like taskflow (I think Pavel looked into that). And most importantly 
avoid long database transactions which include remote calls as well.\

I agree this is a worthy goal we should look to achieve in Liberty. It will 
require a lot more refactoring but should clean things up nicely.


However, this is not achievable - and mostly for an oversight on our side. So 
we should welcome passing down the context to the driver, with the goal of 
removing it in the next release. I think it will be fair to assume the 
interface experimental for this release cycle - and stable for the next one.


Makes sense to me.

The issue is not really with mysql connector but more in its interaction with 
eventlet. This is something that will eventually (hopefully soon) be sorted 
within oslo_db. However, generally speaking it is better to avoid long-standing 
database transactions.
However, we've provided enough reasons for which we'd need, at least for this 
release, push down the database session to the IPAM driver. So it's now up to 
reviewers to decide whether this is acceptable or not.

Ok.


The technical debt aspect of adding a session to the driver is simply due to 
the fact that we'll need to have a follow-up action to remove it.
Such follow up action will imply some more refactoring in the db base class, 
possibly removing some of the code Pavel is introducing and moving it into an 
appropriate IPAM integration module. This will be the additional technical debt.
On the other hand, if the developers working on IPAM agree that it is ok to 
keep passing down the session to the IPAM driver as a permanent solution, then 
we have less technical debt to deal with (and this would be the one we 
anticipated because for Kilo Neutron should be able to run with and without the 
IPAM driver)


I see your point, it creates a bit more work in the next cycle.


John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 transaction to fail.
I do not think there is a lot we can do about this at the moment, unless we 
agree on a more pervasive refactoring:



This is essentially what is described in the Refactoring section of the spec 
[1] (see the third paragraph in that section specifically). The original 
expectation (as you say) was that we would be able to achieve this by only 
changing the DB plugin, but this looks to not be feasible at this point given 
the way sessions are handled in the subclasses.


Otherwise, we'd just made the IPAM driver session aware. This implies changes 
to the Pool and Subnet interface to accept an optional session parameter.
The above works and is probably quicker from an implementation perspective. 
However, doing so somehow represents a failure of the pluggable IPAM effort as 
total separation between IPAM and API operation processing was one of our goals.

Actually, I don't see this as a big deal or a failure. In fact, it may be quite 
common and useful for a given driver to store some state in its own tables 
(like the reference driver is doing). The primary goal is to enable alternate 
IPAM implementations, whether external or completely local. That goal is still 
achieved even with this change. So, I don't see a big problem with the IPAM 
driver being session-aware.

Also, for drivers with a remote backend, remote calls will be made within a DB 
transaction, which is another thing we wanted to avoid.

This is more of a concern, due to the issue with the mysql connector. I guess 
I'd like to understand better what that issue is and how we may resolve it, 
since it is a source of pain not just for IPAM.


And finally, there is the third option. I know IPAM contributors do not even 
want to hear it... but the third option is to enjoy 6 more months to come up 
with a better implementation which does not add any technical debt. In Kilo 
from the IPAM side we're already introducing subnet pools, so it won't be a 
total failure!

I think we can still handle the primary use case without adding technical debt. 
We had hoped to *re-pay* more technical debt with the refactor than we are able 
to achieve, but I don't see any additional debt by making the driver 
session-aware.

John

[1] 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 solution is probably marginally better 
than the fake IP one (eg.: 0.0.0.1 to say the gateway is the first IP). 
Technically they're equivalent - and one could claim that the address-like 
notation is nothing bug and octet based representation of a number.

I agree here. An integer is probably clearer.


I wonder why a user would ask for a random CIDR with a given prefix, and then 
mandate that gateway IP and allocation pools are in precise locations within 
this randomly chosen CIDR. I guess there are good reasons I cannot figure out 
by myself.

Early in the spec review cycle we talked about some generalizations of these 
concepts. I would consider the location of the gateway IP to be a reservation; 
we discussed having subnet templates that (in my mind) are essentially a 
collection of IP reservations. This would allow a user to specify the specific 
locations of various services in a pre-defined manner; routing is just one of 
those services that is prominent as a specific case for backwards compatibility.

In my opinion all that counts here is that the semantics of a resource 
attribute should be the same in the request and the response. For instance, one 
should not have gateway_ip as a relative counter-like IP in the request body 
and then as an actual IP address in the response object.

So, you are agreeing with an alternate name in the request, as suggested?

John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 built-in
support would allow you to request any subnet or a specific subnet.
This concept applies to both pool-based and non-pool-based requests.

Currently, a request needs to be essentially encoded in the cidr field
of the subnet creation API call, in order to provide complete API
backwards compatibility. A blank CIDR indicates any subnet; a specific
CIDR indicates to allocate that subnet. However, the intention is that
individual drivers could add their own types of requests. This is
supported in the request factory defined in [1]. This means, for example,
we can implement a request class RFC3633SubnetRequest that handles
acquiring the CIDR via prefix delegation. The user will pass RFC3633 as
the cidr attribute in that case, so that the correct request class is
instantiated. A similar mechanism can be used for address requests - for
example, EUI64 and other auto-generated addresses.

To enable this, an additional change needed beyond [1] is to use the
request factory for validation of the cidr field rather than the API
layer.


[1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 address scope concept. This concept was discussed during the spec
reviews of pluggable IPAM, and is simply adding a first-class object that
represents a layer 3 address space. A subnet would belong to a specific
scope, and any IP within a scope would be unique. To support the tenant
with overlapping space, you would create multiple scopes for that tenant.

This option maintains backward compatibility for existing deployments,
while allowing us to improve the model moving forward.

John

On 3/11/15, 2:22 AM, Carl Baldwin c...@ecbaldwin.net wrote:

On Tue, Mar 10, 2015 at 11:34 AM, Gabriel Bezerra
gabri...@lsd.ufcg.edu.br wrote:
 Em 10.03.2015 14:24, Carl Baldwin escreveu:
 I'd vote for allowing against such restriction, but throwing an error in
 case of creating a router between the subnets.

 I can imagine a tenant running multiple instances of an application,
each
 one with its own network that uses the same address range, to minimize
 configuration differences between them.

I see your point but yuck!  This isn't the place to skimp on
configuration changes.

Carl

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 instances are associated with a specific subnet
pool. As long as we do not allow overlap within a *pool* this is not
necessary. The pool will imply the scope (currently implicit, with one per
tenant), which the driver/external system would use to differentiate the
CIDR. As I mentioned in an earlier email, this would introduce the
uniqueness constraint in Kilo, but only when pluggable IPAM is enabled.

John




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 support it for backward compatibility and so my
proposal will account for that.

I was proposing that the reference driver not support it either, and we
only handle that use case via the non-pluggable implementation in Kilo,
waiting until Liberty to handle it in the pluggable implementation.
However, I don't think it's particularly harmful to do it either way so I
am OK with this.

Thanks,
John


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 defining uniqueness - address scopes. This 
would be owned by a tenant but could be shared across tenants. It's still in 
the early stages of definition though, and more discussion is needed but should 
probably wait until after Kilo is out!


From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, March 12, 2015 at 6:38 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a 
tenant

My concern is that we are introducing new objects in Neutron that are scoped to 
a tenant and we don't have anything else like that right now. For example, I 
can create 100 3-tier topologies (router + 3 subnets/networks) with duplicated 
names, CIDRs, etc between all of them and it doesn't matter if I do it on 100 
different tenants or all under the same tenant.

Put a different way, tenants don't mean anything in the Neutron data model. 
They are just a tag to use to enforce quotas, policies, and filters on incoming 
API requests. Uniqueness shouldn't come from 'x' + tenant_id.

It seems like what is being introduced here is going to fundamentally change 
that by forcing the creation of separate tenants to have overlapping IPs. I 
think the barrier should be very high to introduce anything that does that.

Can you elaborate why tenants are used for uniqueness for IPAM instead of 
having a separate grouping mechanism?

On Wed, Mar 11, 2015 at 3:24 PM, Ihar Hrachyshka 
ihrac...@redhat.commailto:ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/10/2015 06:34 PM, Gabriel Bezerra wrote:
 Em 10.03.2015 14:24, Carl Baldwin escreveu:
 Neutron currently does not enforce the uniqueness, or
 non-overlap, of subnet cidrs within the address scope for a
 single tenant.  For example, if a tenant chooses to use
 10.0.0.0/24http://10.0.0.0/24 on more than one subnet, he or she is free 
 to do so.
 Problems will arise when trying to connect a router between these
 subnets but that is left up to the tenant to work out.

 In the current IPAM rework, we had decided to allow this overlap
 in the reference implementation for backward compatibility.
 However, we've hit a snag.  It would be convenient to use the
 subnet cidr as the handle with which to refer to a previously
 allocated subnet when talking to IPAM.  If overlap is allowed,
 this is not possible and we need to come up with another
 identifier such as Neutron's subnet_id or another unique IPAM
 specific ID.  It could be a burden on an external IPAM system --
 which does not allow overlap -- to work with a completely
 separate identifier for a subnet.

 I do not know of anyone using this capability (or mis-feature)
 of Neutron.  I would hope that tenants are aware of the issues
 with trying to route between subnets with overlapping address
 spaces and would avoid it.  Is this potential overlap something
 that we should really be worried about?  Could we just add the
 assumption that subnets do not overlap within a tenant's scope?

 An important thing to note is that this topic is different than
 allowing overlap of cidrs between tenants.  Neutron will continue
 to allow overlap of addresses between tenants and support the
 isolation of these address spaces.  The IPAM rework will support
 this.

 Carl Baldwin


 I'd vote for allowing against such restriction, but throwing an
 error in case of creating a router between the subnets.

 I can imagine a tenant running multiple instances of an
 application, each one with its own network that uses the same
 address range, to minimize configuration differences between them.


I agree with Gabriel on the matter. There is nothing inherently wrong
about a tenant running multiple isolated network setups that use
overlapping addresses (as there is nothing wrong about multiple
tenants doing the same).

There seems to be a value in disallowing overlapping subnets attached
to the same router though.

All in all, there seems to be no need to limit neutron API just
because most external IPAM implementation do not seem to care about
supporting the use case.

It's also an issue that the change proposed is backwards incompatible.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAMCPAAoJEC5aWaUY1u57d/cH/A+nAuLrNaCPumjlOPJP90c3
4oSh0ioxEQw2uBRx1mWvcQle0M1U4Psy5CqIjeHgDhRlCNKB2gAYvm7/lCwZoCw7
pxLUerfZPFguNKYCUly1MYyo0gorycFgemoHKEFwHboDJfPdGYxdhW8HuemCClOG

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

[John Belamaric]

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 option 2 below.

I think I would go with the locking solution first because it is most
like what we have today.

+1. The pluggable framework will make it easy to swap these in and out, to
get real-world experience with each.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 
AnyAddressRequest is sent for a subnet where addresses are supposed to be 
autogenerated, because the ipam driver won't generate the address.


Makes sense.


Hmm. How dynamic is Python? I know in Ruby I could do something like this at 
class load time:

config.use_ipam ? DbBasePluginV2 = IpamDbBasePluginV2 : DbBasePluginV2 = 
LegacyDbBasePluginV2

and all the subclasses would work fine as before...

Technically yes.
From a practical perspective however if the subclass is assuming that 
create_port works in the old way, and then instead is working in the ipam 
way, it might be mayhem!


Yes, certainly. But it provides a transition period for plugins to migrate to 
support the new IPAM model.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Update on DB IPAM driver
...

I think the auto-generated case should be a base class as you described in [1], 
but each subclass would implement the specific auto-generation. See the 
discussion at line 468 in [2] and see what you think. Of course for addresses 
that come from RA there would be no IPAM.

I think this makes sense.


Thinking a little more on this, in the case of magic address prefixes, we 
probably should have the factory method generate the right request class. That 
way, the logic for those magic prefixes is all in one place. You could still 
specify the class in the request but the magic prefixes would take priority.



[1] https://review.openstack.org/#/c/150485/
[2] 
https://review.openstack.org/#/c/153236/2/neutron/db/db_base_plugin_v2.py,unified




- The db base refactoring being performed by Pavel is under way [3]. It is 
worth noting that this is a non-negligible change to some of Neutron's basic 
and more critical workflows. We should expect pushback from the community 
regarding the introduction of this change in the 3rd milestone. At this stage I 
would suggest either:
A) consider a strategy for running pluggable IPAM as optional
B) consider delaying to Liberty.
(and that's where I get virtually jeered and pelted with rotten tomatoes)

I wish I had some old tomatoes! Seriously, I think A is a reasonable 
approach. To make this really explicit we may want to basically replace the DB 
plugin class with a shim that delegates to either the current implementation or 
the new implementation, depending on the flag.

The fact that the current implementation is pretty much a bunch of private 
methods in the db base plugin class executed within a transaction for creating 
a port makes the situation a wee bit more complex. I'm not sure we can replace 
the db plugin class with a shim so easily, because we need to consider the 
impact on plugins which inherit from this base class. For instance some plugins 
override methods from the base class, and this would be a problem. For those 
plugins we must ensure old-style IPAM is performed. A transitory solution might 
be to have, for the relevant methods 2 versions - one would be the current one, 
and the other one would be the one leveraging pluggable IPAM. During plugin 
initialisation, the plugin itself will decide whether use or not the latter 
methods. This might be tuneable with a configuration parameter too. The 
downside of this approach is that it will not allow us to remove old baked in 
IPAM code, and will have an impact on code maintainability which ultimately 
will result in accumulating even more technical debt. However, I might be 
missing some better alternative, so if you have any proposal just let me know.

Hmm. How dynamic is Python? I know in Ruby I could do something like this at 
class load time:

config.use_ipam ? DbBasePluginV2 = IpamDbBasePluginV2 : DbBasePluginV2 = 
LegacyDbBasePluginV2

and all the subclasses would work fine as before...


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Update on DB IPAM driver

Hi,

I have updated the patch; albeit not complete yet it's kind of closer to be an 
allocator decent enough to replace the built-in logic.

I will be unable to attend today's L3/IPAM meeting due to a conflict, so here 
are some highlights from me on which your feedback is more than welcome:

- I agree with Carl that the IPAM driver should not have explicit code paths 
for autoaddress subnets, such as DHCPv6 stateless ones. In that case, the 
consumer of the driver will generate the address and then to the IPAM driver 
that would just be allocation of a specific address. However, I have the 
impression the driver still needs to be aware of whether the subnet has an 
automatic address mode or not - since in this case 'any' address allocation 
won't be possible. There already comments about this in the review [1]

I think the auto-generated case should be a base class as you described in [1], 
but each subclass would implement the specific auto-generation. See the 
discussion at line 468 in [2] and see what you think. Of course for addresses 
that come from RA there would be no IPAM.

[1] https://review.openstack.org/#/c/150485/
[2] 
https://review.openstack.org/#/c/153236/2/neutron/db/db_base_plugin_v2.py,unified


- We had a discussion last week on whether the IPAM driver and neutron should 
'share' database tables. I went back and forth a lot of time, but now to me it 
seems the best thing to do is to have the IPAM driver maintain an 'ip_requests' 
tables, where it stores allocation info. This table partially duplicates data 
in IPAllocation, but on the plus side it makes the IPAM driver self sufficient. 
The next step would be to decide whether we want to go a step further and also 
assume the driver should not access at all Neutron's DB, but I would defer that 
discussion to the next iteration (for both the driver and the IPAM interface)

- I promised a non blocking algorithm for IP allocation. The one I was 
developing was based on specifying the primary key on the ip_requests table in 
a way that it would prevent two concurrent requests from getting the same 
address, and would just retry getting an address until the primary key 
constraint was satisfied. However, recent information emerged on MySQL galera's 
(*) data set [2] certification  clarified that this kind of algorithm would 
still result in a deadlock error from failed data set certification. It is 
worth noting that in this case a solution based on traditional compare-and-swap 
is not possible because concurrent requests would be inserting data at the same 
time. I am now working on an alternative solution, and I would like to first 
implement a PoC for it (so that I can prove it works).

- The db base refactoring being performed by Pavel is under way [3]. It is 
worth noting that this is a non-negligible change to some of Neutron's basic 
and more critical workflows. We should expect pushback from the community 
regarding the introduction of this change in the 3rd milestone. At this stage I 
would suggest either:
A) consider a strategy for running pluggable IPAM as optional
B) consider delaying to Liberty.
(and that's where I get virtually jeered and pelted with rotten tomatoes)

I wish I had some old tomatoes! Seriously, I think A is a reasonable 
approach. To make this really explicit we may want to basically replace the DB 
plugin class with a shim that delegates to either the current implementation or 
the new implementation, depending on the flag.


Thanks for reading this post,
Salvatore

[1] https://review.openstack.org/#/c/150485/
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-February/056007.html
[3] https://review.openstack.org/#/c/153236/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

The pluggable IPAM [1] is intended to support the scenario you described below. 
That is, a fixed IP is provided for the port by IPAM, and then the DHCP server 
is programmed to return that IP for that MAC or DUID (for IPv6). If I 
understand correctly, your concern then is:

1) The DHCP server may not allow such programming;
2) The DHCP server may not be able to provide an IP allocation via any means 
other than DHCP (ie, no API to pre-allocate the IP)

I would think then, what you are asking for is the ability to attach an 
interface to a layer 2 network without also giving it an IP in any subnet(s) 
that are on that network. Seems like a reasonable request, but I am not sure 
what would be involved in implementing that.

Additionally, we would need some mechanism to update the port with the IP after 
it is allocated via the DHCP server. Otherwise, I don't think all the iptables 
rules and such will be properly configured, so you probably won't be able to 
pass traffic beyond the local subnet. Not sure on that though.


[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html



From: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com
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-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

Hi John,
Sure, this may not be in the scope of IPAM as originally proposed in [1]. Am 
just trying to see if there can be a solution for this scenario using IPAM.

What I had in mind is also a centrally managed IPAM and not each VM allocating 
its own IP address. Let me clarify.

It's not an uncommon requirement to use a commercial DHCP server in an 
enterprise/DC. I am referring to it as external DHCP server from Openstack's 
perspective.
One scenario of deployment is when IPAM is done through Openstack and in which 
case, the MAC, IP, optionally segment can be programmed in the external DHCP 
server, assuming they have standard API's for that. Then, the VM will get the 
openstack assigned IP address from the DHCP server when it boots up. You also 
suggested this and sure, it's not a problem here.

Now, another scenario and that's of interest is when IPAM itself is done 
directly using the commercial DHCP server for various reasons. I am just trying 
to see how this model will work (or can be extended to work) for this case. 
What's the role of pluggable IPAM [1] in this scenario? If at all there's a way 
to tell the external DHCP server, do your own allocation and return an IP 
address for me for this MAC, segment, then this IP address can be returned 
during the allocate_ip API by the pluggable IPAM? But, I am not sure, an 
external DHCP server will have this flexibility.
Then, in such scenarios, the only way is to not allocate an IP address during 
create_port. When the VM comes up and sends a DHCP request the commercial DHCP 
server responds with an address. The pluggable IPAM then can use its own 
method, and when it discovers the IP address of the VM, it can call to 
update_port with the IP address.
Any other way?

[1] - 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/neutron-ipam.html

Thanks,
Paddu


On Tuesday, February 3, 2015 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 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 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...@infoblox.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@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

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

[John Belamaric]

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 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...@infoblox.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@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 
kpr...@yahoo.commailto:kpr...@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 
jbelama...@infoblox.commailto:jbelama...@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 kpr...@yahoo.commailto:kpr...@yahoo.com
Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, December 17, 2014 at 6:06 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@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.porr

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

[John Belamaric]

Sure, makes sense. The placeholder I was referring to would be communicated to 
the IPAM plugin. Though, if there is no IP, it may be just best not to involve 
the IPAM subsystem.

From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, February 3, 2015 at 4:38 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

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 
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 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 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...@infoblox.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@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 
kpr...@yahoo.commailto:kpr...@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 
jbelama...@infoblox.commailto:jbelama...@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 kpr...@yahoo.commailto:kpr...@yahoo.com
Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, December 17, 2014 at 6:06 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when 
dhcp is disabled

This means whatever tools

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

[John Belamaric]

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 changes related to 
our integration rather than just the relay.

The adapter uses ISC dhcrelay, but we had to patch it to add the link selection 
option. That code is also included with the adapter package, along with a build 
script for it.

[1] https://blueprints.launchpad.net/neutron/+spec/dhcp-relay
[2] https://www.infoblox.com/products/private-hybrid-cloud/openstack-adapter

From: Erhan Ekici erhan.ek...@gmail.commailto:erhan.ek...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, January 6, 2015 at 9:00 AM
To: foss geek thefossg...@gmail.commailto:thefossg...@gmail.com
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
openstack openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with 
External DHCP server

Hi,

As far as I know, there is a spec and feature for external dhcp server 
configuration but just for ironic project (bare metal installation).
Btw, I have not tested it yet.

http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html

Erhan,





On Tue, Jan 6, 2015 at 1:04 PM, foss geek 
thefossg...@gmail.commailto:thefossg...@gmail.com wrote:
Dear All,

Is it possible to configure neutron to take VM ip from external DHCP server?

I am having All In One openstack env deployed using devstack icehouse. I am 
looking for an option to integrate it with external DHCP server.

--
Thanks  Regards
E-Mail: thefossg...@gmail.commailto:thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Belamaric]

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 kpr...@yahoo.commailto:kpr...@yahoo.com
Reply-To: Padmanabhan Krishnan kpr...@yahoo.commailto:kpr...@yahoo.com, 
OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, December 17, 2014 at 6:06 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@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.porr...@dektech.com.aumailto:pasquale.porr...@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.porr...@dektech.com.aumailto:pasquale.porr...@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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@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