Bug #1453
Updated by Ruben S. Montero almost 9 years ago
This is issue is for the Datastore documentation. Originally reported by Matthew Patton in the mailing list:
>The documentation is sure plentiful but it really needs a fact and consistency checker. The >The rampant use of '/var/lib/one/datastores' in particular needs to be excised everywhere >everywhere and replaced with $DATASTORE_LOCATION because there is a huge difference between >between what the front-end is doing with it and what the Host is using it for, or so the >the documentation seems to imply.
> Fix 'onedatastore show <#>' such that "BASE PATH" to use
> the literal string '$DATASTORE_LOCATION' or the current value of the
> variable as 'oned' understands it to be (see /var/lib/one/config). Always
> returning '/var/lib/one/datastores/...' is wrong. Better yet the value
> should be auto-generated unless the user has hard-coded it. Currently it
> appears there is no way for me to force it to be an arbitrary value. This is
> particularly pertinent when dealing with VMware since VMFS are located at
> '/vmfs/volumes' and since there is no persistence, any hackery like creating
> '/var/datastores/<#>' isn't going to survive a reboot.
>The documentation is sure plentiful but it really needs a fact and consistency checker. The >The rampant use of '/var/lib/one/datastores' in particular needs to be excised everywhere >everywhere and replaced with $DATASTORE_LOCATION because there is a huge difference between >between what the front-end is doing with it and what the Host is using it for, or so the >the documentation seems to imply.
> Fix 'onedatastore show <#>' such that "BASE PATH" to use
> the literal string '$DATASTORE_LOCATION' or the current value of the
> variable as 'oned' understands it to be (see /var/lib/one/config). Always
> returning '/var/lib/one/datastores/...' is wrong. Better yet the value
> should be auto-generated unless the user has hard-coded it. Currently it
> appears there is no way for me to force it to be an arbitrary value. This is
> particularly pertinent when dealing with VMware since VMFS are located at
> '/vmfs/volumes' and since there is no persistence, any hackery like creating
> '/var/datastores/<#>' isn't going to survive a reboot.