Date   

Re: How to explicitly specify the password for the account admin?

Simon Johansson <simon@...>
 

We have this in our stub.

properties.uaa.scim.users:
- "admin|DESIRED_PASSWORD|scim.write,scim.read.......

Works well.

On Mon, Oct 19, 2015 at 9:52 AM, Jim Lin <jimlintw922(a)gmail.com> wrote:
Hi all

Every time I re-deploy cloud foundry after updating cf-deployment-manifest.yml, the password of the account admin will be reset to the default value, i.e., "admin".

Can I explicitly specify the password for the account admin in the manifest file? What is the property key?

Thanks all.

Sincerely,
Jim


Cloud Foundry being used for an EU social learning games platform

Christopher Frost
 

I stumbled across this and though other people might be interested.
ProSocialLearn is an EU funded project to help children learn positive
social skills through social gaming. Here is a quote from there "System
Requirements and Architecture" document available on there website.

"Continuing up the technology architecture stack, PSL is still exploring a
number of open alternatives for building up a robust PaaS layer. However,
during the editing of this deliverable, the ProSocialLearn consortium is
already beginning to investigate the Cloud Foundry community (almost a de
facto standard for Platform as a Service environments). PSL is planning to
integrate the Cloud Foundry technology into the added value services of
PSL. Cloud Foundry provides a platform that allows game providers and game
operators to deploy, manage and scale cloud-based games quickly, and easily.
"

They have a Git repo where they are working on a NodeJS based client for
the CF API and a Node based CF web console. This work seems to be being
done by one developer from one of the consortium members based in Spain,
Madrid. They have also released a proof of concept game as well but it
doesn't look like they have formally launched yet.

Links.

http://prosociallearn.eu/
https://github.com/prosociallearnEU

Chris.

Christopher Frost - Pivotal UK
Java Buildpack Team


Re: REST API endpoint for accessing application logs

Ponraj E
 

Hi ,

I executed the command with manually putting the outh token -pasting the o/p here:

C:\WINDOWS\system32>curl -k -H "Authorization: bearer xxxx" "https://doppler.xx.xxx.xxxxxxxx:443/apps/e0dc9133-f800-416d-9e1f-ffeb8d02e4dd/recentlogs"
--1f51e48e4a9bf243ed1e2ab55c090c4d2deb23a7ae255c5c1d8ad178acb9


◄dea_logging_agent►♣0│┌üªπ╩áç¶j2z☺1é☺♀10.78.150.44B╜☺
Ç☺Mon, 19 Oct 2015 06:23:56 GMT express deprecated res.send(status, body): Use res.status(status).se
nd(body) instead at app.js:7:7►☻↑╜╜üªπ╩áç¶"$e0dc9133-f800-416d-9e1f-ffeb8d02e4dd*♥App2☺1
--1f51e48e4a9bf243ed1e2ab55c090c4d2deb23a7ae255c5c1d8ad178acb9


router__0►♣0₧π╪á½╩áç¶j
10.78.149.103B╔♥router_z1z☺0é☺
app_url - [19/10/2015:06:23:41 +0000] "GET / HTTP/1.1" 2
00 0 40 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.
2454.101 Safari/537.36" 10.78.148.7:59978 x_forwarded_for:"ip_addr" vcap_request_id:1cbd4f2d-
84c6-4ef9-6f44-e0c84a4d5e49 response_time:0.624678694 app_id:e0dc9133-f800-416d-9e1f-ffeb8d02e4dd
►☺↑└╥╪á½╩áç¶"$e0dc9133-f800-416d-9e1f-ffeb8d02e4dd*♥RTR2☺0
--1f51e48e4a9bf243ed1e2ab55c090c4d2deb23a7ae255c5c1d8ad178acb9


