Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Currently the Openstack provider will attempt to allocate a floating IP to all Virtual Machines on creation.
Therefore, there should be an option to disable the allocation of a floating IP and rely on only the internal IP only.
A flag such as "--openstack-disable-floating-ip=true" as an option for the openstack provider, which turns off the allocation of the floating IP and the only sets the internal IP address.
All benchmarks should then use the internal address only and only run the ip_address=internal benchmarks and disable the ip_address=external benchmark runs.
You can force internal IP allocation today with --ip_addresses=INTERNAL for
On Tue, Mar 1, 2016 at 4:41 AM, Darryl Weaver email@example.com
Anthony F. Voellm (aka Tony)
@darrylweaver Sorry for hijacking your post.
The network allocation in the OpenStack provider implementation needs more work IMHO, you can actually have multiple networks, not just a
We can work on a short-term solution to address the current issue but we also need to take a step back and look at the big picture to tackle the problems at the root.
I suggest that we need to approach OpenStack from a different perspective. I think we should avoid treating it like a public cloud service provider and assume that all OpenStack cloud deployments are the same. In the wild, there are different versions that have already reached EOL(end of life) like Icehouse, Juno, and soon (Kilo), and not all deployments run all services. Part of the issues in #854 is also related to the mismatch of versions.
To give you an idea of this matrix. Here's list a few things (not exhaustive) that could be different on OpenStack Deployments
Because of all this, I think we need as a community to decide which versions to support, and what exactly should we assume and/or not assume from an OpenStack cloud deployment.
Perhaps a good starting point is to look at the OpenStack DefCore and RefStack effort, which tries to define a minimum set of features that OpenStack cloud must be able to support to brand itself as an OpenStack Powered or OpenStack Compatible cloud.
More info here http://www.openstack.org/brand/interop/
Here are some charts from the October 2015 OpenStack Public User Survey Report showing the current landscape.
I tried the --ip_addresses=INTERNAL and I can confirm that it tries to allocate floating IPs for every single machine. This results in eventually running out of floating IPs and no more benchmarks being processed. I ended up commenting out the floating IP allocation code, so I could continue to get data.
With regards to the broader discussion of what should be supported, then it will be impossible to support every single possible deployment of Openstack, however, there are core components that should be supported, including neutron in several common configurations.
The built in Openstack provider should be useful for most private cloud deployments based on common deployment scenarios, such as using Nova/Cinder/Neutron and should be easily configurable per "Openstack" cloud, using the flags.
Most deployments will have a private and public network and floating IPs, but some have only 1 network and all IPs are public and others just don't issue you many public IPs by default. So, the most common use case is to have the ability to turn on/off floating IPs. Supporting many networks sounds like a complex scenario to me, that may be served better by customising the provider.
What I would prefer to see overall, is to make it easy to customise the existing Openstack provider to create a new provider based on the Openstack provider with any special customisations required, so that additional public cloud providers based on Openstack can add themselves as a provider with any special customisations required. For example, if it was as easy as copy the providers/openstack directory to new-provider directory and add a YAML file in to that directory that customises all the options for the Openstack Provider making the command line just a case of selecting that cloud provider and the defaults are all set correctly.
@darrylweaver Here's what I'm envisioning to address your issue.
Make the flags
The PKB client will try to use an IP address from a network, if available, as a "public IP" in this order:
Then introduce a new OPTIONAL flag, say something like
Would that work in your case?
Yes, that should address my issue.
Not sure about making the --openstack_floating_ip_pool an optional flag as opposed to disabling floating IP allocation. The default common use case is that you would want an instance started on the only available network with a floating IP allocated from any available pool. In that use case it would be nicer if you didn't have to specify any options, but only if there are more complex requirements, i.e. more than 1 network to choose from and more than 1 floating IP pool.
After experimenting with the flags against my OpenStack deployment, I can see what you meant. Adding the flag
Also after thinking about it, having the flags take a list of networks just make things a lot more complex and can cause confusion to the user since most benchmarks rely on just 2 networks, internal and external. Probably, in the future, I'll have PKB create isolated networks and use those for some other benchmarks.
So taking your suggestion, and keeping things simple. I think what we could do is allocate a floating IP only when
The commands would look something like this:
Note: PKB External IP is the IP address PKB uses to SSH into the instance and is equivalent to a Public IP address in your typical public cloud provider.
PKB External IP = floating IP
PKB External IP = IP from Internal Network
One case this wouldn't cover, besides multiple isolated networks, is an external public network that does not use a floating IP. I don't think is a common case, though. To cover it, we could always use the flag you suggested for disabling the floating IP allocation, and then treat public_network like just another network except we will use it's IP for PKB's external IP.
@meteorfox OK, Case A and B make sense to me.
Well, I guess it depends on how you define an openstack external network. Generally the only distinction in Openstack is that there are networks and external networks that floating IPs are allocated from. If we consider all networks that can attach an instance as an "internal" network and any "external" network to be a pool of floating IPs, then there is no such thing as an external network which does not use floating IPs and instances are always started on an "internal" network.
This configuration would match the OVH Openstack deployment, i.e.:
PKB External IP = The fixed IP of the instance from the "internal" network
Which I think works out exactly the same as Case B and is hence already addressed.
So, there may be no need to specifically flag disabling of floating IPs if we are clear what is an internal and external network? Maybe renaming of the flags would be appropriate?
Would it be clearer to have:
That could make it less confusing about the distinction between "internal" and "external" networks, which could be confusing if it is not referring to publicly routed or RFC1918 addresses, which is what most users would assume.