Date   

Re: cf restart-app-instance and environment variables #cf

Mike Youngstrom
 

Correction.  Looks like there is an experiemental zdt restart command also: "cf v3-zdt-restart"

Mike

On Tue, Dec 4, 2018 at 12:10 PM Mike Youngstrom via Lists.Cloudfoundry.Org <youngm=gmail.com@...> wrote:
The functionality is in an experimental state on the server side: https://github.com/cloudfoundry/cf-deployment/releases/tag/v5.2.0

An matching experimental command to do a zero downtime push has been added to the cli: https://github.com/cloudfoundry/cli/pull/1447

I believe we are still waiting for experimental zero downtime restart commands and functionality.

Mike

On Tue, Dec 4, 2018 at 7:55 AM Preetam Palwe <preetam.palwe@...> wrote:
Guys - Any update on below topic ... Is this feature released ???

Thanks

There is also work in flight to implement rolling updates of applications that will allow 'cf restart' to update environment variables for an app based on this proposal https://docs.google.com/document/d/116I_mOWjZcPeIbUvvsh-jAcwpoE_mGPD_SkCel5xXuU/edit#


Re: cf restart-app-instance and environment variables #cf

Mike Youngstrom
 

The functionality is in an experimental state on the server side: https://github.com/cloudfoundry/cf-deployment/releases/tag/v5.2.0

An matching experimental command to do a zero downtime push has been added to the cli: https://github.com/cloudfoundry/cli/pull/1447

I believe we are still waiting for experimental zero downtime restart commands and functionality.

Mike


On Tue, Dec 4, 2018 at 7:55 AM Preetam Palwe <preetam.palwe@...> wrote:
Guys - Any update on below topic ... Is this feature released ???

Thanks

There is also work in flight to implement rolling updates of applications that will allow 'cf restart' to update environment variables for an app based on this proposal https://docs.google.com/document/d/116I_mOWjZcPeIbUvvsh-jAcwpoE_mGPD_SkCel5xXuU/edit#


Re: cf restart-app-instance and environment variables #cf

Preetam Palwe
 

Guys - Any update on below topic ... Is this feature released ???

Thanks

There is also work in flight to implement rolling updates of applications that will allow 'cf restart' to update environment variables for an app based on this proposal https://docs.google.com/document/d/116I_mOWjZcPeIbUvvsh-jAcwpoE_mGPD_SkCel5xXuU/edit#


CF CLI Minimum Supported Version for 2019

Abby Chau
 

Hello everyone,


Earlier this year, in order to focus our resources on the most valuable features and bug fixes, the CLI team announced a minimum supported version policy for older Cloud Controller (CC) API versions: upon the new calendar year, the CF CLI will only maintain support as far back as the previous year’s CF Certification. Older CF CLI versions compatible with older CF releases will continue to be available. However, the CLI team will remove all code pertaining to unsupported releases.


The current CF CLI is backwards compatible to CF 251 / CC v2 API 2.69 / CC v3 API 3.4.0, which was the latest released version as of January 1, 2017.


Starting in 2019, CF CLI will only support:

  • Previous Year’s CF Certification: CF Certification 2018

  • CF-Deployment Release in January 2018: v1.7.0. (CF Release in January 2018: v284)

  • CAPI Release on January 1st, 2018: 1.46.0 (APIs 2.100.0 and 3.35.0)


The CF CLI team welcomes any feedback you may have regarding this. We can be reached via this email, or on Slack at #cli (Cloud Foundry). Thanks.


Best,


Abby Chau and the CF CLI Team

Product Manager, CF CLI



Re: Eirini in 2019 CFAR certification requirements

Eric Malm <emalm@...>
 

Hi, all,

