Here is the link to the survey: https://goo.gl/forms/5lHCbAIEiQf03G1g2. Thanks!

On Fri, Jun 22, 2018 at 9:36 AM, Abby Chau <achau@...> wrote:

Hi everyone,

The CF CLI team sent out a two minute survey recently to gather feedback on changes [1] to the `cf app` display summary information. Please have your say on how the `cf app` summary will change in a future release. Thanks!

Best,

Abby Chau and the CLI team

CF Product Manager, CF CLI

[1]  Based on your feedback recently, we've decided to change the `cf app` to default to the v3 app endpoint. What this means is: 

• users on CC API 3.27.0 or higher, the `cf app app-name` display will change in an upcoming CF CLI release - how the display will change is largely based on your feedback above 
• for users on CC API 3.27.0 or lower, you will continue to see the current `cf app app-name` display; you will not see the new v3 display unless you upgrade to CC API 3.27.0 or higher (and you have the latest version of the CF CLI)

***note, if you are a dedicated Cloud Foundry committer, this is identical to a survey we sent out to you in January.  If you completed that survey, you can ignore this***

- Do you work on Cloud Foundry?

- Have you submitted a pull request or an issue to a Cloud Foundry project?

- Have you written, edited or updated cf-docs?

- Have you participated in a discussion that materialized into a project/update?

- Have you helped champion Cloud Foundry at a Meetup, CF Summit, or an industry event?

- Have you shared your enthusiasm and inspired folks to join the Cloud Foundry community?

Answered Yes to any of the above? Then please take this survey and help us measure our community’s diversity.

Thank you!

- The Cloud Foundry Foundation

On Wed, Jun 27, 2018 at 7:30 PM Abby Chau <achau@...> wrote:

Wondering if you folks have tried using the `v3-create-app` command as Mike has pointed out (and Zach elsewhere). The command is basically the equivalent of `cf push test --no-start` in that it creates an app, leaves it in a `stopped` state, and users can then apply configurations, bind services, set-groups, enable ssh, etc. This command appears to be a workaround for your use cases, but please let us know if that's incorrect. 

My 2 cents here, FWIW... the v3-foo$ syntax feels like it should be only temporary and should eventually be merged back into the more standard commands / feature flag combos.

--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

On Wed, Jun 27, 2018 at 7:30 PM Abby Chau <achau@...> wrote:

Wondering if you folks have tried using the `v3-create-app` command as Mike has pointed out (and Zach elsewhere). The command is basically the equivalent of `cf push test --no-start` in that it creates an app, leaves it in a `stopped` state, and users can then apply configurations, bind services, set-groups, enable ssh, etc. This command appears to be a workaround for your use cases, but please let us know if that's incorrect. 

My 2 cents here, FWIW... the v3-foo$ syntax feels like it should be only temporary and should eventually be merged back into the more standard commands / feature flag combos.

--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

thanks to all that have replied.

i'd like to ask a clarifying question.  it sounds like most of these use-cases are "set up some environment for the app".  this implies to me that these workflows are for new apps and not for updating existing ones.  does that sound right?  are their use-cases for "no-start" when updating an app?

thanks!

-zach

On Wed, Jun 27, 2018 at 4:30 PM Abby Chau <achau@...> wrote:

Hey Bernd and Julian,

Many thanks for your responses. 

Wondering if you folks have tried using the `v3-create-app` command as Mike has pointed out (and Zach elsewhere). The command is basically the equivalent of `cf push test --no-start` in that it creates an app, leaves it in a `stopped` state, and users can then apply configurations, bind services, set-groups, enable ssh, etc. This command appears to be a workaround for your use cases, but please let us know if that's incorrect. 

Best,

Abby

On Wed, Jun 27, 2018 at 3:04 PM, Hjortshoj, Julian <Julian.Hjortshoj@...> wrote:

+1 to that last use case.  In particular, if a service requires bind configuration, then it's not possible to put the binding in an app manifest (because manifests don't support service binding configuration) so it is very helpful to keep your app from starting until the service is bound.

Adding the ability to specify bind configuration in an application manifest might be a reasonable mitigation if --no-start were to disappear.

HTH,

-Julian

---

From: cf-dev@... [cf-dev@...] on behalf of Krannich, Bernd [bernd.krannich@...]
Sent: Wednesday, June 27, 2018 9:55 AM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

Hi Abby,

 

