uec node cd install doesn't handle static network configuration

Bug #446023 reported by Dustin Kirkland  on 2009-10-08
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eucalyptus (Ubuntu)
High
Dustin Kirkland 
Karmic
High
Dustin Kirkland 

Bug Description

In MANAGED-NOVLAN mode (default Ubuntu Eucalyptus networking mode), the cluster controller provides a DHCP (static addressing) server. No other DHCP server handing out dynamic addresses should be enabled on the network (ie, on the router, etc).

In this case, the installation of the Node will not automatically detect a DHCP address. The user will need to manually set a static address.

However, the /etc/network/interfaces written by eucalyptus-udeb.finish-install is non functional. The default configuration handles a DHCP eth0 properly, but not a static eth0.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Attaching the broken /etc/network/interfaces.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Attaching the fixed (by hand) /etc/network/interfaces file.

:-Dustin

Dustin Kirkland  (kirkland) wrote :
Changed in eucalyptus (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Colin Watson (cjwatson)
milestone: none → ubuntu-9.10
summary: - uec cd install doesn't handle static network configuration
+ uec node cd install doesn't handle static network configuration
description: updated
Colin Watson (cjwatson) wrote :

I can understand why br0 would need to be static rather than dhcp. I don't understand why the static network configuration needs to go on br0 rather than on eth0, though; this just seems weird, especially with 'bridge_ports eth0'. Can you explain this for the hard of thinking?

Dustin Kirkland  (kirkland) wrote :

Colin-

I'm sorry, I can't.

I massaged this configuration until I got it to work as expected.

ie,
 a) system can talk out to the network, ping, resolve names, etc.
 b) the network can talk to the system, ping, ssh, wake-on-lan
 c) the cloud can deploy vm's to the system, with their networking properly bridged.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Dan,

Perhaps your network configuration knowledge here is a bit deeper?

:-Dustin

Joseph Salisbury (jsalisbury) wrote :

Attaching the broken /etc/network/interfaces from my configuration.

Joseph Salisbury (jsalisbury) wrote :

Attaching a modified /etc/network/interfaces that allowed the network to start.

Changed in eucalyptus (Ubuntu Karmic):
assignee: Colin Watson (cjwatson) → Dustin Kirkland (kirkland)
Changed in eucalyptus (Ubuntu Karmic):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (3.6 KiB)

This bug was fixed in the package eucalyptus - 1.6~bzr930-0ubuntu1

---------------
eucalyptus (1.6~bzr930-0ubuntu1) karmic; urgency=low

  [ Dustin Kirkland ]
  * debian/eucalyptus-url, debian/eucalyptus-cc.install,
    debian/eucalyptus-cc.links, debian/eucalyptus-cc.postinst::
    - fix whitespace, to match other update-motd urls LP: #450449
    - link to ubuntu.com/cloud, which links to our documentation,
      necessary for new UEC admins
    - ensure that it gets installed with executable permissions,
      LP: #444970
  * debian/eucalyptus-udeb.finish-install: fix typo; fix breakage of
    /etc/network/interfaces when nodes are configured with static IP
    addresses, LP: #446023
  * eucalyptus-cc.upstart,
    eucalyptus-cloud.eucalyptus-cc-registration.upstart,
    eucalyptus-cloud.eucalyptus-sc-registration.upstart,
    eucalyptus-cloud.eucalyptus-walrus-registration.upstart,
    eucalyptus-sc.upstart, eucalyptus-walrus.upstart, rules, control:
    - registration of cc/sc/walrus should *only* ever occur on the CLC,
      so these scripts should be moved to the eucalyptus-cloud package,
      LP: #450815
    - starting cc/sc/walrus should *not* depend on eucalyptus-cloud
      running, since these components can be installed on separate
      machines, LP: #450777
    - but if cc/sc/walrus are on a system doing registration, ensure that
      these jobs kick off when "starting" registration
    - allow for whitespace separated list of $CC_IP_ADDR and $SC_IP_ADDR,
      as there can be more than one of these, and admins in multi-cluster
      or multi-component mode would need to register a list
    - use Replaces to ensure upgrades work properly
  * debian/eucalyptus-ipaddr.conf: update inline documentation accordingly
  * debian/eucalyptus-cc.templates: update public_ips instructions in the
    installer to match the new upstream implementation, LP: #438565
  * eucalyptus-common.eucalyptus.upstart: fix unclean package purging,
    which hangs on stopping eucalyptus service

  [ Upstream ]
  * Merge upstream revision 930
  * This snapshot is expected to fix the following bugs:
    - LP: #449944 - fixes remote component bootstrap issue
    - LP: #430852, #401996 - fix handling of security groups for the admin
    - LP: #449948 - fix issues with network index and address recovery after
      a system restart
    - LP: #398867 - fix storing VLAN tag info from web ui
    - LP: #430266 - fix setting of HTTP error codes
    - LP: #449948 - part of fix to LP:#449948 the CC now correctly sets the
      networkIndex field in the reponse message of describeInstances
    - LP: #438565 - allowing a range of IPs to be specified in the
      VNET_PUBLICIPS field of eucalyptus.conf
    - LP: #449143 - Add the 169.254.169.254 address to eth0 as 'scope link'
      in order to avoid conflict with the UEC avahi-publish mechanism
    - LP: #449135 - Prevents a segfault in CC during client connection to NC
      on describeInstances, when number of instances is high (> 20 or so).
      The number of bytes sent to 'malloc' was being calculated incorrectly.
    - LP: #444838 - fix to fully allow VMs to access meta-data service in
      MANAGED-NOVLAN, when ...

Read more...

Changed in eucalyptus (Ubuntu Karmic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers