Date   
Re: Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

Kartik Lunkad
 

Hey Bin,
Unfortunately, we wouldn't be adding ephemeral disk support for Windows 2012R2-based stemcells. 

Before this feature, we used to provide a large root disk by default that can be used by the applications to store their ephemeral data. 

Thanks,
Kartik

On Thu, Sep 20, 2018 at 10:54 PM Bin Xia via Lists.Cloudfoundry.Org <binxi=microsoft.com@...> wrote:

Hi Kartik,

 

Great to hear that.

Is this feature supported in Windows 2012R2?

Before this new feature, how did customers store their ephemeral data? Using Root disk to store the ephemeral data?

 

Thanks

Bin

 

From: cf-dev@... <cf-dev@...> On Behalf Of Mike Lloyd
Sent: Friday, September 21, 2018 3:36 AM
To: cf-dev@...
Subject: Re: [cf-dev] Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

 

Congrats!

 

From: cf-dev@... <cf-dev@...> On Behalf Of Amit Kumar Gupta
Sent: Thursday, September 20, 2018 1:35 PM
To: cf-dev@...
Subject: Re: [cf-dev] Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

 

Awesome!!!!!

 

Couple ideas:

- might want to consider cross posting to cf-bosh as well if you weren’t already planning to

- if there are high level outcomes this improves, like deploy speed, upgrade speed, security (disk encryption?), or anything like that in addition to Ubuntu  parity, that’d be awesome to call out as well

 

Cheers, congrats on shipping this!

 

Amit

 

On Thu, Sep 20, 2018 at 12:29 PM Kartik Lunkad <klunkad@...> wrote:

Hi all,

We are rolling out Ephemeral Disk Support for the Windows Server, version 1709-based stemcells as well as Windows Server, version 1803-based stemcells! You can find them on https://bosh.io/stemcells/

 

What is this feature? 

This feature will allow you to have a much smaller root disk footprint, and allow you to use ephemeral disk for your applications! We have now reduced the root disk to be 30GB. 

 

What versions? 

You should find this feature in the 1709.13+ and 1803.2+ stemcells! 

 

Recommendations

The minimum ephemeral disk size should be 30GB. You could configure your ephemeral disk based on your applications' needs. Our recommendation would be to have at least a 100GB ephemeral disk size. 

 

How to use it? 

You can utilize this feature just the way you've done with Linux previously with setting vm_types/vm_extensions in your cloud config. Once you've done that, you can then use that in your deployment manifest!

 

Example - 

Cloud Config Example

vm_extenions:
- name: 100GB_ephemeral_disk
  cloud_properties:
    disk: 51200 

Deployment Manifest Example

instance_groups:
- name: windows1709
  instances: 1
  vm_type: default
  stemcell: windows
  vm_extensions: [100GB_ephemeral_disk]

 

The BOSH Windows team have worked hard to enable this functionality. Please do provide us feedback on it! 

 

Thanks,

--

Kartik Lunkad

Senior Product Manager

Pivotal  :: pivotal.io

email: klunkad@...

mobile: 4129614215



--
Kartik Lunkad
Senior Product Manager
Pivotal  :: pivotal.io
mobile: 4129614215

Re: Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

Bin Xia
 

Hi Kartik,

 

Great to hear that.

Is this feature supported in Windows 2012R2?

Before this new feature, how did customers store their ephemeral data? Using Root disk to store the ephemeral data?

 

Thanks

Bin

 

From: cf-dev@... <cf-dev@...> On Behalf Of Mike Lloyd
Sent: Friday, September 21, 2018 3:36 AM
To: cf-dev@...
Subject: Re: [cf-dev] Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

 

Congrats!

 

From: cf-dev@... <cf-dev@...> On Behalf Of Amit Kumar Gupta
Sent: Thursday, September 20, 2018 1:35 PM
To: cf-dev@...
Subject: Re: [cf-dev] Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

 

Awesome!!!!!

 

Couple ideas:

- might want to consider cross posting to cf-bosh as well if you weren’t already planning to

- if there are high level outcomes this improves, like deploy speed, upgrade speed, security (disk encryption?), or anything like that in addition to Ubuntu  parity, that’d be awesome to call out as well

 

Cheers, congrats on shipping this!

 

Amit

 