router__0►♣0Ç╩ΩεΓ╩áç¶j
10.78.149.103B╔♥router_z1z☺0é☺
app_url - [19/10/2015:06:23:56 +0000] "GET / HTTP/1.1" 2
00 0 40 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.
2454.101 Safari/537.36" 10.78.148.7:59978 x_forwarded_for:"ip_addr" vcap_request_id:758c85b6-
dfef-41dc-5def-dc76ccf01498 response_time:0.999714512 app_id:e0dc9133-f800-416d-9e1f-ffeb8d02e4dd
►☺↑█╜ΩεΓ╩áç¶"$e0dc9133-f800-416d-9e1f-ffeb8d02e4dd*♥RTR2☺0
--1f51e48e4a9bf243ed1e2ab55c090c4d2deb23a7ae255c5c1d8ad178acb9--


Questions:

1. What is this guid that the command prints multiple times?

--1f51e48e4a9bf243ed1e2ab55c090c4d2deb23a7ae255c5c1d8ad178acb9--

2. Some of the output is garbled and some are not.

3. As rohit said in the previous comment, I tried installing the noaa client library and executed the sample app
to get the application logs : https://github.com/cloudfoundry/noaa

go build -o bin/sample sample/main.go

My DOPPLER_ADDR env is "https://doppler.xx.xxx.xxxxxxxx.xxx:443"

So when i run the sample.exe, I get the o/p as
===== Error getting recent messages: parse "https://doppler.xx.xxx.xxxxxxxx.xxx:443": invalid URI for request

Am not sure, how is this URI invalid?


---
Ponraj


Re: CF-RELEASE v202 UPLOAD ERROR

Bharath
 

Hi partiban

can u do a checksum of the tar file .


it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*

example:

*sha1sum {file}*

regards
Bharath

On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <epoelke(a)gmail.com> wrote:

You actually do not need to download it. if you just run --

`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`

The director will pull in the release directly from bosh.io.


How to explicitly specify the password for the account admin?

Jim Lin <jimlintw922@...>
 

Hi all

Every time I re-deploy cloud foundry after updating cf-deployment-manifest.yml, the password of the account admin will be reset to the default value, i.e., "admin".

Can I explicitly specify the password for the account admin in the manifest file? What is the property key?

Thanks all.

Sincerely,
Jim


Re: CF-RELEASE v202 UPLOAD ERROR

Eric Poelke
 

You actually do not need to download it. if you just run --

`bosh upload release https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`

The director will pull in the release directly from bosh.io.


Re: CF-RELEASE v202 UPLOAD ERROR

Parthiban Annadurai <senjiparthi@...>
 

Thanks for your Clarifications Amit. I have just followed this link
http://bosh.io/releases/github.com/cloudfoundry/cf-release?version=202 to
download the TAR File and am using it for deployments.

Regards

Parthiban A

On 19 October 2015 at 08:49, Amit Gupta <agupta(a)pivotal.io> wrote:

Yes it's stable.

You should try what Eric Poelke suggested, bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202, that way it
won't even try to untar locally.

If you still want to be able to upload a local tarball, can I ask how
exactly did you get or create your tarball for v202?

Best,
Amit

On Sun, Oct 18, 2015 at 8:09 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Yaa thanks for your suggestions. But, I already checked about the Storage
and all it not even touches 2 GB (Out of 15 GB). When i manually try to
Untar the file also throws error. I think problem with the CF v202. Could
anyone tell me is this version stable or not?

Regards

Parthiban A

On 18 October 2015 at 21:24, Eric Poelke <epoelke(a)gmail.com> wrote:

You can avoid the local disk issues by using bosh.io like so --

bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202


Re: CF-RELEASE v202 UPLOAD ERROR

Amit Kumar Gupta
 

Yes it's stable.

You should try what Eric Poelke suggested, bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202, that way it
won't even try to untar locally.

If you still want to be able to upload a local tarball, can I ask how
exactly did you get or create your tarball for v202?

Best,
Amit

On Sun, Oct 18, 2015 at 8:09 PM, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

Yaa thanks for your suggestions. But, I already checked about the Storage
and all it not even touches 2 GB (Out of 15 GB). When i manually try to
Untar the file also throws error. I think problem with the CF v202. Could
anyone tell me is this version stable or not?

Regards

Parthiban A

On 18 October 2015 at 21:24, Eric Poelke <epoelke(a)gmail.com> wrote:

You can avoid the local disk issues by using bosh.io like so --

bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202


Re: CF-RELEASE v202 UPLOAD ERROR

Parthiban Annadurai <senjiparthi@...>
 

Yaa thanks for your suggestions. But, I already checked about the Storage
and all it not even touches 2 GB (Out of 15 GB). When i manually try to
Untar the file also throws error. I think problem with the CF v202. Could
anyone tell me is this version stable or not?

Regards

Parthiban A

On 18 October 2015 at 21:24, Eric Poelke <epoelke(a)gmail.com> wrote:

You can avoid the local disk issues by using bosh.io like so --

bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202


Re: Diego and Maven support

Daniel Mikusa
 

Can you explain what you mean by "stopped working"? Are you getting an error? Can you include output?

The push process hasn't changed, so that should continue to work. I'm not sure you can use the maven client to switch between DEAs and Diego, but you only need to do that once. So you could manually do that and then push with Maven.

Dan

On Oct 18, 2015, at 4:51 PM, Krzysztof Wilk <chris.m.wilk(a)gmail.com> wrote:

Hello,

Until today I have been a happy user of CloudFoundry Maven plugin version 1.1.2:
https://github.com/cloudfoundry/cf-java-client

It worked for me pretty well.

Unfortunately after having migrated my application from PWS to Diego, this plugin stopped working for me.

cf command line client works well, as expected.

Does the Maven plugin support Diego or should I have to wait until its 2.0 relase?

Thanks for replies,

Yours,
Krzysztof


Diego and Maven support

Krzysztof Wilk
 

Hello,

Until today I have been a happy user of CloudFoundry Maven plugin version 1.1.2:
https://github.com/cloudfoundry/cf-java-client

It worked for me pretty well.

Unfortunately after having migrated my application from PWS to Diego, this plugin stopped working for me.

cf command line client works well, as expected.

Does the Maven plugin support Diego or should I have to wait until its 2.0 relase?

Thanks for replies,

Yours,
Krzysztof


Re: CF-RELEASE v202 UPLOAD ERROR

Eric Poelke
 

You can avoid the local disk issues by using bosh.io like so --

bosh upload release https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202


Re: CF-RELEASE v202 UPLOAD ERROR

Stephen Peggs
 

Try using df to watch the local filesystems while the upload is running. If
you bump 100% anywhere you have the culprit. Either fix that, more space or
a link to a filesystems with more space. Or alternatively put the v202
image on a web server and use the url. That way all the processing is done
on the director.

On Sun, 18 Oct 2015 8:07 am Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

Hello John,
Based on your suggestions, I tried to upload from /tmp. Still
it throws the Error. For your Reference I have attached the ScreenShot.
Could you please take a look on that? Thanks.

Regards

Parthiban A

On 12 October 2015 at 09:14, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

John, Thanks for your suggestions. Let me try with /tmp.

Regards

Parthiban A

On 11 October 2015 at 22:59, John Feminella <jfeminella(a)pivotal.io>
wrote:

It looks like you are trying to upload a release from a local file on
your system called /root/tmp/cf-release-202.tgz.

It also looks like you mounted this path at /. However, you appear to
only have 114M available free space here:

/dev/mapper/VolGroup00-LogVol00_root
2.1G 1.9G 114M 95% /

and this logical volume is 95% full. That will not be enough space to
extract the files -- cf-release-202 is ~2 GB compressed so it will take
considerably more space than that to unzip. You may wish to consider
extracting in a location with more free space available (at least 10 GB or
so). Your /tmp mountpoint may be useful, since it looks like that has 16
GiB free.

best,
~ jf

--
*John Feminella*
Advisory Field Engineer
✉ · jfeminella(a)pivotal.io
t · @jxxf <https://twitter.com/jxxf>

On Sun, Oct 11, 2015 at 5:01 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Ronak,
I have checked the Local machine too, it shows the following,

