Date   

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
 

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


Promote cf-networking from incubation to active

Usha Ramachandran
 

Hi everyone,

The CF networking project (also known as Diego networking, container
networking, c2c) is currently under the cloudfoundry-incubator. We would
like to propose moving it from incubation to active in the upcoming runtime
PMC meeting scheduled for 09/05/2017.

cf-networking-release version 1.0 was released in June this year and it is
the default networking solution in PCF 1.11 and cf-deployment. Here is a
document with more details -
https://docs.google.com/document/d/1ohn9AS7Wic_ZQ1vwPFYCxa6IH1gsJwgOm7c48tIzoSU/edit?usp=sharing

Please let me know if you have any concerns or questions.

Thanks,
Usha
--
Usha Ramachandran | Senior Product Manager | Pivotal Cloud Foundry - San
Francisco


Re: [Proposal] Sharing service instances across orgs and spaces

Dieu Cao <dcao@...>
 

Matt,

I'd suggest also looking into reflecting the sharing of service instances
via service usage events.

-Dieu

On Wed, Aug 30, 2017 at 2:31 AM, Matt McNeeney <mmcneeney(a)pivotal.io> wrote:

Chris;

- We're not yet sure how instances would count towards quotas, but
this is on our list of things we will investigate as we move forward.
- This is true, however our research has shown that this isn't
perceived as a problem. When an intance is shared into a space, running *cf
service xxx* will also show a message saying where the instance was
shared from (in case you need to get in contact with someone from that
other space). Again, we asked a number of CF users about this and they were
happy with this.
*However, if you think this is a problem or have had other feedback
about this please pass it on asap!*
- Another good point, and you're right - we are making it easier for
developers to be malicious here. When we started working on this feature,
we designed a much more explicit permissions system where admins had to
explictly enable sharing of a particular service (and/or plan) from one
space to another. However the feedback on this was that this is overly
restrictive and would be a burden to admins. The solution we have ended up
with for this first version is using a feature flag to enable this in an
environment (i.e. *cf enable-feature-flag service_sharing*).
*Do you think this gives admins enough control, or would you still be
worried about malicious developers sharing instances into your space? Would
you be concerned that developers would accidentally bind to these
instances?*


Sergio;

- The more explicit permissions model we investigated would require
the CF admin to setup sharing rules, rather than OrgManager's. So in your
example, the Org1 and Org2 managers would have to go to their admin
together with an agreement to ask for the sharing rule to be put in place.
As for costings, we were hoping to leave this up to organisations to handle
internally. *Do you see this being an issue for any users you know
about?*
- We want to empower developers to manage their service instances as
much as possible. We already allow them to create services on-demand via *cf
create-service*, and the feedback we have supports our desire to
further empower developers to be as self-service as possible. However, due
to the cost implications you raise, we agree that admins need some level of
control over this, and so we are planning on enhancing the permissions
model following this first version.


Thanks all.

On Wed, Aug 30, 2017 at 7:14 AM Rozenszajn, Sergio <
sergio.rozenszajn(a)sap.com> wrote:

Hi all,



Good proposal, it rises some questions:

