Date   

Re: [abacus] Abacus v1.0.0 available

Chip Childers <cchilders@...>
 

Hristo,

Congratulations to the team!

On Tue, Sep 12, 2017 at 8:07 AM Hristo Iliev <hsiliev(a)gmail.com> wrote:

I'm happy to announce the availability of CF Abacus v1.0.0.

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

The v1.0.0 release comes bundled with:

- MongoDB and CouchDB support
- Improved data format & processing
- 2 new components to measure resource consumption of applications and
service instances in Cloud Foundry
- Concourse deploy pipeline
- Performance & Security improvements

You can find the full release notes on Github:
https://github.com/cloudfoundry-incubator/cf-abacus/releases/tag/v1.0.0

npm modules are available on: https://www.npmjs.com/search?q=cf-abacus

Please feel free to ask any questions on this list or via Github issues.
Pull requests are always welcome as well!

For more info on Abacus please visit:

- source code:
https://github.com/cloudfoundry-incubator/cf-abacus/tree/v1.0.0
- documentation:
https://github.com/cloudfoundry-incubator/cf-abacus/wiki

Thanks to Abacus committers and contributors who helped with this release!

We are already gathering requirements and looking forward to version 2
features. Check what we have so far here:
https://github.com/cloudfoundry-incubator/cf-abacus/wiki/Abacus-v2-features

Hristo Iliev
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: How to start my app in http and https ports?

Daniel Mikusa
 

Your app doesn't need to start both. It should generally just listen on
port 8080 (but technically should be the port listed in the env variable
$PORT) for HTTP requests. HTTPS/TLS is handled at the platform layer.
Usually, there would be a load balancer in front of your CF installation
which accepts HTTPS/TLS requests and terminates them. It would then proxy
requests to the GoRouter & ultimately your application via HTTP.

There are some variations on this as you can have your LB send requests via
HTTPS to the GoRouter which is capable of terminating HTTPS/TLS too (if
it's configured as such). In this way, you can make sure encryption is in
use for one additional hop of the request. For small environments that
don't have LB's, it's also possible to have GoRouter handle incoming
requests directly and terminate HTTPS/TLS. This only works for small envs
though, because it limits you to having one GoRouter. I don't know how
this is handled in PCFDev, but I suspect it might be done this way.

If you require HTTPS/TLS all the way to your application, the current
solution is to use TCP routing instead of a web application. TCP routing
has a different request path which results in your application receiving
the TCP connection from the client. This allows you to configure HTTPS/TLS
at the application level and have traffic encrypted all the way to the app.

Hope that helps!

Dan

On Tue, Sep 12, 2017 at 8:55 AM, Ushani Balasooriya <ushanib(a)gmail.com>
wrote:

My app should start in https:9443 ports. How can I achieve this?

This should be my login url : https://localhost:9443/carbon/

If I use Diego container, should it always be port 8080? Please point me
to a proper document where I can deploy my image in PCF to start on https
port?

This is my log:

2017-09-12T18:14:55.382+05:30 [API/0] [OUT] Created app with guid
fd8a0ddd-06ba-441a-94c7-73a0099589ad
2017-09-12T18:14:57.446+05:30 [API/0] [OUT] Updated app with guid
fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"route"=>"7d708d12-35fa-4fc2-9a87-3d4f8e8fac17",
:verb=>"add", :relation=>"routes", :related_guid=>"7d708d12-35fa-
4fc2-9a87-3d4f8e8fac17"})
2017-09-12T18:15:01.708+05:30 [API/0] [OUT] Updated app with guid
fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"state"=>"STARTED"})
2017-09-12T18:15:01.723+05:30 [STG/0] [OUT] Creating container
2017-09-12T18:15:01.928+05:30 [STG/0] [OUT] Staging...
2017-09-12T18:15:01.928+05:30 [STG/0] [OUT] Successfully created container
2017-09-12T18:15:01.986+05:30 [STG/0] [OUT] Staging process started ...
2017-09-12T18:15:06.062+05:30 [STG/0] [OUT] Staging process finished
2017-09-12T18:15:06.066+05:30 [STG/0] [OUT] Exit status 0
2017-09-12T18:15:06.066+05:30 [STG/0] [OUT] Staging Complete
2017-09-12T18:15:06.095+05:30 [STG/0] [OUT] Destroying container
2017-09-12T18:15:06.260+05:30 [CELL/0] [OUT] Creating container
2017-09-12T18:15:06.378+05:30 [STG/0] [OUT] Successfully destroyed
container
2017-09-12T18:15:20.061+05:30 [API/0] [OUT] Updated app with guid
fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"memory"=>2048,
"disk_quota"=>1024})
2017-09-12T18:15:20.157+05:30 [API/0] [OUT] Updated app with guid
fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"state"=>"STOPPED"})
2017-09-12T18:15:20.382+05:30 [API/0] [OUT] Updated app with guid
fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"state"=>"STARTED"})
2017-09-12T18:15:20.391+05:30 [CELL/0] [OUT] Creating container


=======

{
"staging_env_json": {},
"running_env_json": {},
"environment_json": "invalid_key",
"system_env_json": {
"VCAP_SERVICES": {}
},
"application_env_json": {
"VCAP_APPLICATION": {
"cf_api": "http://api.local.pcfdev.io",
"limits": {
"fds": 16384,
"mem": 2048,
"disk": 1024
},
"application_name": "is5.3.0",
"application_uris": [
"is530.local.pcfdev.io"
],
"name": "is5.3.0",
"space_name": "pcfdev-space",
"space_id": "a725ead6-283c-481d-b727-251865593e67",
"uris": [
"is530.local.pcfdev.io"
],
"users": null,
"application_id": "fd8a0ddd-06ba-441a-94c7-73a0099589ad",
"version": "d4a02bd7-e358-490a-9498-1c359882e5cd",
"application_version": "d4a02bd7-e358-490a-9498-1c359882e5cd"
}
}
}


[abacus] Abacus v1.0.0 available

Hristo Iliev
 

I'm happy to announce the availability of CF Abacus v1.0.0.

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

The v1.0.0 release comes bundled with:

- MongoDB and CouchDB support
- Improved data format & processing
- 2 new components to measure resource consumption of applications and
service instances in Cloud Foundry
- Concourse deploy pipeline
- Performance & Security improvements

You can find the full release notes on Github: https://github.com/
cloudfoundry-incubator/cf-abacus/releases/tag/v1.0.0

npm modules are available on: https://www.npmjs.com/search?q=cf-abacus

Please feel free to ask any questions on this list or via Github issues.
Pull requests are always welcome as well!

For more info on Abacus please visit:

- source code: https://github.com/cloudfoundry-incubator/cf-
abacus/tree/v1.0.0
- documentation: https://github.com/cloudfoundry-incubator/cf-abacus/wiki

Thanks to Abacus committers and contributors who helped with this release!

We are already gathering requirements and looking forward to version 2
features. Check what we have so far here: https://github.com/
cloudfoundry-incubator/cf-abacus/wiki/Abacus-v2-features

Hristo Iliev


How to start my app in http and https ports?

Ushani Balasooriya
 

My app should start in https:9443 ports. How can I achieve this?

This should be my login url : https://localhost:9443/carbon/

If I use Diego container, should it always be port 8080? Please point me to a proper document where I can deploy my image in PCF to start on https port?

This is my log:

2017-09-12T18:14:55.382+05:30 [API/0] [OUT] Created app with guid fd8a0ddd-06ba-441a-94c7-73a0099589ad
2017-09-12T18:14:57.446+05:30 [API/0] [OUT] Updated app with guid fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"route"=>"7d708d12-35fa-4fc2-9a87-3d4f8e8fac17", :verb=>"add", :relation=>"routes", :related_guid=>"7d708d12-35fa-4fc2-9a87-3d4f8e8fac17"})
2017-09-12T18:15:01.708+05:30 [API/0] [OUT] Updated app with guid fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"state"=>"STARTED"})
2017-09-12T18:15:01.723+05:30 [STG/0] [OUT] Creating container
2017-09-12T18:15:01.928+05:30 [STG/0] [OUT] Staging...
2017-09-12T18:15:01.928+05:30 [STG/0] [OUT] Successfully created container
2017-09-12T18:15:01.986+05:30 [STG/0] [OUT] Staging process started ...
2017-09-12T18:15:06.062+05:30 [STG/0] [OUT] Staging process finished
2017-09-12T18:15:06.066+05:30 [STG/0] [OUT] Exit status 0
2017-09-12T18:15:06.066+05:30 [STG/0] [OUT] Staging Complete
2017-09-12T18:15:06.095+05:30 [STG/0] [OUT] Destroying container
2017-09-12T18:15:06.260+05:30 [CELL/0] [OUT] Creating container
2017-09-12T18:15:06.378+05:30 [STG/0] [OUT] Successfully destroyed container
2017-09-12T18:15:20.061+05:30 [API/0] [OUT] Updated app with guid fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"memory"=>2048, "disk_quota"=>1024})
2017-09-12T18:15:20.157+05:30 [API/0] [OUT] Updated app with guid fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"state"=>"STOPPED"})
2017-09-12T18:15:20.382+05:30 [API/0] [OUT] Updated app with guid fd8a0ddd-06ba-441a-94c7-73a0099589ad ({"state"=>"STARTED"})
2017-09-12T18:15:20.391+05:30 [CELL/0] [OUT] Creating container


=======

{
"staging_env_json": {},
"running_env_json": {},
"environment_json": "invalid_key",
"system_env_json": {
"VCAP_SERVICES": {}
},
"application_env_json": {
"VCAP_APPLICATION": {
"cf_api": "http://api.local.pcfdev.io",
"limits": {
"fds": 16384,
"mem": 2048,
"disk": 1024
},
"application_name": "is5.3.0",
"application_uris": [
"is530.local.pcfdev.io"
],
"name": "is5.3.0",
"space_name": "pcfdev-space",
"space_id": "a725ead6-283c-481d-b727-251865593e67",
"uris": [
"is530.local.pcfdev.io"
],
"users": null,
"application_id": "fd8a0ddd-06ba-441a-94c7-73a0099589ad",
"version": "d4a02bd7-e358-490a-9498-1c359882e5cd",
"application_version": "d4a02bd7-e358-490a-9498-1c359882e5cd"
}
}
}


Re: Syslog drain binder job being replaced by cf-syslog-drain release

Altenhofen, Michael <michael.altenhofen@...>
 

Hi Adam,

sorry to nag you again (see [1]) with this, but will that release then implement the existing reconnection logic?

Thanks

Michael

[1] https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/FSD2FITNMDHSIB2ZB2QV2GZMOJTHOV44/

Am 11.09.17, 20:05 schrieb "Adam Hevenor" <ahevenor(a)pivotal.io>:

Hi All -

In the next few packages of cf-release we are going to be introducing a new release called cf-syslog-drain release [1]. This release handles this functionality and was proposed as the Scalable Syslog feature proposal [2]. Properties for drain specific functionality like blacklisting will be moving to this new release. Specific mapping of these properties will be documented in a future version of cf-release notes. This release is also already available in cf-deployment with the experimental operations file titled disable-etcd.

Thanks
Adam

[1] - http://bosh.io/releases/github.com/cloudfoundry/cf-syslog-drain-release?all=1
[2] - https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit


Re: Recommendations for Service parameters

Matt McNeeney
 

Hi Aniruddha,

A new feature has just been merged into the Open Service Broker API
specification that allows service brokers to use JSON schemes in their
catalogs to define the configuration parameters they accept for creating a
service instance, updating a service instance and creating a service
binding:
https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#schema-object

If you are new to JSON schema, this excellent guide should help you:
https://spacetelescope.github.io/understanding-json-schema/

This feature will be supported very soon in Cloud Foundry when the next
version of the spec is released.

Let me know if you have any further questions,
Matt

On Tue, 12 Sep 2017 at 06:20, Aniruddha Kulkarni <aquila.25(a)gmail.com>
wrote:

Hello,
CF provides support for specifying service parameters during:

1. Service instance creation (cf cli: -c option)
2. Service instance bind to an application.
3. Service key creation.

The format of these parameters is owned by the individual services.

My question is what is the recommendation regarding how to "publish" the
service parameter's format to the end-developers who will be using a
Service? i.e. how will an end developer know about what parameters are to
be provided?

Is there any guidance w.r.t to using the service/service plan metadata for
providing this information?

Regards,
--
-Aniruddha Kulkarni


Recommendations for Service parameters

Aniruddha Kulkarni
 

Hello,
CF provides support for specifying service parameters during:

1. Service instance creation (cf cli: -c option)
2. Service instance bind to an application.
3. Service key creation.

The format of these parameters is owned by the individual services.

My question is what is the recommendation regarding how to "publish" the
service parameter's format to the end-developers who will be using a
Service? i.e. how will an end developer know about what parameters are to
be provided?

Is there any guidance w.r.t to using the service/service plan metadata for
providing this information?

Regards,
--
-Aniruddha Kulkarni


Re: Syslog drain binder job being replaced by cf-syslog-drain release

Mike Youngstrom <youngm@...>
 

Great! Do you have a timeline for removal of the old syslog
functionality? Some of our loggregator syslog integrations are not
compatible with the new release. If the old functionality could remain in
place for a couple of months after the complete integration of the new
syslog drain that would be optimal.

Thanks,
Mike

On Mon, Sep 11, 2017 at 12:01 PM, Adam Hevenor <ahevenor(a)pivotal.io> wrote:

Hi All -

In the next few packages of cf-release we are going to be introducing a
new release called cf-syslog-drain release [1]. This release handles this
functionality and was proposed as the Scalable Syslog feature proposal [2].
Properties for drain specific functionality like blacklisting will be
moving to this new release. Specific mapping of these properties will be
documented in a future version of cf-release notes. This release is also
already available in cf-deployment with the experimental operations file
titled disable-etcd.

Thanks
Adam

[1] - http://bosh.io/releases/github.com/cloudfoundry/cf-
syslog-drain-release?all=1
[2] - https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_
5t8RwGGHY_4q4unojI/edit


Re: CF disable-service-access broken

Eric Promislow
 

Hello Prasad,

We filed an issue with the CLI team (
https://github.com/cloudfoundry/cli/issues/1225) to issue a warning
for cases like yours, where an attempt is made to disable access to a
service plan when the plan is
currently available to all orgs. Thanks for taking the time to report this
issue.

Eric Promislow and Matt Royal, CAPI Community Team

On Thu, Aug 31, 2017 at 3:23 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hello Prasad,

This is actually expected behavior. You can find documentation about
service access here https://docs.cloudfoundry.org/
services/access-control.html. It notes a limitation at the bottom.

"You cannot disable access to a service plan for an org if the plan is
currently available to all orgs. You must first disable access for all
orgs; then you can enable access for a particular org."

This is because service access works in two modes: 1) available to
everybody. 2) available in a whitelist to specific organizations.

Service access does NOT work as a blacklist.

The example you posted shows it as available to all, which means it is in
the first mode I listed. If you want more granular control, then you will
need to disable access for all orgs, and then whitelist each org that
should have access.

-Zach


Syslog drain binder job being replaced by cf-syslog-drain release

Adam Hevenor
 

Hi All -

In the next few packages of cf-release we are going to be introducing a new release called cf-syslog-drain release [1]. This release handles this functionality and was proposed as the Scalable Syslog feature proposal [2]. Properties for drain specific functionality like blacklisting will be moving to this new release. Specific mapping of these properties will be documented in a future version of cf-release notes. This release is also already available in cf-deployment with the experimental operations file titled disable-etcd.

Thanks
Adam

[1] - http://bosh.io/releases/github.com/cloudfoundry/cf-syslog-drain-release?all=1
[2] - https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit


Re: about consul_agent's cert

Mariusz Olejnik
 

Check certificates encoding: https://tools.ietf.org/html/rfc7468
In my case some of them were empty on the consul instance:

$ ssh vcap(a)consul -i bosh.pem
$ ls /var/vcap/jobs/consul_agent/config/certs/
# agent.crt agent.key ca.crt server.crt server.key
$ ls /var/vcap/jobs/metron_agent/config/certs/
# loggregator_ca.crt metron_agent.crt metron_agent.key


Re: CF Summit Europe 2017 Unconference

Michael Maximilien
 

Sweet! Who's moderating for you?

Dave Nielsen (on cc:) has moderated many of these in the past and might be
a great source for advices.

Look forward to this. Cheers all,

Max

On Mon, Sep 4, 2017 at 6:52 AM, Daniel Jones <
daniel.jones(a)engineerbetter.com> wrote:

Hi all,

There* will be an Unconference* on the *evening of Tuesday 10th October*
at CF Summit Europe 2017.

This is a separate event to the earlier Community Day, which is for
end-users only.

Folks from the Foundation, EngineerBetter, Anynines, Swisscom and
Resilient Scale are helping to organise things. We're still working out the
finer details, but figured we should let you know that *something* will
be happening so you can make travel plans accordingly.

Location: *Same building as the hotel/congress centre*
Time: *6pm onwards*, probably

We're hoping to combine *lightning talks*, *open space* discussions, and
maybe something a little less sensible like a *Cloud Foundry Pub Quiz*.
We are expecting to have the obligatory free food and drink.

More details to follow as we clarify them. If you have any questions or
suggestions, please contact me or any of the folks CC'd. This is event is
very much for the community, so your input is very welcome.

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153 <+44%207980%20009153>
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists


--
max
http://maximilien.org


Re: Runtime PMC Proposal: CF Services API Project

Dieu Cao <dcao@...>
 

Thanks Matt!
Looking forward to discussing this at the Runtime PMC meeting.

-Dieu

On Fri, Sep 1, 2017 at 7:19 AM, Matt McNeeney <mmcneeney(a)pivotal.io> wrote:

Pivotal would like to propose the CF Services API project for inclusion in
the Runtime PMC as an Active project.

Please find the proposal document attached [1], and let us know if you
have any questions.

