Jenkins build is back to normal : brooklyn-master-build #889

[Apache Jenkins Server]

See 

Build failed in Jenkins: brooklyn-master-build #888

[Apache Jenkins Server]

See 

--
[...truncated 7.54 MB...]
Compressed 119.90 MB of artifacts by 36.5% relative to #887
[JENKINS] Archiving 

 to 
org.apache.brooklyn.camp/camp-base/0.11.0-SNAPSHOT/camp-base-0.11.0-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.brooklyn.camp/camp-base/0.11.0-SNAPSHOT/camp-base-0.11.0-SNAPSHOT.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn.camp/camp-base/0.11.0-SNAPSHOT/camp-base-0.11.0-SNAPSHOT-tests.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn.camp/camp-base/0.11.0-SNAPSHOT/camp-base-0.11.0-SNAPSHOT-sources.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn.camp/camp-base/0.11.0-SNAPSHOT/camp-base-0.11.0-SNAPSHOT-test-sources.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-camp/0.11.0-SNAPSHOT/brooklyn-camp-0.11.0-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-camp/0.11.0-SNAPSHOT/brooklyn-camp-0.11.0-SNAPSHOT.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-camp/0.11.0-SNAPSHOT/brooklyn-camp-0.11.0-SNAPSHOT-tests.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-camp/0.11.0-SNAPSHOT/brooklyn-camp-0.11.0-SNAPSHOT-sources.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-camp/0.11.0-SNAPSHOT/brooklyn-camp-0.11.0-SNAPSHOT-test-sources.jar
Compressed 1.02 MB of artifacts by 24.5% relative to #887
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-karaf-jetty-config/0.11.0-SNAPSHOT/brooklyn-karaf-jetty-config-0.11.0-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-karaf-jetty-config/0.11.0-SNAPSHOT/brooklyn-karaf-jetty-config-0.11.0-SNAPSHOT.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-library/0.11.0-SNAPSHOT/brooklyn-library-0.11.0-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.brooklyn.example/brooklyn-example-hello-world-webapp/0.11.0-SNAPSHOT/brooklyn-example-hello-world-webapp-0.11.0-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.brooklyn.example/brooklyn-example-hello-world-webapp/0.11.0-SNAPSHOT/brooklyn-example-hello-world-webapp-0.11.0-SNAPSHOT.war
[JENKINS] Archiving 

 to 
org.apache.brooklyn.example/brooklyn-example-hello-world-webapp/0.11.0-SNAPSHOT/brooklyn-example-hello-world-webapp-0.11.0-SNAPSHOT-sources.jar
[JENKINS] Archiving 

 to 
org.apache.brooklyn.example/brooklyn-example-hello-world-webapp/0.11.0-SNAPSHOT/brooklyn-example-hello-world-webapp-0.11.0-SNAPSHOT-test-sources.jar
Compressed 785.32 KB of artifacts by 93.7% relative to #887
[JENKINS] Archiving 

 to 
org.apache.brooklyn/brooklyn-test-support/0.11.0-SNAPSHOT/brooklyn-test-support-0.11.0-SNAPSHOT.pom
[JENKINS] Archiving 

How to express aggregator in yaml

[Graham Ashby]

OK, I've got this problem:
I have a list of hosts_ports that I've created in a cluster using an 
Aggregator.  So far so good.. .By using attributeWhenReady, it fills in 
when all the values are ready.
Now in another part of my application, I want to use this in a template.
The thing is, I want to wait until all the elements in the list are not 
null before I do the template.install.
I've got a resources.install.latch, which seems to be the right latch to 
use.  However, it needs a boolean

So my question is:  How can I write an Aggregator in yaml that will only 
be true if all the elements of the list are not null? 
 I'm sure it's possible, and I could do it if I was writing Java.  But 
there isn't a lot of documentation on how to do this.

Thanks
Graham Ashby
graham.as...@ca.ibm.com

[GitHub] brooklyn-ui issue #36: Updated logout step to work in karaf mode

[bostko]

Github user bostko commented on the issue:

https://github.com/apache/brooklyn-ui/pull/36
  
@sjcorbett thanks for the notes!
I added in apache/brooklyn-server#578 an `unauthorize` call which seems to 
solve the issues in classic mode.
Could you check both PRs again,
Thanks!


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

[GitHub] brooklyn-server issue #573: Do not runtime-inherit catalog item

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/573
  
