Date   

Re: Service Fabrik goes Open Source and proposing CF Incubation - LAST CALL FOR COMMENTS

Michael Maximilien
 

Hi, all,

Last chance for comments on the Service Fabrik proposal. We will move by EOD PDT for a vote.

Best,

dr.max

ibm cloud labs 
sillicon valley, ca
usa 

Sent from my iPhone

On Oct 31, 2017, at 5:30 AM, Michael Maximilien <maxim@...> wrote:

FYI...

See below. Please take some time to peruse the proposals and links. Thanks,

Link again: https://docs.google.com/document/d/1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I

dr.max

ibm cloud labs 
sillicon valley, ca
usa 

Sent from my iPhone

Begin forwarded message:

From: "Jain, Ashish" <ashish.jain09@...>
Date: October 30, 2017 at 7:29:55 PM GMT+1
To: "Michael Maximilien" <mmaximilien@...>, "Michael Maximilien " <maxim@...>
Subject: FW: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

Hi Dr. Max,

 

Thanks for organizing the extensions meeting and providing us another opportunity to answer questions on Service Fabrik. As discussed during the meeting we want to go ahead with voting on our incubation proposal next week Wednesday 8th November. Considering this we are open for any comments on our incubation proposal till next Monday (6th November). Can you please help us with an official announcement about this to the complete Cloud Foundry community?

 

Best regards,

Ashish

 

From: "Jain, Ashish" <ashish.jain09@...>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Date: Wednesday, 27 September 2017 at 1:01 PM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Cc: Chip Childers <cchilders@...>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

 

Hi Alex,

 

I have replied back on the comments you had on the proposal. We look forward to any more thoughts or comments you may have.

 

Best regards,

Ashish

 

From: Jain, Ashish [mailto:ashish.jain09@...]
Sent: Tuesday, September 26, 2017 12:04 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Cc: Chip Childers <cchilders@...>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

 

Hi Therese,

 

