Date   

Re: [CAUTION] Re: [cf-dev] Proposed BOSH logging interface

Marco Voelz
 

Dear Jesse,

 

did anything come out of this proposal? Did you end up picking up this track of work?

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, 8. May 2018 at 10:08
To: "cf-dev@..." <cf-dev@...>, Dmitriy Kalinin <dkalinin@...>
Subject: [CAUTION] Re: [cf-dev] Proposed BOSH logging interface

 

Dear Jesse,

 

Thanks for putting this proposal out there. We would be happy to see an automated logfile forwarding mechanism. Here's a couple of comments on your initial points:

* Including the filename in the syslog metadata is very useful and something we'd really like to have. Currently it is something we're working around a bit.

* The appname/tag field should probably contain the release's name as well as a prefix. My proposal here is `<deployment name>.<instance group name>.<job name>`. wdyt?

* We haven't made any particular use of the priority field, so losing control over this field wouldn't matter for out use-cases. Severity is usually something that the actual log message needs to contain, as the logger's severity can only be set on its initial creation, afaik.

* Restricting the depth of recursion seems reasonable. So far, I don't think we're using bosh releases which have more than 1 folder below their /var/vcap/sys/log/<job name>/ folder.

 

Concerning the requirements about permissions on the logfiles you'd want to forward: Did you talk to Dmitriy/the BOSH team about this? With stemcell series 3541.x the permissions on the standard folders below /var/vcap were tightened a bit, so just wanted to make sure that your assumptions are in line with the upcoming changes in the stemcells.

 

Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Jesse T. Alford <jalford@...>
Sent: Tuesday, April 3, 2018 12:55:38 AM
To: cf-dev@...
Subject: [cf-dev] Proposed BOSH logging interface

 

Hello! We're the CF Platform Logging team. We maintain `syslog-release` and have been working to improve and regularize platform logging behavior.

 

This is a proposal intended to establish reasonable expectations about what should be logged and what should be forwarded in bosh-deployed cloud systems.

 

Historically, it has been up to each release to provide for their log forwarding, if any. We intend `syslog-release` to provide a consistent interface useful enough to replace all other provisions for the forwarding of logs from bosh jobs.

 

## Proposed Interface

If log forwarding is enabled, some files in `/var/vcap/sys/log` (and its subdirectories, recursively), will have any line written to them forwarded as the MSG portion of an RFC5424 compliant syslog message. Which files are forwarded is governed first by file extension, and secondarily by file permissions.

 

`syslog-release` attempts to read any file ending in `.log`.

(This allows us to avoid forwarding rotated logs, swapfiles, etc.)

It will forward from such files if either of the following are true:

- it is world-readable

- it is readable to the `vcap` group

 

In particular, this means that logs will not be forwarded from files where:

- user and group are root:root

- user and group are vcap:root or vcap:none

- user and group are vcap:vcap, but it is not group-readable

 

…unless they are world-readable.

 

We think that this interface will allow us to avoid running a log forwarder with elevated permissions, while also allowing jobs to, for instance, write DEBUG or similar logs to a file that is not group-readable, thus improving their security and reducing the load on the logging system while still making them available on the ephemeral disk for debugging purposes.

 

## Questions

There are a couple of things around this interface we're especially interested in feedback on, in addition to the obvious "will this be a problem for you" overall question.

 

We may have to have a proviso that the depth of this is not unlimited. This depends somewhat on what is inexpensive to implement and maintain, and is an area we'd appreciate feedback on. Is three levels deep from `/var/vcap/sys/log` (i.e. `/var/vcap/sys/log/jobname/processname/*`) enough? Would four be?

 

In the old way of doing things, more control over the PRI information and other syslog fields was available to release authors. Logs forwarded from files currently all come out as PRI 14, which translates to Facility: User, Severity: Info. Additionally, the appname/tag field is set to the name of the directory containing the log file. Is this enough/good info? If we were to include the filename, too, would that be useful? Sufficient?

 

## Testing with the Proposed Interface

We have recently implemented a feature to help release authors evaluate the proposed interface. If you set `syslog.respect_file_permissions: true`, blackbox will not be run with elevated capabilities, and you'll be able to see what is and isn't forwarded under the proposed interface.


Re: Free to Migrate to BPM

Krannich, Bernd
 

Hi Josh,

 

This is great news, thanks for sharing!

 

