Support CLI editing of VM details #101

Closed
opened 2020-08-20 12:29:27 -04:00 by JoshuaBoniface · 21 comments
JoshuaBoniface commented 2020-08-20 12:29:27 -04:00 (Migrated from git.bonifacelabs.ca)

Some VM details should be easily editable from the CLI rather than requiring XML editing. Networks is the most obvious one since editing these and "generating" MACs is tedious, but this could also extend to several other common elements too, or eventually all aspects.

Some VM details should be easily editable from the CLI rather than requiring XML editing. Networks is the most obvious one since editing these and "generating" MACs is tedious, but this could also extend to several other common elements too, or eventually all aspects.
JoshuaBoniface commented 2020-08-20 12:29:27 -04:00 (Migrated from git.bonifacelabs.ca)

changed milestone to %4

changed milestone to %4
JoshuaBoniface commented 2020-10-21 03:41:23 -04:00 (Migrated from git.bonifacelabs.ca)

Still consider this a nice-to-have feature, especially for networks. Would however require PVC to keep a model of the VM somehow, beyond the simple XML-only storage of today. I can see two potential implementations:

  1. My original thought: the client requests the XML document, this is parsed, the relevant line(s) are added/removed, then the updated XML is written back to the cluster.

Pros: Easier to implement, Fewer unrelated code changes
Cons: Inflexible, Spaghettified code

  1. A more robust approach: store VM details on the cluster as a set of configuration keys/values, then generate a Libvirt XML on-demand when needed.

Pros: Much more robust code, Abstracts libvirt configuration entirely, Potentially more flexibility (modules)
Cons: Extensive code rewrites, Complexity

Still consider this a nice-to-have feature, especially for networks. Would however require PVC to keep a model of the VM somehow, beyond the simple XML-only storage of today. I can see two potential implementations: 1. My original thought: the client requests the XML document, this is parsed, the relevant line(s) are added/removed, then the updated XML is written back to the cluster. Pros: Easier to implement, Fewer unrelated code changes Cons: Inflexible, Spaghettified code 2. A more robust approach: store VM details on the cluster as a set of configuration keys/values, then generate a Libvirt XML on-demand when needed. Pros: Much more robust code, Abstracts libvirt configuration entirely, Potentially more flexibility (modules) Cons: Extensive code rewrites, Complexity
JoshuaBoniface commented 2020-10-21 03:42:24 -04:00 (Migrated from git.bonifacelabs.ca)

mentioned in issue #93

mentioned in issue #93
JoshuaBoniface commented 2020-11-07 15:49:44 -05:00 (Migrated from git.bonifacelabs.ca)

Option 2 is actually infeasible while preserving the pvc vm define functionality. That just leaves option 1, the parsing and setting of values.

I can see a few elements where this sort of easy CLI editing will be extremely useful:

  1. VM vCPU counts
  2. VM vRAM counts
  3. Networks (add/remove)
  4. Volumes (add/remove)
  5. Consoles (serial/vnc, add/remove)

This should be easily implementable either by (a) subcommands to pvc vm modify (e.g. pvc vm modify vcpu), which will require reworking of the existing pvc vm modify command, or (b) a set of new subcommands for each element (e.g. pvc vm vcpu <subcommand>, with subcommands like get and modify).

I think option (b) is nicer long-term and provides far more flexibility.

Option 2 is actually infeasible while preserving the `pvc vm define` functionality. That just leaves option 1, the parsing and setting of values. I can see a few elements where this sort of easy CLI editing will be extremely useful: 1. VM vCPU counts 2. VM vRAM counts 3. Networks (add/remove) 4. Volumes (add/remove) 5. Consoles (serial/vnc, add/remove) This should be easily implementable either by (a) subcommands to `pvc vm modify` (e.g. `pvc vm modify vcpu`), which will require reworking of the existing `pvc vm modify` command, or (b) a set of new subcommands for each element (e.g. `pvc vm vcpu <subcommand>`, with subcommands like `get` and `modify`). I think option (b) is nicer long-term and provides far more flexibility.
JoshuaBoniface commented 2020-11-07 16:03:50 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 9f1dd3540445e3cf40046de8e858101c7e979461