Thanks for resolving all the comments J. We welcome others in the community to kindly review our proposal which is available @ (https://docs.google.com/document/d/1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I/edit#) and look forward to answering any questions you may have on Service Fabrik.

 

Best regards,

Ashish

 

 

From: Therese Stowell [mailto:tstowell@...]
Sent: Monday, September 25, 2017 1:34 PM
To: Discussions about Cloud Foundry projects and the system overall. <
cf-dev@...>
Cc: Chip Childers <
cchilders@...>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

 

Hi Ashish,

I've resolved all my comments.

best,

Therese

 

On Fri, Sep 22, 2017 at 5:52 PM, Jain, Ashish <ashish.jain09@...> wrote:

Hi Therese,

 

I have tried my best to add all the information as pointed by you. We look forward to anymore thoughts or comments you may have on the proposal.

 

Best Regards,

Ashish

 

From: Therese Stowell [mailto:tstowell@...]
Sent: Friday, September 22, 2017 3:11 PM
To: Discussions about Cloud Foundry projects and the system overall. <
cf-dev@...>
Cc: Chip Childers <
cchilders@...>
Subject: [cf-dev] Re: Re: Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

 

Hi Ashish,

Thanks for the prompt replies.

Could you please add the info in your comments into the main doc? I'd be happy to resolve the comments after that.

best,

Therese

 

On Fri, Sep 22, 2017 at 4:43 AM, Jain, Ashish <ashish.jain09@...> wrote:

Hi Therese,

 

We have responded back to the comments you had on the incubation proposal. We look forward to any more thoughts or comments you may have.

 

Best Regards,

Ashish

 

From: Jain, Ashish [mailto:ashish.jain09@...]
Sent: Thursday, September 21, 2017 11:06 PM
To: Discussions about Cloud Foundry projects and the system overall. <
cf-dev@...>; Chip Childers <cchilders@...>
Subject: [cf-dev] Re: Re: Service Fabrik goes Open Source and proposing CF Incubation

 

Thank you Dr. Max for providing us a slot in yesterday’s #CAB call. It was great to be there and present Service Fabrik to the CF community. We look forward to answering any questions which the community may have on Service Fabrik.  Our incubation proposal is hosted here (https://docs.google.com/document/d/1LiYxLkHoAThLXQp08Wvrit8kg07J1GdsbIkid6X145I/edit) which provide more details on Service Fabrik.

 

Best Regards,

Ashish

 

From: Michael Maximilien [mailto:maxim@...]
Sent: Monday, August 21, 2017 9:38 PM
To: Chip Childers <
cchilders@...>
Cc: CF Developers Mailing List <
cf-dev@...>
Subject: [cf-dev] Re: Service Fabrik goes Open Source

 

Absolutely! Will reach out to Ashish and other SAP friends to schedule for September.

 

 

 

dr.max

 

ibm cloud labs 

sillicon valley, ca

usa 

 

Sent from my iPhone


On Aug 21, 2017, at 8:56 AM, Chip Childers <cchilders@...> wrote:

Neat!

 

cc/ Dr Max, since I think this would be really cool to have as a demo on one of the monthly CAB calls!

 

-chip

On Mon, Aug 21, 2017 at 11:47 AM Jain, Ashish <ashish.jain09@...> wrote:

Dear All,

SAP Cloud Platform team proudly announces the Open Source release of Service Fabrik (SF) and related projects.

What is Service Fabrik?

Service Fabrik is Cloud Foundry broker envisioned as one-stop for provisioning & management of enterprise grade backing services (for example PostgreSQL, MongoDB, RabbitMQ, Redis) for enterprise grade Cloud Foundry applications. It supports provisioning of developer only services using Docker Swarm and production grade services via BOSH release.

Hmm, What else?

Well, it enables provisioning of highly available and scalable services on a multi-cloud infrastructure with ease and speed. Effortlessly monitor, upgrade services with patches, security updates and backup or restore mission critical data in a periodic automated way are some of its key highlights.

Ohh really, anyone using it?

We already have hundreds of BOSH based & thousands of Containers based service deployments running in production which uses Service Fabrik. We recently announced the General Availability of backing services, managed by Service Fabrik, on SAP Cloud Platform.

That seems promising where can I get all of it?

Service Fabrik code can be found here. Details on related GitHub repositories below

[1] service-fabrik-boshrelease - BOSH release to deploy Service Fabrik

[2] service-fabrik-lvm-volume-driver - Logical volume driver for Docker based service

[3] service-fabrik-blueprint-service - Test service to try out Service Fabrik

[4] service-fabrik-blueprint-app - Test app to try out blueprint service

[5] service-fabrik-blueprint-boshrelease – BOSH release for blueprint service

[6] service-fabrik-backup-restore – Library for backup & restore of service instances.

 

Some resources which will provide more insight on Service Fabrik are as follows:

[1] Service-Fabrik @ Silicon Valley Summit

[2] Service Fabrik goes Open Source

And We Propose to Incubate!

We have made the proposal to include Service Fabrik as Cloud Foundry incubation project, details here

That sounds awesome, but who rescues me?

Our team is just one click away, feel free to post an issue and we will help you at the earliest.

What Else?

Thanks from the SAP Cloud Platform & See you soon.

--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

 

 

 



Re: CF mailing lists migration Tuesday at 9am PST

Chris Clark
 

Migration is now complete and things seem fully functional (including search function).  Please let me know if you have any issues or concerns.  You can take a look at the new interface here, or just continue to use email.  

Links to the old lists have been redirected and should be working fine.  

However, if there are links out there (in documentation, stack overflow, wherever) pointing to specific posts on the lists, those links have broken.  Hopefully the search function will allow people to easily find old posts, so this shouldn't be a big inconvenience.  If it is, please let me know. 

- Chris Clark

On Mon, Nov 6, 2017 at 1:06 PM, Chris Clark <cclark@...> wrote:
Dr Max - 

Tomorrow we will just be migrating the lists hosted on Mailman (cf-dev, cf-bosh, cf-ambassadors, cf-speakers, etc).  But we can certainly add cf-extensions, project leads, and any others we'd like as well.  I'll ask them tomorrow about migrating google groups (which I believe all the others are) and get back to you.  Should be easy enough to do though. 

- Chris

On Sat, Nov 4, 2017 at 6:22 PM, Michael Maximilien <mmaximilien@...> wrote:
Ditto.

What about the other smaller lists? PMC lists etc?

Thanks,

Max

On Fri, Nov 3, 2017 at 6:38 PM Eric Malm <emalm@...> wrote:
Thanks for the notice, Chris! Excited to hear we're finally migrating (and will get a working search function again)!

On Fri, Nov 3, 2017 at 10:14 AM, Chris Clark <cclark@...> wrote:
Hello all,

cf-dev, and all other Cloud Foundry Foundation mailing lists, will be migrating from Mailman to Groups.io on Nov 7th, Tuesday, at 9am PST.  Migration should take an hour or two, and during this time there will be a delay in any new posts.  The archives will be still be available. 

Groups.io should provide significant improvements in functionality and UI over Mailman.  For those of you interacting with this list solely through email, you likely won't notice the change.  If you use the interface at lists.cloudfoundry.org, you will soon see a nice new GUI to use... the domain, and associated URLs, will remain the same.  If you'd like to learn more about Groups.io, please reference their documentation.  

I'll let you know Tuesday once migration is complete.  Please reach out if you have any questions, concerns, exultations.  

Chris Clark

--
dr.max Sent from my iPhone http://maximilien.org



eclipse che docker is possible to push?

강경원
 

Hello.
Is it possible to push docker eclipse/che at cf?


Renaming the database instance group in cf-deployment

Iryna Shustava
 

Hey cf-dev.

The RelInt team is going to rename the database instance group in cf-deployment from singleton-database to database. This change will also apply to any ops files that reference the database instance group.

Please let us know if you have any questions or concerns about this change.

Thanks!

Iryna & Heather
The Release Integration Team


Re: Dynamic service catalog

Matt McNeeney
 

Thanks Peter, that makes sense. Whilst it is the broker who is responsible
for catalog changes, admins should expect that the catalog (and therefore
marketplace entries) *may *change when they update a service broker. If
this happens automatically, then I feel we should have a clearer strategy
for how service broker authors should modify and delete existing services
and plans.

Are there any other service broker authors who have this use case? It would
be great to hear more feedback on this from others who are struggling with
the same issue.

On Mon, Nov 6, 2017 at 9:11 PM Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi Matt,

I would expect the behavior to be the same to the explicit broker update
as described in the documentation
<https://docs.cloudfoundry.org/services/managing-service-brokers.html#catalog-validation>
.
With cf update-service-broker the admin does not see the catalog changes,
so he cannot approve them.
In both cases the responsibility for catalog changes is with the broker.

AFAIK service prices are not defined in the service catalog but in the
billing system, which is outside CF control.

In our case we need to support multiple service versions as they are
incompatible.
Each service version is deployed separately. The broker can discover all
deployed versions.
When we deploy a new service version, we expect the consumers to see it in
the catalog along with the old versions.
Asking the admin to update the broker would be an additional manual effort.

Best regards,
Peter


On Fri, Nov 3, 2017 at 2:58 PM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Hey Peter,

This is an interesting use case. The idea of CC periodically refreshing
service broker catalog's has been raised a few times before, especially
when talking about brokers that aren't deployed on CF, but are managed
somewhere else. However, this idea has raised a number of issues in the
past, including:

- What happens to existing service instances and bindings that were
created using a plan that has now disappeared?
- What happens to existing service instances and bindings that were
created using a plan that has now changed?

This is especially important if say the pricing of a plan changes, as
there is no method for a developer to 'accept' the new plan. When an admin
explicitly updates a service broker, this is mitigated as they are asking
the platform to *use *the new catalog.

I'm interested to learn more about your broker, and why you want to offer
a separate plan for each version. And if you have any thoughts on the
above, I'd welcome those too! These has been discussed at length by the
OSBAPI working group as we are keen to put the right service/plan
deprecation strategies in place to support this kind of workflow.

Matt


On Fri, Nov 3, 2017 at 12:01 PM Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
In our use-case we want to provide a separate plan for each service
version. When a new service version is deployed, we want to see a new plan
for it in the marketplace.

My understanding so far is that the service catalog exposed by a service
broker is relatively static.
AFAIK Cloud Controller fetches the catalog from the broker only during
create-service-broker or update-service-broker. Both of these require admin
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

One neat solution could be service brokers to use standard http cache
control headers in the response to GET /v2/catalog to declare the
expiration time of the catalog.
When the marketplace is requested, CC could refetch the expired service
catalogs from the respective brokers.

Best regards,
Peter



Re: app-ssh-endpoint port change question

강경원 <atplus12345 at gmail.com...>
 

I tried but "cf curl /v2/info" is not changing.

On Oct 27, 2017 03:03, "Eric Malm" <emalm(a)pivotal.io> wrote:

Hi,

You should also make sure to configure the ssh-proxy job in diego-release
to listen on "0.0.0.0:10022", via the `diego.ssh_proxy.listen_addr`
property: https://github.com/cloudfoundry/diego-release/
blob/v1.29.1/jobs/ssh_proxy/spec#L32-L34

Best,
Eric Malm, CF Diego PM

On Thu, Oct 26, 2017 at 7:44 AM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi,

You can change ssh endpoint port by changing
http://bosh.io/jobs/cloud_controller_ng?source=github.com/
cloudfoundry/cf-release&version=278#p=app_ssh.port

properties:
app_ssh:
port: 10022

Thanks
Ronak


On Thu, Oct 26, 2017 at 7:50 PM, 강경원 <atplus12345(a)gmail.com> wrote:

Hi. How can I change the "app_ssh_endpoint" lb port from 2222 to another
ones like 10022?


NOTICE [ruby-buildpack]: Removal of Ruby 2.1 (MRI) after 2017-10-06

Stephen Levine
 

The first release of the Ruby buildpack after December 6, 2017 will not
include any versions of (MRI) Ruby starting with 2.1.x version numbers.
Upstream support for Ruby 2.1 ended on 2017-04-01[1]. This change is
therefore overdue.

[1]
https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/

Thanks,
Stephen Levine
CF Buildpacks PM


NOTICE [nodejs-buildpack]: Change of default version to v6 and removal of v7 after 2017-10-06

Stephen Levine
 

The first release of the Node.js buildpack after December 6, 2017 will not
include any versions of Nodejs with 7.x.x version numbers. These versions
of Node.js are not covered by LTS, and as such they are no longer supported
upstream[1].

In addition, the default version of Node.js, which is used when no other
version of Node.js is specified in package.json, will change to v6 in the
same release that v7 is removed. Node.js v6 is the oldest active LTS
version line and has been since 2017-04-01[1]. This change is therefore
overdue.

[1] https://github.com/nodejs/Release

Thanks,
Stephen Levine
CF Buildpacks PM


Re: Dynamic service catalog

Peter Dotchev <dotchev@...>
 

Hi Matt,

I would expect the behavior to be the same to the explicit broker update as
described in the documentation
<https://docs.cloudfoundry.org/services/managing-service-brokers.html#catalog-validation>
.
With cf update-service-broker the admin does not see the catalog changes,
so he cannot approve them.
In both cases the responsibility for catalog changes is with the broker.

AFAIK service prices are not defined in the service catalog but in the
billing system, which is outside CF control.

In our case we need to support multiple service versions as they are
incompatible.
Each service version is deployed separately. The broker can discover all
deployed versions.
When we deploy a new service version, we expect the consumers to see it in
the catalog along with the old versions.
Asking the admin to update the broker would be an additional manual effort.

Best regards,
Peter

On Fri, Nov 3, 2017 at 2:58 PM, Matt McNeeney <mmcneeney(a)pivotal.io> wrote:

Hey Peter,

This is an interesting use case. The idea of CC periodically refreshing
service broker catalog's has been raised a few times before, especially
when talking about brokers that aren't deployed on CF, but are managed
somewhere else. However, this idea has raised a number of issues in the
past, including:

- What happens to existing service instances and bindings that were
created using a plan that has now disappeared?
- What happens to existing service instances and bindings that were
created using a plan that has now changed?

This is especially important if say the pricing of a plan changes, as
there is no method for a developer to 'accept' the new plan. When an admin
explicitly updates a service broker, this is mitigated as they are asking
the platform to *use *the new catalog.

I'm interested to learn more about your broker, and why you want to offer
a separate plan for each version. And if you have any thoughts on the
above, I'd welcome those too! These has been discussed at length by the
OSBAPI working group as we are keen to put the right service/plan
deprecation strategies in place to support this kind of workflow.

Matt


On Fri, Nov 3, 2017 at 12:01 PM Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
In our use-case we want to provide a separate plan for each service
version. When a new service version is deployed, we want to see a new plan
for it in the marketplace.

My understanding so far is that the service catalog exposed by a service
broker is relatively static.
AFAIK Cloud Controller fetches the catalog from the broker only during
create-service-broker or update-service-broker. Both of these require admin
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

One neat solution could be service brokers to use standard http cache
control headers in the response to GET /v2/catalog to declare the
expiration time of the catalog.
When the marketplace is requested, CC could refetch the expired service
catalogs from the respective brokers.

Best regards,
Peter



Re: CF mailing lists migration Tuesday at 9am PST

Chris Clark
 

Dr Max -

Tomorrow we will just be migrating the lists hosted on Mailman (cf-dev,
cf-bosh, cf-ambassadors, cf-speakers, etc). But we can certainly add
cf-extensions, project leads, and any others we'd like as well. I'll ask
them tomorrow about migrating google groups (which I believe all the others
are) and get back to you. Should be easy enough to do though.

- Chris

On Sat, Nov 4, 2017 at 6:22 PM, Michael Maximilien <mmaximilien(a)gmail.com>
wrote:

Ditto.

What about the other smaller lists? PMC lists etc?

Thanks,

Max

On Fri, Nov 3, 2017 at 6:38 PM Eric Malm <emalm(a)pivotal.io> wrote:

Thanks for the notice, Chris! Excited to hear we're finally migrating
(and will get a working search function again)!

On Fri, Nov 3, 2017 at 10:14 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Hello all,

cf-dev, and all other Cloud Foundry Foundation mailing lists, will be
migrating from Mailman to Groups.io on Nov 7th, Tuesday, at 9am PST.
Migration should take an hour or two, and during this time there will be a
delay in any new posts. The archives will be still be available.

Groups.io should provide significant improvements in functionality and
UI over Mailman. For those of you interacting with this list solely
through email, you likely won't notice the change. If you use the
interface at lists.cloudfoundry.org, you will soon see a nice new GUI
to use... the domain, and associated URLs, will remain the same. If you'd
like to learn more about Groups.io, please reference their documentation
<https://groups.io/static/help>.

I'll let you know Tuesday once migration is complete. Please reach out
if you have any questions, concerns, exultations.

Chris Clark
--
dr.max Sent from my iPhone http://maximilien.org


Re: New to cloud foundry

David Sabeti
 

Hi,

The docs at that page assume you're using cf-release and the ruby BOSH CLI.
Try following the documentation here:
https://github.com/cloudfoundry/cf-deployment/blob/master/deployment-guide.md

Thanks!
David Sabeti

On Wed, Nov 1, 2017 at 2:56 PM Sir June <sir_june(a)yahoo.com> wrote:

Hi,
I am also a newbie and trying to install cloudfloundry over vSphere (
https://docs.cloudfoundry.org/deploying/vsphere/index.html). I managed
to got to the point of "Customizing the Cloud Foundry Deployment Manifest
Stub". At the last step "bosh deployment cf-deployment.yml", it gave out
an error of "Command '*cmd.DeploymentOpts' does not support extra
arguments: cf-deployment.yml" . I am stuck at this point. I'd appreciate
any help/pointers!

thanks,
sirjune


[Abacus] Version 2: Inception

Hristo Iliev
 

We are planning an inception on the features we want to have in Abacus v2
on November 21st from 10-12am PST

We invite everyone interested to take a look at the repo [1], check the
ideas gathered so far [2] and provide feedback in the doc [3] or via Slack
[4] or better, join us at the inception meeting.

We'll use the Abacus weekly Zoom.us video conference:
https://zoom.us/j/788691850
<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F788691850&sa=D&usd=2&usg=AFQjCNEt6mxd-EM0VZUfOlko0uoe6N4XSw>

Regards,
Hristo Iliev

[1] https://github.com/cloudfoundry-incubator/cf-abacus
[2] https://github.com/cloudfoundry-incubator/cf-abacus/wiki/
Abacus-v2-features
[3] https://docs.google.com/document/d/15tst4kCnvQ-SiTG4TtM5eXm6hIEhYZ_
31BanDKq3h1A/edit?usp=sharing
[4] https://abacusdev-slack.mybluemix.net


Re: CF mailing lists migration Tuesday at 9am PST

Michael Maximilien
 

Ditto.

What about the other smaller lists? PMC lists etc?

Thanks,

Max

On Fri, Nov 3, 2017 at 6:38 PM Eric Malm <emalm(a)pivotal.io> wrote:

Thanks for the notice, Chris! Excited to hear we're finally migrating (and
will get a working search function again)!

On Fri, Nov 3, 2017 at 10:14 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Hello all,

cf-dev, and all other Cloud Foundry Foundation mailing lists, will be
migrating from Mailman to Groups.io on Nov 7th, Tuesday, at 9am PST.
Migration should take an hour or two, and during this time there will be a
delay in any new posts. The archives will be still be available.

Groups.io should provide significant improvements in functionality and UI
over Mailman. For those of you interacting with this list solely through
email, you likely won't notice the change. If you use the interface at
lists.cloudfoundry.org, you will soon see a nice new GUI to use... the
domain, and associated URLs, will remain the same. If you'd like to learn
more about Groups.io, please reference their documentation
<https://groups.io/static/help>.

I'll let you know Tuesday once migration is complete. Please reach out
if you have any questions, concerns, exultations.

Chris Clark
--
dr.max Sent from my iPhone http://maximilien.org


Re: CF mailing lists migration Tuesday at 9am PST

Eric Malm <emalm@...>
 

Thanks for the notice, Chris! Excited to hear we're finally migrating (and
will get a working search function again)!

