Date   

Re: [Proposal] Deprecation of the firehose endpoint

Johannes Tuchscherer
 

Hi Neil,

Thanks for the feedback. We actually created PRs for both, firehose-exporter[0] and to firehose-to-syslog[1]. We will continue working with the maintainers to get these pulled in. 

Best,
Johannes


On Tue, Mar 5, 2019 at 11:26 AM Neil MacDougall <neil.macdougall@...> wrote:
Johannes,

A 6 month deprecation window works for Stratos - that should be fine for us to update.

If you can work with the firehose-exporter project to get that updated and off the firehose within the next 2 or 3 months, that would be super helpful and give us time to integrate and test, assuming its a drop-in replacement for the current firehose based version.

Many thanks,

Neil

On 25 Feb 2019, at 23:51, Johannes Tuchscherer <jtuchscherer@...> wrote:

Hi everybody,

thanks for the continuous stream of feedback. We are definitely going to support the firehose-exporter and firehose-to-syslog projects off the firehose to the RLP. The stories in our backlog are coming up soon. Stanislav, do you think that looking at what we did with the firehose-to-syslog project would help you to migrate the kafka-firehose-nozzle?

Also, based on the feedback I have received so far I am open to increasing the deprecation window to 6 months. Would that be acceptable?

Thanks,
Johannes

On Sun, Feb 24, 2019 at 4:22 PM Stanislav German-Evtushenko <s.germanevtushenko@...> wrote:
Hi Johannes,

We are heavy users of loggregator and we have the same concerns as others in the thread.