So essentially, cf-deployment at some point in time will run containerized processes, even on “plain VMs”, excellent.

 

This coincides with the mail from Cornelius (https://lists.cloudfoundry.org/g/cf-dev/message/8120) around Containerizing CF. When discussing the Containerizing proposal, our hope was always that BPM adoption would pick up so that converting into Kubernetes artifacts could benefit from the BPM metadata.

 

Seems like all of this is now nicely falling in place.

 

Thanks,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

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 Josh Collins <jcollins@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, 3. July 2018 at 21:20
To: cf-pm <cf-pm@...>, "cf-dev@..." <cf-dev@...>, CF Dev <cf-dev-eng@...>
Subject: [cf-dev] Free to Migrate to BPM

 

Hey Y'all,

 

You may know this already, but I wanted to send out a broad communication to make sure you're in the know and to build a shared understanding about the process for migrating to BPM going forward.

 

As of cf-deployment v1.40.0, BPM is colocated on all instance groups in cf-d.

 

It's available for every component team to adopt when validated against their component's features.

 

To-date, teams that have completed validation have enabled BPM by including logic within their jobs to rely on BPM based on whether the `bpm.enabled` property is set to true for their jobs. And adding an entry to `operations/experimental/enable-bpm.yml` to set that property/value to true in the deployment manifest.

 

The following jobs currently have entries in enable-bpm.yml:

  • uaa
  • route-emitter
  • rep
  • bbs
  • auctioneer
  • ssh-proxy
  • file-server

Now that BPM is on each VM by default you can validate your components in your pipelines by enabling BPM directly within your job(s).

 

And when ready to publish your bpm-enablement changes in a release, please... 

 

For each team that has a component/job that's already validated against BPM, it would be great if you could enable it directly as per above and, if appropriate, submit a PR which removes the entry from `enable-bpm.yml.` 

 

At some point in the relatively near future, I'll delete `enable-bpm.yml,` but only after all components listed have enabled it and I've heard folk's pipelines no longer rely on it's existence.

 

Thank you for reading this through and thanks very much in advance for replying with any questions, feedback, or suggestions and issues related to this communique.

 

Cheers,

 

Josh

 

 

 

 

 


cf-deployment 3.0

Josh Collins
 

Hey Y'all,

Cf-deployment 3.0 is around the corner. 
We're going to go 3.0 in 2-3 weeks.

We released cf-deployment 2.0 on June 18th and included 'breaking' changes.

Breaking changes in the context of cf-d are changes which would require special attention from operators for the deployment to succeed. Executing the same bosh deploy command/args run used in the previous deployment may fail depending on which ops files and features operators had deployed with in the past.

Going forward, we'd like to introduce a more regular (~monthly) cadence to major point releases of cf-deployment.

The goal is two-fold and in-order-of-importance:
  1. provide a reliable mechanism for cf component teams to integrate and release major  changes
  2. mitigate fear of major point releases in the minds of operators/cf-consumers

As of today, we've got one PR that includes breaking changes and I'm putting out a call to y'all.
If you've got what you'd consider to be a breaking change that warrants going out in a major point release of cf-deployment, please submit your PRs and reach out to the RelInt team as soon as you're able to so we can come up to speed and support you!

Cheers,

Josh






Free to Migrate to BPM

Josh Collins
 

Hey Y'all,

You may know this already, but I wanted to send out a broad communication to make sure you're in the know and to build a shared understanding about the process for migrating to BPM going forward.

As of cf-deployment v1.40.0, BPM is colocated on all instance groups in cf-d.

It's available for every component team to adopt when validated against their component's features.

To-date, teams that have completed validation have enabled BPM by including logic within their jobs to rely on BPM based on whether the `bpm.enabled` property is set to true for their jobs. And adding an entry to `operations/experimental/enable-bpm.yml` to set that property/value to true in the deployment manifest.

The following jobs currently have entries in enable-bpm.yml:
  • uaa
  • route-emitter
  • rep
  • bbs
  • auctioneer
  • ssh-proxy
  • file-server
Now that BPM is on each VM by default you can validate your components in your pipelines by enabling BPM directly within your job(s).

And when ready to publish your bpm-enablement changes in a release, please... 

For each team that has a component/job that's already validated against BPM, it would be great if you could enable it directly as per above and, if appropriate, submit a PR which removes the entry from `enable-bpm.yml.` 

At some point in the relatively near future, I'll delete `enable-bpm.yml,` but only after all components listed have enabled it and I've heard folk's pipelines no longer rely on it's existence.

Thank you for reading this through and thanks very much in advance for replying with any questions, feedback, or suggestions and issues related to this communique.

Cheers,

Josh






Incubation proposal: CF Containerization

Cornelius Schumacher <cschum@...>
 

Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/).

