role of iprange not clear

[rade]

A user reports "My worry about using the -iprange was that maybe it would restrict the ip range I could use weave with."

Looking at our docs, it is indeed not absolutely clear that iprange is used for automatic allocation only.

[squaremo]

I'm sure there is a long and storied history, but on the surface of it, the names of those arguments do not make it clear what they do. We could fix the documentation, or fix the names, or both. (If we fix the names, we'll have to keep the old ones for compatibility I suppose)

[rade]

Lets fix the names. What have you got in mind?

[squaremo]

What have you got in mind?

Discussion on <group chat du jour> brought up --ipam-range and --ipam-default-subnet. I'll leave in support for -iprange and -ipsubnet, with a deprecation notice.

[rade]

This naming scheme is inconsistent with what we currently have for router options. We don't use dashes in options, and we use - instead of --.

[squaremo]

Those are both things I dislike! And -ipamrange and -ipamdefaultsubnet are difficult to read.

[rade]

Those are both things I dislike!

Fine, so fix them.

Also note that ipam is not a term we generally use in our docs. #1040

[squaremo]

note that ipam is not a term we generally use in our docs.

ipalloc could be used in place of ipam. A bit longer, but more obvious if we don't actually refer to IPAM anywhere.

Those are both things I dislike!

Fine, so fix them.

As a prerequisite to doing this?

[rade]

As a prerequisite to doing this?

Yes. Or stick to the current scheme (which would be my recommendation; and raise a separate issue for revamping the flag parsing).

[squaremo]

No-one in good conscience could add an option -ipallocdefaultsubnet. Nicely punted into the long grass, there.

[rade]

We already have initpeercount.

[squaremo]

Yeah that's not ideal either really

[squaremo]

We already have initpeercount.

.. and --with-dns, --without-dns, --replace, --no-default-ipam, ....

[rade]

.. and --with-dns, --without-dns, --replace, --no-default-ipam, ....

None of those are launch options. And they are never mixed with other options that follow a different scheme.

[squaremo]

Oh right, it's one of those "except when it isn't" rules.

[rade]

I have been thinking about the backward compatibility story... I reckon what users are most concerned about isn't substitutability, but interoperability - being able to run new and old in the same network, and thus being able to roll out and upgrade gradually. That requires protocol compatibility, not script compatibility.

Hence renaming of commands & options is actually fine, though obviously if it is easy to retain the old ones in parallel then we should do so (but advise users in the release notes that they should really update their scripts, etc, since we won't retain the old version indefinitely).

[squaremo]

@rade Should we cross-post that to #602?