@neykov correct.  I will add this as a failing test and suggest that this 
PR:

https://github.com/apache/brooklyn-server/pull/338

seek to confirm that the test passes.

(marking this WIP until i fix)


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

[GitHub] brooklyn-server pull request #571: Better error reporting

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-server/pull/571


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

[GitHub] brooklyn-server issue #571: Better error reporting

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/571
  
Tests pass -- merging.  If `badRequest` is too bad we can improve that 
subsequently.  As noted we use `badRequest` already if `launch` fails when we 
know it's YAML; if it fails in auto-detect mode we should probably throw the 
same.  Not giving an error equates to 500 server error which is probably wrong; 
chances are launch fails either because we couldn't parse or the synchronous 
launch steps are invalid, which unless the provided yaml references something 
that is broken, is going to be because the supplied yaml itself is broken IE 
**bad request**.




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

[jira] [Commented] (BROOKLYN-323) Inconsistent logout behavior for Basic Authentication

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894631#comment-15894631
 ] 

ASF GitHub Bot commented on BROOKLYN-323:
-

Github user bostko commented on the issue:

https://github.com/apache/brooklyn-server/pull/578
  
This PR is not dependent brooklyn-ui#36.


> Inconsistent logout behavior for Basic Authentication
> -
>
> Key: BROOKLYN-323
> URL: https://issues.apache.org/jira/browse/BROOKLYN-323
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0, 0.10.0, 0.9.1
> Environment: Firefox, Internet Explorer, Google Chrome
>Reporter: Valentin Aitken
> Fix For: 0.10.0
>
>
> Observed behavior:
> When clicking logout browser asks for a password.
> When entering a password browser asks you sequentially to enter username and 
> password.
> How logout should be implemented for Basic Authentication:
> http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
> My explanation for behavior with the current code:
> First to clear out how brooklyn-ui is working and what it does.
> It polls infinitely the brooklyn api to retrieve status for the applications 
> which are on the dashboard.
> To do that each request has to be authenticated.
> Logout:
> When user click logout, UI fires an ajax call to get a a proper Unauthorized 
> response.
> Current response for the logout request contains Unauthorized response which 
> should invalidate credentials.
> For Google Chrome it does invalidate the request credentials but it does not 
> reload the DOM (or the webpage)
> When user try to type username and password to login back again, it is 
> followed by another username and password prompt. 
> My explanation for this is that login actually appeared from one of the 
> application status calls rather than the index page and credentials are not 
> populated through the DOM.
> Because of this credentials have to be typed for every single request and  UI 
> is making status calls infinitely so in other words user have to enter 
> username and password infinitely.
> However for Internet Explorer it behaves differently.
> It just unauthenticate the one Ajax request and from there nothing happens. 
> Deletion of the session within Internet Explorer doesn't happen and browser 
> stays authenticated.
> My idea for solving those problems is to do a full reload of the web page 
> after deauthenticating.
> so Brooklyn can have only one javascript authentication cycle.
> I will provide a solution which does that in one simple step.
> Calling the /logout API call which returns Unauthorized response and redirect 
> to the home page. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] brooklyn-server issue #578: BROOKLYN-323: Use proper WWW-Authorization heade...

[bostko]

Github user bostko commented on the issue:

https://github.com/apache/brooklyn-server/pull/578
  
This PR is not dependent brooklyn-ui#36.


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

Jenkins build is back to normal : brooklyn-server-master #475

[Apache Jenkins Server]

See 

[GitHub] brooklyn-server pull request #564: Winrm CmdFeed

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-server/pull/564


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

[GitHub] brooklyn-server issue #564: Winrm CmdFeed

[geomacy]

Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/564
  
LGTM, most renamings addressed and @neykov was happy to leave them as-is 
anyway. Will merge.


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

[jira] [Commented] (BROOKLYN-323) Inconsistent logout behavior for Basic Authentication

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894202#comment-15894202
 ] 

ASF GitHub Bot commented on BROOKLYN-323:
-

Github user sjcorbett commented on the issue:

https://github.com/apache/brooklyn-server/pull/578
  
I'll leave this while brooklyn-ui#36 is still open.


