add-subnet subcommand references absent create-subnet command

Bug #1614345 reported by Katherine Cox-Buday on 2016-08-18
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Running tip on commit 0806e96

$juju help add-subnet
Usage: juju add-subnet [options] <CIDR>|<provider-id> <space> [<zone1> <zone2> ...]

Add an existing subnet to Juju.

-m, --model (= "")
    Model to operate in. Accepts [<controller name>:]<model name>

Adds an existing subnet to Juju, making it available for use. Unlike
"juju create-subnet", this command does not create a new subnet, so it
is supported on a wider variety of clouds (where SDN features are not
available, e.g. MAAS). The subnet will be associated with the given
existing Juju network space.

Subnets can be referenced by either their CIDR or ProviderId (if the
provider supports it). If CIDR is used an multiple subnets have the
same CIDR, an error will be returned, including the list of possible
provider IDs uniquely identifying each subnet.

Any availablility zones associated with the added subnet are automatically
discovered using the cloud API (if supported). If this is not possible,
since any subnet needs to be part of at least one zone, specifying
zone(s) is required.

Dimiter Naydenov (dimitern) wrote :

It's not quite absent, it was never fully implemented and it's also feature flagged:

$ JUJU_DEV_FEATURE_FLAGS=post-net-cli-mvp juju help create-subnet
Usage: juju create-subnet [options] <CIDR> <space> <zone1> [<zone2> <zone3> ...] [--public|--private]

create a new subnet

-m, --model (= "")
    Model to operate in. Accepts [<controller name>:]<model name>
--private (= true)
    disable public access with shadow addresses
--public (= false)
    enable public access with shadow addresses

Creates a new subnet with a given CIDR, associated with an existing Juju
network space, and attached to one or more availablility zones. Desired
access for the subnet can be specified using the mutually exclusive flags
--private and --public.

When --private is specified (or no flags are given, as this is the default),
the created subnet will not allow access from outside the model and
the available address range is only cloud-local.

When --public is specified, the created subnet will support "shadow addresses".
This means all machines inside the subnet will have cloud-local addresses
configured, but there will also be a shadow address configured for each
machine, so that the machines can be accessed from outside the model (similarly
to the automatic public IP addresses supported with AWS VPCs).

This command is only supported on clouds which support creating new subnets
dynamically (i.e. Software Defined Networking or SDN). If you want to make
an existing subnet available for Juju to use, rather than creating a new
one, use the "juju subnet add" command.

Some clouds allow a subnet to span multiple zones, but others do not. It is
an error to try creating a subnet spanning more than one zone if it is not

Apart from that, I agree the add-subnet help text should be updated not to refer to create-subnet.

Changed in juju-core:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 2.0.0
affects: juju-core → juju
Changed in juju:
milestone: 2.0.0 → none
milestone: none → 2.0.0
Curtis Hovey (sinzui) on 2016-10-06
Changed in juju:
milestone: 2.0.0 → 2.0.1
Curtis Hovey (sinzui) on 2016-10-28
Changed in juju:
milestone: 2.0.1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers