new: Support specifying complex list arguments as JSON

[lgarber-akamai]

📝 Description

This change adds support for specifying complex lists (e.g. interfaces) as a single JSON string rather than a series of arguments. This should improve the UX when writing scripts that may use these complex structures.

This pull request also makes various changes to generalize parent/child logic rather than explicitly relating it to lists.

This PR originally included improvements to the command help pages but I decided to break it out into a separate PR because of how big this PR was getting 🙂

✔️ How to Test

The following test steps assume you have pulled down this PR and run make install.

Integration Testing

make testint

Unit Testing

make testunit

Manual Testing

Complex Lists as JSON

1. Attempt to create a Linode with the interfaces argument defined as JSON:

linode-cli linodes create \
  --label test-instance \
  --region us-mia \
  --image linode/alpine3.19 \
  --root_pass 'testp4ssw0rd!!!!!!23123' \
  --type g6-nanode-1 \
  --interfaces '[{"purpose": "public"}, {"purpose": "vlan", "label": "test-vlan"}]' \
  --debug

2. Ensure the interfaces JSON is properly represented in the debug request body output.
3. Navigate to the instance in Cloud Manager and ensure it has been configured as expected.

[lgarber-akamai]

I originally wanted to implement this validation using argparse's mutually exclusive groups but I couldn't get it to play nicely with multiple compatible fields.

[lgarber-akamai]

This isn't specific to this change but should address some weird errors I was running into.

[lgarber-akamai]

I don't know if I like the wording here, any suggestions would be much appreciated!

[zliang-akamai]

I noticed that a VLAN is used in the interfaces of the instance creation command so VPC creation in step 1 is probably not necessary?

[lgarber-akamai]

I noticed that a VLAN is used in the interfaces of the instance creation command so VPC creation in step 1 is probably not necessary?

Oops, you're right. I think I copied it from another PR description and forgot to remove it lol

[yec-akamai]

LGTM. Unit test and manual test passed locally!

However, I'm seeing a couple of similar errors when running the integration tests around put operations, i.e.

>       exec_test_command(BASE_CMD + ["put", str(file_path), bucket_name])

This failed when assert the process.retruncode:

>       assert process.returncode == 0

Not sure if it's related to this PR or a interim issue, but as a heads up. I'm looking into it as well.

[lgarber-akamai]

LGTM. Unit test and manual test passed locally!

However, I'm seeing a couple of similar errors when running the integration tests around put operations, i.e.

>       exec_test_command(BASE_CMD + ["put", str(file_path), bucket_name])

This failed when assert the process.retruncode:

>       assert process.returncode == 0

Not sure if it's related to this PR or a interim issue, but as a heads up. I'm looking into it as well.

Nice find, I'll look into this as well!

[zliang-akamai]

Firewall tests are failing on my end..

Are you able to reproduce it?

[lgarber-akamai]

@zliang-akamai Looks like they're failing on my end too, I'll take a quick look

[lgarber-akamai]

So it looks like supporting dicts as JSON introduces some weird multi-parent conflicts with commands that nest complex lists in dicts (e.g. Firewalls). Given the main use-case of this feature is to reduce complexity when specifying complex lists of objects, I'll remove dicts as JSON from the scope of this PR 👍

[yec-akamai]

Integration test passed! Nice work 🎉

[zliang-akamai]

Tested locally. Nice work!