[root(a)opencf microbosh]# df -H
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00_root
2.1G 1.9G 114M 95% /
tmpfs 985M 0 985M 0% /dev/shm
/dev/sda1 102M 74M 24M 77% /boot
/dev/mapper/VolGroup00-LogVol00_home
2.1G 3.3M 2.0G 1% /home
/dev/mapper/VolGroup00-LogVol00_opt
6.3G 13M 5.9G 1% /opt
/dev/mapper/VolGroup00-LogVol00_tmp
16G 2.7M 16G 1% /tmp
/dev/mapper/VolGroup00-LogVol00_usr
6.3G 2.0G 4.0G 34% /usr
/dev/mapper/VolGroup00-LogVol00_var
4.2G 126M 3.9G 4% /var

I think size is fine only. Could you?? Thanks.

Regards

Parthiban A

On 11 October 2015 at 14:15, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Check "df -h" on your local system from where you are uploading the
release.

On Sun, Oct 11, 2015 at 4:44 PM, Parthiban A <senjiparthi(a)gmail.com>
wrote:

Hi All,
When am uploading the Cloud Foundry Release v202 to the
Director, its throwing the following error.

bosh upload release /root/tmp/cf-release-202.tgz
Acting as user 'admin' on 'microbosh'

Verifying release...
File exists and readable OK
Extract tarball FAILED

Release is invalid, please fix, verify and upload again

My Director VM has more than Enough Free Space in it too.

Sorry, I don't know where to post this issue.

Could anyone please help me on this issue, since am struck with this
more than a week. Thanks

Regards

Parthiban A


Re: CF-RELEASE v202 UPLOAD ERROR

Parthiban Annadurai <senjiparthi@...>
 

Hello John,
Based on your suggestions, I tried to upload from /tmp. Still
it throws the Error. For your Reference I have attached the ScreenShot.
Could you please take a look on that? Thanks.

Regards

Parthiban A

On 12 October 2015 at 09:14, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

John, Thanks for your suggestions. Let me try with /tmp.

Regards

Parthiban A

On 11 October 2015 at 22:59, John Feminella <jfeminella(a)pivotal.io> wrote:

It looks like you are trying to upload a release from a local file on
your system called /root/tmp/cf-release-202.tgz.

It also looks like you mounted this path at /. However, you appear to
only have 114M available free space here:

/dev/mapper/VolGroup00-LogVol00_root
2.1G 1.9G 114M 95% /

and this logical volume is 95% full. That will not be enough space to
extract the files -- cf-release-202 is ~2 GB compressed so it will take
considerably more space than that to unzip. You may wish to consider
extracting in a location with more free space available (at least 10 GB or
so). Your /tmp mountpoint may be useful, since it looks like that has 16
GiB free.

best,
~ jf

--
*John Feminella*
Advisory Field Engineer
✉ · jfeminella(a)pivotal.io
t · @jxxf <https://twitter.com/jxxf>

On Sun, Oct 11, 2015 at 5:01 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Ronak,
I have checked the Local machine too, it shows the following,

[root(a)opencf microbosh]# df -H
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00_root
2.1G 1.9G 114M 95% /
tmpfs 985M 0 985M 0% /dev/shm
/dev/sda1 102M 74M 24M 77% /boot
/dev/mapper/VolGroup00-LogVol00_home
2.1G 3.3M 2.0G 1% /home
/dev/mapper/VolGroup00-LogVol00_opt
6.3G 13M 5.9G 1% /opt
/dev/mapper/VolGroup00-LogVol00_tmp
16G 2.7M 16G 1% /tmp
/dev/mapper/VolGroup00-LogVol00_usr
6.3G 2.0G 4.0G 34% /usr
/dev/mapper/VolGroup00-LogVol00_var
4.2G 126M 3.9G 4% /var

I think size is fine only. Could you?? Thanks.

Regards

Parthiban A

On 11 October 2015 at 14:15, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Check "df -h" on your local system from where you are uploading the
release.

On Sun, Oct 11, 2015 at 4:44 PM, Parthiban A <senjiparthi(a)gmail.com>
wrote:

Hi All,
When am uploading the Cloud Foundry Release v202 to the
Director, its throwing the following error.

bosh upload release /root/tmp/cf-release-202.tgz
Acting as user 'admin' on 'microbosh'

Verifying release...
File exists and readable OK
Extract tarball FAILED