On Thu, Sep 20, 2018 at 12:29 PM Kartik Lunkad <klunkad@...> wrote:

Hi all,

We are rolling out Ephemeral Disk Support for the Windows Server, version 1709-based stemcells as well as Windows Server, version 1803-based stemcells! You can find them on https://bosh.io/stemcells/

 

What is this feature? 

This feature will allow you to have a much smaller root disk footprint, and allow you to use ephemeral disk for your applications! We have now reduced the root disk to be 30GB. 

 

What versions? 

You should find this feature in the 1709.13+ and 1803.2+ stemcells! 

 

Recommendations

The minimum ephemeral disk size should be 30GB. You could configure your ephemeral disk based on your applications' needs. Our recommendation would be to have at least a 100GB ephemeral disk size. 

 

How to use it? 

You can utilize this feature just the way you've done with Linux previously with setting vm_types/vm_extensions in your cloud config. Once you've done that, you can then use that in your deployment manifest!

 

Example - 

Cloud Config Example

vm_extenions:
- name: 100GB_ephemeral_disk
  cloud_properties:
    disk: 51200 

Deployment Manifest Example

instance_groups:
- name: windows1709
  instances: 1
  vm_type: default
  stemcell: windows
  vm_extensions: [100GB_ephemeral_disk]

 

The BOSH Windows team have worked hard to enable this functionality. Please do provide us feedback on it! 

 

Thanks,

--

Kartik Lunkad

Senior Product Manager

Pivotal  :: pivotal.io

email: klunkad@...

mobile: 4129614215

Re: Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

Mike Lloyd <mike@...>
 

Congrats!

 

From: cf-dev@... <cf-dev@...> On Behalf Of Amit Kumar Gupta
Sent: Thursday, September 20, 2018 1:35 PM
To: cf-dev@...
Subject: Re: [cf-dev] Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

 

Awesome!!!!!

 

Couple ideas:

- might want to consider cross posting to cf-bosh as well if you weren’t already planning to

- if there are high level outcomes this improves, like deploy speed, upgrade speed, security (disk encryption?), or anything like that in addition to Ubuntu  parity, that’d be awesome to call out as well

 

Cheers, congrats on shipping this!

 

Amit

 

On Thu, Sep 20, 2018 at 12:29 PM Kartik Lunkad <klunkad@...> wrote:

Hi all,

We are rolling out Ephemeral Disk Support for the Windows Server, version 1709-based stemcells as well as Windows Server, version 1803-based stemcells! You can find them on https://bosh.io/stemcells/

 

What is this feature? 

This feature will allow you to have a much smaller root disk footprint, and allow you to use ephemeral disk for your applications! We have now reduced the root disk to be 30GB. 

 

What versions? 

You should find this feature in the 1709.13+ and 1803.2+ stemcells! 

 

Recommendations

The minimum ephemeral disk size should be 30GB. You could configure your ephemeral disk based on your applications' needs. Our recommendation would be to have at least a 100GB ephemeral disk size. 

 

How to use it? 

You can utilize this feature just the way you've done with Linux previously with setting vm_types/vm_extensions in your cloud config. Once you've done that, you can then use that in your deployment manifest!

 

Example - 

Cloud Config Example

vm_extenions:
- name: 100GB_ephemeral_disk
  cloud_properties:
    disk: 51200 

Deployment Manifest Example

instance_groups:
- name: windows1709
  instances: 1
  vm_type: default
  stemcell: windows
  vm_extensions: [100GB_ephemeral_disk]

 

The BOSH Windows team have worked hard to enable this functionality. Please do provide us feedback on it! 

 

Thanks,

--

Kartik Lunkad

Senior Product Manager

Pivotal  :: pivotal.io

email: klunkad@...

mobile: 4129614215

Re: Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

Amit Kumar Gupta
 

Awesome!!!!!

Couple ideas:
- might want to consider cross posting to cf-bosh as well if you weren’t already planning to
- if there are high level outcomes this improves, like deploy speed, upgrade speed, security (disk encryption?), or anything like that in addition to Ubuntu  parity, that’d be awesome to call out as well

Cheers, congrats on shipping this!

Amit

On Thu, Sep 20, 2018 at 12:29 PM Kartik Lunkad <klunkad@...> wrote:
Hi all,
We are rolling out Ephemeral Disk Support for the Windows Server, version 1709-based stemcells as well as Windows Server, version 1803-based stemcells! You can find them on https://bosh.io/stemcells/

What is this feature? 
This feature will allow you to have a much smaller root disk footprint, and allow you to use ephemeral disk for your applications! We have now reduced the root disk to be 30GB. 

What versions? 
You should find this feature in the 1709.13+ and 1803.2+ stemcells! 

Recommendations
The minimum ephemeral disk size should be 30GB. You could configure your ephemeral disk based on your applications' needs. Our recommendation would be to have at least a 100GB ephemeral disk size. 

How to use it? 
You can utilize this feature just the way you've done with Linux previously with setting vm_types/vm_extensions in your cloud config. Once you've done that, you can then use that in your deployment manifest!

Example - 

Cloud Config Example

vm_extenions:
- name: 100GB_ephemeral_disk
  cloud_properties:
    disk: 51200 

Deployment Manifest Example

instance_groups:
- name: windows1709
  instances: 1
  vm_type: default
  stemcell: windows
  vm_extensions: [100GB_ephemeral_disk]

The BOSH Windows team have worked hard to enable this functionality. Please do provide us feedback on it! 

Thanks,
--
Kartik Lunkad
Senior Product Manager
Pivotal  :: pivotal.io
mobile: 4129614215

Ephemeral Disk Support for Windows 1709 and Windows 1803 Stemcells

Kartik Lunkad
 

Hi all,
We are rolling out Ephemeral Disk Support for the Windows Server, version 1709-based stemcells as well as Windows Server, version 1803-based stemcells! You can find them on https://bosh.io/stemcells/

What is this feature? 
This feature will allow you to have a much smaller root disk footprint, and allow you to use ephemeral disk for your applications! We have now reduced the root disk to be 30GB. 

What versions? 
You should find this feature in the 1709.13+ and 1803.2+ stemcells! 

Recommendations
The minimum ephemeral disk size should be 30GB. You could configure your ephemeral disk based on your applications' needs. Our recommendation would be to have at least a 100GB ephemeral disk size. 

How to use it? 
You can utilize this feature just the way you've done with Linux previously with setting vm_types/vm_extensions in your cloud config. Once you've done that, you can then use that in your deployment manifest!

Example - 

Cloud Config Example

vm_extenions:
- name: 100GB_ephemeral_disk
  cloud_properties:
    disk: 51200 

Deployment Manifest Example

instance_groups:
- name: windows1709
  instances: 1
  vm_type: default
  stemcell: windows
  vm_extensions: [100GB_ephemeral_disk]

The BOSH Windows team have worked hard to enable this functionality. Please do provide us feedback on it! 

Thanks,
--
Kartik Lunkad
Senior Product Manager
Pivotal  :: pivotal.io
mobile: 4129614215

CF CLI v6.39.1 Released Today

Abby Chau
 

Hey everyone,

Just dropping a note to say that the CF CLI team released cf CLI v6.39.1 today, which includes a bug fix for using `cf push` with the `-s` stack flag and multiple buildpacks; now the CLI correctly honors the `-s` flag if provided in the push request. Please see release notes for details. 

Best,

Abby Chau
Product Manager, CF CLI

Re: [cf-abacus] Usage Sampler proposal

Michael Maximilien
 

Nice. Thanks for sending this Hristo.

Let’s make sure to chat about this in a future Extensions or CAB call. Will provide initial feedback in doc.

Best,

Max

On Tue, Sep 18, 2018 at 4:39 AM Hristo Iliev <hsiliev@...> wrote:
Hi all,

Abacus team is ready to start the next big chunk of work. We want to remove the time-based metrics we now use to integrate with Cloud Foundry's app & service events and replace them with sampling.

Why?
Time-based metrics are complex, costly in terms of CPU and storage space. Clients have to renew time-based usage, which requires persistence on their side. We see tham as unreliable and error-prone.

How?
We are proposing a new Sampler component that will expose REST API for continuous events.

More info can be found in this document:

Your feedback is highly appreciated.

Regards,
Hristo Iliev

--
dr.max Sent from my iPhone http://maximilien.org

FINAL REMINDER: CAB call for September is Wednesday 09/19 @ 8a PST or 11a EST