Thanks for raising the topic of whether to include Eirini as an option in the 2019 CFAR certification requirements. Although the Eirini team has made tremendous progress over the past 6 months or so, it seems premature for the CFF to commit to including Eirini as a certified option for 2019. The team is close to passing a minimal set of CF Acceptance Tests, with the latest update in the #eirini-dev channel (https://cloudfoundry.slack.com/archives/C8RU3BZ26/p1543575973001900) reporting 66 passing, 1 failing, and 155 skipped tests, but according to https://github.com/cloudfoundry-incubator/eirini-ci/blob/master/pipelines/ci/cats-conf.yml that set of CATs does not yet even include all of the default suites in the CATs config (as per https://github.com/cloudfoundry/cf-acceptance-tests#test-configuration). In either case, those particular suites of CATs do not validate functionality such as application security groups, CF SSH, and app tasks that platform operators can enable or should configure, even if some CFAR environments may happen to disable them for their app developers.

In addition to parity of feature functionality, I'm concerned that we would be granting certification to CFAR distributions that have not yet demonstrated a reasonable level of parity with current expectations of operational reliability and scale. For comparison, at the start of 2016, Diego had already been running the entirety of PWS for three months and had committed to backwards compatibility of its APIs and BOSH properties, and Pivotal had shipped PCF with it as the default container backend. I'm not aware of an Eirini-backed CFAR having the same level of practical operational validation at scale.

I understand that the community members that are most committed to Eirini are concerned about missing all of 2019 for certification, so I'd like to propose the following course of action. Although the CFAR certifications have been on an annual cadence, the "Updates" section in the provider requirements (https://www.cloudfoundry.org/provider-requirements/) seem to me to state that the CFF has the authority to update them at any time. This annual cadence for certification seems intended primarily to give vendors enough lead time to react to proposed breaking changes in the certification, such as the removal of the DEAs and the transition from cf-release to cf-deployment in terms of integration expectations.  Adding Eirini as a certification option once it is sufficiently robust in both feature parity and operational maturity would be an additive change, however, and therefore one that would not require advance notice or review lest it render existing distributions incompatible. Should Eirini achieve that parity during the 2019 calendar, that amendment could be released in, say, a "2019.1" certification revision during that year, in advance of the expected certification requirements for 2020.

Thanks again,
Eric



On Mon, Nov 26, 2018 at 10:53 AM Julz Friedman <julz.friedman@...> wrote:
> That phrasing doesn't read as a component I would want to run in production (or in a certified distribution).

Oops! You’re quite right Matt, this is still the README from my original spike many months ago, before we even officially started the project — we’ll be sure to update that asap :-).

In the mean time, fwiw, there’s a (very) long and detailed proposal document, from when we originally approved Eirini as an incubator project, with much much more detail about the reasoning available here: https://docs.google.com/document/d/1qs6UQQDWMkfOpY19XqS3CfvI00jCns876TjplJ6E95s/edit?ouid=109489329491803931461&usp=docs_home&ths=true

Thanks!

On Mon, 26 Nov 2018 at 18:37, Matt Cholick <cholick@...> wrote:
The eirini repository's current README (https://github.com/cloudfoundry-incubator/eirini#y-tho-y) states: "Partly a fun experiment, partly a proof of concept"

That phrasing doesn't read as a component I would want to run in production (or in a certified distribution).

That section doesn't really dive into strong detail as to "why" the project important either. I think fleshing that section out more would be valuable.

-Matt


On Mon, Nov 19, 2018 at 8:13 AM Chip Childers <cchilders@...> wrote:
On Sat, Nov 17, 2018 at 5:03 AM Krannich, Bernd <bernd.krannich@...> wrote:
  • If I am not getting things wrong this means that distributions could be certified with only running Diego well before the Diego GA.
This is an accurate statement.
 

[1] Feedback: For governance docs (@Chip Childers), it might be worthwhile to keep things in a public Github repo, too.


Ack - will work on that. :) 


CF CLI v6.41.0 Released Today

Will Murphy
 

Hello everyone,

The CF CLI team released v6.41.0 of the CF CLI today. See the release notes for more details.

Highlights Include

Assign a Stack to a Buildpack epic

Supports the ability to assign a stack to a buildpack that is missing stack metadata. See official documentation for more details.

Important Note: It's important to note that once you assign a stack to a buildpack, you cannot undo the action unless you have access to your buildpack bits.

Additional notes:

  • If you have two buildpacks with the same name, and one has a stack associated, and the other has a nil stack; when you run cf update-buildpack buildpack-name --assign-stack stack - the buildpack with nil stack will be updated.