On Fri, Nov 3, 2017 at 10:14 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Hello all,

cf-dev, and all other Cloud Foundry Foundation mailing lists, will be
migrating from Mailman to Groups.io on Nov 7th, Tuesday, at 9am PST.
Migration should take an hour or two, and during this time there will be a
delay in any new posts. The archives will be still be available.

Groups.io should provide significant improvements in functionality and UI
over Mailman. For those of you interacting with this list solely through
email, you likely won't notice the change. If you use the interface at
lists.cloudfoundry.org, you will soon see a nice new GUI to use... the
domain, and associated URLs, will remain the same. If you'd like to learn
more about Groups.io, please reference their documentation
<https://groups.io/static/help>.

I'll let you know Tuesday once migration is complete. Please reach out if
you have any questions, concerns, exultations.

Chris Clark


CF mailing lists migration Tuesday at 9am PST

Chris Clark
 

Hello all,

cf-dev, and all other Cloud Foundry Foundation mailing lists, will be
migrating from Mailman to Groups.io on Nov 7th, Tuesday, at 9am PST.
Migration should take an hour or two, and during this time there will be a
delay in any new posts. The archives will be still be available.

Groups.io should provide significant improvements in functionality and UI
over Mailman. For those of you interacting with this list solely through
email, you likely won't notice the change. If you use the interface at
lists.cloudfoundry.org, you will soon see a nice new GUI to use... the
domain, and associated URLs, will remain the same. If you'd like to learn
more about Groups.io, please reference their documentation
<https://groups.io/static/help>.