Michael Maximilien
 

Hi, all, 
 
Final reminder for the September CAB call tomorrow @ 8a PST or 11a EST.
 
Brief Agenda [0]
 
0. CFF update on up coming CF-Summit Basel
1. Update/highlights for the various PMC
2. “Service Fabrik 2.0 – Architecture, Design" followed by a demo by @Chattopadhyay, Subhankar of SAP [1]
3. “Updates on CF Container Runtime (aka Kubo)” by Urvashi Reddy of Pivotal [2]
 
Zoom soon. Best,

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

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: cf-dev@...
Cc: ureddy@...
Subject: REMINDER: CAB call for September is Wednesday 09/19 @ 8a PST or 11a EST
Date: Wed, Sep 12, 2018 3:04 PM
 
 

Hi, all,

 

Quick reminder for the CAB call next Wednesday and announcing one talk:

 

1. “Updates on CF Container Runtime (aka Kubo)” by Urvashi Reddy of Pivotal

2. TBD - if you have a talk please email me ASAP

 

Full agenda and Zoom details in [0]. Zoom soon. Best,

 

------

dr.max

ibm ☁ 

silicon valley, ca

maximilien.org

 

[0] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#heading=h.mewn94q54hla

[1] https://github.com/cloudfoundry-incubator/kubo-release

 
 

Re: Set maxHttpHeaderSize in tomcat server as a parameter

Lingesh Mouleeshwaran
 

Thanks, Sajjad !!!

On Tue, Sep 18, 2018 at 10:56 PM, <sajjadgholami2006@...> wrote:
Thanks Dan, I know you are trying to help me with other options, but we already considered those options. As Lingesh mentioned in the PR message, this is happening in more CF services now with moving to JWT and it's sort of blocking the basic functionalities; so it's much better to have it in main repo :)

Thanks a lot Lingesh for making the PR, I'll follow that and use it whenever it's merged :)

Best,
Sajjad


Re: Set maxHttpHeaderSize in tomcat server as a parameter

sajjadgholami2006@...
 

Thanks Dan, I know you are trying to help me with other options, but we already considered those options. As Lingesh mentioned in the PR message, this is happening in more CF services now with moving to JWT and it's sort of blocking the basic functionalities; so it's much better to have it in main repo :)

Thanks a lot Lingesh for making the PR, I'll follow that and use it whenever it's merged :)

Best,
Sajjad

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

Liu Liming
 

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

[cf-abacus] Usage Sampler proposal

Hristo Iliev
 

Hi all,

Abacus team is ready to start the next big chunk of work. We want to remove the time-based metrics we now use to integrate with Cloud Foundry's app & service events and replace them with sampling.

Why?
Time-based metrics are complex, costly in terms of CPU and storage space. Clients have to renew time-based usage, which requires persistence on their side. We see tham as unreliable and error-prone.

How?
We are proposing a new Sampler component that will expose REST API for continuous events.

More info can be found in this document:

Your feedback is highly appreciated.

Regards,
Hristo Iliev

Re: Set maxHttpHeaderSize in tomcat server as a parameter

Lingesh Mouleeshwaran
 

Hello All, 


Regards
Lingesh M

On Tue, Sep 18, 2018 at 8:06 AM, Daniel Mikusa <dmikusa@...> wrote:
On Mon, Sep 17, 2018 at 4:55 PM, <sajjadgholami2006@...> wrote:
I see what you mean Dan, I know that it doesn't need the whole repo to be forked and it's just tomcat configuration; but that still needs another 'public' repo to host the tomcat customized configuration.

It doesn't have to be public. It can be on a company's internal network. It just needs to be accessible from the platform where the buildpack is running. That's why it's convenient to use the Staticfile buildpack and host the config on the platform itself.
 
Look at it from a corporation's view, they don't want to trust more repositories than the formal open source repos having a support of a community and it's secure since the community has it under control, instead of my own public repo that I can mess it up anytime.

I wouldn't expect anyone to trust a random repo from the internet. They'd want to host their own Tomcat config on a server they control, like an app they push to their platform using the Staticfile buildpack.

Anyway, I probably do not fully understand your use case and that's OK. I just wanted to suggest this other option in case it might work for you.