> Inconsistent logout behavior for Basic Authentication
> -
>
> Key: BROOKLYN-323
> URL: https://issues.apache.org/jira/browse/BROOKLYN-323
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0, 0.10.0, 0.9.1
> Environment: Firefox, Internet Explorer, Google Chrome
>Reporter: Valentin Aitken
> Fix For: 0.10.0
>
>
> Observed behavior:
> When clicking logout browser asks for a password.
> When entering a password browser asks you sequentially to enter username and 
> password.
> How logout should be implemented for Basic Authentication:
> http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
> My explanation for behavior with the current code:
> First to clear out how brooklyn-ui is working and what it does.
> It polls infinitely the brooklyn api to retrieve status for the applications 
> which are on the dashboard.
> To do that each request has to be authenticated.
> Logout:
> When user click logout, UI fires an ajax call to get a a proper Unauthorized 
> response.
> Current response for the logout request contains Unauthorized response which 
> should invalidate credentials.
> For Google Chrome it does invalidate the request credentials but it does not 
> reload the DOM (or the webpage)
> When user try to type username and password to login back again, it is 
> followed by another username and password prompt. 
> My explanation for this is that login actually appeared from one of the 
> application status calls rather than the index page and credentials are not 
> populated through the DOM.
> Because of this credentials have to be typed for every single request and  UI 
> is making status calls infinitely so in other words user have to enter 
> username and password infinitely.
> However for Internet Explorer it behaves differently.
> It just unauthenticate the one Ajax request and from there nothing happens. 
> Deletion of the session within Internet Explorer doesn't happen and browser 
> stays authenticated.
> My idea for solving those problems is to do a full reload of the web page 
> after deauthenticating.
> so Brooklyn can have only one javascript authentication cycle.
> I will provide a solution which does that in one simple step.
> Calling the /logout API call which returns Unauthorized response and redirect 
> to the home page. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] brooklyn-server issue #578: BROOKLYN-323: Use proper WWW-Authorization heade...

[sjcorbett]

Github user sjcorbett commented on the issue:

https://github.com/apache/brooklyn-server/pull/578
  
I'll leave this while brooklyn-ui#36 is still open.


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

[GitHub] brooklyn-ui issue #36: Updated logout step to work in karaf mode

[sjcorbett]

Github user sjcorbett commented on the issue:

https://github.com/apache/brooklyn-ui/pull/36
  
@bostko Looks like this negatively impacts logging out of the non-Karaf 
distribution. After logging out I've found that:
* master non-karaf: prompts for re-authentication.
* master karaf: 405 error `POST is not supported by this URL`
* this pr karaf: displays page with "login" in big text. Clicking it 
prompts for re-authentication.
* this pr non-karaf: displays page with "login" in big text. Clicking it 
logs the user back in without requiring re-authentication.

We should prompt the user to re-authenticate in the standard distribution.


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

[jira] [Commented] (BROOKLYN-323) Inconsistent logout behavior for Basic Authentication

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/BROOKLYN-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894138#comment-15894138
 ] 

ASF GitHub Bot commented on BROOKLYN-323:
-

Github user sjcorbett commented on the issue:

https://github.com/apache/brooklyn-server/pull/578
  
@bostko looks good. Will test and merge if ok.


> Inconsistent logout behavior for Basic Authentication
> -
>
> Key: BROOKLYN-323
> URL: https://issues.apache.org/jira/browse/BROOKLYN-323
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0, 0.10.0, 0.9.1
> Environment: Firefox, Internet Explorer, Google Chrome
>Reporter: Valentin Aitken
> Fix For: 0.10.0
>
>
> Observed behavior:
> When clicking logout browser asks for a password.
> When entering a password browser asks you sequentially to enter username and 
> password.
> How logout should be implemented for Basic Authentication:
> http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication
> My explanation for behavior with the current code:
> First to clear out how brooklyn-ui is working and what it does.
> It polls infinitely the brooklyn api to retrieve status for the applications 
> which are on the dashboard.
> To do that each request has to be authenticated.
> Logout:
> When user click logout, UI fires an ajax call to get a a proper Unauthorized 
> response.
> Current response for the logout request contains Unauthorized response which 
> should invalidate credentials.
> For Google Chrome it does invalidate the request credentials but it does not 
> reload the DOM (or the webpage)
> When user try to type username and password to login back again, it is 
> followed by another username and password prompt. 
> My explanation for this is that login actually appeared from one of the 
> application status calls rather than the index page and credentials are not 
> populated through the DOM.
> Because of this credentials have to be typed for every single request and  UI 
> is making status calls infinitely so in other words user have to enter 
> username and password infinitely.
> However for Internet Explorer it behaves differently.
> It just unauthenticate the one Ajax request and from there nothing happens. 
> Deletion of the session within Internet Explorer doesn't happen and browser 
> stays authenticated.
> My idea for solving those problems is to do a full reload of the web page 
> after deauthenticating.
> so Brooklyn can have only one javascript authentication cycle.
> I will provide a solution which does that in one simple step.
> Calling the /logout API call which returns Unauthorized response and redirect 
> to the home page. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] brooklyn-server issue #564: Winrm CmdFeed