Thank you very much for reaching out. Indeed, we are frequent users of the `no-start` flag. A couple of use cases:

 

• After a `cf ssh-enable APP_NAME`, you’ll need to restart your app to be able to SSH in. To prevent starting the app twice in that process, people do a `cf push --no-start` and then an explicit `cf start APP_NAME` afterwards.
• The same applies for changes of security groups which also require an app restart.
• Lastly, and maybe most importantly, people use `no-start` for pushing an app to which they want to bind services. They push the app with “no-start”, “cf create-service” their services, “cf bind-service” them to the app, and only then start the app.

 

So, I guess in summary, for all operations changing the app environment, doing those changes with the app not yet started is a common use case for us.

 

Regards,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

 

 

From: <cf-dev@...> on behalf of Abby Chau <achau@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 27. June 2018 at 18:18
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

 

Hi everyone,

 

The CF CLI is soliciting feedback on how you use the `no-start` flag: 

• what are your specific use cases? 
• if the flag was no longer available, how might that affect you? (Would you strongly object to such a change, and why?) would you have a sensible workaround?

 

Feedback

 

Please contact us on the #cli channel on Cloud Foundry Slack. Alternatively, respond directly to this email.

Best,

Abby Chau

CF Product Manager, CF CLI

 

Note: The CF CLI team is currently working on updating the `cf v3-push` command to use the server side manifest work we've completed (with the Capi team), and to update the command such that it has as much feature parity with the current `cf-push` as possible. The eventual goal is to make the `cf push` command default to the enhanced v3-push command for users (on cc api 3.27 or higher). Since there is more granular control options in v3, `no-start` is a more nebulous flag.

Hey Bernd and Julian,

Many thanks for your responses. 

Wondering if you folks have tried using the `v3-create-app` command as Mike has pointed out (and Zach elsewhere). The command is basically the equivalent of `cf push test --no-start` in that it creates an app, leaves it in a `stopped` state, and users can then apply configurations, bind services, set-groups, enable ssh, etc. This command appears to be a workaround for your use cases, but please let us know if that's incorrect. 

Best,

Abby

On Wed, Jun 27, 2018 at 3:04 PM, Hjortshoj, Julian <Julian.Hjortshoj@...> wrote:

+1 to that last use case.  In particular, if a service requires bind configuration, then it's not possible to put the binding in an app manifest (because manifests don't support service binding configuration) so it is very helpful to keep your app from starting until the service is bound.

Adding the ability to specify bind configuration in an application manifest might be a reasonable mitigation if --no-start were to disappear.

HTH,

-Julian

---

From: cf-dev@... [cf-dev@...] on behalf of Krannich, Bernd [bernd.krannich@...]
Sent: Wednesday, June 27, 2018 9:55 AM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

Hi Abby,

 

Thank you very much for reaching out. Indeed, we are frequent users of the `no-start` flag. A couple of use cases:

 

• After a `cf ssh-enable APP_NAME`, you’ll need to restart your app to be able to SSH in. To prevent starting the app twice in that process, people do a `cf push --no-start` and then an explicit `cf start APP_NAME` afterwards.
• The same applies for changes of security groups which also require an app restart.
• Lastly, and maybe most importantly, people use `no-start` for pushing an app to which they want to bind services. They push the app with “no-start”, “cf create-service” their services, “cf bind-service” them to the app, and only then start the app.

 

So, I guess in summary, for all operations changing the app environment, doing those changes with the app not yet started is a common use case for us.

 

Regards,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

 

 

From: <cf-dev@...> on behalf of Abby Chau <achau@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 27. June 2018 at 18:18
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

 

Hi everyone,

 

The CF CLI is soliciting feedback on how you use the `no-start` flag: 

• what are your specific use cases? 
• if the flag was no longer available, how might that affect you? (Would you strongly object to such a change, and why?) would you have a sensible workaround?

 

Feedback

 

Please contact us on the #cli channel on Cloud Foundry Slack. Alternatively, respond directly to this email.

Best,

Abby Chau

CF Product Manager, CF CLI

 

Note: The CF CLI team is currently working on updating the `cf v3-push` command to use the server side manifest work we've completed (with the Capi team), and to update the command such that it has as much feature parity with the current `cf-push` as possible. The eventual goal is to make the `cf push` command default to the enhanced v3-push command for users (on cc api 3.27 or higher). Since there is more granular control options in v3, `no-start` is a more nebulous flag.