Configuring OpenStack to use jumbo frames (MTU 9000)

Controller nodes

Disable puppet :

# systemctl stop puppet
# systemctl disable puppet

Place a given controller into standby mode :

# pcs cluster standby $(hostname)

Update the MTU for all physical NICs being used by either provider or tenant networks :

# echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-eth0

Update the various Neutron related configuration files :

Note that if tenant networks are being used then we need to allow for the overhead of VXLAN and GRE.

# echo “dhcp-option-force=26,8900” > /etc/neutron/dnsmasq-neutron.conf
# openstack-config –set /etc/neutron/dhcp_agent.ini DEFAULT dnsmasq_config_file /etc/neutron/dnsmasq-neutron.conf
# openstack-config –set /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini agent veth_mtu 8900
# openstack-config –set /etc/neutron/l3_agent.ini DEFAULT network_device_mtu 9000
# openstack-config –set /etc/nova/nova.conf DEFAULT network_device_mtu 9000

Reboot to ensure everything persists.

# reboot

Unstandby the node and repeat on the remaining controllers :

# pcs cluster unstandby $(hostname)

Compute nodes

Disable puppet :

# systemctl stop puppet
# systemctl disable puppet

Update the MTU for all physical NICs being used by either provider or tenant networks :

# echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-eth0

Update the OVS plugin configuration file :

# openstack-config –set /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini agent veth_mtu 8900
# openstack-config –set /etc/nova/nova.conf DEFAULT network_device_mtu 9000

Reboot to ensure everything persists.

# reboot

Source: https://access.redhat.com/solutions/1417133

Advertisements

Huawei e220 modem on linux

So support for these little beggars has been present since 2.6.20. They’re pretty clever things – setup as mass storage devices containing the drivers so on Windows the install wizard sets it up and you’re online within seconds. With linux its a quick config file edit. You’ll need to have wvdial or gnome ppp installed. Here’s the /etc/wvdial.conf file which works fine with 3 in the U.K. and seems to be the case with vodafone as well.

[Dialer Defaults]
Phone = *99***1#
Username = wap
Password = password
Stupid Mode = 1
Dial Command = ATDT

[Dialer 3G]
Modem = /dev/ttyUSB0
Baud = 384000
Init2 = ATZ
Init3 = ATq0 V1 E1 S0=0 &C1 &D1 +FCLASS=0
ISDN = 0

Then (as root), run:

wvdial 3G and you should be on!

Fedora kernel bug triage

I’ve just tallied up the fedora kernel bug count for release 7, 8 and devel – 759. Then I looked back to mid-november – 756. Still, things are improving. There has been a resurgence in the fedora triage effort with some debate on fedora-devel as to how best tackle the issue of a growing bug count in Fedora. Jon Stanley and John Poelstra in particular have been getting active and thrashed out some ideas at FUDCON, which I was unable to attend but have made it a priority to get to next year.

Anyway, I digress. As Linux becomes more popular, more people file bugs. Soon maintainers of large packages such as the kernel, openoffice.org or firefox get lost under the crashing weight. So here’s how the process works.

Someone files a bug – it comes in under category NEW.
The triager (or a maintainer if they are able) reviews and either requests more info (sets bug to NEEDINFO) or accepts the problem and sets to ASSIGNED.

The triagers work is then done. Other states such as ON_DEV exist where the maintainer can acknowledge he is working on a solution. There is also:

MODIFIED – fix is available for testing
ON_QA – fix is being tested
NEXTRELEASE – fix has been confirmed as working and will arrive in next release

Ultimately bugs end up as INSUFFICIENT_DATA where the original reporter could not provide the information or has since lost interest – I consider this the least favourable resolution. CURRENTRELEASE is the golden goose where the fix has been approved and all parties are happy. About 25% of F7 kernel bugs have ended up in this state. See diagram below – the current state of F7 kernel bugs.

Bug triaging is an excellent way for those who know the basics to get further into Linux and start learning about various parts of the system and teaches more than a year of system administration ever could. I commend it to the house!

Fedora 7 kernel bug status 16th January, 2008

Building kernels requires patience…

For the past few months and now in the run-up to the re-launch of Fedora Triage Project, I have been going back through Fedora 7 kernel bugs and closing out those which are obviously dead. As in, the report was made and for a variety of reasons, never got resolved. Its frustrating as I know how much time and effort goes into filing a report and this goodwill goes in vain.

Nevertheless, although I should be applying myself to the task of finding gainful employment, I find myself awake at 2am, running a scratch build in Koji in the hope that this bug can be closed. At the same time, my laptop is building a kernel with backported Qlogic SCSI drivers to try and resolve this bug and my main desktop machine is chuntering away to produce a kernel with the patch from this bug that might help resolve that particular issue.

Its all good fun, though the inexorable increase of bugs has led to exasperation on the fedora-devel-list and a bit of soul-searching as how to best tackle the problem of so many bugs and so many bug reporters feeling a little, well, un-loved…