Service Discovery epic

With app service discovery, apps pushed to Cloud Foundry can establish container-to-container communications through a known route. This allows front end apps to easily connect with back end apps.

Now users can use cf create-shared-domain internal.com --internal to create an internal route, and domains has been updated to include a new details column to let users know if a route is internal.

See official documentation for more details.

Refactors

Important Note:

We've discovered that for commands we've refactored previously, the CLI started incorrectly allowing for additional arguments to be passed in commands, which are ignored silently. Moving forward and starting with these refactored commands, if you provide additional arguments to a command, the command will fail with a meaningful message. [details](#162259630]

Note we intend to fix this bug for all refactored commands in a major CLI release see additional details

Services-related Refactors

In order to prepare for a upcoming service-related feature, the Services API team in London refactored the following commands. Big thanks to the SAPI team for providing this work to us.

User-facing changes include:

  • Updating output where necessary and flavor text to promote consistently as described in our style guide

Create-shared-domain Refactor

In order to prepare for the Service Discovery (Container to Container Networking feature), we've refactored cf create-shared-domain.
story

User-facing changes include:

  • Updating output where necessary and flavor text to promote consistently as described in our style guide

Built with Golang 1.11.x story

Updated to Golang 1.11. See the Golang release summaries for details on the bug fixes.

Enhancements

  • updated cf --help to include the delete command story

Plugin Updates

Contributors: SAPI London team (for the marketplace refactor), Slawek Ligus and the C2C Networking team (for cross team efforts for the Service Discover feature) Thomas Viehman, Jennifer Spinney, Will Murphy, Magesh Kumar Murali, Abby Chau

Note: The minimum version of the CC API this CF CLI release is compatible with is CC API v2.69.0. See our minimum supported version policy for more information.


Best,

Will and the CF CLI Team


Re: #cf seccomp #cf

Julz Friedman
 

Hi hjinkim - the 'configurable' column in that table actually means whether you can opt in/out of the feature, not whether you can configure it (admittedly that's rather unclear!). Garden enables seccomp by default and does not allow opting out (hence it's marked as false in the configurable column), and there are no plans to change that.

Although the table doesn't show it, it would also be possible - as I think you're suggesting - to allow configuring custom seccomp rules for particular containers. We don't currently have plans to allow that because it would require exposing quite a lot of new complexity to users which would be difficult given the Cloud Foundry UX (we try to hide low-level details from users), and might risk allowing users to ask for less secure rules than we would want. Do you have a particular use case in mind where you would want more configurable rules than the defaults we set out of the box?

Thanks!
Julz


On Thu, 29 Nov 2018 at 10:52 <hjinkim@...> wrote:

Hi.
As you see the image I inserted above,
Currently there is no support for configurable Seccomp Filtering in CFAR Garden v1.40.0. Do you have any plan to support configurable Seccomp filtering in CFAR Garden sooner or later?


#cf seccomp #cf

hjinkim@...
 


Hi.
As you see the image I inserted above,
Currently there is no support for configurable Seccomp Filtering in CFAR Garden v1.40.0. Do you have any plan to support configurable Seccomp filtering in CFAR Garden sooner or later?


Re: Call for Papers Deadline for CF Summit (Philadelphia)

Swarna Podila
 

A reminder for y'all to get your speaking proposals in before Friday.

If you'd like to get feedback on your abstract or would like for it to be reviewed for a sanity-check, please don't hesitate to "@cfp-help" in #summit channel on CF Slack.

--Swarna.


Re: cf login error

bguttmann@...
 

Hi,

are you able to curl the API's /v2/info endpoint? 

That means 'curl https://<api-url>/v2/info' .

Regards,

Benjamin


cf login error

Russell Blue
 

Hi,

I deployed cf on openstack and 15 vm running and okay.
But cf login error: behind firewall....
please help me.

best regards


Re: routing-release 0.183.0

Shubha Anjur Tupil
 

@Gabriel Rosenhouse brought up a important point that we wanted to call out.

  • When an application instance crashes while processing a request Gorouter now returns an error and takes the backend out of the pool temporarily, without retrying another backend details
This change may cause increased 502 rates for existing apps. Let us know if you have any questions. 




On Tue, Nov 13, 2018 at 10:46 AM Shubha Anjur Tupil <sanjurtupil@...> wrote:
We cut routing-release 0.183.0 today morning. 

Release highlights: 
  • Operator can specify HTTP headers to be added by Gorouter to responses details
  • Operator can specify HTTP headers to be removed by Gorouter from the responses details
  • We have updated locket to the latest commit details
  • Fixed an issue introduced with the move to BPM for TCP Router on accumulating TCP-Router HAProxy instances details
  • With the move to BPM, operators should use the syslog release for access log streaming. enable_access_log_streaming is no longer supported in the Gorouter details
  • Gorouter stdout logs includes vcap_request_id so operators can correlate the stdout logs with access logs for easier debugging of issues details
  • Route registrar now supports registration of TCP routes details
  • When an application instance crashes while processing a request Gorouter now returns an error and takes the backend out of the pool temporarily, without retrying another backend details
  • We have updated from Cflinux2 to Cflinuxfs3 details
  • We are still evaluating the issue we are having with performance reports and have not been able to get a root cause details
Regards, 
Routing team


Re: Eirini in 2019 CFAR certification requirements

Julz Friedman
 

> That phrasing doesn't read as a component I would want to run in production (or in a certified distribution).

Oops! You’re quite right Matt, this is still the README from my original spike many months ago, before we even officially started the project — we’ll be sure to update that asap :-).

