You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@brooklyn.apache.org by aledsage <gi...@git.apache.org> on 2015/06/26 16:52:38 UTC

[GitHub] incubator-brooklyn pull request: Feature: byon customization

GitHub user aledsage opened a pull request:

    https://github.com/apache/incubator-brooklyn/pull/721

    Feature: byon customization

    Allows a BYON location to have more complex configuration (e.g. each machine having its own separate map of config), including in YAML.
    
    Also supports a MACHINE_CHOOSER config. This can be used to customize the choice of which available machine should be returned, when obtain() is called.
    
    The motivation is to make BYON more useful for multi-VM deployments, where you want to pick particular machines for particular software components.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/aledsage/incubator-brooklyn feature/byon-customization

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-brooklyn/pull/721.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #721
    
----
commit 7b866a9ecf5aa87798c9130ade2e865a35545d88
Author: Aled Sage <al...@gmail.com>
Date:   2015-06-26T13:36:18Z

    Adds PRIVATE_ADDRESSES config to SshMachineLocation
    
    - and same to WinRmMachineLocation

commit 09f3cc87afcf99772bf6597dc4bb2f77ed10660d
Author: Aled Sage <al...@gmail.com>
Date:   2015-06-26T13:44:57Z

    Cleanup ByonLocationResolverTest

commit 64adbb7f3b5198f2f79a13890597f0561ec0637e
Author: Aled Sage <al...@gmail.com>
Date:   2015-06-26T13:45:54Z

    Adds MACHINE_CHOOSER to FixedListMachineProvisioningLocation
        
    Allows a function to be supplied, to choose from the set of available
    machines when obtain() is called.

commit 0be24f935ef417fa9ca280e4055da8aa44f2881a
Author: Aled Sage <al...@gmail.com>
Date:   2015-06-26T13:46:31Z

    ByonLocationResolver: support complex machine config
    
    Adds support for each machine in BYON having more complex config,
    such as each having its own set of config options (where each machine
    has a map of config values).

commit a310b296afb150e5ccb85bd1d56684fd651df4ba
Author: Aled Sage <al...@gmail.com>
Date:   2015-06-26T13:47:02Z

    Fix SoftwareProcessEntityTest.MyService
    
    - Set the SERVICE_STATE_ACTUAL, rather than leaving the attribute
      always saying Lifecycle.CREATED

commit 5c07519d516349d979486b502ea02ecc974fac9d
Author: Aled Sage <al...@gmail.com>
Date:   2015-06-26T13:49:02Z

    BrooklynYamlLocationResolver: don’t swallow exception
    
    Previously inresolveLocation() we were just getting the “collapseText” 
    of the exception in the thrown toString, rather than having the 
    cause set. This meant that the underlying cause (e.g. of an NPE etc)
    was never being logged.
    
    Instead, set the cause when throwing the the IllegalStateException, 
    as well as having the nice toString.

----


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-brooklyn pull request: Feature: byon customization

Posted by ahgittin <gi...@git.apache.org>.

Github user ahgittin commented on the pull request:

    https://github.com/apache/incubator-brooklyn/pull/721#issuecomment-116590922
  
    @aledsage Do we want to add any documentation for this?
    
    And it looks like any attempt to use `MachineChooser` is going to require writing java, is that right?  Is there a way we could encourage YAML for this instead?  We could define `tags` as config on BYON and then if `MACHINE_CHOOSER` is a map with no type the default instance will expect a `requiredTags` string or list.  (This could also allow us to define a "FYON" -- find your own nodes -- where we point it at all cloud instances with some tags, and it imports other tags which we can use to give specific machines to specific roles.)


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-brooklyn pull request: Feature: byon customization

Posted by aledsage <gi...@git.apache.org>.

Github user aledsage commented on the pull request:

    https://github.com/apache/incubator-brooklyn/pull/721#issuecomment-118083628
  
    Merging now, into 0.8.0-SNAPSHOT. We can revisit this, to make it more easily used by yaml. We can change the Java interface for this if required.


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-brooklyn pull request: Feature: byon customization

Posted by asfgit <gi...@git.apache.org>.

Github user asfgit closed the pull request at:

    https://github.com/apache/incubator-brooklyn/pull/721


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-brooklyn pull request: Feature: byon customization

Posted by hzbarcea <gi...@git.apache.org>.

Github user hzbarcea commented on the pull request:

    https://github.com/apache/incubator-brooklyn/pull/721#issuecomment-116382204
  
    +1 good to go


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-brooklyn pull request: Feature: byon customization

Posted by aledsage <gi...@git.apache.org>.

Github user aledsage commented on the pull request:

    https://github.com/apache/incubator-brooklyn/pull/721#issuecomment-118083482
  
    I've added docs to `docs/guide/ops/locations/index.md`.


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-brooklyn pull request: Feature: byon customization

Posted by aledsage <gi...@git.apache.org>.

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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---