Project Name: CF Services API
Project Lead: Matt McNeeney
Development Operating Model: Pairing
Initial Team: 1 product manager and 5 engineers from Pivotal

Thanks,
Matt McNeeney, Pivotal

[1] https://docs.google.com/a/pivotal.io/document/d/17-g3B9mXXz_
5bwlnksr1KeyjvXAeJQtW9jHMNJ3npP0/edit?usp=sharing


Re: CF Summit Europe 2017 Unconference

Dr Nic Williams <drnicwilliams@...>
 

_
/(|
( :
__\ \ _____
(____) `|
(____)| |
(____).__|
(___)__.|_____


CF Summit Europe 2017 Unconference

Daniel Jones
 

Hi all,

There* will be an Unconference* on the *evening of Tuesday 10th October* at
CF Summit Europe 2017.

This is a separate event to the earlier Community Day, which is for
end-users only.

Folks from the Foundation, EngineerBetter, Anynines, Swisscom and Resilient
Scale are helping to organise things. We're still working out the finer
details, but figured we should let you know that *something* will be
happening so you can make travel plans accordingly.

Location: *Same building as the hotel/congress centre*
Time: *6pm onwards*, probably

We're hoping to combine *lightning talks*, *open space* discussions, and
maybe something a little less sensible like a *Cloud Foundry Pub Quiz*. We
are expecting to have the obligatory free food and drink.

More details to follow as we clarify them. If you have any questions or
suggestions, please contact me or any of the folks CC'd. This is event is
very much for the community, so your input is very welcome.

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists


CF CLI v6.30.0 Released Today - CF Networking commands

Koper, Dies <diesk@...>
 

The CF CLI team cut 6.30.0 today.
Deb, yum and Homebrew repos have been updated; binaries, installers and link to release notes are available at:

https://github.com/cloudfoundry/cli#downloads
Container networking commands

This cf CLI release exposes the Container Networking feature of allowing direct network traffic between apps, bypassing the router.

This enables apps to be connected to by other apps without being routable from the Internet.

This functionality has been available with the network-policy CLI plugin and is now part of the cf CLI with the following commands:



cf add-network-policy SOURCE_APP --destination-app DESTINATION_APP [(--protocol (tcp | udp) --port RANGE)]

cf network-policies [--source SOURCE_APP]

cf remove-network-policy SOURCE_APP --destination-app DESTINATION_APP --protocol (tcp | udp) --port RANGE


The new commands require Network Policy API V1, which was introduced in cf-deployment v0.21.0 and as an optional deploy in CF release v271 (CC API v3.29.0) or higher.
Refer to the documentation<https://docs.cloudfoundry.org/devguide/deploy-apps/cf-networking.html#create-policies> for details.

New & updated community plugins

* started-apps<https://github.com/cdelashmutt-pivotal/service-use> v0.1.0 - Easily view which apps are started
Check it out!

Regards,
Dies Koper
Cloud Foundry Product Manager - CLI


Method to retrieve task metadata from within running task

Al Maline
 

Is there a method to retrieve some basic metadata about a running task from within the task container? For example determine the user who launched the task so the task can email results. Or the task ID, space ID and Org ID so the task can store traceable output.


Runtime PMC Proposal: CF Services API Project

Matt McNeeney
 

Pivotal would like to propose the CF Services API project for inclusion in
the Runtime PMC as an Active project.

Please find the proposal document attached [1], and let us know if you have
any questions.

Project Name: CF Services API
Project Lead: Matt McNeeney
Development Operating Model: Pairing
Initial Team: 1 product manager and 5 engineers from Pivotal

Thanks,
Matt McNeeney, Pivotal

[1]
https://docs.google.com/a/pivotal.io/document/d/17-g3B9mXXz_5bwlnksr1KeyjvXAeJQtW9jHMNJ3npP0/edit?usp=sharing


Re: Issue with cf service plan name access and update

Zach Robinson
 

Hi Ketaki, I'm not able to reproduce that issue on latest CF.
-Zach


Re: CF disable-service-access broken

Zach Robinson
 

Hello Prasad,

This is actually expected behavior. You can find documentation about service access here https://docs.cloudfoundry.org/services/access-control.html. It notes a limitation at the bottom.

"You cannot disable access to a service plan for an org if the plan is currently available to all orgs. You must first disable access for all orgs; then you can enable access for a particular org."

This is because service access works in two modes: 1) available to everybody. 2) available in a whitelist to specific organizations.

Service access does NOT work as a blacklist.

The example you posted shows it as available to all, which means it is in the first mode I listed. If you want more granular control, then you will need to disable access for all orgs, and then whitelist each org that should have access.

-Zach