lxops commands like launch, have a "-P key=value" flag that overrides config and global properties.
If the config file has an origin, or device-template, the config file is used to derive
the paths of the filesystems/devices that should be cloned or copied into the target (launched) instance.
The command-line properties should not be used for the origin or template instance.
Therefore one could use a command-line property to change the normal location of the instance
while using the normal location of clone or copy the filesystems from.
For example:
Suppose that:
The config c.yaml has a filesystem with pattern: (fsroot)/(instance)
fsroot is a global property that has the value z/prod
The config device-template is set to "t1"
Run:
lxops launch -name a1 c.yaml
This will create the filesystem z/prod/a1,
and copy the directory /z/prod/t1/ into it.
Now, let's say I want to create a test container at another location, so I override fsroot in the command line:
lxops launch -name a2 -P fsroot=z/test c.yaml
This will currently try to copy /z/test/t1/ into /z/test/a2/, but since /z/test/t1 doesn't exist, it will not get copied.
With this proposal the command line property fsroot will be applied to the destination container, a2, but not to the template, t1, so /z/test/a2/ will be created with the contents of /z/prod/t1/
There is currently a config field called "source-config" that attempts to solve this problem by providing a different config to be used for origins or templates. It was meant to be used as follows:
create a new config c-test.yaml with an fsroot that overrides the global properties
In c-test.yaml, specify "source-config: c.yaml"
I have found this to be cumbersome, because I need to maintain two configs for each type of container.
On the other hand, creating explicit configs for each container makes it easier to track the parameters used to create each container.
So I'm not sure which is the right strategy.
I currently do not use command-line properties at all.
lxops commands like launch, have a "-P key=value" flag that overrides config and global properties. If the config file has an origin, or device-template, the config file is used to derive the paths of the filesystems/devices that should be cloned or copied into the target (launched) instance.
The command-line properties should not be used for the origin or template instance. Therefore one could use a command-line property to change the normal location of the instance while using the normal location of clone or copy the filesystems from.
For example:
Suppose that:
Run:
This will create the filesystem z/prod/a1, and copy the directory /z/prod/t1/ into it.
Now, let's say I want to create a test container at another location, so I override fsroot in the command line:
This will currently try to copy /z/test/t1/ into /z/test/a2/, but since /z/test/t1 doesn't exist, it will not get copied.
With this proposal the command line property fsroot will be applied to the destination container, a2, but not to the template, t1, so /z/test/a2/ will be created with the contents of /z/prod/t1/
There is currently a config field called "source-config" that attempts to solve this problem by providing a different config to be used for origins or templates. It was meant to be used as follows:
I have found this to be cumbersome, because I need to maintain two configs for each type of container. On the other hand, creating explicit configs for each container makes it easier to track the parameters used to create each container.
So I'm not sure which is the right strategy.
I currently do not use command-line properties at all.