Dan

 
That's my whole point, it can be a parameter exposed in the formal code base which everyone has trust on. 



Re: Set maxHttpHeaderSize in tomcat server as a parameter

Daniel Mikusa
 

On Mon, Sep 17, 2018 at 4:55 PM, <sajjadgholami2006@...> wrote:
I see what you mean Dan, I know that it doesn't need the whole repo to be forked and it's just tomcat configuration; but that still needs another 'public' repo to host the tomcat customized configuration.

It doesn't have to be public. It can be on a company's internal network. It just needs to be accessible from the platform where the buildpack is running. That's why it's convenient to use the Staticfile buildpack and host the config on the platform itself.
 
Look at it from a corporation's view, they don't want to trust more repositories than the formal open source repos having a support of a community and it's secure since the community has it under control, instead of my own public repo that I can mess it up anytime.

I wouldn't expect anyone to trust a random repo from the internet. They'd want to host their own Tomcat config on a server they control, like an app they push to their platform using the Staticfile buildpack.

Anyway, I probably do not fully understand your use case and that's OK. I just wanted to suggest this other option in case it might work for you.

Dan

 
That's my whole point, it can be a parameter exposed in the formal code base which everyone has trust on. 


Apps/microservices that have long request processing times.

Jonathan Stockley
 

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: Set maxHttpHeaderSize in tomcat server as a parameter

sajjadgholami2006@...
 

I see what you mean Dan, I know that it doesn't need the whole repo to be forked and it's just tomcat configuration; but that still needs another 'public' repo to host the tomcat customized configuration. Look at it from a corporation's view, they don't want to trust more repositories than the formal open source repos having a support of a community and it's secure since the community has it under control, instead of my own public repo that I can mess it up anytime. That's my whole point, it can be a parameter exposed in the formal code base which everyone has trust on. 

Re: Set maxHttpHeaderSize in tomcat server as a parameter

Daniel Mikusa
 

On Mon, Sep 17, 2018 at 1:28 PM, <sajjadgholami2006@...> wrote:

[Edited Message Follows]

Thanks Lingesh for sharing your repo; right I actually did try it on my own repo as well, but we want it to be formally accepted and be in the original build-pack to use.

Daniel, you're right; but again this needs another repo to be setup, we want to only trust the one formal original CF repo that has the community watching it instead of moving to unreliable sources or to create and maintain our own repo besides this that's why I'm suggesting to make the change in original repo :)

Not sure what you mean. It doesn't require that you fork the buildpack. You just need to host your Tomcat config somewhere. That's cause the buildpack will need to download it, since it's not part of the JBP. The easiest way is to push your config w/the Staticfile buildpack. Then you can use `cf set-env` and tell the JBP to use your external config bundle from your Staticfile app. You could post the config elsewhere too, like S3 or any other HTTP server.

Dan


 


Re: Set maxHttpHeaderSize in tomcat server as a parameter

sajjadgholami2006@...
 

Thanks Lingesh,

We can argue that this is kind of needed for CF services, due to the nature of using JWT token in header; if you want to put something convincing in the pull-request comment ;) 

Re: Set maxHttpHeaderSize in tomcat server as a parameter

Lingesh Mouleeshwaran
 

Alright Thanks, Sajjid, Let me create a pull request for the same. Need to wait for the community concerns as well

On Mon, Sep 17, 2018 at 10:58 PM, <sajjadgholami2006@...> wrote:

[Edited Message Follows]

Thanks Lingesh for sharing your repo; right I actually did try it on my own repo as well, but we want it to be formally accepted and be in the original build-pack to use.

Daniel, you're right; but again this needs another repo to be setup, we want to only trust the one formal original CF repo that has the community watching it instead of moving to unreliable sources or to create and maintain our own repo besides this that's why I'm suggesting to make the change in original repo :)


Re: Set maxHttpHeaderSize in tomcat server as a parameter

sajjadgholami2006@...
 
Edited

Thanks Lingesh for sharing your repo; right I actually did try it on my own repo as well, but we want it to be formally accepted and be in the original build-pack to use.

Daniel, you're right; but again this needs another repo to be setup, we want to only trust the one formal original CF repo that has the community watching it instead of moving to unreliable sources or to create and maintain our own repo besides this that's why I'm suggesting to make the change in original repo :)