In the mean time, fwiw, there’s a (very) long and detailed proposal document, from when we originally approved Eirini as an incubator project, with much much more detail about the reasoning available here: https://docs.google.com/document/d/1qs6UQQDWMkfOpY19XqS3CfvI00jCns876TjplJ6E95s/edit?ouid=109489329491803931461&usp=docs_home&ths=true

Thanks!


On Mon, 26 Nov 2018 at 18:37, Matt Cholick <cholick@...> wrote:
The eirini repository's current README (https://github.com/cloudfoundry-incubator/eirini#y-tho-y) states: "Partly a fun experiment, partly a proof of concept"

That phrasing doesn't read as a component I would want to run in production (or in a certified distribution).

That section doesn't really dive into strong detail as to "why" the project important either. I think fleshing that section out more would be valuable.

-Matt


On Mon, Nov 19, 2018 at 8:13 AM Chip Childers <cchilders@...> wrote:
On Sat, Nov 17, 2018 at 5:03 AM Krannich, Bernd <bernd.krannich@...> wrote:
  • If I am not getting things wrong this means that distributions could be certified with only running Diego well before the Diego GA.
This is an accurate statement.
 

[1] Feedback: For governance docs (@Chip Childers), it might be worthwhile to keep things in a public Github repo, too.


Ack - will work on that. :) 


Re: Eirini in 2019 CFAR certification requirements

Matt Cholick
 

The eirini repository's current README (https://github.com/cloudfoundry-incubator/eirini#y-tho-y) states: "Partly a fun experiment, partly a proof of concept"

That phrasing doesn't read as a component I would want to run in production (or in a certified distribution).

That section doesn't really dive into strong detail as to "why" the project important either. I think fleshing that section out more would be valuable.

-Matt


On Mon, Nov 19, 2018 at 8:13 AM Chip Childers <cchilders@...> wrote:
On Sat, Nov 17, 2018 at 5:03 AM Krannich, Bernd <bernd.krannich@...> wrote:
  • If I am not getting things wrong this means that distributions could be certified with only running Diego well before the Diego GA.
This is an accurate statement.
 

[1] Feedback: For governance docs (@Chip Childers), it might be worthwhile to keep things in a public Github repo, too.


Ack - will work on that. :) 


Re: smoke-test instances

Josh Collins
 

Hey Russell,

You probably know this, but it's worth stating that cf-deployment deploys cf-smoke-tests as an errand so no VM will be created until you run the bosh command to run the smoke-tests errand.

Since you shared an error, perhaps you attempted to run the errand and this is the response?