Fissile is fully open source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@suse.com>


Re: (action requested) cf app display changes

Abby Chau
 

Hi all,

Thank you to everyone who gave us feedback on changing  the `cf app` display summary information. We really appreciate your input. 

We've taken your feedback into consideration and have decided to move forward with app display option #2 - see below [1]. Since option #3 (being able to provide a `--process` specific flag) was also popular, we are open to supporting this feature in the future as we receive more feedback about usage of procfiles and multiple processes. 

See this document for a summary of upcoming changes, and please do not hesitate to reach out if you have any additional questions. 

Best,

Abby

[1]  



On Fri, Jun 22, 2018 at 9:40 AM, Abby Chau <achau@...> wrote:
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)



CF Application Runtime PMC - CF Networking Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

Hello All,

Usha Ramachandran, the Project Lead for the CF Networking team within the Application Runtime PMC, is rotating into a role internal to Pivotal. We thank her for her time serving as the CF Networking Project Lead.

The CF Networking team, split between San Francisco and Santa Monica, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member.

Please send nominations to me/in reply to this posting by end of day July 11th, 2018.

If you have any questions about the role/process, please let me know.
These are described in the CFF governance documents. [1]

-Dieu Cao

CF Application Runtime PMC Lead


Re: Quick (2 min) survey for the Cloud Foundry Community!

Chris Clark
 

All you CF contributors and community folks out there, please take a quick 2 minutes and compete this survey, if you would!  This will help us get a sense of the makeup of the Cloud Foundry Community, and it's super fast.  Thank you!

On Wed, Jun 20, 2018 at 4:33 PM, Chris Clark <cclark@...> wrote:
***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



--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: CF CLI: how do you use `no-start` with `cf push`

Dr Nic Williams <drnicwilliams@...>
 

I use no-start because ‘cf push’ doesn’t have flags to set env vars/service bindings.

If the response to that is “use manifest.yml” then perhaps get rid off all the push flags and force ppl to use manifest.yml. As it stands now, we can cf push most attributes of the manifest.yml, except env vars and service bindings.


From: cf-dev@... <cf-dev@...> on behalf of Hjortshoj, Julian <Julian.Hjortshoj@...>
Sent: Friday, June 29, 2018 3:06:03 AM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI: how do you use `no-start` with `cf push`
 
We have not tried the v3 api, but yes, that sounds correct to me, and v3-create-app seems like a reasonable substitute.

From: cf-dev@... [cf-dev@...] on behalf of Zach Robinson [zrobinson@...]
Sent: Wednesday, June 27, 2018 4:58 PM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

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

 

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.



Removing varz support for Routing components

Shubha Anjur Tupil
 

Hi, 

To walk down memory lane a bit, the varz endpoints were replaced with the firehose more than two years ago. The relevant threads are


In the interest of code maintenance for the routing components we are considering removing the code to support the varz endpoints. All users should have transitioned to using the firehose nozzle. Let us know if and why this might be a problem. 

Regards, 
Shubha



Re: CF CLI: how do you use `no-start` with `cf push`

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

We have not tried the v3 api, but yes, that sounds correct to me, and v3-create-app seems like a reasonable substitute.

From: cf-dev@... [cf-dev@...] on behalf of Zach Robinson [zrobinson@...]
Sent: Wednesday, June 27, 2018 4:58 PM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

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

 

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.



Re: CF CLI: how do you use `no-start` with `cf push`

Abby Chau
 

Hey Bernd,

Zach can speak more to this but, I believe, the CC v3 API has been stable for some time, with v3.27

The v3 prefixed CF CLI commands are relatively lesser known so apologies if it's been relatively unclear. All the CF CLI v3 prefixed commands are all still considered experimental (the CLI commands such as `cf v3-push`, `cf v3-app`, `cf v3-set-health-check`, `cf v3-droplets`, etc) . A few reasons for this are that the CF CLI team wanted to garner feedback about them from users, and we wanted the freedom to change the commands (output, etc) based on user feedback. An example of this is the `cf v3-app` command, which we will be changing soon based on user feedback. (There is a survey out currently about the UX). 

