Hi Andrew,
I think that's a very useful change. Let me give a summary of what my
understanding of the change is:
* Using a java class declaring ConfigKeys with @CatalogConfig annotation will
display those keys in the UI (if priority > 0)
brooklyn.catalog:
version: 0.0.1
id: bash
item:
type: VanillaWindowsProcess
will display in UI configuration for Install PowerShell command, Install
Command, Customize PowerShell command, etc.
* Parameters defined in brooklyn.parameters override keys coming from the
java class for the UI - only the brooklyn.parameters will be visible in the UI
brooklyn.catalog:
version: 0.0.1
id: bash-custom-parameters
item:
type: bash
brooklyn.parameters:
- username
- password
will display in UI configuration for username, password
* Specializing a catalog item in a new catalog item with brooklyn.parameters
will concatenate the parameters, adding the current catalog item's parameters
to the beginning of the list
brooklyn.catalog:
version: 0.0.1
id: downloader
item:
type: bash-custom-parameters
brooklyn.parameters:
- download_url
will display in UI configuration for download_url, username, password
---
I think that's a nice compromise between having too many configuration items in
the UI and having to repeat brooklyn.parameters on each catalog item
re-definition/specialization.
At runtime we will get all brooklyn.parameters including all config keys
defined on the java class so in yaml we can use the DSL to access them.
--
+1 from me.
Svet.
> On 26.07.2016 г., at 22:45, Andrew Kennedy <[email protected]>
> wrote:
>
> One thing to note in the latest commit on the PR is that I made some
> changes suggested by @neykov to always add the configuration from the
> entity as parameters, and also to *prepend* new parameters. That means that
> in the UI, the list of parameters will be sorted in the reverse order of
> entity hierarchy, with the parameters defined on the current entity first,
> then the entity it inherited from, and so on. This is the _inheritance_
> hierarchy, of entity definitions in BOm files or via Java class and
> interface inheritance, not the structural parent-child relationships. I am
> not 100% convinced this is the best way, as it does fill up the UI with
> more parameters, but at least they are all visible and in a sensible order.
>
> Perhaps we could add some further properties to SpecParameter that can be
> used as display hints?
>
> Andrew.
>
> On Tue, 26 Jul 2016 at 20:42 Andrew Kennedy <
> [email protected]> wrote:
>
>> - https://github.com/apache/brooklyn-server/pull/229
>>
>> I have created this PR to fix an issue with the handling of
>> brooklyn.parameters in BOM files. We now merge config keys and maps, so it
>> is expected that an entity will have its configuration be the union of the
>> config of its ancestors, with the lowest level config taking priority. This
>> PR does the same for parameters - instead of replacing the entire set of
>> parameters when an entity is declared, we add the new parameters,
>> overwriting any that already exist and have the same config key. This means
>> an entity can alter defaults or descriptions for a key when it is defined,
>> and these will be used when retrieving config.
>>
>> One issue is that this now results in long lists of parameters in the UI,
>> and one must also be quite careful referencing config to make sure the
>> correct entity is in scope. Also, if an entity has some parameters defined,
>> they are only available to its descendants. If you wish to make them
>> visible in the application UI details, they must be re-declared there, and
>> again, care must be taken with coping when retrieving the config values.
>>
>> I think this PR is probably good enough to use as-is, but I'm interested
>> in any feedback and ideas for further changes and improvements that can be
>> implemented in a future PR. If nobody objects, i would like to merge this
>> in a few days?
>>
>> Thanks,
>> Andrew.
>> --
>>
>> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
>>
> --
>
> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