Regardless, I'd like to invite you to engage us in Slack rather than this cf-dev list as we'll be able to more actively respond: #cloud-foundry

When you post your issue to the cloud-foundry slack channel, please include the bosh deploy command you used to deploy your foundation, the bosh command you used which triggered the error response you included above, and the error output (perhaps with a bit more output before/after the snippet you included here).

Thanks so much!

Josh and the CF Release Integration team


Call for Papers Deadline for CF Summit (Philadelphia)

Swarna Podila
 

Dear Cloud Foundry Community,
The deadline for submitting your speaking proposals for Cloud Foundry Summit North America 2019 in Philadelphia is this Friday, November 30 at 11.59pm US Pacific.  Please submit your proposals before the deadline.

Please submit here: https://www.cloudfoundry.org/event_subpages/cfna-2019-cfp/

If you'd like to get your abstract reviewed or need some help finessing your abstract, please do not hesitate to ping @cfp-help on #summit channel on the Cloud Foundry slack.

There will not be an extension to the deadline this time.

Please do not hesitate to contact me (via email or slack) if you have any questions.

Regards,
Swarna.


smoke-test instances

Russell Blue
 

Hi,

I deployed cloud foundry on openstack and 15 vms created but smoke-test dont create.
please help me.
error: Blobstore object not found

best reagards,


Re: Apps/microservices that have long request processing times.

Nikolay Valchev
 

Hi,

 

Are there any plans for enabling the graceful shutdown configuration on app level? From user experience point of view this is very similar to the health check timeout, which is configurable to max of 180, if not configured differently by CF operators.

 

Thanks,

Nikolay

 

 

From: <cf-dev@...> on behalf of Liu Liming <andyliuliming@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, 18 September 2018, 17:16
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Apps/microservices that have long request processing times.

 

Hi Jo,

I think there’s one config in the rep job:

  containers.graceful_shutdown_interval_in_seconds:

    description: "EXPERIMENTAL: time in seconds between signalling a container to shutdown gracefully and stopping it forcefully. Should not be less than 10."

default: 10

if you are using the open source version of CF, I think you can overrite it under this path:

 

  - name: rep

    release: diego

    properties:

      diego:

        executor:

          instance_identity_ca_cert: ((diego_instance_identity_ca.certificate))

          instance_identity_key: ((diego_instance_identity_ca.private_key))

        rep:

          preloaded_rootfses:

          - cflinuxfs2:/var/vcap/packages/cflinuxfs2/rootfs.tar

          use_vcontainer: false

          vcontainer:

            api_location: "vcontainer.service.cf.internal:8892"

            ca_cert: "((service_cf_internal_ca.certificate))"

            client_cert: "((diego_vcontainer_client.certificate))"

            client_key: "((diego_vcontainer_client.private_key))"

      containers:

       graceful_shutdown_interval_in_seconds: 10000000

        trusted_ca_certificates:

          - ((application_ca.certificate))

 

And if you are using the PCF, I think you can use the ops manager to override the value if it provided one way to do this.

 

Thanks,

Andy

 

From: <cf-dev@...> on behalf of Jonathan Stockley <jstockle@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, September 18, 2018 at 6:31 AM
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] Apps/microservices that have long request processing times.

 

Hi,

According to https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#moving-apps an app instance has only 10 seconds to finish processing a request before being killed off.

I have an app that does document rendition generation and it can take upwards of 10 minutes for long documents.

Is the 10 seconds grace period configurable?

 

Thanks,

Jo


Re: DNS on cf-deployment

Sridhar Vennela
 

dns is bosh addon, you can run below command. 

bosh -e bosh-lite update-runtime-config bosh-deployment/runtime-configs/dns.yml --name dns

Sridhar


On Tue, Nov 20, 2018 at 9:46 PM Russell Blue via Lists.Cloudfoundry.Org <bluerussell20=yahoo.com@...> wrote:
Hi,

I deploy bosh and cf-deployment without DNS. How can deploy with dns?
please help me.

best regards




DNS on cf-deployment

Russell Blue
 

Hi,

I deploy bosh and cf-deployment without DNS. How can deploy with dns?
please help me.

best regards