[nakomis]

Github user nakomis commented on the issue:

https://github.com/apache/brooklyn-server/pull/564
  
@neykov It looks like @bostko has addressed the bulk of the issues. Are you 
happy to merge this now?


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

[GitHub] brooklyn-server issue #578: BROOKLYN-323: Use proper WWW-Authorization heade...

[sjcorbett]

Github user sjcorbett commented on the issue:

https://github.com/apache/brooklyn-server/pull/578
  
@bostko looks good. Will test and merge if ok.


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

[GitHub] brooklyn-ui issue #36: Updated logout step to work in karaf mode

[sjcorbett]

Github user sjcorbett commented on the issue:

https://github.com/apache/brooklyn-ui/pull/36
  
@bostko looks good. Will test and merge if ok.


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

Re: Uploading ZIPs for a better dev workflow

[Geoff Macartney]

It also means clients ('br' at least) can easily validate the upload even
before execution by checking that all the manifest details are present.

On Fri, 3 Mar 2017 at 09:57 Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:

> Just on the last point of "We could also support the example below", I'd
> say let's not even be that flexible - my feeling is that the more flexible
> we are, the more confusing it is, and the harder to get right.  If we're
> going to add this capability let's just have one way to do it; if you are
> going to do a ZIP upload, you MUST have a catalog.bom, which MUST contain a
> manifest section, which MUST have both a symbolic name and a version.  That
> way everything's explicit and very clear, every time.
>
>
>
> On Thu, 2 Mar 2017 at 11:45 Aled Sage  wrote:
>
> Geoff, all,
>
> I was imagining the manifest version (in the catalog.bom) to be separate
> from the item version. The reason is that we support multiple items in
> the bom that can be independently versioned.
>
> Somone perverted could write:
>
> brooklyn.catalog:
>version: 1.0
>manifest:
>  symbolic_name: com.example.Foo
>  version: 2.0
>items:
>- id: foo
>  version: 3.0
>  itemType: entity
>  item:
>type: blah
>- id: bar
>  version: 4.0
>  itemType: entity
>  item:
> type: blah.blah
>
> Here, the "1.0" version is not used by anything; the auto-generated OSGi
> bundle would be version 2.0; catalog item foo would be 3.0; and catalog
> item bar would be 4.0.
>
> If we were starting from scratch, I'd be tempted to lock things down a
> lot more for what we actually support. For now, it feels like asking for
> an explicit version is a reasonable thing to do.
>
> ---
> We could also support the example below, where "1.0" is used by both the
> manifest and the item:
>
> brooklyn.catalog:
>version: 1.0
>manifest:
>  symbolic_name: com.example.Foo
>items:
>- id: foo
>  itemType: entity
>  item:
>type: blah
>
> The general rule would be: if there is a version in the manifest
> section, that will be used; if not then a top-level version number will
> be used. If that is also missing, then fail.
>
> i.e. we would not accept:
>
> # Fails - manifest has no version.
> brooklyn.catalog:
>manifest:
>  symbolic_name: com.example.Foo
>items:
>- id: foo
>  version: 1.0
>  itemType: entity
>  item:
>type: blah
>
> Thoughts?
>
> Aled
>
>
> On 02/03/2017 10:02, Geoff Macartney wrote:
> > I take Alex's point about the manifest being Java specific, and I agree
> > therefore we shouldn't insist on it.
> >
> > +1 also to preferring explicit name/version in the catalog.bom rather
> than
> > as API params, I agree we do
> > need to keep the version in source control.
> >
> > Question on your straw man, does the 'version' below
> >
> >  brooklyn.catalog:
> > manifest:
> >   symbolic_name: com.example.Foo
> >   version: 1.0.0-SNAPSHOT
> > items:
> >
> > _replace_ the 'version' in existing catalogs
> >
> > brooklyn.catalog:
> >  version: "0.1.0-SNAPSHOT"
> >
> > or is it an independently variable value, i.e. the version of the bundle,
> > separate from the version of catalog items that it happens to contain?
> > (Sounds a bit disquieting, but I guess it's possible).
> >
> > e.g. could you have
> >
> > brooklyn.catalog:
> >version: 0.11.0-SNAPSHOT
> >manifest:
> >  symbolic_name: com.example.Foo
> >  version: 1.0.0-SNAPSHOT
> >items:
> >- id: foo
> >  type: xyz
> >
> > which would be bundle com.example.Foo:1.0.0-SNAPSHOT, which happens to
> > contain item foo:0.11.0-SNAPSHOT?
> >
> > If so, what would happen if you left out the second line above? What
> > version of 'foo' would the catalog contain?
> >
> > Or does the version within the manifest _mean_ that it is not only the
> > bundle version you are specifying, but the catalog item versions too? (I
> > guess unless the item explicitly supplies its own version.)
> >
> > Geoff
> >
> >
> >
> >
> > On Wed, 1 Mar 2017 at 17:26 Aled Sage  wrote:
> >
> > Hi all,
> >
> > Discussion of the REST api kicked off again in
> >
> https://github.com/apache/brooklyn-server/pull/485#issuecomment-283280366:
> >
> >  Alex wrote:
> >
> >  Requiring a MANIFEST.MF makes the input strongly java-centric; I'd
> >  like to appeal to people who write YAML blueprints with co-bundled
> >  scripts and images. They'd wonder why they can't simply make and
> >  upload a ZIP. They could probably be persuaded to supply a name and
> >  optional version on a CLI or UI, and understand why it is needed
> >  (hence supporting those args) but it would not be idiomatic to
> >  anyone but a java programmer to create a 

Re: Uploading ZIPs for a better dev workflow

[Geoff Macartney]

Just on the last point of "We could also support the example below", I'd
say let's not even be that flexible - my feeling is that the more flexible
we are, the more confusing it is, and the harder to get right.  If we're
going to add this capability let's just have one way to do it; if you are
going to do a ZIP upload, you MUST have a catalog.bom, which MUST contain a
manifest section, which MUST have both a symbolic name and a version.  That
way everything's explicit and very clear, every time.



On Thu, 2 Mar 2017 at 11:45 Aled Sage  wrote:

> Geoff, all,
>
> I was imagining the manifest version (in the catalog.bom) to be separate
> from the item version. The reason is that we support multiple items in
> the bom that can be independently versioned.
>
> Somone perverted could write:
>
> brooklyn.catalog:
>version: 1.0
>manifest:
>  symbolic_name: com.example.Foo
>  version: 2.0
>items:
>- id: foo
>  version: 3.0
>  itemType: entity
>  item:
>type: blah
>- id: bar
>  version: 4.0
>  itemType: entity
>  item:
> type: blah.blah
>
> Here, the "1.0" version is not used by anything; the auto-generated OSGi
> bundle would be version 2.0; catalog item foo would be 3.0; and catalog
> item bar would be 4.0.
>
> If we were starting from scratch, I'd be tempted to lock things down a
> lot more for what we actually support. For now, it feels like asking for
> an explicit version is a reasonable thing to do.
>
> ---
> We could also support the example below, where "1.0" is used by both the
> manifest and the item:
>
> brooklyn.catalog:
>version: 1.0
>manifest:
>  symbolic_name: com.example.Foo
>items:
>- id: foo
>  itemType: entity
>  item:
>type: blah
>
> The general rule would be: if there is a version in the manifest
> section, that will be used; if not then a top-level version number will
> be used. If that is also missing, then fail.
>
> i.e. we would not accept:
>
> # Fails - manifest has no version.
> brooklyn.catalog:
>manifest:
>  symbolic_name: com.example.Foo
>items:
>- id: foo
>  version: 1.0
>  itemType: entity
>  item:
>type: blah
>
> Thoughts?
>
> Aled
>
>
> On 02/03/2017 10:02, Geoff Macartney wrote:
> > I take Alex's point about the manifest being Java specific, and I agree
> > therefore we shouldn't insist on it.
> >
> > +1 also to preferring explicit name/version in the catalog.bom rather
> than
> > as API params, I agree we do
> > need to keep the version in source control.
> >
> > Question on your straw man, does the 'version' below
> >
> >  brooklyn.catalog:
> > manifest:
> >   symbolic_name: com.example.Foo
> >   version: 1.0.0-SNAPSHOT
> > items:
> >
> > _replace_ the 'version' in existing catalogs
> >
> > brooklyn.catalog:
> >  version: "0.1.0-SNAPSHOT"
> >
> > or is it an independently variable value, i.e. the version of the bundle,
> > separate from the version of catalog items that it happens to contain?
> > (Sounds a bit disquieting, but I guess it's possible).
> >
> > e.g. could you have
> >
> > brooklyn.catalog:
> >version: 0.11.0-SNAPSHOT
> >manifest:
> >  symbolic_name: com.example.Foo
> >  version: 1.0.0-SNAPSHOT
> >items:
> >- id: foo
> >  type: xyz
> >
> > which would be bundle com.example.Foo:1.0.0-SNAPSHOT, which happens to
> > contain item foo:0.11.0-SNAPSHOT?
> >
> > If so, what would happen if you left out the second line above? What
> > version of 'foo' would the catalog contain?
> >
> > Or does the version within the manifest _mean_ that it is not only the
> > bundle version you are specifying, but the catalog item versions too? (I
> > guess unless the item explicitly supplies its own version.)
> >
> > Geoff
> >
> >
> >
> >
> > On Wed, 1 Mar 2017 at 17:26 Aled Sage  wrote:
> >
> > Hi all,
> >
> > Discussion of the REST api kicked off again in
> >
> https://github.com/apache/brooklyn-server/pull/485#issuecomment-283280366:
> >
> >  Alex wrote:
> >
> >  Requiring a MANIFEST.MF makes the input strongly java-centric; I'd
> >  like to appeal to people who write YAML blueprints with co-bundled
> >  scripts and images. They'd wonder why they can't simply make and
> >  upload a ZIP. They could probably be persuaded to supply a name and
> >  optional version on a CLI or UI, and understand why it is needed
> >  (hence supporting those args) but it would not be idiomatic to
> >  anyone but a java programmer to create a META-INF/ dir with a
> >  MANIFEST.MF and its syntax. Meanwhile it is very easy for us to
> >  convert the ZIP to a JAR on the server. Feels like uncontroversial
> >  good UX.
> >
> >  OTOH for a java programmer a MANIFEST.MF is natural, and 

Re: [PROPOSAL/DISCUSSION] yaml DSL for invoking effectors

[Geoff Macartney]

hi Aled,

taking your points in reverse order:

4.  I agree I can't see a good use case. If it's just doing a lookup with
no side effects that would surely be more easily done by reading a sensor,
not invoking an effector.
3.  It seems that the ability to invoke side effects is the main reason you
would want to be able to invoke an effector; you're making the entity _do_
something, maybe with a result; this suggests that...
2. ...you would actually want to re-invoke the effector each time you read
the config. But that sounds risky. In the CA server type example you
probably wouldn't want to do this - you don't want to get a fresh public
certificate each time you invoke the "sign-CSR" effector, rather it's
something you do once when you initialise the entity that needs a
certificate. I think the problem is that ...
1.  ...we don't have a clear idea of the use-cases we would need to
support; I think there are likely several possible use-cases here, but that
they are likely to have slightly different requirements, especially around
point 2.

Would it be too conservative to suggest that we don't do any more on this
until we do have a clear and compelling use-case in mind, when it will be
(I hope) a lot easier to see what way it should be done? As you say the key
question is "_should_ we support..." and until we can clearly see "ah yes,
we need that now, in order to do XYZ" maybe we shouldn't add it in the hope
that it might be useful.

I'd be keen to hear what @grkvlt thinks on this now, - Andrew?

Geoff




On Thu, 2 Mar 2017 at 11:59 Aled Sage  wrote:

> Hi Geoff,
>
> I think long-term you're example would be covered by "Defining an
> Effector as a Sequence of Tasks". That topic needs a lot more
> (separate!) discussion, but in brief the idea is that an effector
> definition is a first-class concept in the yaml (rather than using
> "entity.initializers"); there would be yaml-support for defining a
> sequence of tasks (e.g. execute some bash, do a http call, make an
> effector call, etc). The yaml for "make an effector call" might end up
> looking similar to this DSL discussion, but the context in which it
> would be used is very different.
>
> ---
> I think the key question for this discussion is: should we support
> effector-invocation via the DSL *for config values*?
>
> If so:
>
>  1. What use-case(s) are we trying to support?
>  2. Should the effector be executed every time the config value is
> retrieved, or only once (and the result stored for subsequent lookups)?
>  3. Should it be relied upon for side-effects (e.g. the CA certificate
> request example etc)?
>  4. Or should it only be used for effectors that are getters/lookups?
>
> For (3), I now lean towards the use of the EntityInitializer (and longer
> term the "sequence of tasks" approach).
>
> For (4), I'm not sure what a good use-case is (e.g. why can't we set a
> sensor with that value, which might require extending the "source"
> entity to add an additional "sensor feed" that retrieves the value for us).
>
> For (2), I'm not sure what is most intuitive to users who are
> reading/writing the blueprint yaml. It could be argued either way, which
> suggests different users will expect different things! Therefore I'd
> want to avoid relying on side-effects that you only want to happen once!
>
> Aled
>
>
> On 02/03/2017 10:30, Geoff Macartney wrote:
> > I don't think we should just be thinking about a use-case like the CA
> > server, which is maybe more limited in behaviour than the more general
> idea
> > here of being able to call effectors.
> >
> > In particular, what if you wanted to embed the effector invocation on
> some
> > entity within the code for an effector of your own entity?   i.e. you
> have
> > an effector on entity A that does some stuff when invoked, including
> > invoking an effector on entity B?  (And maybe using the result when
> > calculating its own result instead of storing it in a sensor).
> >
> > Is that something we'd want to support?Is it a "stage 2" thing we
> would
> > add later on, some time after implementing the EntityInitializer
> approach?
> >
> > G
> >
> > On Wed, 1 Mar 2017 at 12:32 Alex Heneveld <
> alex.henev...@cloudsoftcorp.com>
> > wrote:
> >
> > An `EntityInitializer` for this purpose is a nice alternative pattern --
> > better than the child entity I suggested at #155 -- until we have
> sequence
> > effector YAML.  Is there anything `$brooklyn:effector` gives us that an
> > initializer wouldn't do in a cleaner way?
> >
> > Best
> > Alex
> >
> >
> > On 1 March 2017 at 11:54, Aled Sage  wrote:
> >
> >> Hi all,
> >>
> >> I'd like to resurrect the discussion of whether the yaml DSL should
> >> support invoking effectors.
> >>
> >> See https://github.com/apache/brooklyn-server/pull/155. (That was
> merged,
> >> but Alex will revert it while we discuss if we want it, and if so then
> how
> >> it would behave).
> >>
> >> If folk have additional use-cases and 