mentioned in commit 9f1dd3540445e3cf40046de8e858101c7e979461
JoshuaBoniface commented 2020-11-07 17:36:26 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 3ad093d363ec30753165d870064821f6d1bc057d

mentioned in commit 3ad093d363ec30753165d870064821f6d1bc057d
JoshuaBoniface commented 2020-11-07 18:02:19 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 7cec2fa1ad6baac3f6f6dfae16529577b62c874a

mentioned in commit 7cec2fa1ad6baac3f6f6dfae16529577b62c874a
JoshuaBoniface commented 2020-11-07 18:02:58 -05:00 (Migrated from git.bonifacelabs.ca)

Elements 1 and 2 (vCPU and memory) are done. Element 5 will probably be next as this is similarly easy. Elements 3 and 4 are more complex.

Elements 1 and 2 (vCPU and memory) are done. Element 5 will probably be next as this is similarly easy. Elements 3 and 4 are more complex.
JoshuaBoniface commented 2020-11-07 19:12:41 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 4f2f46c68dfa3a2397d5409c7ff376b86a68e815

mentioned in commit 4f2f46c68dfa3a2397d5409c7ff376b86a68e815
JoshuaBoniface commented 2020-11-07 19:13:08 -05:00 (Migrated from git.bonifacelabs.ca)

Decided to abandon element 5. It is hard enough and also rare enough to not really justify this.

Decided to abandon element 5. It is hard enough and also rare enough to not really justify this.
JoshuaBoniface commented 2020-11-07 22:52:46 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit e7037e4e1423f2eb5d17c270cb9e8fe1e518ad68

mentioned in commit e7037e4e1423f2eb5d17c270cb9e8fe1e518ad68
JoshuaBoniface commented 2020-11-07 23:03:34 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 1f040031c7b41785368e5972546c7c8226597e04

mentioned in commit 1f040031c7b41785368e5972546c7c8226597e04
JoshuaBoniface commented 2020-11-08 00:49:35 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit cf57c54475cd6ed15ecffaf04bb1f8c21ad2b2fe

mentioned in commit cf57c54475cd6ed15ecffaf04bb1f8c21ad2b2fe
JoshuaBoniface commented 2020-11-08 00:57:25 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 5f5f4dd421

mentioned in commit 5f5f4dd42123e14bf57aa5d5b56970ce63cd006b
JoshuaBoniface commented 2020-11-08 00:57:25 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 03d4be79b7

mentioned in commit 03d4be79b78558f07473176bd06167bdef931d68
JoshuaBoniface commented 2020-11-08 00:57:26 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 569dcd84a4

mentioned in commit 569dcd84a4d37c35c4cce72186689d43354378bd
JoshuaBoniface commented 2020-11-08 00:57:26 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 1ff5d8bf46

mentioned in commit 1ff5d8bf468cce08d5f1b772e57dd63acb14c789
JoshuaBoniface commented 2020-11-08 00:57:26 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 18d3fc8431

mentioned in commit 18d3fc8431b452b8f97945c1a2db551aa2389d80
JoshuaBoniface commented 2020-11-08 00:57:26 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit b72c415bf1

mentioned in commit b72c415bf194cf9e7440932ee13990cb1743a185
JoshuaBoniface commented 2020-11-08 00:57:26 -05:00 (Migrated from git.bonifacelabs.ca)

mentioned in commit 9c339f4191

mentioned in commit 9c339f4191f16b5a13ea54975805d9febcc2d460
JoshuaBoniface commented 2020-11-08 01:04:10 -05:00 (Migrated from git.bonifacelabs.ca)

closed via commit a4536c31d4

closed via commit a4536c31d4496d2d014214b0a87824b364c62c62
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: parallelvirtualcluster/pvc#101
No description provided.