- Org1 probably pays money for the service and when sharing the
service to Org2 the payment should be shared as well à how can this
be structured?
- You say: " To manage any security concerns around this, a CF admin
would have to enable one-way sharing between two spaces" à I see it
more like: Org2 admin says to Org1 admin: "I'm interested in using service
ABC (and I'm ready to pay my part for it)". If they both agree, Org2 admin
enables sharing from Org1 to Org2. After that Org1 admin (or a Org1
developer) shares Org1 service instance to Org2.
- à I believe that sharing services can be done by a developer but it
is actually an admin decision due to the costs impact



Sergio



*From:* Christopher Brown [mailto:cbrown(a)pivotal.io]
*Sent:* יום ג 29 אוגוסט 2017 20:22
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: [Proposal] Sharing service instances across orgs
and spaces



Hi there,



Interesting proposal, thank you for suggesting it! I have a few questions
around some of the practicalities:

- How would shared services count towards the service instance quotas
in the respective spaces?
- Does the ability to share a service into a space that you do not
have access to cause a sensitive information leak? e.g. I can try and share
a service into organizations and spaces until it is successful which
confirms the existence of that organization, space, and possibly service
name.
- Does the ability to share a service into a space that you do not
have access to open developers up to abuse where someone else shares
malicious services into their spaces?

At the risk of the configuration becoming tedious: perhaps space
developers should be able to configure where they can accept service
sharing requests from?



Christopher



On Thu, Jun 29, 2017 at 6:35 AM, Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Many Cloud Foundry users have expressed a desire to share service
instances across orgs and spaces. Whilst this could be considered an
anti-pattern for some data services, there are many use cases for which the
ability to do this is important. Two examples are sharing config servers
and messaging queues.



The workarounds that exist today (e.g. creating user-provided services)
require credentials to be passed around in some out-of-band way and will
prevent the platform from being able to do things like automatic rotation
of credentials in the future.



We'd like to propose a new workflow that looks like this:



$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE



A SpaceDeveloper in the target org/space will only be able to bind/unbind
to/from the shared service instance, and running cf service will show
that the service instance has been shared.



To manage any security concerns around this, a CF admin would have to
enable one-way sharing between two spaces with a command like:



$ cf enable-service-sharing SERVICE SOURCE_ORG SOURCE_SPACE TARGET_ORG
TARGET_SPACE





We'd love to hear feedback from the community on this proposal. If you
have any other use cases that this could help with, please let us know
about those too.



Matt





Re: doppler client firehose subscribe turned disposabed

Adam Hevenor
 

This is likely due to the nozzle not being able to keep up with the load from Traffic Controller. You can confirm this by looking for slow consumer alerts [1]. It is recommended to scale your nozzle instances to match the number of Traffic Controllers in your deployment.

[1] - Loggregator Operator Guide - https://docs.cloudfoundry.org/loggregator/log-ops-guide.html

Adam


Re: [Proposal] Sharing service instances across orgs and spaces

Matt McNeeney
 

Chris;

- We're not yet sure how instances would count towards quotas, but this
is on our list of things we will investigate as we move forward.
- This is true, however our research has shown that this isn't perceived
as a problem. When an intance is shared into a space, running *cf
service xxx* will also show a message saying where the instance was
shared from (in case you need to get in contact with someone from that
other space). Again, we asked a number of CF users about this and they were
happy with this.
*However, if you think this is a problem or have had other feedback
about this please pass it on asap!*
- Another good point, and you're right - we are making it easier for
developers to be malicious here. When we started working on this feature,
we designed a much more explicit permissions system where admins had to
explictly enable sharing of a particular service (and/or plan) from one
space to another. However the feedback on this was that this is overly
restrictive and would be a burden to admins. The solution we have ended up
with for this first version is using a feature flag to enable this in an
environment (i.e. *cf enable-feature-flag service_sharing*).
*Do you think this gives admins enough control, or would you still be
worried about malicious developers sharing instances into your space? Would
you be concerned that developers would accidentally bind to these
instances?*


Sergio;

- The more explicit permissions model we investigated would require the
CF admin to setup sharing rules, rather than OrgManager's. So in your
example, the Org1 and Org2 managers would have to go to their admin
together with an agreement to ask for the sharing rule to be put in place.
As for costings, we were hoping to leave this up to organisations to handle
internally. *Do you see this being an issue for any users you know
about?*
- We want to empower developers to manage their service instances as
much as possible. We already allow them to create services on-demand via *cf
create-service*, and the feedback we have supports our desire to further
empower developers to be as self-service as possible. However, due to the
cost implications you raise, we agree that admins need some level of
control over this, and so we are planning on enhancing the permissions
model following this first version.


Thanks all.

On Wed, Aug 30, 2017 at 7:14 AM Rozenszajn, Sergio <
sergio.rozenszajn(a)sap.com> wrote:

Hi all,



Good proposal, it rises some questions:

- Org1 probably pays money for the service and when sharing the
service to Org2 the payment should be shared as well à how can this be
structured?
- You say: " To manage any security concerns around this, a CF admin
would have to enable one-way sharing between two spaces" à I see it
more like: Org2 admin says to Org1 admin: "I'm interested in using service
ABC (and I'm ready to pay my part for it)". If they both agree, Org2 admin
enables sharing from Org1 to Org2. After that Org1 admin (or a Org1
developer) shares Org1 service instance to Org2.
- à I believe that sharing services can be done by a developer but it
is actually an admin decision due to the costs impact



Sergio



*From:* Christopher Brown [mailto:cbrown(a)pivotal.io]
*Sent:* יום ג 29 אוגוסט 2017 20:22
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: [Proposal] Sharing service instances across orgs
and spaces



Hi there,



Interesting proposal, thank you for suggesting it! I have a few questions
around some of the practicalities:

- How would shared services count towards the service instance quotas
in the respective spaces?
- Does the ability to share a service into a space that you do not
have access to cause a sensitive information leak? e.g. I can try and share
a service into organizations and spaces until it is successful which
confirms the existence of that organization, space, and possibly service
name.
- Does the ability to share a service into a space that you do not
have access to open developers up to abuse where someone else shares
malicious services into their spaces?

At the risk of the configuration becoming tedious: perhaps space
developers should be able to configure where they can accept service
sharing requests from?



Christopher



On Thu, Jun 29, 2017 at 6:35 AM, Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Many Cloud Foundry users have expressed a desire to share service
instances across orgs and spaces. Whilst this could be considered an
anti-pattern for some data services, there are many use cases for which the
ability to do this is important. Two examples are sharing config servers
and messaging queues.



The workarounds that exist today (e.g. creating user-provided services)
require credentials to be passed around in some out-of-band way and will
prevent the platform from being able to do things like automatic rotation
of credentials in the future.



We'd like to propose a new workflow that looks like this:



$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE



A SpaceDeveloper in the target org/space will only be able to bind/unbind
to/from the shared service instance, and running cf service will show
that the service instance has been shared.



To manage any security concerns around this, a CF admin would have to
enable one-way sharing between two spaces with a command like:



$ cf enable-service-sharing SERVICE SOURCE_ORG SOURCE_SPACE TARGET_ORG
TARGET_SPACE





We'd love to hear feedback from the community on this proposal. If you
have any other use cases that this could help with, please let us know
about those too.



Matt




2201 - 2220 of 9425