Release is invalid, please fix, verify and upload again

My Director VM has more than Enough Free Space in it too.

Sorry, I don't know where to post this issue.

Could anyone please help me on this issue, since am struck with this
more than a week. Thanks

Regards

Parthiban A


Re: "application_version" is changed although source code is not changed.

Gerhard
 

I have only ever needed the app version when counting requests served by a
specific app build. It's not a common use case and it was easy to work
around, so it wasn't really an issue. I was not expecting this behaviour
from the application_version value, but it makes sense now.

Cheers, Gerhard.

On Friday, 16 October 2015, Matthew Sykes <matthew.sykes(a)gmail.com> wrote:

The application version really represents the versioned metadata for the
application. It changes regularly. [1] The only guarantee for version is
that it will change if the app restarts (could be due to package changes or
explicit operation), the health check changes, or the memory changes.

The droplet hash is not an appropriate representation of "application"
version since it doesn't take enough into account. It is something that
could be added to VCAP_APPLICATION but I think people would want to
understand why it's needed there.

Out of curiosity, are people acting on the application version in a way
that breaks things if it changes when the app bits or droplet did not? If
so, how?

Thanks.

[1]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/models/runtime/app.rb#L164-L178

On Fri, Oct 16, 2015 at 3:15 AM, Gerhard Lazu <gerhard(a)cloudcredo.com
<javascript:_e(%7B%7D,'cvml','gerhard(a)cloudcredo.com');>> wrote:

I was also assuming that app version would not change between app
restarts (when the same droplet is used). I was wrong.

Would it make more sense if the app version was the droplet shasum?

On Thursday, 15 October 2015, CF Runtime <cfruntime(a)gmail.com
<javascript:_e(%7B%7D,'cvml','cfruntime(a)gmail.com');>> wrote:

application_version is mostly an internal cloud foundry concern. The
DEAs broadcast the application version they are running, and the health
manager uses that with what version it expects to be running to converge
the system on the desired state.

Restarting the app is supposed to terminate the old instances and start
the new ones, so they new ones get a new application version so they are
separate from the old.

Joseph
CF Release Integration Team

On Thu, Oct 15, 2015 at 2:00 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com>
wrote:

Hi.
I have a question about a json field "application_version" in an
environment
variable "VCAP_APPLICATION".

By intuition, "application_version" should be only changed when there is
some update for an application.
Actually, when an application is terminated for some reasons and
restarted
automatically, "application_version" remain unchanged.

As far as I see it, however, "application_version" is changed when I "cf
restart" my application i.e. CCNG should use the same droplet so there
are
no differences from the one before deployment.

If it is possible, could someone please tell me the intention about this
implementation?


Thanks.

Hiroaki UKAJI



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-application-version-is-changed-although-source-code-is-not-changed-tp2262.html
Sent from the CF Dev mailing list archive at Nabble.com.

--
Matthew Sykes
matthew.sykes(a)gmail.com
<javascript:_e(%7B%7D,'cvml','matthew.sykes(a)gmail.com');>


Re: Open sourcing our RDS service broker

James Bayer
 

thank you for sharing this! i know someone else was working on a similar
thing.

CFF team, do we have a place to curate lists of service brokers? bosh.io is
a great place to list bosh releases [0], but we don't have a place like
that for services / service brokers. at one time there was an attempt to do
it in the community wiki [1] but it's not really updated or high-fidelity.

[0] http://bosh.io/releases
[1]
https://github.com/cloudfoundry-community/awesome-bosh-releases/blob/master/README.md

On Thu, Oct 15, 2015 at 9:23 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Thanks that's a really nice job !

On Fri, Oct 16, 2015 at 1:15 PM, Eric Poelke <epoelke(a)gmail.com> wrote:

Throwing this out there for anyone who might find it useful.

https://github.com/epoelke/rds-service-broker

--
Thank you,

James Bayer


Re: Cloud Foundry Java Client V2

James Bayer
 

exciting work ben, scott, and all involved thus far! this is great news to
anyone wanting to integrate with cloud foundry from a client with java api
interoperability, which covers a large number of situations.

