With the change from ml2/ovs DHCP agents towards OVN implementation
in neutron there is no port with device_owner network:dhcp anymore.
Instead DHCP is provided by network:distributed port.
Closes-Bug: 2055245
Change-Id: Ibb569b9db1475b8bbd8f8722d49228182cd47f85
For networks with subnets with enabled DHCP service don't provide
mtu value in the metadata. That way cloud-init will not configure it
"statically" in e.g. netplan's config file and guest OS will use MTU
value provided by the DHCP service.
Closes-Bug: #1899487
Change-Id: Ib775c2210349b72b3dc033554ac6d8b35b8d2d79
Strip out everything matching '(is|use)_neutron', except the tests for
nova-network code and two other places that these tests rely on. Along
the way, remove a whole load of apparently unnecessary mocking that
clearly wasn't caught when we switched over the bulk of testing to use
the neutron network driver.
Change-Id: Ifa9c5c468400261a5e1f66b72c575845173a4f8f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
All of these functions only have a single caller now, so move them to
their calling site. Two functions are renamed to better fit their
purpose but there is otherwise no change in functionality.
Change-Id: I48237f306fb901dec9ec805704c891fd3cbb12e3
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This add the vf_trusted field for network metadata. Currently only
libvirt is supporting it.
Implements blueprint bp/sriov-trusted-vfs
Change-Id: I4aa2786cfa95b923078679a398bdfe4de622be57
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
DNS nameserver information is subnet-specific, but nova provides this
information globally, which makes it impossible for system
configuration tools to place the nameserver information in the right
place (e.g., in interface configuration files). This commit modifies
nova to *also* provide the DNS information per-subnet, where it can be
accessed by tools that want to configure the system properly.
Change-Id: I003a25b0d60cb6cd16c3ee1ad1a43910825622be
Closes-bug: #1693265
When Bandit scans nova/console/xvp.py and nova/virt/netutils.py, the
high severity issue ("B701:jinja2_autoescape_false") are triggered. By
adding #nosec to above code, this alarm will be surpressed.
"When autoescaping is enabled, Jinja2 will filter input strings to
escape any HTML content submitted via template variables. Without
escaping HTML input the application becomes vulnerable to Cross Site
Scripting (XSS) attacks."[1] However, the "injected_network_template" is
a template with text format and different rules, and is not intended to
be executable. Hence, the security concern is not applicable here.
[1] https://docs.openstack.org/developer/bandit/plugins/jinja2_autoescape_false.html
Closes-Bug: #1701712
Change-Id: Ie819d90492af1e5c3b3d64403495d7355dc2cd91
Currently it is not possible to decide from looking at the network
metadata whether an IPv6 subnet is using slaac, dhcpv6-stateless or
dhcpv6-stateful.
So we add ipv6_address_mode information into the subnet metadata when
it is available and use that to construct the subnet type.
As a result, the type for a subnet with mode SLAAC will be "ipv6_slaac"
instead of "ipv6_dhcp" and similarly for the other available modes.
Change-Id: I751200a354ec9be2bfd5f94d3e4bbf53dab2c8bb
Partial-Bug: 1676363
Previously, the 'type' of the hypervisor network device, was exposed to
the guest directly. That does not make sense, as
a.) this leaks needless information into the guest
b.) the guest cannot be reasonably expected to make decisions
based on a type of link that is present underneath the
virtual device that is presented to the guest.
c.) guests then are forced to either continuously track these types
or to assume that unknown type is "phy".
This limits the exposure of types to a specific list. Any other
type will be shown to the guest as 'phy'.
Change-Id: Iea458fba29596cd2773d8d3565451af60b02bcca
Closes-Bug: #1642679
Nova supports file injection of network templates. Putting these in a
config drive is the only way to configure networking without DHCP.
At present, setting the 'use_ipv6' config option to False prevents the
generation of IPv6 network info, even if there are IPv6 networks
available. This was fine when using nova-network, where the same config
option is used to control generation of these subnets. However, a
mismatch between this nova option and equivalent IPv6 options in neutron
would result in IPv6 packets being dropped.
Seeing as there is apparent reason for not including IPv6 network info
when IPv6 capable networks are present, we can ignore this option.
Instead, we include info for all available networks in the template, be
they IPv4 or IPv6.
Change-Id: I188fc2cd1b26fe7a71804f7e7d66b111d6f15e30
Implements: blueprint centralize-config-options-pike
Enhance the _build_device_metadata method to expose virtual interface with vlan
to the devices metadata. Previously, only interfaces with tags could be
exposed.
Implements: blueprint sriov-pf-passthrough-neutron-port-vlan
Change-Id: I7abf16b996bd68aa7fa1e3a121eae3147a244284
The mtu field is hidden inside the "meta" section, so we have to get
it from there.
Change-Id: Ic44dcdb04cbaf8a007338258d74eec136a580289
Closes-Bug: 1576713
The config options of the section
"nova/netconf" got moved to the
new central location
"nova/conf/netconf.py"
Change-Id: I8a17b6f00b15e03de55385fc0206bdc82441304a
Depends-On: I0da2ad7daa942b85c3395dc4861c6e18368ece88
Implements: blueprint centralize-config-options-newton
Add options from 'virt.netutils'. These options are part of the
'DEFAULT' group but are included in the "nova.conf.virt" file in hope
that they can eventually be moved to their own group.
Change-Id: Iadde1aff056008988d21deb914cdd18c8347e5d3
Implements: bp centralize-config-options
This code currently throws an exception and fails the build if an
instance boots on a network without a v4 subnet. Protect against
this by checking it has a ipv4 subnet.
Change-Id: I7c5de308b557293f5ac6b919d5566ace809ce200
Closes-bug: #1476402
This patch builds the network information from Neutron into a format
that can be exposed via the metadata API in subsequent patches.
The data will be consumed by guest instances via cloud-init and other
in-guest agents.
Partial-Implements: blueprint metadata-service-network-info
Change-Id: Ic2841339f462676249f0fbddabcfdb3da39ffc4d
On Python 3, iterators have a __next__() method, but no next() method.
Use the builtin next() function which works on Python 2 and Python 3.
This patch was generated by the sixer tool version 0.2:
https://pypi.python.org/pypi/sixer
Manual change:
* Fix indentation
* tarfile.TarFile is not an iterator and has a next() method on Python 2
and Python 3: revert changes in
nova/tests/unit/virt/xenapi/image/test_utils.py and changes on
self._tarfile in nova/virt/xenapi/image/utils.py.
Blueprint nova-python3
Change-Id: Ie691d6f236a5aeef049f0b191dd07167020443d7
This change adds the ability to inject routes in interfaces.template
by injecting them in the template engine.
It adds support for injecting extra routes when instances are spawned
on networks that do not have DHCP or Neutron routers.
Routes are now found in each interface in the interfaces variable.
The following attributes are available for each route:
* gateway (eg. 192.168.0.1)
* cidr (eg. 192.168.10.0/24)
* network (eg. 192.168.10.0)
* netmask (eg. 255.255.255.0)
Example of how to inject routes in interfaces.template:
{% for ifc in interfaces %}
auto {{ ifc.name }}
iface {{ ifc.name }} inet static
# [...]
{% for route in ifc.routes %}
post-up ip route add {{ route.cidr }} via {{ route.gateway }} dev {{ ifc.name }}
pre-down ip route del {{ route.cidr }} via {{ route.gateway }} dev {{ ifc.name }}
{% endfor %}
{% endfor %}
Note: Routes are not injected by default in interfaces.template.
This is to avoid any potential conflicts with existing network agents
such as dhcp, l3, etc.
See nova/tests/network/interfaces-override.template for a complete
example on how to interact with the new interface 'routes' attribute.
Blueprint: network-template-routes-injection
DocImpact: Routes are now available in the network template engine.
Change-Id: Ic22c8af721d539c8180b5caa7ba348e834ddbb56
Use previously detected template file (in template variable)
instead of CONF.injected_network_template.
Existing detection logic is fine:
* If template argument is defined, it is used.
* If template argument is None, CONF.injected_network_template is used.
Change-Id: I77385bfb2d79be34aed476ed4840fe03c59ed7df
Closes-bug: #1441892
The oslo team is recommending everyone to switch to the
non-namespaced versions of libraries. Updating the hacking
rule to include a check to prevent oslo.* import from
creeping back in.
This commit includes:
- using oslo_utils instead of oslo.utils
- using oslo_serialization instead of oslo.serialization
- using oslo_db instead of oslo.db
- using oslo_i18n instead of oslo.i18n
- using oslo_middleware instead of oslo.middleware
- using oslo_config instead of oslo.config
- using oslo_messaging instead of "from oslo import messaging"
- using oslo_vmware instead of oslo.vmware
Change-Id: I3e2eb147b321ce3e928817b62abcb7d023c5f13f
When using networks without DHCP enabled and "flat_injected" set to True,
the interfaces template is injected in the associated instances or
included in the config drive metadata.
The template includes the interface name, based on a progressive numbering
(eth0, eth1, etc). In case of multiple nics, there's no clear way to
identify the interfaces in the guest OS if the actual interface naming
differs, this is especially valid for Windows instances.
Since the MAC address (hardware address) assigned to each vNIC identifies
uniquely the interface, providing the mac address during the template
generation solves the issue.
Change-Id: Id82db6d83caedf0e95f882d909b77ea9b98b2547
Closes-Bug: #1400080
Update interfaces.template to support ipv6 based dns servers. Make
sure we validate the version of the ip addresses before we
fill them in.
Closes-Bug: #1355777
Change-Id: I7229656bfa5ff5a29c63befc3b9ce91c46e04723
The Xen driver duplicates quite a bit of code used to inject the `interfaces`
template into the guest.
This patch makes the Xen driver use the generic `netutils` version.
Parameter defaults were moved from the signature into the method since in the
original code, you wouldn't be able to override them due to their value being
populated at import-time, not run-time.
Change-Id: I4cd1631b8e6ec2dc3fae1f8eb0362aecead53f1e
Libvirt's LXC implementation exposes a read-only `/proc/sys/net` to the
guests. This causes some of the guest's default network configuration scripts
to fail.
This patch works-around the issue by using `post-up` hooks to configure IPv6.
Closes-Bug: 1340791
Change-Id: I805cad98d855fcb2c90b07e98ad3653d1620bd42
If you have more than one interface and IPv6 enabled, then the interfaces file
emitted would have the incorrect syntax: the `auto eth1` line would be
appended to the end of the `gateway` line of the previous stanza.
This was a result of improper whitespace control in the Jinja template which
this patch fixes.
In order to prevent regressions, this patch swaps out the existing tests with
corresponding tests that are whitespace sensitive. This is important because
it's difficult to tweak Jinja templates in a way that fixes the whitespace
for one scenario while not breaking another.
Closes-Bug: 1339888
Change-Id: Id5566ea2f93ee1a6b8bc42e83bc64a1c6a09e680
We don't need to have the vi modelines in each source file,
it can be set in a user's vimrc if required.
Also a check is added to hacking to detect if they are re-added.
Change-Id: I347307a5145b2760c69085b6ca850d6a9137ffc6
Closes-Bug: #1229324
get_non_legacy_network_template assumes that IPv4 is always available
So if i try to use Nova Network without any ipv4 using say
"nova network-create public --fixed-range-v6 fd8c:215d:178e:452:0:0:0:0/64"
then the deployment fails. So fix the code to ensure ipv4 is optional
Fixes LP# 1216178
Change-Id: Ib0c47a49debd4fed83d382a301687df23ca2ec0d
Cheetah is unmaintained since 2010 and it's unlikely to get Python3
support soon. Also, the rest of OpenStack (mostly) standardized on
Jinja2.
Implements: blueprint jinja-templating-conversion
Change-Id: Ia15f00ee96d3c1d55d7c290f20ccc988e4c52e1a
This patch removes legacy network info wihch is unused in any Hypervisor
drivers, clean up related tests and Also removes legacy method from
nova.network.model.
Partly implement blueprint nova-network-legacy
Change-Id: Ia3f11b1a162878817445619575b35187110dafb5
When using Quantum for networking and setting flat_injected to
inject network settings into the guest VM, Nova injects a static
network configuration for networks using DHCP. This change
checks for the existence of a dhcp server and, if found, does not
inject static settings for that network.
Due to limitations of the legacy network info, the fix only
applies when new-style network info is passed to the injection
template function. The only code still passing in legacy
network info is in libvirt, and there is work ongoing to
remove that dependency.
Fixes bug 1163985
Fixes bug 1112659
Change-Id: I8d3f16bde22e1c6dc0d2432aa263e2b15ae5c93a
fixes bug 1175725
Will allow for the flag to be set to filter out ipv6 if
configured but will not add ipv6 to template if ipv6 is not
configured in quantum. This will allow spwan to continue
working in the case where ipv6 is not configured but flag
use_ipv6 is set in nova.
Change-Id: I26ebdff81efcdeff827521cec247d2c443a5e0ad
The code in
commit 7be531fe94
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Tue Jan 15 20:43:48 2013 +0000
Refactor code for setting up libvirt disk mappings
accidentally broken launching of instances where
the flavor had non-zero swap specified. This was
not caught due to complete lack of test coverage
for the '_create_image' method. This adds two
test cases for that method, exercising this bug.
It also fixes a bug in netutils which was not
handling a NULL network mapping, which is a valid
scenario for several callers.
Fixes bug #1131306
Change-Id: I214561ba3ec6440d11a5afb0665e6b6f990bd148
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The cfg API is now available via the oslo-config library, so switch to
it and remove the copied-and-pasted version.
Add the 2013.1b4 tarball to tools/pip-requires - this will be changed
to 'oslo-config>=2013.1' when oslo-config is published to pypi. This
will happen in time for grizzly final.
Add dependency_links to setup.py so that oslo-config can be installed
from the tarball URL specified in pip-requires.
Remove the 'deps = pep8==1.3.3' from tox.ini as it means all the other
deps get installed with easy_install which can't install oslo-config
from the URL.
Make tools/hacking.py include oslo in IMPORT_EXCEPTIONS like it already
does for paste. It turns out imp.find_module() doesn't correct handle
namespace packages.
Retain dummy cfg.py file until keystoneclient middleware has been
updated (I18c450174277c8e2d15ed93879da6cd92074c27a).
Change-Id: I4815aeb8a9341a31a250e920157f15ee15cfc5bc
The my_ip, host and use_ipv6 options are used all over the codebase
and they're pretty well related to each other. Create a new netconf
module for them to live in.
There are now no options registered globally in nova.config!
blueprint: scope-config-opts
Change-Id: Ifde37839ae6f38e6bf99dff1e80b8e25fd68ed25
The only reason for importing nova.config now is where one of the
options defined in that file is needed. Rather than importing
nova.config using an import statement, use CONF.import_opt() so
that it is clear which option we actually require.
In future, we will move many options out of nova.config so many
of these import_opt() calls will either go away or cause a module
other than nova.config to be imported.
Change-Id: I0646efddecdf2530903afd50c1f4364cb1d5dce1
Modules import nova.config for two reasons right now - firstly, to
reference nova.config.CONF and, secondly, if they use one of the
options defined in nova.config.
Often modules import nova.openstack.common.cfg and nova.config
which is a bit pointless since they could just use cfg.CONF if
they just want to nova.config in order to reference CONF.
Let's just use cfg.CONF everywhere and we can explicitly state
where we actually require options defined in nova.config.
Change-Id: Ie4184a74e3e78c99658becb18dce1c2087e450bb
Now that options have all moved from nova.flags to nova.config, we can
safely remove the nova.flags imports and replace them with nova.config
imports.
Change-Id: Ic077a72dd6419bbf1e1babe71acfa43c4e8b55c8
Use the global CONF variable instead of FLAGS. This is purely a cleanup
since FLAGS is already just another reference to CONF.
We leave the nova.flags imports until a later cleanup commit since
removing them may cause unpredictable problems due to config options not
being registered.
Change-Id: Icb61d67965628dca65bda393d4373beab5c5c64a
This continues the work Michael did on blueprint config-drive-v2
Things added:
* web service /openstack/2012-08-10 with:
user_data
meta_data.json
* web service supporting /openstack/content
Things changed:
* Changed the name 'files' (/openstack/files) to be 'content'
This is to be more generic and apply to future re-use of it
for some purpose other than personalities (injected_files)
* 'meta_data.json' and 'user_data' are used for openstack
* 'user-data' (without .raw) in the ec2 config drive rendering
* 'content_path' is a attribute of each of the entries in the 'files'
its value is the path from the openstack metadata service root to
where the content is located.
This means that the user does not have to know anything explicit about
'/content'. They just have to take the 'content_path' and append it
to the top level entry point of metadata service.
Explicit example:
http://169.254.169.254/openstack/2012-08-10/meta_data.json
has:
files[{path: "/etc/passwd", content_path: "/content/0001"}]
To get the file, user appends 'content_path' to
http://169.254.169.254/openstack
* network config (Template) is available in /content also, and
the key that points to it is 'network_config'. This occurs only
if there are network's that are "injected" (same behavior as previously)
The meta_data.json now contains
uuid: <instance uuid>
meta: meta tags provided they will appear in a dict here
files:
This is a list of dicts, where each dict has 2 fields:
* 'path' (the path provided)
* 'content_id': the location in /content/ that will give the content
public-keys:
Dict of keyname : value
network_config:
This is a dict, containing 'content_path' and 'name' (network_config)
hostname: the hostname
name: the nova boot name
TODO:
* want to add other items into openstack metadata
* public-hostname
* IP addresses
* keystone-endpoint
* url of metadata service: ideally only show this if there
is a web service available. the path seems hard coded at the moment
to be http://169.254.169.254/openstack, but I do not know if there
is a way to determine if one is present or not.
* document config-drive-v2
Change-Id: I6b9097624a9c1a972e4851d79f6d557376f59d32
Provides two drivers for implementing security groups in xenapi:
1) domU driver that enforces security groups on the Openstack virtual appliance (use advised with FlatDHCP in HA mode)
2) dom0 driver that enforces security groups where VIFs are attached
Both drivers translate security groups into iptables rules.
Existing libvirt code has been refactored to reduce the amount of duplicated code to a minimum
Now Addressing reviewers's comments on style. Fixing issue spotted with snapshots
Change-Id: Ifa16a8f2508a709be03241bac0f942fe1a51d1e8
Steven Blatzheim