[GitHub] brooklyn-server pull request #571: Better error reporting

[ahgittin]

Github user ahgittin commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/571#discussion_r104112617
  
--- Diff: 
rest/rest-resources/src/main/java/org/apache/brooklyn/rest/resources/ApplicationResource.java
 ---
@@ -374,7 +378,13 @@ public Response createPoly(byte[] 
inputToAutodetectType) {
 
 
 if (spec != null) {
-return launch(potentialYaml, spec);
+try {
+return launch(potentialYaml, spec);
+} catch (Exception e) {
+Exceptions.propagateIfFatal(e);
+log.warn("Failed REST deployment launching "+spec+": "+e);
+throw WebResourceUtils.badRequest(e, "Error launching 
blueprint (autodetecting)");
--- End diff --

This seemed like the best status code to use and it's what we use on line 
294/297.  Do you think there's a better one?  If we do nothing it will give 
Internal Server Error which seems worse?


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

Re: Specifying proxy

[Alex Heneveld]

Hi Mahammad,

Both Apache Brooklyn and jclouds follow the usual Java convention for 
specifying proxy behaviour.  See:


https://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html

Let us know how you get on.  Note you'll need to proxy all TCP 
connections, http(s) and for ssh.


Best
Alex


On 02/03/2017 18:05, Valiyev, Mahammad wrote:

Hello,

I need to specify a proxy for Apache Brooklyn in environment variables 
somewhere to run an application on AWS. I have set the proxies in 
/etc/environment, but this doesn't solve the problem. How can I solve this?

Kind regards,
Mahammad Valiyev