curtin-dev team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

Review: Needs Fixing

Thanks for getting something started.  The origin of this scenario comes from the Subiquity installer which handles writing a network configuration into the target outside of curtin and cloud-init.  In this scenario, subiquity provides *no* network config at all to curtin, and leaves net-meta in 'auto' mode by default.  The goal for subiquity is to have curtin not emit any config into the target system.

For auto, the lack of network-config means curtin needs to generate a sensible network config and it uses the environment in which it is running to make a best-guess.  We cannot use the lack of custom network config presented to curtin as a desire to *NOT* generate a network config as this would break existing use-cases where we do not provide network config to curtin but do expect the target system to have networking.

I think for the subiquity scenario, we want to introduce a new mode to net-meta, 'disabled'  Which does what you describe above; namely, curtin will not attempt to do _any_ configuration of networking in the target.

We will then request that subiquity specify a net-meta --mode=disabled in their install command, and this still allows users which pass a "disabled" network config to curtin to pass this through to the target.  For verification of this feature we need the following scenarios:

1) a vmtest where no 'network' config is supplied; good news is that all of the existing storage tests do this today

2) a vmtest where we specify net-meta --mode=disabled;  this is a new scenario where we use the following config:

install:
   network_commands:
      disabled: ['curtin', 'net-meta', 'disabled']

3) a vmtest where we specify a network disabled config

network:
  config: disabled

And possibly this variant

network;
  config: disabled
  version: 1

I'd like us to confirm that we can use the former config, as this is what
cloud-init accepts natively, we just need to confirm that curtin will pass
this through correctly.


Something simple like this would avoid most changes to curtin, and then
we just need unittests to verify this, and the 2 vmtest scenarios (2 and 3)


% git diff
diff --git a/curtin/commands/net_meta.py b/curtin/commands/net_meta.py
index fdb909e1..09983c0f 100644
--- a/curtin/commands/net_meta.py
+++ b/curtin/commands/net_meta.py
@@ -80,6 +80,11 @@ def net_meta(args):
 
     state = util.load_command_environment()
     cfg = config.load_command_config(args, state)
+
+    if args.mode == 'disabled':
+        LOG.debug("net-meta mode is '%s'. network config disabled", args.mode)
+        sys.exit(0)
+
     if cfg.get("network") is not None:
         args.mode = "custom"
 
@@ -160,7 +165,7 @@ CMD_ARGUMENTS = (
        'action': 'store', 'metavar': 'TARGET',
        'default': os.environ.get('TARGET_MOUNT_POINT')}),
      ('mode', {'help': 'meta-mode to use',
-               'choices': ['dhcp', 'copy', 'auto', 'custom']})
+               'choices': ['disabled', 'dhcp', 'copy', 'auto', 'custom']})
      )
 )

-- 
https://code.launchpad.net/~lamoura/curtin/+git/curtin/+merge/383785
Your team curtin developers is subscribed to branch curtin:master.