yahoo-eng-team team mailing list archive

[Rich Lees <1714495@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

I have been banging my head a bit with this one, especially as I am sure
it *used* to work although in theory it should never have done! I would
imagine a systemd update would have broken things.

I can't get cloud-init to configure the network when using `distro:
arch`. What seems to happen is this:

  - systemd looks at current units/services to start and begins boot.
  - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
  - init.apply_network_config happens with bringup=False.
  - arch.py writes out a netctl config and enables it using netctl reenable enp0s3.
  - netctl creates a new systemd unit (netctl@enp0s3) and enables it
  - systemd list of services already resolved, so does not start netctl@enp0s3 as it was created after the boot process started

So after the system is fully brought up, the interface is configured but
NOT started. A subsequent reboot makes the network become available.

A few things and thoughts:

  - I tried making bringup=True by force but cloud-init-local is too early in the boot process and netctl barfs when trying to do a restart on an interface here.
  - Debian and RHEL based seem to have their own ways of managing network that involve putting files in a certain place that an *already existing* service then comes along and processes later.
  - Tried from "master" and from 0.7.9.tar.gz

I can't think of a way netctl could ever work with cloud-init. Possibly
using systemd-networkd instead would be wise but then things like
Vagrant and no doubt other "cloud" providers expect Arch to be using
netctl.

Thoughts? Ideas? Even a .patch so I can bodge something to work would be
a big help right now but everything I have tried fails for one reason or
another.

** Affects: cloud-init
     Importance: Undecided
         Status: New

** Description changed:

  I have been banging my head a bit with this one, especially as I am sure
  it *used* to work although in theory it should never have done! I would
  imagine a systemd update would have broken things.
  
  I can't get cloud-init to configure the network when using `distro:
  arch`. What seems to happen is this:
  
-   - systemd looks at current units/services to start and begins boot.
-   - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
-   - init.apply_network_config happens with bringup=False.
-   - arch.py writes out a netctl config and enables it using netctl reenable enp0s3.
-   - netctl creates a new systemd unit (netctl@enp0s3) and enables it
-   - systemd list of services already resolved, so does not start netctl@enp0s3 as it was created after the boot process started
+   - systemd looks at current units/services to start and begins boot.
+   - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
+   - init.apply_network_config happens with bringup=False.
+   - arch.py writes out a netctl config and enables it using netctl reenable enp0s3.
+   - netctl creates a new systemd unit (netctl@enp0s3) and enables it
+   - systemd list of services already resolved, so does not start netctl@enp0s3 as it was created after the boot process started
  
  So after the system is fully brought up, the interface is configured but
- NOT started. A subsequent reboot makes the system become available.
+ NOT started. A subsequent reboot makes the network become available.
  
  A few things and thoughts:
  
-   - I tried making bringup=True by force but cloud-init-local is too early in the boot process and netctl barfs when trying to do a restart on an interface here.
-   - Debian and RHEL based seem to have their own ways of managing network that involve putting files in a certain place that an *already existing* service then comes along and processes later.
-   - Tried from "master" and from 0.7.9.tar.gz
+   - I tried making bringup=True by force but cloud-init-local is too early in the boot process and netctl barfs when trying to do a restart on an interface here.
+   - Debian and RHEL based seem to have their own ways of managing network that involve putting files in a certain place that an *already existing* service then comes along and processes later.
+   - Tried from "master" and from 0.7.9.tar.gz
  
  I can't think of a way netctl could ever work with cloud-init. Possibly
  using systemd-networkd instead would be wise but then things like
  Vagrant and no doubt other "cloud" providers expect Arch to be using
  netctl.
  
  Thoughts? Ideas? Even a .patch so I can bodge something to work would be
  a big help right now but everything I have tried fails for one reason or
  another.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1714495

Title:
  Archlinux Netctl Bringup

Status in cloud-init:
  New

Bug description:
  I have been banging my head a bit with this one, especially as I am
  sure it *used* to work although in theory it should never have done! I
  would imagine a systemd update would have broken things.

  I can't get cloud-init to configure the network when using `distro:
  arch`. What seems to happen is this:

    - systemd looks at current units/services to start and begins boot.
    - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
    - init.apply_network_config happens with bringup=False.
    - arch.py writes out a netctl config and enables it using netctl reenable enp0s3.
    - netctl creates a new systemd unit (netctl@enp0s3) and enables it
    - systemd list of services already resolved, so does not start netctl@enp0s3 as it was created after the boot process started

  So after the system is fully brought up, the interface is configured
  but NOT started. A subsequent reboot makes the network become
  available.

  A few things and thoughts:

    - I tried making bringup=True by force but cloud-init-local is too early in the boot process and netctl barfs when trying to do a restart on an interface here.
    - Debian and RHEL based seem to have their own ways of managing network that involve putting files in a certain place that an *already existing* service then comes along and processes later.
    - Tried from "master" and from 0.7.9.tar.gz

  I can't think of a way netctl could ever work with cloud-init.
  Possibly using systemd-networkd instead would be wise but then things
  like Vagrant and no doubt other "cloud" providers expect Arch to be
  using netctl.

  Thoughts? Ideas? Even a .patch so I can bodge something to work would
  be a big help right now but everything I have tried fails for one
  reason or another.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1714495/+subscriptions