On Fri, Oct 16, 2015 at 11:12 PM, Josh Long <starbuxman(a)gmail.com> wrote:

This is awesome! Using reactive-streams is particularly inspired. Congrats
and I'm very much looking forward to this work.

Will v1 receive support for individually addressable IPs, or will that be
unique to v2?


On Thursday, October 15, 2015, Ben Hale <bhale(a)pivotal.io> wrote:

As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.

We on the Cloud Foundry Java Experience team have been aware for some
time that the current implementation of the Java Client is less than
ideal. Among the most common complaints were the lack of separation
between interface and implementation, the subpar network performance, and
the requirement that users understand how to orchestrate common concepts
like `push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.

To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.

In V1, the coverage of the APIs[2] was incomplete (about half, if I had
to guess). Our commitment is to deliver a complete API and implementation
in V2, including all 300+ documented APIs. We’ve observed that this API
might not actually be the right level of abstraction for many users
though. Knowing that you need to create an application, create a package,
stage a droplet, create and start a process, etc. for `push` is quite a
burden on many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.

This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.

I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].


-Ben Hale
Cloud Foundry Java Experience

[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client


--
Josh Long
Spring Developer Advocate, Pivotal
joshlong.com | @starbuxman
--
Thank you,

James Bayer


[abacus] Abacus v0.0.2-rc.1 available

Jean-Sebastien Delfino
 

I'm happy to announce the availability of CF Abacus v0.0.2-rc.1
(incubating).

Abacus provides usage metering and aggregation for Cloud Foundry services
and app runtimes.

This release candidate is for the interested members of the community to
get a chance to try Abacus and ask any questions or submit issues and pull
requests in the next few days before we cut a final v0.0.2 release.

The pre-release Git tag and release notes can be found on Github:
https://github.com/cloudfoundry-incubator/cf-abacus/releases/tag/v0.0.2-rc.1

The CI build can be found on Travis CI:
https://travis-ci.org/cloudfoundry-incubator/cf-abacus/builds/85870667

The npm modules can be found on npmjs:
https://www.npmjs.com/search?q=cf-abacus

Please feel free to ask any questions about this pre-release of Abacus on
this list. We'll also start a few threads on the list sometime next week to
discuss the design of some of the features we've included in v0.0.2.
Finally, issues or -- even better -- pull requests are welcome on Github!

For more info on Abacus please visit:
https://github.com/cloudfoundry-incubator/cf-abacus/tree/v0.0.2-rc.1

Thanks!

- Jean-Sebastien


Re: Cloud Foundry Java Client V2

Josh Long
 

This is awesome! Using reactive-streams is particularly inspired. Congrats
and I'm very much looking forward to this work.

Will v1 receive support for individually addressable IPs, or will that be
unique to v2?

On Thursday, October 15, 2015, Ben Hale <bhale(a)pivotal.io> wrote:

As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.

We on the Cloud Foundry Java Experience team have been aware for some time
that the current implementation of the Java Client is less than ideal.
Among the most common complaints were the lack of separation between
interface and implementation, the subpar network performance, and the
requirement that users understand how to orchestrate common concepts like
`push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.

To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.

In V1, the coverage of the APIs[2] was incomplete (about half, if I had to
guess). Our commitment is to deliver a complete API and implementation in
V2, including all 300+ documented APIs. We’ve observed that this API might
not actually be the right level of abstraction for many users though.
Knowing that you need to create an application, create a package, stage a
droplet, create and start a process, etc. for `push` is quite a burden on
many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.

This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.

I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].


-Ben Hale
Cloud Foundry Java Experience

[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client
--
Josh Long
Spring Developer Advocate, Pivotal
joshlong.com | @starbuxman


Re: Defining a singular plan for all services

CF Runtime
 

What services do you want to define this default plan for?

Natalie & Mikhail
Runtime & OSS Integration

On Wed, Oct 14, 2015 at 2:22 AM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Hi,

How can I define a default plan to be used by more than one services
without repeating the same plan definition in settings.yml file?

Appreciate your help.

7101 - 7120 of 9422