Github user aledsage commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/721#issuecomment-116662599
@ahgittin good point about docs - will add some!
For `MachineChooser`, you're right that it would currently either have to
write Java, or use existing YAML mechanisms such as `$brooklyn:object`.
In the spirit of getting the Java API right, and then ensuring that we can
cleanly express things in YAML, do you think the Java API is right? Should we
use `Function<Iterable<? extends MachineLocation>, MachineLocation>`, or would
we be better using a specific type (e.g. so there is more opportunity to supply
`TypeCoercion` code)? If the Java API is ok, and won't make YAML support hard
to add, then shall we merge this PR?
Your suggested YAML behaviour sounds good and interesting. However, I'd be
hesitant to implement a default behaviour (which we'd then have to support for
quite a while) in this PR. There are other valid options, such as matching on a
config key (rather than on a tag's value), which is what the customer driving
this feature is proposing. I do like the way the tags approach can translate to
jclouds-byon, where the tags are on the VMs themselves.
How about we take it to the dev list to discuss what we'd want to support
as "native" yaml.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
