This is an automated email from the ASF dual-hosted git repository. duncangrant pushed a commit to branch ruby-3 in repository https://gitbox.apache.org/repos/asf/brooklyn-docs.git
commit 28a107aab570431ac4bb62f6d0bcd44c2f4b90f3 Merge: 06230ce 84156e3 Author: Richard Downer <[email protected]> AuthorDate: Fri Feb 26 10:05:19 2021 +0000 Merge apache-brooklyn/master as at commit 84156e39 guide/blueprints/catalog/schema.md | 25 +++++-- guide/blueprints/custom-entities.md | 4 +- guide/blueprints/entity-configuration.md | 12 ++++ .../{ => policies}/_elect-primary-policies.md | 0 .../available_policies.md} | 20 ------ guide/blueprints/policies/index.md | 21 ++++++ guide/blueprints/policies/writing_policies.md | 76 +++++++++++++++++++++ guide/blueprints/yaml-reference.md | 51 ++++++++++---- guide/ops/configuration/index.md | 79 ++++++++++++++++++++-- guide/ops/externalized-configuration.md | 33 ++++++++- package.json | 2 +- 11 files changed, 277 insertions(+), 46 deletions(-) diff --cc guide/blueprints/policies/available_policies.md index bc42607,3b2a613..23982aa --- a/guide/blueprints/policies/available_policies.md +++ b/guide/blueprints/policies/available_policies.md @@@ -1,28 -1,7 +1,8 @@@ --- -title: Off-the-Shelf Policies +title: Policies +layout: website-normal --- - Policies perform the active management enabled by Brooklyn. - They can subscribe to entity sensors and be triggered by them (or they can run periodically, - or be triggered by external systems). - - Policies can add subscriptions to sensors on any entity. Normally a policy will subscribe to sensors on - either its associated entity, that entity's children and/or to the members of a "group" entity. - - Common uses of a policy include the following: - - * perform calculations, - * look up other values, - * invoke effectors (management policies) or, - * cause the entity associated with the policy to emit sensor values (enricher policies). - - Entities can have zero or more `Policy` instances attached to them. - - - Off-the-Shelf Policies - ---------------------- - Policies are highly reusable as their inputs, thresholds and targets are customizable. Config key details for each policy can be found in the Catalog in the Brooklyn UI. diff --cc guide/ops/configuration/index.md index a3b3102,6b04739..6996847 --- a/guide/ops/configuration/index.md +++ b/guide/ops/configuration/index.md @@@ -73,17 -66,11 +73,17 @@@ Users and passwords for Brooklyn can b ### HTTPS Configuration -See [HTTPS Configuration]({{book.path.docs}}/ops/configuration/https.md) for general information on configuring HTTPS. +See [HTTPS Configuration](https.html) for general information on configuring HTTPS. + +<!-- +---------- +-- NOTE: comment out this section on catalog as the behaviour described is not enabled by default since +-- https://github.com/apache/brooklyn-server/pull/233; re-enable this when that changes +---------- - ## Catalog in Karaf + ## Catalog in OSGi With the traditional launcher, Brooklyn loads the initial contents of the catalog from a `default.catalog.bom` file -as described in the section on [installation]({{book.path.docs}}/ops/production-installation.md). Brooklyn finds Java +as described in the section on [installation](/guide/ops/production-installation.html). Brooklyn finds Java implementations to provide for certain things in blueprints (entities, enrichers etc.) by scanning the classpath. In the OSGI world this approach is not used, as each bundle only has visibility of its own and its imported Java packages. diff --cc guide/ops/externalized-configuration.md index 877ad18,ebddcad..5b60657 --- a/guide/ops/externalized-configuration.md +++ b/guide/ops/externalized-configuration.md @@@ -198,21 -197,44 +198,44 @@@ Then, a blueprint which referred to `$b able to query the Vault REST API for configuration values. The different suppliers implement alternative authentication options that Vault provides. - For *all* of the authentication methods, you must always set these properties in `brooklyn.cfg`: + Brooklyn supports the "Key/Value" Secrets Engine, with API version 1 or version 2. See + [KV Secrets Engine](https://www.vaultproject.io/docs/secrets/kv) in the Vault documentation to help you decide which + one to use. + + If you are using version 1, here are the properties you can set: -```properties +{% highlight properties %} brooklyn.external.supplierName.endpoint=<Vault HTTP/HTTPs endpoint> brooklyn.external.supplierName.path=<path to a Vault object> + brooklyn.external.supplierName.kv-api-version=1 # can be omitted - 1 is the default -``` +{% endhighlight %} For example, if the path is set to `secret/brooklyn`, then attempting to retrieve the key `foo` would cause Brooklyn to retrieve the value of the `foo` key on the `secret/brooklyn` object. This value can be set using the Vault CLI like this: -```bash +{% highlight bash %} vault write secret/brooklyn foo=bar -``` +{% endhighlight %} + If you are using version 2, here are the properties you can set: + + ```properties + brooklyn.external.supplierName.endpoint=<Vault HTTP/HTTPs endpoint> + brooklyn.external.supplierName.mountPoint=<path to the secrets engine> + brooklyn.external.supplierName.path=<path to the key> + brooklyn.external.supplierName.kv-api-version=2 + ``` + + For example, if the k/v secrets engine is mounted at `secret/` and secrets are stored in the object `brooklyn`, then + set `mountPoint` to `secret` (no trailing slash) and `path` to `brooklyn`. Values can be set on this object using the + Vault CLI like this: + + ```bash + vault kv put secret/brooklyn foo=bar + ``` + + #### Authentication by username and password The `userpass` plugin for Vault allows authentication with username and password.
