@varde-flyt/vfac 0.7.0 → 0.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +29 -5
- package/dist/vfac.mjs +1257 -373
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -26,11 +26,19 @@ vfac guide
|
|
|
26
26
|
vfac whoami
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
`doctor` checks the endpoint,
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
declares the oldest client it supports;
|
|
33
|
-
before sending your credential anywhere.
|
|
29
|
+
`doctor` checks the endpoint, which Project this terminal has selected, the API,
|
|
30
|
+
whether this client is new enough for the platform it is pointed at, your
|
|
31
|
+
credential and what that credential reaches, in that order, and reports the first
|
|
32
|
+
thing that is actually wrong. A platform declares the oldest client it supports;
|
|
33
|
+
below that, `doctor` fails and says so before sending your credential anywhere.
|
|
34
|
+
|
|
35
|
+
The selected Project and the Projects your credential reaches are two different
|
|
36
|
+
lines, and reading the second as the first is the mistake worth naming: a command
|
|
37
|
+
with no `--project` uses the SELECTED one, and having access to a Project is not
|
|
38
|
+
the same as being in it. `doctor` also says so when it has just started a fresh
|
|
39
|
+
config because the old one could not be read — the endpoint and Project you had
|
|
40
|
+
set are gone in that case, and the unreadable file is kept beside it rather than
|
|
41
|
+
discarded.
|
|
34
42
|
|
|
35
43
|
`doctor` is also the one command that contacts a host other than your own
|
|
36
44
|
platform: it asks `registry.npmjs.org` whether a newer `vfac` has been published.
|
|
@@ -73,6 +81,22 @@ vfac get product-instance <productInstanceId>
|
|
|
73
81
|
Secrets are supplied per apply and never belong in the manifest — a manifest is a
|
|
74
82
|
file you commit. `vfac plan` lists the ones an apply will still need.
|
|
75
83
|
|
|
84
|
+
### `metadata.key` is the name you choose
|
|
85
|
+
|
|
86
|
+
`manifest init` writes one into the file, derived from `--name`. It is what the
|
|
87
|
+
platform recognises the resource by on every later apply, and it is the one
|
|
88
|
+
identifier in a manifest that is yours: a resource key is 3–63 characters of
|
|
89
|
+
lowercase letters, digits and hyphens, starting with a letter and ending with a
|
|
90
|
+
letter or digit.
|
|
91
|
+
|
|
92
|
+
**A key is claimed for good, and a delete does not release it.** The record of a
|
|
93
|
+
deleted resource keeps its key, so a manifest that named it can never apply again
|
|
94
|
+
— `vfac plan` answers `GONE` — and a replacement needs a different key. That is
|
|
95
|
+
worth knowing before the delete rather than after it, because after it there is
|
|
96
|
+
nothing to undo; `vfac lifecycle delete` says the same thing at the prompt. If
|
|
97
|
+
what you want is to stop the service and keep the option of bringing it back,
|
|
98
|
+
`vfac lifecycle suspend` is the reversible one.
|
|
99
|
+
|
|
76
100
|
## Reading a setting from another resource
|
|
77
101
|
|
|
78
102
|
A setting may take its value from an output another resource publishes, instead
|