I'll let you know Tuesday once migration is complete. Please reach out if
you have any questions, concerns, exultations.

Chris Clark


Re: Dynamic service catalog

Matt McNeeney
 

Hey Peter,

This is an interesting use case. The idea of CC periodically refreshing
service broker catalog's has been raised a few times before, especially
when talking about brokers that aren't deployed on CF, but are managed
somewhere else. However, this idea has raised a number of issues in the
past, including:

- What happens to existing service instances and bindings that were
created using a plan that has now disappeared?
- What happens to existing service instances and bindings that were
created using a plan that has now changed?

This is especially important if say the pricing of a plan changes, as there
is no method for a developer to 'accept' the new plan. When an admin
explicitly updates a service broker, this is mitigated as they are asking
the platform to *use *the new catalog.

I'm interested to learn more about your broker, and why you want to offer a
separate plan for each version. And if you have any thoughts on the above,
I'd welcome those too! These has been discussed at length by the OSBAPI
working group as we are keen to put the right service/plan deprecation
strategies in place to support this kind of workflow.

Matt

On Fri, Nov 3, 2017 at 12:01 PM Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
In our use-case we want to provide a separate plan for each service
version. When a new service version is deployed, we want to see a new plan
for it in the marketplace.

My understanding so far is that the service catalog exposed by a service
broker is relatively static.
AFAIK Cloud Controller fetches the catalog from the broker only during
create-service-broker or update-service-broker. Both of these require admin
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

