| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Also change placeholders to jinja2 type
|
|
|
|
| |
These files are being installed with nova
|
|
|
|
|
|
|
| |
documentation
See http://www.freedesktop.org/software/systemd/man/systemd.unit.html for more
information
|
| |
|
| |
|
|
|
|
| |
This will make the experience more pleasant
|
| |
|
|
|
|
|
| |
Now horizon-setup also configures Apache, given that they will be in
the same host. This can be split in different setup scripts.
|
| |
|
| |
|
|
|
|
| |
Also change systemd units and configure extension to match this change
|
|
|
|
| |
These files are being installed with cinder.
|
| |
|
|
|
|
| |
Also change placeholders to jinja2 type
|
| |
|
| |
|
|
|
|
| |
Also change systemd units and configure extension to match this change
|
| |
|
|
|
|
| |
Also change placeholders to jinja2 type
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now keystone-setup also configures postgres and rabbitmq. This can be
split in different setup scripts, but I think that rabbitmq, postgres,
are likely to be in the controller node.
|
|
|
|
| |
Also change placeholders to jinja2 type
|
|
|
|
| |
Also remove quotes from the Environment variable.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
created in chunk)
|
| |
|
| |
|
|
|
|
|
|
| |
This enables serial console access to local nodes from the host machine
by running `novaconsole $VM_NAME` after it has been installed by running
pip install git+http://github.com/larsks/novaconsole.git
|
| |
|
| |
|
| |
|
|
|
|
| |
config
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be handled by neutron, and except for the mis-configuration,
it should have been.
However, since both neutron and nova were configured to handle
firewalling, they would both install their firewall rules into iptables,
and it would be random which one would be used as either service is
likely to start before the other and install their hook first.
The result being that we'd randomly not be able to reach VMs after a
reboot, unless we'd installed the same firewall rules in both nova and
neutron.
|
|
|
|
|
|
|
|
|
| |
If /var/run is a directory that is not emptied every boot, then it will
contain references to stale network namespaces, which do not work when
neutron tries to create networks.
If it is flushed appropriately then neutron will create the namespaces
when it needs to.
|
|
|
|
|
|
|
| |
We don't think it's necessary, and it sometimes races with
nova-compute.service, failing if certain network devices aren't created
yet, so let's see if Nova should be the one starting the machines up at
boot time.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is required for Open vSwitch to be able to signal that every
network interface required has been configured.
It also means we no longer need to set the links to promiscuous mode
ourselves, since interfaces need to be set in promiscuous mode to allow
bridging to work and Open vSwitch handles this responsibility if it is
configured to be the one to do the link setup.
|
|
|
|
|
|
|
|
|
| |
ovs-cleanup is responsible for reconciling the state in openvswitch's
database and neutron's configuration.
This can fail if other services are also changing ovs configuration
though, and the missing dependency resulted in neutron removing the
interface while ovs-cleanup was about to do so.
|
|
|
|
|
|
|
|
|
|
| |
This allows the subsequent DHCP request to get the same IP address back,
which means it only needs one address for first boot, and the address
can be pre-allocated by the DHCP server before deployment.
This is needed for the floating address range to be allocated in some
set-ups, such as our local one at the office, where a subnet in a
different class is routed to the server.
|
|
|
|
|
|
|
|
|
| |
This adds masking config for the virtual devices to prevent them from
attempting to DHCP, and stops us from giving the ip of eno1 to the
bridge device, since eno1's address was obtained by DHCP, so it's
against the rules to statically allocate that address to an interface.
Now, we DHCP for a new address for the bridge.
|
|
|
|
|
|
| |
If we leave that interface with its address, then the routing table is
incorrect, as it will try to send connections out from an interface that
cannot handle them.
|
|
|
|
|
|
|
|
|
|
| |
After the external interface has been bound to Open vSwitch, we should
not attempt to DHCP on it, as it won't receive the DHCP responses.
Attempting to DHCP results in startup stalling on network-online.target,
because systemd-networkd-wait-online.service looks at every network
interface it should configure based on the [Match] sections, and waits
for all of them to be configured by systemd-networkd, which will never
finish if DHCP is broken.
|
|
|
|
|
|
|
| |
We want the network links to be configured before we start
systemd-networkd, because we have to use ovs instead of networkd's
config for the interfaces in OpenStack, but we still want to use
networkd to manage DHCP on the interfaces.
|