Starting with the `cf v3-app` command, (which we will remove the experimental status for soon, and which the current `cf app` command will default to using for users on CC API 3.27. or higher) the CF CLI team have embarked on a concerted effort to remove experimental status for all the other v3 prefixed commands. We realise this may have an impact on users, and we want to mitigate for this as much as possible - we are doing so by asking the community for feedback, and updating them as much as possible regarding our current efforts. 

After we release the work for the `cf v3-app`, we will be looking at other CF CLI v3 prefixed commands to remove the experimental status for - again we are keen on making sure impact is minimal for users whilst simultaneously trying to make sure all the benefits of the v3 CC API functionality is fully realised as intended. 

I hope this makes sense, please do not hesitate to reach out if you have any questions or feedback. We will be communicating with the community each step of the way. 

Best,

Abby


On Thu, Jun 28, 2018 at 7:50 AM, Chip Childers <cchilders@...> wrote:
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



Re: CF CLI: how do you use `no-start` with `cf push`

Christian Brinker
 

Hi,

+1 on chips idea. ;-)

v3-foo was fun but we should get rid of that syntax.

Greetings
Christian

On Thu, 28 Jun 2018 at 16:50 Chip Childers <cchilders@...> wrote:
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

--
E-Mail: cbrinker@...

evoila GmbH
Weberstraße 21
55130 Mainz
Germany

Geschäftsführer: Johannes Hiemer

Amtsgericht Mainz HRB 42719

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If You are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


Re: CF CLI: how do you use `no-start` with `cf push`

Chip Childers <cchilders@...>
 

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


Re: CF CLI: how do you use `no-start` with `cf push`

Krannich, Bernd <bernd.krannich@...>
 

Hi Abby, Zach,

 

I don’t think we have looked into v3 commands in too much detail. Please forgive my ignorance in this topic, are the v3 commands already considered a stable API so that I could check if people can replace their existing “--no-start” scenarios with it?

 

> this implies to me that these workflows are for new apps and not for updating existing ones.

IIRC, some of those workflows are done as part of blue-/green-updates. I am not sure that people would completely delete their currently inactive app completely, or if they would just keep updating the inactive app and then switch over to it.

 

Thanks in advance,

Bernd

 

From: <cf-dev@...> on behalf of Zach Robinson <zrobinson@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 28. June 2018 at 01:58
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] CF CLI: how do you use `no-start` with `cf push`

 

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

 

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.

 


Re: CF CLI: how do you use `no-start` with `cf push`

John Mcteague <john@...>
 

We have multiple foundries in our org and occasionally we would want to push an app in the stopped state to a pool for DR purposes (active/active across foundries is always desirable but simply not always practical for older applications transitioning to CF). 


On Thu, 28 Jun 2018, 00:58 Zach Robinson, <zrobinson@...> wrote:
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

 

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.



Clarification regarding Custom roles in CF

Raghav, Prashant <prashant.raghav@...>
 

Hi Team,
We would need clarification regarding custom roles on Cloud foundry.
 
Our use case is as follows:
 
Relevant permissions:
  1. deploy applications
  2. (re)start/stop applications
  3. access application logs
  4. bind cf services to applications
  1. market place services, e.g. MySQL
  2. user-provided services, e.. for storing access credentials of external services on AWS
  1. create/update cf services, e.g. set access credentials
  2. view cf service settings via the cf command line interface, e.g. see unencrypted passwords
Defining roles and permissions is tightly integrated with the intended work processes.
In a DevOps I would suggest the following:
  • Role DevOp
  • permissions 1, 2, 3, 4
  • Role Admin
  • permissions 5, 6
 
 
Could you please provide solution for such kind of issues.
 
Thanks & Regards, 
Prashant Raghav
B&PS-IN-CLD 
Atos India Pvt. Ltd, 
Embassy Tech zone,  
MIDC - Phase II Block 1.5, 
Hinjewadi, Pune. 
Email : prashant.raghav@... 
 
 
 
 


Re: CF CLI: how do you use `no-start` with `cf push`

Zach Robinson
 

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

 

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.



Re: CF CLI: how do you use `no-start` with `cf push`

Abby Chau
 

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

 

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.



Re: CF CLI: how do you use `no-start` with `cf push`

Hjortshoj, Julian <Julian.Hjortshoj@...>
 

+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

 

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.

1261 - 1280 of 9377