One neat solution could be service brokers to use standard http cache
control headers in the response to GET /v2/catalog to declare the
expiration time of the catalog.
When the marketplace is requested, CC could refetch the expired service
catalogs from the respective brokers.

Best regards,
Peter



Dynamic service catalog

Peter Dotchev <dotchev@...>
 

Hi folks,

We need to change the set of plans offered by some of our services
dynamically.
In our use-case we want to provide a separate plan for each service
version. When a new service version is deployed, we want to see a new plan
for it in the marketplace.

My understanding so far is that the service catalog exposed by a service
broker is relatively static.
AFAIK Cloud Controller fetches the catalog from the broker only during
create-service-broker or update-service-broker. Both of these require admin
privileges.
Is there some other mechanism to update the service catalog in the
marketplace?

One neat solution could be service brokers to use standard http cache
control headers in the response to GET /v2/catalog to declare the
expiration time of the catalog.
When the marketplace is requested, CC could refetch the expired service
catalogs from the respective brokers.

Best regards,
Peter


Re: Adding client to uaa shows insufficient scope

Chaitra Hegde
 

Hi,

I am using SAP HANA cloud foundry and I deployed the UAA as a cloud foundry app using a
manifest generated by ./gradlew manifests. In the localhost the uaa , app and api gets
deployed simultaneously and they are accessible at points /uaa, /app and /api. But in
cloud foundry when I deploy the uaa as an app, I have to deploy the sample app separately
and after login the uaa must redirect me to the sample app page. How do I deploy the
sample app separately and set the redirect url? Any help will be appreciated.


Re: JSON Data in User Provided Service Credential

Jon Martin
 

Thanks Zach,

We'll continue to use JSON then. Much appreciated!


Re: JSON Data in User Provided Service Credential

Carlo Alberto Ferraris
 

(sorry, please ignore this message)

1901 - 1920 of 9387