Add option to change ID prefix

[bboreham]

Prefixing everything with ignite- cuts into the number of characters available in some situations.

[stealthybox]

I'm supportive of this change.

I'm curious which character limits were you running into and how many more you needed to make what you ran into work?
Hopefully other CNI's don't need shorter ID's or some kind of truncation...

Adding the global flag makes sense, but we should really get thing plumbed into the ignite config.
Would you be willing to do so?

The only tricky part is making the flag override happen in the proper order.
This should be pretty similar to the code-path for configuring the container/docker runtime via flag/config.

[bboreham]

Weave Net creates a device named like vethweplfirst7c out of the first 7 characters of the ID you give it. Interface names are limited to 15 bytes.

The first 4 - veth - are necessary to coexist with standard Linux networking tools. We could tweak the next 4 - "we" is for Weave, "p" is for public and "l" is link, if I remember correctly, but even after that, taking the first 7 with ignite- really cuts into the diversity of names.

We could also re-code Weave Net to hash the name instead of taking the prefix, at the cost of making things harder to track down when you need to troubleshoot.

I don't know what other CNI implementations do in this situation.

[bboreham]

I added namePrefix to the config.

(I added it to v1alpha3 at the same time; not sure if that is meant to be immutable but it will be backwards-compatible)

[stealthybox]

We're working on making this work in ignite-spawn

[bboreham]

I have rebased after the flaky test was fixed, and added a commit to pass the option through to ignite-spawn

[stealthybox]

This patch is very close to being mergeable.

( nit: namePrefix,--name-prefix is misleading.
idPrefix,--id-prefix or systemPrefix is better in retrospect. )

We think a good addition would be patching the value into the VM Status on the first write of the VM object to disk.
This would be before the ignite-spawn handoff, so we wouldn't need the ignite-spawn flag to pass the value, since ignite-spawn has access to the VM object.

This allows us to remove the error-burden of flags for commands like ignite vm rm where the VM already exists and the value has to match.

This behavior would closely match the runtime/network status added in v0.8.0, and there's existing patching logic and tests that we can rely on.

Sunny and I plan to give this a more detailed look tomorrow.
Thanks for the continued work on getting this to work properly.

[darkowlzz]

LGTM!
Thanks.