Date   

Re: Do we connect to the CF when we setup using pcfdev

Stephen Levine
 

Hi Praveen,

PCF Dev does not connect to a separate PCF or CF installation. PCF Dev can
be administered using the cf CLI (by following the instructions at boot) or
using Apps Manager (by opening a browser to https://local.pcfdev.io).

PCF Dev requires an internet connection to resolve *.local.pcfdev.io
addresses using public DNS. If you would like to run PCF Dev without an
internet connection, see here:
http://docs.pivotal.io/pcf-dev/work-offline.html

In the future, questions about PCF Dev can be asked at our Github issue
tracker: http://docs.pivotal.io/pcf-dev/work-offline.html

Thanks,
Stephen
PCF Dev PM

On Tue, Sep 20, 2016 at 11:41 AM, Praveen sadineni <sadinenip(a)gmail.com>
wrote:

Hello ,

I have a PCFdev setup and when evr we deploy an application or do any
administration of PCFdev where do we connect ,
Is it that all locally we do this or do we connect to PCF ,
Secondly if we are connecting to PCF why are we connecting
and if we are not connecting to PCF why do I need to have internet to push
the applications, when I disable the internet we get error.
or we cannot even see the console.


Do we connect to the CF when we setup using pcfdev

Praveen sadineni
 

Hello ,

I have a PCFdev setup and when evr we deploy an application or do any administration of PCFdev where do we connect ,
Is it that all locally we do this or do we connect to PCF ,
Secondly if we are connecting to PCF why are we connecting
and if we are not connecting to PCF why do I need to have internet to push the applications, when I disable the internet we get error.
or we cannot even see the console.


Re: Announcement: default etcd cluster to TLS in cf-release spiff templates

Grifalconi, Michael <michael.grifalconi@...>
 

Hello all,

It’s been a couple of days that we are struggling on the update of CF v240 to v241 together with the TLS upgrade for etcd.

We are following the guide provided but we always get random deployment failures during the step about adding the etcd TLS node and the etcd http proxy job.

Our deployment failed because of hm9000, loggregator_trafficcontroller and doppler. Not all together, but one after the others: first if failed because of hm9000, hit deploy again and at the 3rd time it worked; same for loggregator.

For doppler it didn’t help to try multiple times (error was ‘panic: sync cluster failed’). We solved this by restarting both the single etcd (with TLS) and the proxy.

We deployed v240 from scratch and did the upgrade several times and we never had a ‘clean’ deployment, we always got a lot of issues that has been fixed by just a second (or third) try with no changes or by stopping all etcd vms, deleting the persistent storage and restarting them.

This is a no-go for productive deployments.

Do you have any ideas on this topic? Are we doing something wrong?


Thanks a lot

Best,
Michael

From: Amit Gupta <agupta(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Thursday 15 September 2016 at 03:34
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Announcement: default etcd cluster to TLS in cf-release spiff templates

Hi all,

I'd like to change the cf-release manifest generation templates to default to running etcd in secure TLS mode. It currently supports both TLS and non-TLS modes of operation. The etcd job will support both modes of operation for the near future, but I'd like to make the manifest scripts only support TLS, meaning anyone using those templates will either need to switch to TLS mode or do their own post-processing of the manifest to disable TLS.

Detailed instructions for upgrading a non-TLS cluster to a TLS cluster with zero downtime are here: https://docs.google.com/document/d/1ZzWzp3H6H3t1ikk6Fl-8x1LX2a_0dHPJ5MMLEwY0inI/edit. Note that this should allow for zero app and logging downtime, but minimal downtime for certain features such as binding a syslog-drain-url service.

Please let me know if you have any feedback about this forthcoming change.

Best,
Amit


Re: SSL termination for private domains

Shannon Coen
 

Some time ago I sketched out an epic to add support for multiple certs to
gorouter, configured via BOSH manifest property, but these stories have
languished in the icebox while we've addressed more urgent work.

I would like to hear from the community whether an operator managed feature
would be of value, as it would be relatively cheap.

I have also heard requests for user self-service management of certs for
private domains, as Carlo described. This would be a much more complex
feature to deliver, but I can certainly see the value.

Tell me about the pain of managing TLS certificates. How are you dealing
with this today? Which of these approaches would be more helpful in
enabling your developers? Which of these features would you be more
disappointed to hear would not be delivered?

Thank you!

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Mon, Sep 19, 2016 at 6:11 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

I have a question about the SSL termination epic[1], whose goal IIUC is to
provide the ability for operators to have multiple TLS certificates: it
seems only shared domains are being considered (because the stories talk
about *operators* setting up multiple certs); are there no plans for
private domains? Put otherwise: are there plans for allowing *users* to
provide the cert for a domain they registered in their org?

[1] https://www.pivotaltracker.com/epic/show/2135866

(I originally posted the question on slack but got no reply, so
crossposting here)


Re: Anyone use the /heathz endpoint on Gorouter?

Shannon Coen
 

Authentication was removed from /healthz in 2013 apparently (and the
Gorouter README wasn't updated). I just discovered last week that the
healthcheck endpoint doesn't require auth.

We'll add /health, bring it up to parity with the User-Agent behavior, and
add documentation for operators how to healthcheck the routers from an LB
on docs.cloudfoundry.org. We'll leave /healthz in place for a couple
releases, but we'll remove it from documentation and plan to remove it
soon.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Mon, Sep 19, 2016 at 9:47 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Those sound useful. I'll have to look into re-enabling the health check.

We removed it because we were having some trouble with the authentication
of the status endpoint from our custom health monitor on the F5. I
probably could have figured it out but was in a rush and wasn't sure of the
value it provided anyway. I wasn't ever aware of the User Agent based
health check until now.

I'm assuming the new endpoint won't need to be authenticated since the
current user agent approach isn't authenticated, correct? That would help
make it even better.

That said if I did still use /healthz and planned to transition to /heath
I would request a couple of releases where both endpoints were available.
Changing health check mid deploy while maintaining up time would be a
tricky task.

Mike

On Mon, Sep 19, 2016 at 4:42 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Thanks for the feedback, Mike.

Do you recall what kind of problems you had with the /heathz endpoint?

Here's few enhancements we've made recently that are healthcheck-related,
and eliminate scenarios where a load balancer might consider a router
instance healthy when it is not serving requests.

On graceful shutdown, the healthcheck response will return 503 for a
configurable duration before the server stops listening for requests [1].
This allows the router to continue serving requests until the load balancer
considers a router instance unhealthy (interval x threshold).

On startup, a gorouter instance won't be considered started by BOSH until
after the healthcheck has returned a 200 for a configurable duration [2].
This gives a load balancer time to consider the instance healthy before
BOSH rolls the next router instance during a deploy.

[1] https://github.com/cloudfoundry-incubator/routing-releas
e/blob/develop/jobs/gorouter/spec#L48
[2] https://github.com/cloudfoundry-incubator/routing-releas
e/blob/develop/jobs/gorouter/spec#L36

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Mon, Sep 19, 2016 at 2:37 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

We used to use the /healthz path but ran into some problems with it.

We eventually decided to stop using this endpoint and instead simply
check to see if gorouter is listening on 80. It was unclear to us what
value the /healthz check was doing that simply waiting for gorouter to
listen on 80 was providing.

Anyway, we're fine with renaming /healthz to /health and I would also
like to see some documentation or something about what having a LB checking
/health can provide more than simply ensuring the router is listening on 80.

Mike

On Mon, Sep 19, 2016 at 1:54 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

For a very long time, the /healthz endpoint has been documented as
deprecated. The recommended method of healthchecking Gorouter has been to
send a User-Agent http header.

We recently merged a PR that enabled configuring the value of the
User-Agent header as AWS, GCP, and Azure load balancers all send a
different value.

However, we've found that the User-Agent header is typically not
documented and difficult to discover, while configuring a load balancer
healthcheck with a path and port is ubiquitous. So we're planning to
refresh the http healthcheck endpoint. We're even adding http healthcheck
endpoints to the haproxy in cf-release and to the TCP router.

We don't know why the gorouter healthcheck endpoint was named /heathz
and not /heath, and rather than carry forward this legacy to our new
endpoints we're hoping we can rename the /heathz endpoint to /health. Would
this cause issues for anyone? Worst case, it would require a load balancer
config change synchronized with the deploy.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Anyone use the /heathz endpoint on Gorouter?

Mike Youngstrom
 

Those sound useful. I'll have to look into re-enabling the health check.

We removed it because we were having some trouble with the authentication
of the status endpoint from our custom health monitor on the F5. I
probably could have figured it out but was in a rush and wasn't sure of the
value it provided anyway. I wasn't ever aware of the User Agent based
health check until now.

I'm assuming the new endpoint won't need to be authenticated since the
current user agent approach isn't authenticated, correct? That would help
make it even better.

That said if I did still use /healthz and planned to transition to /heath I
would request a couple of releases where both endpoints were available.
Changing health check mid deploy while maintaining up time would be a
tricky task.

Mike

On Mon, Sep 19, 2016 at 4:42 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Thanks for the feedback, Mike.

Do you recall what kind of problems you had with the /heathz endpoint?

Here's few enhancements we've made recently that are healthcheck-related,
and eliminate scenarios where a load balancer might consider a router
instance healthy when it is not serving requests.

On graceful shutdown, the healthcheck response will return 503 for a
configurable duration before the server stops listening for requests [1].
This allows the router to continue serving requests until the load balancer
considers a router instance unhealthy (interval x threshold).

On startup, a gorouter instance won't be considered started by BOSH until
after the healthcheck has returned a 200 for a configurable duration [2].
This gives a load balancer time to consider the instance healthy before
BOSH rolls the next router instance during a deploy.

[1] https://github.com/cloudfoundry-incubator/routing-
release/blob/develop/jobs/gorouter/spec#L48
[2] https://github.com/cloudfoundry-incubator/routing-
release/blob/develop/jobs/gorouter/spec#L36

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Mon, Sep 19, 2016 at 2:37 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

We used to use the /healthz path but ran into some problems with it.

We eventually decided to stop using this endpoint and instead simply
check to see if gorouter is listening on 80. It was unclear to us what
value the /healthz check was doing that simply waiting for gorouter to
listen on 80 was providing.

Anyway, we're fine with renaming /healthz to /health and I would also
like to see some documentation or something about what having a LB checking
/health can provide more than simply ensuring the router is listening on 80.

Mike

On Mon, Sep 19, 2016 at 1:54 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

For a very long time, the /healthz endpoint has been documented as
deprecated. The recommended method of healthchecking Gorouter has been to
send a User-Agent http header.

We recently merged a PR that enabled configuring the value of the
User-Agent header as AWS, GCP, and Azure load balancers all send a
different value.

However, we've found that the User-Agent header is typically not
documented and difficult to discover, while configuring a load balancer
healthcheck with a path and port is ubiquitous. So we're planning to
refresh the http healthcheck endpoint. We're even adding http healthcheck
endpoints to the haproxy in cf-release and to the TCP router.

We don't know why the gorouter healthcheck endpoint was named /heathz
and not /heath, and rather than carry forward this legacy to our new
endpoints we're hoping we can rename the /heathz endpoint to /health. Would
this cause issues for anyone? Worst case, it would require a load balancer
config change synchronized with the deploy.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


SSL termination for private domains

Carlo Alberto Ferraris
 

I have a question about the SSL termination epic[1], whose goal IIUC is to provide the ability for operators to have multiple TLS certificates: it seems only shared domains are being considered (because the stories talk about *operators* setting up multiple certs); are there no plans for private domains? Put otherwise: are there plans for allowing *users* to provide the cert for a domain they registered in their org?

[1] https://www.pivotaltracker.com/epic/show/2135866

(I originally posted the question on slack but got no reply, so crossposting here)


Re: Admin activity without ruby based CLI?

Yogesh Gowdra
 

I figured that we can set different admin password in 'oauth-clients.xml'. With this approach, I can pretty much use APIs to create new clients and further oAuth related operations.

Thanks


Re: Anyone use the /heathz endpoint on Gorouter?

Shannon Coen
 

Thanks for the feedback, Mike.

Do you recall what kind of problems you had with the /heathz endpoint?

Here's few enhancements we've made recently that are healthcheck-related,
and eliminate scenarios where a load balancer might consider a router
instance healthy when it is not serving requests.

On graceful shutdown, the healthcheck response will return 503 for a
configurable duration before the server stops listening for requests [1].
This allows the router to continue serving requests until the load balancer
considers a router instance unhealthy (interval x threshold).

On startup, a gorouter instance won't be considered started by BOSH until
after the healthcheck has returned a 200 for a configurable duration [2].
This gives a load balancer time to consider the instance healthy before
BOSH rolls the next router instance during a deploy.

[1] https://github.com/cloudfoundry-incubator/routing-release/blob/develop/
jobs/gorouter/spec#L48
[2] https://github.com/cloudfoundry-incubator/routing-release/blob/develop/
jobs/gorouter/spec#L36

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Mon, Sep 19, 2016 at 2:37 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

We used to use the /healthz path but ran into some problems with it.

We eventually decided to stop using this endpoint and instead simply check
to see if gorouter is listening on 80. It was unclear to us what value the
/healthz check was doing that simply waiting for gorouter to listen on 80
was providing.

Anyway, we're fine with renaming /healthz to /health and I would also like
to see some documentation or something about what having a LB checking
/health can provide more than simply ensuring the router is listening on 80.

Mike

On Mon, Sep 19, 2016 at 1:54 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

For a very long time, the /healthz endpoint has been documented as
deprecated. The recommended method of healthchecking Gorouter has been to
send a User-Agent http header.

We recently merged a PR that enabled configuring the value of the
User-Agent header as AWS, GCP, and Azure load balancers all send a
different value.

However, we've found that the User-Agent header is typically not
documented and difficult to discover, while configuring a load balancer
healthcheck with a path and port is ubiquitous. So we're planning to
refresh the http healthcheck endpoint. We're even adding http healthcheck
endpoints to the haproxy in cf-release and to the TCP router.

We don't know why the gorouter healthcheck endpoint was named /heathz and
not /heath, and rather than carry forward this legacy to our new endpoints
we're hoping we can rename the /heathz endpoint to /health. Would this
cause issues for anyone? Worst case, it would require a load balancer
config change synchronized with the deploy.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Anyone use the /heathz endpoint on Gorouter?

Mike Youngstrom
 

We used to use the /healthz path but ran into some problems with it.

We eventually decided to stop using this endpoint and instead simply check
to see if gorouter is listening on 80. It was unclear to us what value the
/healthz check was doing that simply waiting for gorouter to listen on 80
was providing.

Anyway, we're fine with renaming /healthz to /health and I would also like
to see some documentation or something about what having a LB checking
/health can provide more than simply ensuring the router is listening on 80.

Mike

On Mon, Sep 19, 2016 at 1:54 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

For a very long time, the /healthz endpoint has been documented as
deprecated. The recommended method of healthchecking Gorouter has been to
send a User-Agent http header.

We recently merged a PR that enabled configuring the value of the
User-Agent header as AWS, GCP, and Azure load balancers all send a
different value.

However, we've found that the User-Agent header is typically not
documented and difficult to discover, while configuring a load balancer
healthcheck with a path and port is ubiquitous. So we're planning to
refresh the http healthcheck endpoint. We're even adding http healthcheck
endpoints to the haproxy in cf-release and to the TCP router.

We don't know why the gorouter healthcheck endpoint was named /heathz and
not /heath, and rather than carry forward this legacy to our new endpoints
we're hoping we can rename the /heathz endpoint to /health. Would this
cause issues for anyone? Worst case, it would require a load balancer
config change synchronized with the deploy.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: Admin activity without ruby based CLI?

Yogesh Gowdra
 

Hi Madhura,
Thanks for the response. But to use that API we need admin bearer access token which essentially requires that admin user be created. So my question is how do I start provisioning such admin account without using above mentioned tools. I know there is default 'admin' account. How do I reset its password without using these tools. Appreciate any insights on this.

Thanks


Anyone use the /heathz endpoint on Gorouter?

Shannon Coen
 

For a very long time, the /healthz endpoint has been documented as
deprecated. The recommended method of healthchecking Gorouter has been to
send a User-Agent http header.

We recently merged a PR that enabled configuring the value of the
User-Agent header as AWS, GCP, and Azure load balancers all send a
different value.

However, we've found that the User-Agent header is typically not documented
and difficult to discover, while configuring a load balancer healthcheck
with a path and port is ubiquitous. So we're planning to refresh the http
healthcheck endpoint. We're even adding http healthcheck endpoints to the
haproxy in cf-release and to the TCP router.

We don't know why the gorouter healthcheck endpoint was named /heathz and
not /heath, and rather than carry forward this legacy to our new endpoints
we're hoping we can rename the /heathz endpoint to /health. Would this
cause issues for anyone? Worst case, it would require a load balancer
config change synchronized with the deploy.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


[IMPORTANT] EOL Timeline for Legacy DEA Backend

Dieu Cao <dcao@...>
 

Hello all,

We would like to share the official End of Life timeline for the DEA
backend in Cloud Foundry.
Details can be found here [1] or in the attached pdf.

At a high level, the plan is to continue maintenance support for DEAs for 6
months from when Diego hits the Diego 1.0 release marker.
We expect that to happen towards the end of this month.

Please let us know if you have any questions/concerns.
Feel free to comment in the google doc.

-Dieu Cao
Runtime PMC Lead

[1] https://goo.gl/y0E3vL


Re: Admin activity without ruby based CLI?

Madhura Bhave
 

Hi Yogesh,

You can add users directly via the API. Here is the documentation for the
API: http://docs.cloudfoundry.org/api/uaa/#create61

Madhura

On Fri, Sep 16, 2016 at 1:58 PM, Yogesh Gowdra <yogeshgv(a)gmail.com> wrote:

Hi,
I am planning to use UAA to implement SSO for my java based micro
services. Our infrastructure does not let me use any other tools (like ruby
based tools like uaac or cf) apart from java based. Is there any way in UAA
I can setup new admin user or use existing admin user (by changing
passwords) for my client registrations and other setups? Any help much
appreciated.

Thanks


Admin activity without ruby based CLI?

Yogesh Gowdra
 

Hi,
I am planning to use UAA to implement SSO for my java based micro services. Our infrastructure does not let me use any other tools (like ruby based tools like uaac or cf) apart from java based. Is there any way in UAA I can setup new admin user or use existing admin user (by changing passwords) for my client registrations and other setups? Any help much appreciated.

Thanks


Re: Sharing single service instance across all orgs/spaces

Jacek Szlachta <jacek.szlachta@...>
 

Hi Vinod,

Yes, it is supported. Firehose pulls log data from loggregator, Cloud
Foundry's logging subsystem.
I recommend logsearch (http://www.logsearch.io/) with an extension for
Cloud Foundry (
https://github.com/cloudfoundry-community/logsearch-for-cloudfoundry)

Regards,
Jacek

On 16 September 2016 at 21:00, Vinod Singh <vinoddandy(a)gmail.com> wrote:

Thanks for quick response, Michael.

But I am using DEA CF 235 only. Is this supported on non-Diego version of
CF ?

Regards,
Vinod

On Fri, Sep 16, 2016 at 2:25 PM, Michal Kuratczyk <mkuratczyk(a)pivotal.io>
wrote:

Hi Vinod,

You can't do this using this approach indeed but Cloud Foundry provides
the Firehose component with all logs from all applications as a stream you
can use to feed you ELK stack.
The easiest way will be to deploy firehose-to-syslog nozzle (
https://github.com/cloudfoundry-community/firehose-to-syslog) which will
capture that data and send it to your ELK's syslog endpoint.

You can read more about Firehose here https://docs.cloudfoundry
.org/loggregator/architecture.html#firehose

Best regards,

On Fri, Sep 16, 2016 at 8:17 PM, Vinod Singh <vinoddandy(a)gmail.com>
wrote:

Hi All,

We are redirecting the application logs to ELK system from Cloud Foundry
deployment.

The issue is : we have to create a user provided service instance in
each space of each user's org to provide logging url to the application.
This is tedious because each time I create a new space I have to create a
CUPS for logging.

Solution : is it possible to create the service instance by CF admin in
his space/org and share across all user's orgs ? I know it is not possible
today because service instances are restricted to user's space only.

Can CF provide some solution in future to fulfill above user case ?

Thoughts/Comments ?

Regards,
Vinod


--
Michal Kuratczyk | Solution Architect | Pivotal Inc.
Mobile +48602421588 | mkuratczyk(a)pivotal.io


Re: Sharing single service instance across all orgs/spaces

Vinod Singh <vinoddandy@...>
 

Thanks for quick response, Michael.

But I am using DEA CF 235 only. Is this supported on non-Diego version of
CF ?

Regards,
Vinod

On Fri, Sep 16, 2016 at 2:25 PM, Michal Kuratczyk <mkuratczyk(a)pivotal.io>
wrote:

Hi Vinod,

You can't do this using this approach indeed but Cloud Foundry provides
the Firehose component with all logs from all applications as a stream you
can use to feed you ELK stack.
The easiest way will be to deploy firehose-to-syslog nozzle (
https://github.com/cloudfoundry-community/firehose-to-syslog) which will
capture that data and send it to your ELK's syslog endpoint.

You can read more about Firehose here https://docs.
cloudfoundry.org/loggregator/architecture.html#firehose

Best regards,

On Fri, Sep 16, 2016 at 8:17 PM, Vinod Singh <vinoddandy(a)gmail.com> wrote:

Hi All,

We are redirecting the application logs to ELK system from Cloud Foundry
deployment.

The issue is : we have to create a user provided service instance in each
space of each user's org to provide logging url to the application. This is
tedious because each time I create a new space I have to create a CUPS for
logging.

Solution : is it possible to create the service instance by CF admin in
his space/org and share across all user's orgs ? I know it is not possible
today because service instances are restricted to user's space only.

Can CF provide some solution in future to fulfill above user case ?

Thoughts/Comments ?

Regards,
Vinod


--
Michal Kuratczyk | Solution Architect | Pivotal Inc.
Mobile +48602421588 | mkuratczyk(a)pivotal.io


Re: Sharing single service instance across all orgs/spaces

Michal Kuratczyk
 

Hi Vinod,

You can't do this using this approach indeed but Cloud Foundry provides the
Firehose component with all logs from all applications as a stream you can
use to feed you ELK stack.
The easiest way will be to deploy firehose-to-syslog nozzle (
https://github.com/cloudfoundry-community/firehose-to-syslog) which will
capture that data and send it to your ELK's syslog endpoint.

You can read more about Firehose here
https://docs.cloudfoundry.org/loggregator/architecture.html#firehose

Best regards,

On Fri, Sep 16, 2016 at 8:17 PM, Vinod Singh <vinoddandy(a)gmail.com> wrote:

Hi All,

We are redirecting the application logs to ELK system from Cloud Foundry
deployment.

The issue is : we have to create a user provided service instance in each
space of each user's org to provide logging url to the application. This is
tedious because each time I create a new space I have to create a CUPS for
logging.

Solution : is it possible to create the service instance by CF admin in
his space/org and share across all user's orgs ? I know it is not possible
today because service instances are restricted to user's space only.

Can CF provide some solution in future to fulfill above user case ?

Thoughts/Comments ?

Regards,
Vinod
--
Michal Kuratczyk | Solution Architect | Pivotal Inc.
Mobile +48602421588 | mkuratczyk(a)pivotal.io


Sharing single service instance across all orgs/spaces

Vinod Singh <vinoddandy@...>
 

Hi All,

We are redirecting the application logs to ELK system from Cloud Foundry
deployment.

The issue is : we have to create a user provided service instance in each
space of each user's org to provide logging url to the application. This is
tedious because each time I create a new space I have to create a CUPS for
logging.

Solution : is it possible to create the service instance by CF admin in his
space/org and share across all user's orgs ? I know it is not possible
today because service instances are restricted to user's space only.

Can CF provide some solution in future to fulfill above user case ?

Thoughts/Comments ?

Regards,
Vinod


Re: Document about "suspended" org

Noburou TANIGUCHI
 

Hello Nick,

Thank you for your kind response.

I've made up a collection of information related behaviors with "suspended"
organization.

https://gist.github.com/nota-ja/287bdc3299d0c2847085f865b9f2e58d

Hope it helps your team's documentation.

Regards,


Nicholas Calugar wrote
Hi Noburou,

You are correct, this should be documented better. Would you mind filing
an
issue here and I’ll work with our documentation team to make this better:

https://github.com/cloudfoundry/docs-cloudfoundry-concepts


Thanks,

Nick

Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

On September 7, 2016 at 6:48:56 PM, Noburou TANIGUCHI (
dev(a).m001
)
wrote:

Thank you, Nicholas,

While the linked documents seems for me to tell almost nothing about
'suspended' orgs, your explanation is very helpful. I understood its
objective and how to use.

The last thing still I don't know is the details of the effects of it.
When
a org is suspended, which operations cannot be executed by the OrgManagers
/
OrgAuditors / OrgBillingManagers / SpaceManagers / SpaceDevelopers /
SpaceAuditors? Is there any list or table about them? If no, I think I can
make one. But this is not the solution. I think it should be a part of
docs.cloudfoundry.org. So if I make it, do you accept it as a part of
official document?

Regards,


Nicholas Calugar wrote
Hi Noburou,

The Organizations API documents a status:
http://apidocs.cloudfoundry.org/241/organizations/update_an_organization.html

It appears this can be “active” or “suspended”:
https://github.com/cloudfoundry/cloud_controller_ng/blob/dd9aab29120e455f15853534372d1e5549216691/app/models/runtime/organization.rb#L4

When the organization is suspended, various API requests are denied. This
is useful for operators to be able to suspend organizations for some
reason, e.g. not paying their bill.


Thanks,

Nick

Nicholas Calugar
Product Manager - Cloud Foundry API
Pivotal Software, Inc.

On September 6, 2016 at 3:44:27 AM, Noburou TANIGUCHI (
dev(a).m001
)
wrote:

Hi CF guys,

Is there any document / information about the status "suspended" of an
org?

I've found so many codes about it [1], but cannot find any document in
docs.cloudfoundry.org [2].

I want to know what is the objective(s) of it, what is expected in a
suspended org (it seems that everything in the org should be read-only),
and
how we can make use of it.

Thanks in advance.

[1]
https://github.com/cloudfoundry/cloud_controller_ng/search?utf8=%E2%9C%93&q=suspended&type=Code
[2] https://docs.cloudfoundry.org/search?q=suspended




-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Document-about-suspended-org-tp5716.html
Sent from the CF Dev mailing list archive at Nabble.com.




-----
I'm not a ...
Noburou TANIGUCHI
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Document-about-suspended-org-tp5716p5726.html
Sent from the CF Dev mailing list archive at Nabble.com.




-----
I'm not a ...
Noburou TANIGUCHI
--
View this message in context: http://cf-dev.70369.x6.nabble.com/Document-about-suspended-org-tp5716p5758.html
Sent from the CF Dev mailing list archive at Nabble.com.

3701 - 3720 of 9425