We use loggregator for:
- storing all application logs for 6 month (regulations requirement) using kafka-firehose-nozzle
- getting all platform metrics for monitoring purposes using kafka-firehose-nozzle
- getting all applications metrics to provide monitoring dashboard using kafka-firehose-nozzle and cf-metrics-refinery (see https://cloudfoundry.slack.com/messages/C6WFZ5K0F/p1531268612000101)

Another concern is autoscaler (https://github.com/cloudfoundry-incubator/app-autoscaler-release). It is relying on loggregator and I haven't seen any updates on moving out of it yet.

Best regards,
Stanislav




Re: [Proposal] Deprecation of the firehose endpoint

Neil MacDougall
 

Johannes,

A 6 month deprecation window works for Stratos - that should be fine for us to update.

If you can work with the firehose-exporter project to get that updated and off the firehose within the next 2 or 3 months, that would be super helpful and give us time to integrate and test, assuming its a drop-in replacement for the current firehose based version.

Many thanks,

Neil

On 25 Feb 2019, at 23:51, Johannes Tuchscherer <jtuchscherer@...> wrote:

Hi everybody,

thanks for the continuous stream of feedback. We are definitely going to support the firehose-exporter and firehose-to-syslog projects off the firehose to the RLP. The stories in our backlog are coming up soon. Stanislav, do you think that looking at what we did with the firehose-to-syslog project would help you to migrate the kafka-firehose-nozzle?

Also, based on the feedback I have received so far I am open to increasing the deprecation window to 6 months. Would that be acceptable?

Thanks,
Johannes

On Sun, Feb 24, 2019 at 4:22 PM Stanislav German-Evtushenko <s.germanevtushenko@...> wrote:
Hi Johannes,

We are heavy users of loggregator and we have the same concerns as others in the thread.

We use loggregator for:
- storing all application logs for 6 month (regulations requirement) using kafka-firehose-nozzle
- getting all platform metrics for monitoring purposes using kafka-firehose-nozzle
- getting all applications metrics to provide monitoring dashboard using kafka-firehose-nozzle and cf-metrics-refinery (see https://cloudfoundry.slack.com/messages/C6WFZ5K0F/p1531268612000101)

Another concern is autoscaler (https://github.com/cloudfoundry-incubator/app-autoscaler-release). It is relying on loggregator and I haven't seen any updates on moving out of it yet.

Best regards,
Stanislav




Re: Announcement: CC API v2 Deprecation Plan

Guillaume Berche
 

Hi Greg,

I'd like to renew related feedback provided last october on the subject at https://lists.cloudfoundry.org/g/cf-dev/topic/26659245#8303

There are many tooling out there that currently rely on the CC API V2 (such as UIs, service brokers, provisionning tools such as terraform-provider-cf or SAP MTA...). These tooling usually leverage CC API clients [2]. Ways to reduce impacts for such tooling would be to work with client maintainers (both official, experimental and unsupported) to sync the CC API V2 deprecation with availability of CC API V3 support in clients from most widely used programming languages.

In particular, regarding the go-lang client, we had a related exchange with the CLI team at cf summit, and a related issue https://github.com/cloudfoundry/cli/issues/1481 tracks this feedback, which seems to have received positive community interest. It would be useful to hear feedback from the CLI or VAT teams on this suggestion.

Thanks,

Guillaume.


On Wed, Feb 13, 2019 at 11:34 PM Greg Cobb <gcobb@...> wrote:
Greetings cf-dev!

The V3 Acceleration Team has been hard at work expanding the CC v3 API to cover resources that were previously only available on the v2 API. We are now ready to announce our CC V2 API Deprecation Plan.

As per the plan, we will announce the start of the v2 deprecation window at a future date. We recognize that transitioning from the v2 API will be an involved process for some clients, so we recommend starting now for resources that are available on the v3 API. 

Please feel free to comment on the document, respond to this email, or message us in the #v3-acceleration-team channel on the Cloud Foundry Slack if you have any questions.

In the meantime, we are still soliciting feedback on the remaining v3 API proposals and the v3 API in general. We would like to give a shout out to the Stratos team for their in-depth notes about their experiences using v3.

Thanks!
V3 Acceleration Team


Re: Managing services...instance limit for this service has been reached

orlysicat <Orlando_Sicat@...>
 

Hi, guys. I'm facing the same problem. I would've liked to peep into the
links you gave, Ben, but they are all dead. Can you please share them again?
Thanks



--
Sent from: http://cf-dev.70369.x6.nabble.com/


Re: Request for Feedback: Metadata Feature and CLI Options

Stefan Mayr
 

Hi Abby,

Am 04.03.2019 um 07:20 schrieb Abby Chau:
Please see if you able to add comments and if not, we can look into what
the issue might be. 
Commenting works now.

Thanks,

- Stefan


Re: Request for Feedback: Metadata Feature and CLI Options

Abby Chau
 

Hi Stefan,

Thanks for reaching out, glad there's excitement about the feature. The document should be accessible to anyone who has the link (they should also be able to comment as well, which we would appreciate to get a pulse and feedback on the CLI options) - please let us know if you are unable to add comments. 

Thanks for asking about the set-env (key,value versus = sign) - we did think of that option as well and now I wish we had added that option to the document.  

Please see if you able to add comments and if not, we can look into what the issue might be. 

Best,

Abby

On Mon, Mar 4, 2019 at 1:33 AM Stefan Mayr <stefan@...> wrote:
Hi Abby,

Am 02.03.2019 um 08:28 schrieb Abby Chau:
> Hello again,
>
> We are writing to let you know the CF CLI team will be supporting an
> upcoming feature, metadata, which allow users to associate resources
> with information (labels) to provide human friendly descriptions for
> things like managing external system identifiers, tracking owner and
> contact information.[1]
>
> For more information regarding the feature, see and provide comments on
> this document
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1fVO3nA0T5uApN5yWqSZaD3ddZQClCzogeivKxhriLJs_edit-3Fusp-3Dsharing&d=DwIFaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=liU6OeWExDTKt6ST32Np9Q&m=pCjPCUXoba7B26W2dxttdTOLgO7oHk5uehq5_8TgGDg&s=Ir-9fKA1ArWmBbYvA4-lHdq0taJxx_iamsAZf5XKPCs&e=>.
> Your feedback is greatly appreciated. Thanks again! 
>
> Best,
>
> CF CLI Team
>
> [1] CAPI Feature Narrative
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1Ebko-5FwNu4wWLnAdHg6wmydEMTx-5FIdwYnb4Ys0mxVmM4_edit&d=DwIFaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=liU6OeWExDTKt6ST32Np9Q&m=pCjPCUXoba7B26W2dxttdTOLgO7oHk5uehq5_8TgGDg&s=dQ7ZCM1wRKyZ7mZMSmHhfPw2uPnU7w21TIO_FA37Xxo&e=>
> _._,_._,_

after having seen some more or less elegant workarounds on CF summits we
really appreciate this becoming a native feature for the v3 API. How do
you want to count votes for option #1 or #2? Mailinglist or a comment on
the document? The document is still read-only. Shall we request write
access individually or will it be opened for everyone?

As this proposal worries values consistency of old and new commands I
have to ask one question: cf set-env uses key and value as individual
parameters without an in-between equal-sign. Is there a reason why both
options use one parameter key=value?

- Stefan
















Re: Request for Feedback: Metadata Feature and CLI Options

Stefan Mayr
 

Hi Abby,

Am 02.03.2019 um 08:28 schrieb Abby Chau:
Hello again,

We are writing to let you know the CF CLI team will be supporting an
upcoming feature, metadata, which allow users to associate resources
with information (labels) to provide human friendly descriptions for
things like managing external system identifiers, tracking owner and
contact information.[1]

For more information regarding the feature, see and provide comments on
this document
<https://docs.google.com/document/d/1fVO3nA0T5uApN5yWqSZaD3ddZQClCzogeivKxhriLJs/edit?usp=sharing>.
Your feedback is greatly appreciated. Thanks again! 

Best,

CF CLI Team

[1] CAPI Feature Narrative
<https://docs.google.com/document/d/1Ebko_wNu4wWLnAdHg6wmydEMTx_IdwYnb4Ys0mxVmM4/edit>
_._,_._,_
after having seen some more or less elegant workarounds on CF summits we
really appreciate this becoming a native feature for the v3 API. How do
you want to count votes for option #1 or #2? Mailinglist or a comment on
the document? The document is still read-only. Shall we request write
access individually or will it be opened for everyone?

As this proposal worries values consistency of old and new commands I
have to ask one question: cf set-env uses key and value as individual
parameters without an in-between equal-sign. Is there a reason why both
options use one parameter key=value?

- Stefan


Request for Feedback: Metadata Feature and CLI Options

Abby Chau
 

Hello again,

We are writing to let you know the CF CLI team will be supporting an upcoming feature, metadata, which allow users to associate resources with information (labels) to provide human friendly descriptions for things like managing external system identifiers, tracking owner and contact information.[1]

For more information regarding the feature, see and provide comments on this document. Your feedback is greatly appreciated. Thanks again! 

Best,

CF CLI Team


Stratos Deployment Survey

Neil MacDougall
 

Hi All,

The Stratos team is keen to understand more about how our users are deploying Stratos.

To this end we’ve put together a short survey that we’d love it if you could take a minute or two to complete:


Based on you’re responses, we’ll look at changes we can make to better support the most used deployment scenarios and (possibly) remove some of the deployment mechanisms that aren’t being used.

Thank you in advance.

Regards,

Neil
on behalf of the Stratos team


Request for Feedback: New Deployment Workflows With CLI Options

Abby Chau
 

Hi everyone,


We are writing to inform and invite feedback from the Community regarding upcoming work on the CLI V7 beta:

  • two upcoming features (Rolling Deployments and App Rollbacks)

  • proposed changes to app starts/restart CLI commands to support these features

  • and several CLI workflow options to support the new features. Any future deployment strategy work will likely follow the same CLI command patterns

Please see details about the above topics here - we would appreciate any feedback in the comments section of the document. Thank you, and we hope to hear from you.


Best,


CF CLI and CAPI Teams





Re: Propose removing --no-start from cf push in CLI v7

Abby Chau
 

Hi everyone,

Thanks to everyone who gave us feedback regarding the `--no-start` flag on the V7 CLI. Apologies it's taken so long to close the loop. We appreciate your feedback (and suggestions for alternative solutions) - they were all valuable to inform[1] our decisions. 

We wanted to circle back to let you know that after consideration we've decided to re-implement the standard workflow for `--no-start` on `cf push` on the V7 CLI (we are still far from releasing a GA version but have been releasing V7 beta CLI releases).  

Given the ubiquitous of usage and the complicated use cases for `--no-start`, we felt it was valuable to reimplement the standard functionality as long as we were also able to support other complicated deployment workflows, including granular commands and rollbacks. 

We don't plan on making changes to the standard no-start workflow: `cf push app --no-start` --> apply config --> `cf start` however we do plan on making changes to `cf start` to enable more complicated workflows in the following ways:
  • if a user has rolled back an app, `cf start` will start the app using the same droplet they've roll back 
  • if a user has rolled back their app, and they want the latest droplet, they can use a new `--latest` flag on `cf start`. 
The changes to `cf start` and the roll back functionality does not currently exist on V7 beta CLI but we hope to start work on them soon. 

To read more about what I've detailed above (including what "standard --no-start workflow" even means), and the new deployment workflows we plan to build on V7 beta CLI, please read and comment on Request for Feedback: New Deployment Workflows With CLI Options. As always, your feedback is valuable. 

Please do not hesitate to get in touch if you have any questions or additional feedback by:
  • replying to this email
  • commenting on the above doc
  • reaching out on #Cloud Foundry Slack 
Best,

Abby
CF CLI, Product Manager


[1] I've included screenshots of some of the CLI command modeling we did to give you an idea of how much consideration we gave to this subject matter, particularly given your feedback on the various use cases for running `--no-start` with `cf push`.

On Fri, Oct 5, 2018 at 10:15 AM Zach Robinson <zrobinson@...> wrote:
Hi Norm,

That's an interesting possible UX. Part of this process is to gather feedback before making a change and to potentially alter the proposal to better fit everybody's needs.  Thanks for sharing this.


Re: request to move app-autoscaler from cloudfoundry-incubator to cloudfoundry organization

Chris Clark
 

Congrats, Bo and team!  I'll reach out to you today and we can proceed with migration.


On Wed, Feb 27, 2019 at 10:55 AM Bo Yang <byang@...> wrote:
Thanks Michael! 

@Chris,  please let us know once it is ready for us to move code over. 

Best Regards, 

- Bo

-----Michael Maximilien/Almaden/IBM wrote: -----
To: Bo Yang/Seattle/IBM@IBMUS, cf-dev@..., cf-extensions-pmc@...
From: Michael Maximilien/Almaden/IBM
Date: 02/27/2019 10:44AM
Cc: cclark@...
Subject: Re: request to move app-autoscaler from cloudfoundry-incubator to cloudfoundry organization

Hi, Bo and App AutoScaler team,
 
Thanks for your request to move the App AutoScaler project [0] out of incubation into the core cloudfoundry organization [1].
 
Based on your evidences (listed below) and no descending comments from the PMC and our process [2] I welcome your request.
 
Over the next few days, let's work with Chris (on CC:) from the CFF to help you in that move.
 
Congratulations. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 
----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: Bo Yang/Seattle/IBM@IBMUS
Cc: cclark@..., cf-extensions-pmc@...
Subject: Re: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 1:30 PM
 
Hi, Bo,
 
Thanks for this request and justification. You make a strong point.
 
----------
Let me give everyone on the PMC a chance to chime in. I am particularly interested if they have any descending constructive views---email the list or me directly.
 
Let's give everyone until Wednesday 02/27 8:00 AM Pacific for any objections. If none, then Chris and I will work with you to move your project.
 
Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 
----- Original message -----
From: "Bo Yang" <byang@...>
Sent by: cf-extensions-pmc@...
To: cf-extensions-pmc@...
Cc: "Michael Maximilien" <maxim@...>, "Chris Clark" <cclark@...>
Subject: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 12:04 PM
 
Hi, 
 
We are requesting to move app-autoscaler project from "github.com/cloudfoundry-incubator" to "github.com/cloudfoundry" given we think it has  reached a level that we can graduate it from an incubator. Here are the justifications
 
1. This project has been GAed in Sep 2018
2. It has been running in production for quite some time at SwissCom and SAP
3. It has been formally released as part of commercial offering of IBM Cloud. See "what is new in Cloud Foundry Enterprise Environment version 2.1.0"  ( https://cloud.ibm.com/docs/cloud-foundry?topic=cloud-foundry-what-s-new-in-ibm-cloud-foundry-enterprise-environment#v210 )
 
thanks, 

-Bo
 

 

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To post to this group, send email to cf-extensions-pmc@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/OFCE5C6069.CB0BF5F3-ON002583AC.006D6F9F-002583AC.006E4564%40notes.na.collabserv.com.
 
 

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To post to this group, send email to cf-extensions-pmc@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/OF1C9CCC00.D946C90E-ON002583AE.0067FAFA-002583AE.0067FB0B%40notes.na.collabserv.com.


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: request to move app-autoscaler from cloudfoundry-incubator to cloudfoundry organization

Bo Yang <byang@...>
 

Thanks Michael! 

@Chris,  please let us know once it is ready for us to move code over. 

Best Regards, 

- Bo

-----Michael Maximilien/Almaden/IBM wrote: -----
To: Bo Yang/Seattle/IBM@IBMUS, cf-dev@..., cf-extensions-pmc@...
From: Michael Maximilien/Almaden/IBM
Date: 02/27/2019 10:44AM
Cc: cclark@...
Subject: Re: request to move app-autoscaler from cloudfoundry-incubator to cloudfoundry organization

Hi, Bo and App AutoScaler team,
 
Thanks for your request to move the App AutoScaler project [0] out of incubation into the core cloudfoundry organization [1].
 
Based on your evidences (listed below) and no descending comments from the PMC and our process [2] I welcome your request.
 
Over the next few days, let's work with Chris (on CC:) from the CFF to help you in that move.
 
Congratulations. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: Bo Yang/Seattle/IBM@IBMUS
Cc: cclark@..., cf-extensions-pmc@...
Subject: Re: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 1:30 PM
 
Hi, Bo,
 
Thanks for this request and justification. You make a strong point.
 
----------
Let me give everyone on the PMC a chance to chime in. I am particularly interested if they have any descending constructive views---email the list or me directly.
 
Let's give everyone until Wednesday 02/27 8:00 AM Pacific for any objections. If none, then Chris and I will work with you to move your project.
 
Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 
----- Original message -----
From: "Bo Yang" <byang@...>
Sent by: cf-extensions-pmc@...
To: cf-extensions-pmc@...
Cc: "Michael Maximilien" <maxim@...>, "Chris Clark" <cclark@...>
Subject: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 12:04 PM
 
Hi, 
 
We are requesting to move app-autoscaler project from "github.com/cloudfoundry-incubator" to "github.com/cloudfoundry" given we think it has  reached a level that we can graduate it from an incubator. Here are the justifications
 
1. This project has been GAed in Sep 2018
2. It has been running in production for quite some time at SwissCom and SAP
3. It has been formally released as part of commercial offering of IBM Cloud. See "what is new in Cloud Foundry Enterprise Environment version 2.1.0"  ( https://cloud.ibm.com/docs/cloud-foundry?topic=cloud-foundry-what-s-new-in-ibm-cloud-foundry-enterprise-environment#v210 )
 
thanks, 

-Bo
 

 

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To post to this group, send email to cf-extensions-pmc@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/OFCE5C6069.CB0BF5F3-ON002583AC.006D6F9F-002583AC.006E4564%40notes.na.collabserv.com.
 
 


Re: request to move app-autoscaler from cloudfoundry-incubator to cloudfoundry organization

Chip Childers
 

Congratulations Bo and the rest of the team!

Chip Childers, CTO
Cloud Foundry Foundation


On Wed, Feb 27, 2019 at 1:44 PM Michael Maximilien <maxim@...> wrote:
Hi, Bo and App AutoScaler team,
 
Thanks for your request to move the App AutoScaler project [0] out of incubation into the core cloudfoundry organization [1].
 
Based on your evidences (listed below) and no descending comments from the PMC and our process [2] I welcome your request.
 
Over the next few days, let's work with Chris (on CC:) from the CFF to help you in that move.
 
Congratulations. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 
----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: Bo Yang/Seattle/IBM@IBMUS
Cc: cclark@..., cf-extensions-pmc@...
Subject: Re: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 1:30 PM
 
Hi, Bo,
 
Thanks for this request and justification. You make a strong point.
 
----------
Let me give everyone on the PMC a chance to chime in. I am particularly interested if they have any descending constructive views---email the list or me directly.
 
Let's give everyone until Wednesday 02/27 8:00 AM Pacific for any objections. If none, then Chris and I will work with you to move your project.
 
Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 
----- Original message -----
From: "Bo Yang" <byang@...>
Sent by: cf-extensions-pmc@...
To: cf-extensions-pmc@...
Cc: "Michael Maximilien" <maxim@...>, "Chris Clark" <cclark@...>
Subject: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 12:04 PM
 
Hi, 
 
We are requesting to move app-autoscaler project from "github.com/cloudfoundry-incubator" to "github.com/cloudfoundry" given we think it has  reached a level that we can graduate it from an incubator. Here are the justifications
 
1. This project has been GAed in Sep 2018
2. It has been running in production for quite some time at SwissCom and SAP
3. It has been formally released as part of commercial offering of IBM Cloud. See "what is new in Cloud Foundry Enterprise Environment version 2.1.0"  ( https://cloud.ibm.com/docs/cloud-foundry?topic=cloud-foundry-what-s-new-in-ibm-cloud-foundry-enterprise-environment#v210 )
 
thanks, 

-Bo
 

 

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To post to this group, send email to cf-extensions-pmc@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/OFCE5C6069.CB0BF5F3-ON002583AC.006D6F9F-002583AC.006E4564%40notes.na.collabserv.com.
 
 

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To post to this group, send email to cf-extensions-pmc@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/OFC97623BA.A9513262-ON002583AE.006650AC-002583AE.0066EEDB%40notes.na.collabserv.com.


Re: request to move app-autoscaler from cloudfoundry-incubator to cloudfoundry organization

Michael Maximilien
 

Hi, Bo and App AutoScaler team,
 
Thanks for your request to move the App AutoScaler project [0] out of incubation into the core cloudfoundry organization [1].
 
Based on your evidences (listed below) and no descending comments from the PMC and our process [2] I welcome your request.
 
Over the next few days, let's work with Chris (on CC:) from the CFF to help you in that move.
 
Congratulations. Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: Bo Yang/Seattle/IBM@IBMUS
Cc: cclark@..., cf-extensions-pmc@...
Subject: Re: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 1:30 PM
 
Hi, Bo,
 
Thanks for this request and justification. You make a strong point.
 
----------
Let me give everyone on the PMC a chance to chime in. I am particularly interested if they have any descending constructive views---email the list or me directly.
 
Let's give everyone until Wednesday 02/27 8:00 AM Pacific for any objections. If none, then Chris and I will work with you to move your project.
 
Best,

------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 
----- Original message -----
From: "Bo Yang" <byang@...>
Sent by: cf-extensions-pmc@...
To: cf-extensions-pmc@...
Cc: "Michael Maximilien" <maxim@...>, "Chris Clark" <cclark@...>
Subject: request to move app-autoscaler from
Date: Mon, Feb 25, 2019 12:04 PM
 
Hi, 
 
We are requesting to move app-autoscaler project from "github.com/cloudfoundry-incubator" to "github.com/cloudfoundry" given we think it has  reached a level that we can graduate it from an incubator. Here are the justifications
 
1. This project has been GAed in Sep 2018
2. It has been running in production for quite some time at SwissCom and SAP
3. It has been formally released as part of commercial offering of IBM Cloud. See "what is new in Cloud Foundry Enterprise Environment version 2.1.0"  ( https://cloud.ibm.com/docs/cloud-foundry?topic=cloud-foundry-what-s-new-in-ibm-cloud-foundry-enterprise-environment#v210 )
 
thanks, 

-Bo
 

 

--
You received this message because you are subscribed to the Google Groups "cf-extensions-pmc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-extensions-pmc+unsubscribe@....
To post to this group, send email to cf-extensions-pmc@....
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/cf-extensions-pmc/OFCE5C6069.CB0BF5F3-ON002583AC.006D6F9F-002583AC.006E4564%40notes.na.collabserv.com.
 
 


#Spring #java buildpack #Spring Autoreconfiguration #spring #java

sivanes.may28@...
 

I am trying to deploy the legacy spring (version 1.1) application in cloud foundry. I want to use spring auto-reconfiguration feature for the app but the feature is not enabled for my app.But if I try changing higher versions of spring, I could see this feature is enabled in the java build pack. Can't we use spring auto-reconfiguration feature for spring older versions like 1.1 and 2.0.?Thanks in Advance


Re: [Proposal] Deprecation of the firehose endpoint

Johannes Tuchscherer
 

Hi everybody,

thanks for the continuous stream of feedback. We are definitely going to support the firehose-exporter and firehose-to-syslog projects off the firehose to the RLP. The stories in our backlog are coming up soon. Stanislav, do you think that looking at what we did with the firehose-to-syslog project would help you to migrate the kafka-firehose-nozzle?

Also, based on the feedback I have received so far I am open to increasing the deprecation window to 6 months. Would that be acceptable?

Thanks,
Johannes

On Sun, Feb 24, 2019 at 4:22 PM Stanislav German-Evtushenko <s.germanevtushenko@...> wrote:
Hi Johannes,

We are heavy users of loggregator and we have the same concerns as others in the thread.

We use loggregator for:
- storing all application logs for 6 month (regulations requirement) using kafka-firehose-nozzle
- getting all platform metrics for monitoring purposes using kafka-firehose-nozzle
- getting all applications metrics to provide monitoring dashboard using kafka-firehose-nozzle and cf-metrics-refinery (see https://cloudfoundry.slack.com/messages/C6WFZ5K0F/p1531268612000101)

Another concern is autoscaler (https://github.com/cloudfoundry-incubator/app-autoscaler-release). It is relying on loggregator and I haven't seen any updates on moving out of it yet.

Best regards,
Stanislav


Re: [Proposal] Deprecation /containermetrics endpoint on the loggregator_trafficcontroller

Johannes Tuchscherer
 

Hi there,

we haven't heard from anyone who is currently consuming the /containermetrics endpoint. We went ahead an removed it. It will be gone as of loggregator release 105.

Please let us know if you have any questions. You can reach us in the Cloud Foundry slack in the #loggregator channel.

Best,
Johannes

On Mon, Feb 4, 2019 at 12:03 PM Johannes Tuchscherer <jtuchscherer@...> wrote:
Hi there,

the loggregator team would like to remove the /containermetrics endpoint on the loggregator_trafficcontroller (see here: https://github.com/cloudfoundry/loggregator-release/blob/master/docs/trafficcontroller.md#endpoints). This endpoint originally was introduced as an endpoint for the Cloud Controller to fetch metrics about the running container.
As of cf-deployment v7.2 (https://github.com/cloudfoundry/cf-deployment/releases/tag/v7.2.0), Cloud Controller now reaches out to log-cache to fetch the container metrics. 
Therefore, we would like to remove this endpoint to keep our API and code base lean and clean. If there are consumers of this endpoint besides the Cloud Controller, please let us know. 

Thanks,
Johannes


Re: [Proposal] Deprecation of the firehose endpoint

Stanislav German-Evtushenko
 

Hi Johannes,

We are heavy users of loggregator and we have the same concerns as others in the thread.

We use loggregator for:
- storing all application logs for 6 month (regulations requirement) using kafka-firehose-nozzle
- getting all platform metrics for monitoring purposes using kafka-firehose-nozzle
- getting all applications metrics to provide monitoring dashboard using kafka-firehose-nozzle and cf-metrics-refinery (see https://cloudfoundry.slack.com/messages/C6WFZ5K0F/p1531268612000101)

Another concern is autoscaler (https://github.com/cloudfoundry-incubator/app-autoscaler-release). It is relying on loggregator and I haven't seen any updates on moving out of it yet.

Best regards,
Stanislav


Re: Retrieving events for a custom UAA Installation #cf

Shetty, Viraj S [CTR]
 

Any ideas from anyone ?