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

See -- [...truncated 8.19 MB...] [JENKINS] Archiving to

Re: Proposal: Add appId optional paramater to deploy api

The core `id` is a low-level part of `BrooklynObject` used by all adjuncts and entities and persistence. It feels wrong and risky making this something that is user- or client- settable. I gave one example but there are others. What's wrong with a new config key or reusing `camp.id`? We

Re: Proposal: Add appId optional paramater to deploy api

Hi Alex, Other things get a lot simpler for us if we can just supply the app-id (e.g. subsequently searching for the app, or ensuring that a duplicate app is not deployed). It also means we're not adding another concept that we need to explain to users. To me, that simplicity is very

Re: Proposal: Add appId optional paramater to deploy api

2 feels compelling to me. I want us to have the ability easily to change the ID generation eg to conform with external reqs such as timestamp or source. Go with deploymentUid or similar? Or camp.id? Best Alex On 26 Jul 2017 15:00, "Aled Sage" wrote: Hi Mark, We removed

Re: Proposal: Add appId optional paramater to deploy api

Hi Mark, We removed from EntitySpec the ability to set the id for two reasons: 1. there was no use-case at that time; simplifying the code by deleting it was therefore sensible - we'd deprecated it for several releases. 2. allowing all uids to be generated/managed internally is simpler to

Re: Proposal: Add appId optional paramater to deploy api

Thanks Geoff for the good summary IMO the path of least resistance that provides the best / most predictable behaviour is allowing clients to optionally set the app id. Off the top of my head I cant see this causing any issue, as long as we sanitise the supplied id something like

Re: Proposal: Add appId optional paramater to deploy api

Thanks all for the advice. I think Geoff's email summarises the issue nicely. I like Alex's suggestion but agree that limiting ourselves to deploy in the first is probably significantly easier. Personally I don't feel comfortable with using a tag for idempotency and I do like Aled's suggestion

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

See

Re: Proposal: Add appId optional paramater to deploy api

If I understand correctly this isn't quite what Duncan/Aled are asking for though? Which is not a "request id" but an idempotency token for an application. It would need to work long term, not just cached for a short time, and it would need to work across e.g. HA failover, so it wouldn't be just a

Re: Proposal: Add appId optional paramater to deploy api

// apologies this ended up so long! Hi Alex, Svet, all, Interesting suggestion by Alex - sounds useful. However, even with that it would require implementing a big chunk of logic in the upstream system. I keep coming back to thinking that `appId=...` gives the simplest semantics for such

Build failed in Jenkins: brooklyn-server-master #683

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on cassandra13 (cassandra ubuntu) in workspace

[GitHub] brooklyn-server pull request #780: Removes all logging of vault responses

Github user asfgit closed the pull request at: https://github.com/apache/brooklyn-server/pull/780 --- 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

[GitHub] brooklyn-server pull request #779: Exclude Vault headers trace log

Github user bostko closed the pull request at: https://github.com/apache/brooklyn-server/pull/779 --- 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

[GitHub] brooklyn-server issue #779: Exclude Vault headers trace log

Github user bostko commented on the issue: https://github.com/apache/brooklyn-server/pull/779 Closing in favor of #780 --- 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

[GitHub] brooklyn-server issue #780: Removes all logging of vault responses

Github user bostko commented on the issue: https://github.com/apache/brooklyn-server/pull/780 LGTM. --- 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

[GitHub] brooklyn-server pull request #780: Removes all logging of vault responses

GitHub user m4rkmckenna opened a pull request: https://github.com/apache/brooklyn-server/pull/780 Removes all logging of vault responses Previously body & headers were logged now only the URI and status code is logged (builds upon #774 ) You can merge this pull request

[GitHub] brooklyn-server pull request #779: Exclude Vault headers trace log

GitHub user bostko opened a pull request: https://github.com/apache/brooklyn-server/pull/779 Exclude Vault headers trace log You can merge this pull request into a Git repository by running: $ git pull https://github.com/bostko/brooklyn-server exclude-headers Alternatively

Re: Proposal: Add appId optional paramater to deploy api

I think both proposals make sense. Even if implemented separately. Wondering what's the right place to put the ID though. Isn't the tags a better place for that? I suppose it depends on whether we want YAML blueprints to have access to it. Svet. > On 25.07.2017 г., at 21:56, Alex Heneveld