Date   

Re: Minimal CF Install for Demos

David Sabeti
 

Hey Matt,

We've heard a lot about this recently, so the Release Integration team has some stories prioritized to ship a manifest with a small footprint than the usual cf-deployment: https://www.pivotaltracker.com/story/show/155371326. The idea is that operators would use the manifest to deploy to a cloud provider, but only end up with 4-5 VMs.

Feel free to reach out in the #release-integration channel in the CF slack if you have any questions.

David Sabeti
Project Lead, CF Release Integration

On Mon, Apr 23, 2018 at 2:58 PM Matt Curry <matt.curry@...> wrote:

Does anyone have a guilde for a minimal CF install on AWS or GCP for demo purproses?

 

In other words, the cheapest and smallest possible working install.

 

I think that this is the point of CFDev, but I need to be able to run 2 installs side by side, and also need to be able to deploy it to a cloud provider so that it is public facing.

 

Thanks,

Matt


Minimal CF Install for Demos

Matt Curry
 

Does anyone have a guilde for a minimal CF install on AWS or GCP for demo purproses?

 

In other words, the cheapest and smallest possible working install.

 

I think that this is the point of CFDev, but I need to be able to run 2 installs side by side, and also need to be able to deploy it to a cloud provider so that it is public facing.

 

Thanks,

Matt


Re: cF CLI v6.36.0 Released - droplet upload, service bindings, disablekeepalives

Abby Chau
 

Thanks for reaching out - apologies for the delay in response. We do not currently have plans to support "cf download-droplet". However, if we receive more user feedback about adding support for this feature, then we can review this again. In the meantime, we believe cf-local will take care of this use case. Thanks. 


On Thu, Apr 5, 2018 at 2:39 PM, Dr Nic Williams <drnicwilliams@...> wrote:
To clarify future plans: are there plans for "cf download-droplet" to be a 1st-class citizen, or do you recommend we use + promote to others a CLI plugin?



Re: CF / K8S (and related projects) Special Interest Group Call

Amit Kumar Gupta
 

Hey Chip

Thanks for organizing this, sounds interesting!  Is there some way to create a recurring calendar invite that anyone on cf-dev@ can join?  In the mean time, I can create a calendar event for myself, what will the duration of the meeting be?

Cheers,
Amit

On Mon, Apr 23, 2018 at 8:22 AM, Chip Childers <cchilders@...> wrote:
Hi all!

There's a ton of activity in the CF and larger open source community working to better integrate K8S (and other related projects) with the CF technology stacks. They include everything from the CFCR project, CFAR projects with work streams to explore integrations, network level integrations, approaches to make BOSH work well with k8s, ideas around containerizing the CFAR components, etc...  These efforts are happening in many different corners of our community, making it hard to track from the outside looking in. To help share what's happening, we'll be hosting an ongoing call specific to this topic. This is open to anyone that wants to join. This is an informal call for information sharing and open discussions.

First call will be this Wednesday (April 25th) at noon US Eastern (9 AM US Pacific time, 5 PM UK time). Calls will be every other week as well.

Dial in number: 215-315-3487
No PIN needed

International Callers
Dial the local number below based on your location. When prompted, enter your host's conference number (215-315-3487), then the "#" key.
-Germany: 030 30807999
-Ireland: (01) 525 5652
-United Kingdom: 020 3514 1993
Other international numbers available here: https://www.uberconference.com/international 

Please shout if you have any questions. I've sent this group a placeholder for the meeting, and I'll be sharing with cf-dev@ and the broader community in the coming days.

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815



Re: cf-notifications incubator status

Adam Hevenor
 

Guillaume - 

The slack channel is the best way to get in touch. One note the PM listed on the cloudfoundry.org site is incorrect. Nadja Conklin has taken over as PM and the team is located here in Denver with the Loggregator team. I'll pass along the feedback about having a publicly accesible backlog. 

Adam


CF / K8S (and related projects) Special Interest Group Call

Chip Childers <cchilders@...>
 

Hi all!

There's a ton of activity in the CF and larger open source community working to better integrate K8S (and other related projects) with the CF technology stacks. They include everything from the CFCR project, CFAR projects with work streams to explore integrations, network level integrations, approaches to make BOSH work well with k8s, ideas around containerizing the CFAR components, etc...  These efforts are happening in many different corners of our community, making it hard to track from the outside looking in. To help share what's happening, we'll be hosting an ongoing call specific to this topic. This is open to anyone that wants to join. This is an informal call for information sharing and open discussions.

First call will be this Wednesday (April 25th) at noon US Eastern (9 AM US Pacific time, 5 PM UK time). Calls will be every other week as well.

Dial in number: 215-315-3487
No PIN needed

International Callers
Dial the local number below based on your location. When prompted, enter your host's conference number (215-315-3487), then the "#" key.
-Germany: 030 30807999
-Ireland: (01) 525 5652
-United Kingdom: 020 3514 1993
Other international numbers available here: https://www.uberconference.com/international 

Please shout if you have any questions. I've sent this group a placeholder for the meeting, and I'll be sharing with cf-dev@ and the broader community in the coming days.

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: cf-notifications incubator status

Guillaume Berche
 

Hi,

Sorry I had missed the notification team page [4] on the CFF page, I'll then follow up with the notification team on their slack.

[4] https://www.cloudfoundry.org/projects/

Thanks,

Guillaume.

On Fri, Apr 20, 2018 at 7:05 PM, Guillaume Berche <bercheg@...> wrote:
Hi,

I'd like to learn the status of the notifications repo [1], which team is working on it and its backlog.

There seems to have some commits this year, which reference a pivotal tracker [3][2], but it does not seem yet made public to the community. The associated developer don't seem to have a CF slack account.

[1] https://github.com/cloudfoundry-incubator/notifications
[2] https://github.com/cloudfoundry-incubator/notifications/commit/ed739776696411a6d4b902d6f0bbb92044e2227b
[3] https://www.pivotaltracker.com/story/show/154300458

Thanks in advance,

Guillaume.


Re: How to lock account in UAA using UAA API? #cf

shilpa kulkarni
 

Thank you. It worked. 


cf-notifications incubator status

Guillaume Berche
 

Hi,

I'd like to learn the status of the notifications repo [1], which team is working on it and its backlog.

There seems to have some commits this year, which reference a pivotal tracker [3][2], but it does not seem yet made public to the community. The associated developer don't seem to have a CF slack account.

[1] https://github.com/cloudfoundry-incubator/notifications
[2] https://github.com/cloudfoundry-incubator/notifications/commit/ed739776696411a6d4b902d6f0bbb92044e2227b
[3] https://www.pivotaltracker.com/story/show/154300458

Thanks in advance,

Guillaume.


Re: How to lock account in UAA using UAA API? #cf

DHR
 

In that case you might have to send an updated request with “active”: false via a PUT request to /Users/:guid

On 20 Apr 2018, at 11:25, shilpa kulkarni <shilpakulkarni91@...> wrote:

Hi DHR,

Yes I tried setting locked to true as follows:

But I am getting following error response:
{
  "error_description": "Cannot set user account to locked. User accounts only become locked through exceeding the allowed failed login attempts.",
  "error": "scim",
  "message": "Cannot set user account to locked. User accounts only become locked through exceeding the allowed failed login attempts."
}


Re: How to lock account in UAA using UAA API? #cf

shilpa kulkarni
 

Hi DHR,

Yes I tried setting locked to true as follows:

But I am getting following error response:
{
  "error_description": "Cannot set user account to locked. User accounts only become locked through exceeding the allowed failed login attempts.",
  "error": "scim",
  "message": "Cannot set user account to locked. User accounts only become locked through exceeding the allowed failed login attempts."
}


Re: How to lock account in UAA using UAA API? #cf

DHR
 

Hi Shilpa,

Did you try sending a PATCH request as per the example you linked, with locked: true ?

Eg

PATCH /Users/0daf6e54-52c5-4360-bd4a-77f5355950b3/status HTTP/1.1
Content-Type: application/json
Authorization: Bearer fe11ae74b429403796ea13c017bff06c
Accept: application/json
Host: localhost
Content-Length: 22

{
  "locked" : true }

On 19 Apr 2018, at 08:13, shilpa kulkarni <shilpakulkarni91@...> wrote:

Hello,
I am using cloud foundry UAA APIs.  I want to lock user account. But in the API documentation,  I am getting only unlock account API. 
Reference link:
http://docs.cloudfoundry.org/api/uaa/version/4.12.0/#unlock-account

Is there any way to lock account in UAA using API.?

Thanks & Regards
Shilpa Kulkarni


How to lock account in UAA using UAA API? #cf

shilpa kulkarni
 

Hello,
I am using cloud foundry UAA APIs.  I want to lock user account. But in the API documentation,  I am getting only unlock account API. 
Reference link:
http://docs.cloudfoundry.org/api/uaa/version/4.12.0/#unlock-account

Is there any way to lock account in UAA using API.?

Thanks & Regards
Shilpa Kulkarni


Re: Announcing the Windows 2016 stack on Cloud Foundry

Dr Nic Williams <drnicwilliams@...>
 

Incredible work everyone!

Dr. Nic


From: cf-dev@... <cf-dev@...> on behalf of A William Martin <amartin@...>
Sent: Wednesday, April 18, 2018 6:19:21 PM
To: Cloud Foundry dev
Subject: [cf-dev] Announcing the Windows 2016 stack on Cloud Foundry
 

Dear cf-dev:


With the recent cf-deployment version 1.22, I’m pleased to announce the general availability of Cloud Foundry’s support for Windows Server 2016 (actually, version 1709) and its native Windows container technology.



TL;DR


Cloud Foundry developers can now use the windows2016 stack to push .NET applications, use more CF features (i.e. cf ssh), and expect a more elastic, scalable, stable experience on Cloud Foundry, due to the advantages afforded by Windows Server Containers. This is an important step for a sustainable runtime and platform experience for .NET.


Getting Started


Operators can upload a Windows Server version 1709 stemcell from bosh.io and bosh deploy with the windows2016-cell.yml ops file. Developers can then cf push with the windows2016 stack and hwc_buildpack.



A Giant Leap for .NET + Cloud Foundry


This effectively brings the .NET and Cloud Foundry technology ecosystems closer together, giving .NET apps a sustainable opportunity to leverage the full benefits of CF’s evolving runtime while consuming the Windows and IIS capabilities they also need. One can even use cf ssh to debug a cf-pushed .NET app remotely from Visual Studio – to be demoed at CF Summit NA this week!


With the previous 2012 R2 stack (powered by IronFrame) and older Diego MSI, the experience for .NET apps and Windows deployment was rather sub-par. To address this, the CFF Windows teams have been working towards a level of “pragmatic parity” between the capabilities available for apps hosted on Linux and those on Windows. We think we’ve finally achieved the right foundation to serve many more CF features in the future in both worlds.


As more is now possible for .NET on CF, at the same time, the Windows runtime has become simpler. For example, it now uses the same app lifecycle as Linux-hosted apps, which means multiple buildpacks landed for .NET apps without extra work. This shows an important aspect of sustainable “pragmatic parity” between Linux and Windows moving forward.


What can .NET apps use on Cloud Foundry now?


The latest features are cf ssh, accurate application CPU metrics, full container file system, context path routing, and multiple buildpacks. However, the benefits afforded by Windows containers are more than in the list of working features, but shine in the actual behavior of the platform while running .NET apps.


For example, on the 2012 R2 stack, greedy apps could easily starve others of CPU and even consume the cell itself. Now, since CPU shares are available, apps on the windows2016 stack don’t suffer from noisy neighbors and are as elastic and scalable as Linux apps (but with a bit more memory overhead on Windows of course).


How was this made possible?


The new Windows has containers! (They’re analogous to those on Linux but naturally not quite like them.) Fortuitously, this means the new Windows stack can now use the same Garden infrastructure as Linux Diego cells, in which it swaps out runc for winc, an OCI-compliant container plugin for Windows, authored by the CF Garden Windows team. The stack also ships with groot-windows, a Garden image plugin. For details, there’s a CF Summit session coming up about it this Friday.


What is Windows Server version 1709?


This is a derivative of Windows Server 2016, delivered as part of Microsoft’s “Semi-Annual Channel” (SAC) releases of Windows Server. You can think of them similarly to the non-LTS versions of Ubuntu (16.10, 17.04, 17.10, etc.). While they may seem merely another version schema, the advances in the containerization characteristics in each SAC release are quite significant.


Why 1709?


Pinning first to “version 1709” aims to deliver to CF the best isolation and networking available from Windows containers. To continue along this track, the CF Garden Windows team has started to develop against “version 1803” with an eye towards the upcoming Windows Server 2019. We hope these versions will have what’s needed to implement container-to-container networking and more.


What about AWS?


If you look on bosh.io, you’ll notice the AWS stemcell (under “Windows 2016”) is conspicuously missing. Unfortunately, AWS doesn’t yet publish a Windows Server v1709 AMI, but Azure and GCP are good to go. (For vSphere, you still need to build your own stemcell, but CF BOSH Windows continues to work on improved ways of doing so.) While we’re lobbying for AWS to ship a 1709 AMI, Amazon still hasn’t given any timeline for its availability, and for that we could use your help.


Thanks


There are so many Cloud Foundry contributors to thank in this year-long effort. To call out a few:


  • Special thanks to the Garden team, pun-master Julian Friedman, Will Martin, Ed King, et al., who have given their expertise, inspiration, and guidance since the inception in February last year to send us along the OCI-compatible route. The next frontier is containerd!

  • Thanks to Diego, especially Eric Malm and John Shahid, for working with us so openly and acceptingly.

  • Thanks to Buildpacks, Stephen Levine and team, for maintaining the HWC Buildpack and guiding the common developer infrastructure for all.

  • And many thanks to CAPI, BOSH, Release Integration, for supporting the new Windows stack efforts and making it real.

  • I'm sure there are others as well, and we look forward to working with even more teams as our efforts grow!


Stay tuned for more info from the CFF Windows teams! There is still lots work to do, and we thrive on your feedback. Find us on the Cloud Foundry Slack at #garden-windows or #bosh-core-dev.


Cheers,

William

CFF Garden Windows / BOSH Windows project lead




Announcing the Windows 2016 stack on Cloud Foundry

A William Martin
 

Dear cf-dev:


With the recent cf-deployment version 1.22, I’m pleased to announce the general availability of Cloud Foundry’s support for Windows Server 2016 (actually, version 1709) and its native Windows container technology.



TL;DR


Cloud Foundry developers can now use the windows2016 stack to push .NET applications, use more CF features (i.e. cf ssh), and expect a more elastic, scalable, stable experience on Cloud Foundry, due to the advantages afforded by Windows Server Containers. This is an important step for a sustainable runtime and platform experience for .NET.


Getting Started


Operators can upload a Windows Server version 1709 stemcell from bosh.io and bosh deploy with the windows2016-cell.yml ops file. Developers can then cf push with the windows2016 stack and hwc_buildpack.



A Giant Leap for .NET + Cloud Foundry


This effectively brings the .NET and Cloud Foundry technology ecosystems closer together, giving .NET apps a sustainable opportunity to leverage the full benefits of CF’s evolving runtime while consuming the Windows and IIS capabilities they also need. One can even use cf ssh to debug a cf-pushed .NET app remotely from Visual Studio – to be demoed at CF Summit NA this week!


With the previous 2012 R2 stack (powered by IronFrame) and older Diego MSI, the experience for .NET apps and Windows deployment was rather sub-par. To address this, the CFF Windows teams have been working towards a level of “pragmatic parity” between the capabilities available for apps hosted on Linux and those on Windows. We think we’ve finally achieved the right foundation to serve many more CF features in the future in both worlds.


As more is now possible for .NET on CF, at the same time, the Windows runtime has become simpler. For example, it now uses the same app lifecycle as Linux-hosted apps, which means multiple buildpacks landed for .NET apps without extra work. This shows an important aspect of sustainable “pragmatic parity” between Linux and Windows moving forward.


What can .NET apps use on Cloud Foundry now?


The latest features are cf ssh, accurate application CPU metrics, full container file system, context path routing, and multiple buildpacks. However, the benefits afforded by Windows containers are more than in the list of working features, but shine in the actual behavior of the platform while running .NET apps.


For example, on the 2012 R2 stack, greedy apps could easily starve others of CPU and even consume the cell itself. Now, since CPU shares are available, apps on the windows2016 stack don’t suffer from noisy neighbors and are as elastic and scalable as Linux apps (but with a bit more memory overhead on Windows of course).


How was this made possible?


The new Windows has containers! (They’re analogous to those on Linux but naturally not quite like them.) Fortuitously, this means the new Windows stack can now use the same Garden infrastructure as Linux Diego cells, in which it swaps out runc for winc, an OCI-compliant container plugin for Windows, authored by the CF Garden Windows team. The stack also ships with groot-windows, a Garden image plugin. For details, there’s a CF Summit session coming up about it this Friday.


What is Windows Server version 1709?


This is a derivative of Windows Server 2016, delivered as part of Microsoft’s “Semi-Annual Channel” (SAC) releases of Windows Server. You can think of them similarly to the non-LTS versions of Ubuntu (16.10, 17.04, 17.10, etc.). While they may seem merely another version schema, the advances in the containerization characteristics in each SAC release are quite significant.


Why 1709?


Pinning first to “version 1709” aims to deliver to CF the best isolation and networking available from Windows containers. To continue along this track, the CF Garden Windows team has started to develop against “version 1803” with an eye towards the upcoming Windows Server 2019. We hope these versions will have what’s needed to implement container-to-container networking and more.


What about AWS?


If you look on bosh.io, you’ll notice the AWS stemcell (under “Windows 2016”) is conspicuously missing. Unfortunately, AWS doesn’t yet publish a Windows Server v1709 AMI, but Azure and GCP are good to go. (For vSphere, you still need to build your own stemcell, but CF BOSH Windows continues to work on improved ways of doing so.) While we’re lobbying for AWS to ship a 1709 AMI, Amazon still hasn’t given any timeline for its availability, and for that we could use your help.


Thanks


There are so many Cloud Foundry contributors to thank in this year-long effort. To call out a few:


  • Special thanks to the Garden team, pun-master Julian Friedman, Will Martin, Ed King, et al., who have given their expertise, inspiration, and guidance since the inception in February last year to send us along the OCI-compatible route. The next frontier is containerd!

  • Thanks to Diego, especially Eric Malm and John Shahid, for working with us so openly and acceptingly.

  • Thanks to Buildpacks, Stephen Levine and team, for maintaining the HWC Buildpack and guiding the common developer infrastructure for all.

  • And many thanks to CAPI, BOSH, Release Integration, for supporting the new Windows stack efforts and making it real.

  • I'm sure there are others as well, and we look forward to working with even more teams as our efforts grow!


Stay tuned for more info from the CFF Windows teams! There is still lots work to do, and we thrive on your feedback. Find us on the Cloud Foundry Slack at #garden-windows or #bosh-core-dev.


Cheers,

William

CFF Garden Windows / BOSH Windows project lead




Re: REMINDER: CAB call for April is Wednesday 04/18 @ 8a PST or 11a EST

Michael Maximilien
 

Final reminder. If you are in Boston for summit meet in room 156C otherwise zoom.

No specific agenda items. Just chatting and QAs. It will be fun!

Zoom soon.

Best,

dr.max
ibm ☁ 
silicon valley, ca



dr.max
ibm ☁ 
silicon valley, ca


On Apr 11, 2018, at 4:39 PM, Michael Maximilien <maxim@...> wrote:

FYI...
 
Reminder that the CAB call for April is scheduled for next Wednesday 04/18 @ 8a PST / 11a EST.
 
Since next week is also CF Summit week, in Boston, MA, we plan to do the CAB call live at the conference.
 
So please plan to join us in Room 156C as we will have a live discussions and QAs with conference attendees and those joining us on Zoom [1].
 
No other agenda items are planed. I will send one more reminder next week on this list. See you all soon.
 
Best,


JBP 4.x: Committed heap shows signs of memory leak

Siva <mailsiva@...>
 

Hello CF community,
I wanted to poll the community to see if anyone has come across this issue as described in the below github issue:
We are noticing this in more than 1 service running JBP 4.x. Any feedback/input would be greatly appreciated. 

Thanks


Re: Understanding hard CPU limits

Marco Voelz
 

Thanks for the thorough explanation, Eric!

 

Warm regards

Marco

 

From: <cf-dev@...> on behalf of Eric Malm <emalm@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Wednesday, 11. April 2018 at 11:32
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Understanding hard CPU limits

 

Oh, I omitted one detail from the CC logic: the 1024 CPU-share maximum corresponds to 8192 MB (8 GB) of allocated memory, and this controls the proportionality constant between memory and CPU shares.

 

Thanks,

Eric

 

On Tue, Apr 10, 2018 at 10:42 PM, Eric Malm <emalm@...> wrote:

Hey, Michael and Marco,

 

Sorry for the delay in getting a chance to respond to this thread. In general, CF apps receive an allocation of CPU shares proportional to their allocated memory, but with some high and low cutoffs and some limited granularity:

 

- The minimum number of CPU shares that an app instance (or task) will receive is 10.

- The maximum is 1024.

- The granularity is roughly every 10 shares (10.24, to be precise).

 

 

In my personal experiments when setting the garden.cpu_quota_per_share_in_us property, the number of cores does not factor into the per-instance limit, and the quota is enforced as CPU time across all the cores. To constrain a 64 MB-memory app instance to at most 6.4% CPU usage, I had to set garden.cpu_quota_per_share_in_us to 640. A 1 GB-memory app instance, which has 122 CPU shares, can then use up to 78.1% of a CPU core.

 

Best,

Eric

 

On Fri, Apr 6, 2018 at 11:02 AM, Dieu Cao <dcao@...> wrote:

I believe Julz is on vacation this week.

Adding Ed King, the anchor on the Garden team.

 

Dieu

 

On Tue, Apr 3, 2018, 3:08 AM Marco Voelz <marco.voelz@...> wrote:

 

/cc Eric and Julz: Could you maybe help us understand this? Thanks!


From: cf-dev@... <cf-dev@...> on behalf of Grifalconi, Michael <michael.grifalconi@...>
Sent: Monday, March 26, 2018 10:54:32 AM
To:
cf-dev@...
Subject: [CAUTION] [cf-dev] Understanding hard CPU limits

 

Hi,

We were trying out the hard CPU limit as per docs
https://github.com/cloudfoundry/garden-runc-release/releases?after=v1.9.2

GitHub is where people build software. More than 27 million people use GitHub to discover, fork, and contribute to over 80 million projects.




according to formula for single core machine,

APP_MEM_IN_MB * 100us / 1000 = MILLISECONDS_PER_100_MILLISECOND_PERIOD

In our tests, to get 6.4% CPU usage on a 64MB application and ~100% for a 1GB application we had to set the 'cpu_quota_per_share_in_us' to 3200. (Cell has 4 core and 16GB or ram, overcommit factor of 2).

That changes the formula to:
APP_MEM_IN_MB * 100us / 32000 = MILLISECONDS_PER_100_MILLISECOND_PERIOD

Can you help us to understand from where this 'times 32' comes from? Is the total available RAM of the cell (16GB * overcommit of 2) and number of cpu cores does not matter?

Thanks and regards,
Michael



 

 


Re: Proposal for Incubation in the Extensions PMC: CF Dev

Michael Maximilien
 

Hi, all,

Don’t forget to provide feedback for CF-dev. The proposing team has asked for a vote and since we have a CAB call for this Wednesday, I want to use that as the deadline.

If there are no pending comments, we will move for a vote after the call.

Thanks for your attention.

Best,

Max


On Fri, Feb 23, 2018 at 3:20 PM Stephen Levine <slevine@...> wrote:

Hi All,


Pivotal is proposing CF Dev for inclusion in the Extensions PMC as a new incubating project.


CF Dev is a deployment of BOSH and cf-deployment that runs locally in Garden containers. It uses native hypervisors to start quickly with zero external dependencies. It also provides a fully functional BOSH director.


CF Dev is currently available on Github [1].


I would also like to introduce everyone to Scott Sisil, who is joining me as Co-PM on Pivotal's local and community developer initiatives. Please reach out to Scott and/or myself for questions about CF Dev.


Details:


Project Name: CF Dev

Project Proposal: See [2], and attached.

Proposed Project Leads: Stephen Levine, Pivotal & Scott Sisil Pivotal

Proposed Contributors: Emily Casey, Pivotal; Dave Protasowski, Pivotal; Stephen Hiehn, Pivotal

Proposed Scope: See [2], and attached.

Development Operating Model: Pairing (local + remote)

Technical Approach: CF CLI plugin that starts a VM using the OS native hypervisor.


Please let us know if you have any questions or feedback.


[1] https://github.com/pivotal-cf/cfdev

[2] https://docs.google.com/document/d/1QBTstRXN-1MmINZr1b1G5K6cM6bptQRvsafg_nyP8I8/edit#


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


Re: Proposal for Incubation in the Extensions PMC: CF Dev

Dr Nic Williams <drnicwilliams@...>
 

Wow, a 3G ram footprint would be incredible goal.


From: cf-dev@... <cf-dev@...> on behalf of Scott Sisil <ssisil@...>
Sent: Monday, April 16, 2018 8:03:21 AM
To: Guillaume Berche
Cc: cf-dev; Casey, Emily (Pivotal); Chip Childers
Subject: Re: [cf-dev] Proposal for Incubation in the Extensions PMC: CF Dev
 
Hi All,

We wanted to give everyone a quick update on progress we have made with CF Dev:
  •  We fixed the privileged port access bug (Issue #11). Now all users should be able to login to CF Dev using the CF CLI.
  •  We received a lot of feedback on the memory / disk space footprint. The team is actively working on shrinking both of these with a goal that we can get to a memory footprint of less than 3 GB
  •  We have added telemetry to start collecting anonymous usage analytics. The raw analytics data will be available via a public Amazon S3 bucket. We also plan to publish a quarterly analytics report to the projects Github page.

Just a quick reminder that Stephen Levine will be presenting a demo of CF Dev at the Thursday keynote @ CF Summit this week.

Finally, we would appreciate any additional feedback to the project - please submit feedback in the proposal itself or respond directly to this email thread.

Thanks
Scott

On Tue, Feb 27, 2018 at 4:32 AM, Guillaume Berche <bercheg@...> wrote:
Thanks Stephen.

Guillaume.

On Tue, Feb 27, 2018 at 12:09 AM, Stephen Levine <slevine@...> wrote:
Hi Guillaume,

Apologies for the google doc permissions issue -- should be fixed now :)

We don't have a public tracker or design docs yet, but we plan to have both soon.

-Stephen

On Mon, Feb 26, 2018 at 5:56 PM, Guillaume Berche <bercheg@...> wrote:
Thanks Stephen for opensourcing CF Dev through this proposal, seems great!

I wonder whether there is a public backlog for the project ? I see some commits such as [1] apparently refer to pivotal tracker story ids, but the project does not yet seem public [2].
May be the tracker refers to some design doc that I could not yet find in the source, if not this might be useful to the community.

Thanks in advance,

Guillaume.

ps: the proposal google doc permissions seem to be set to read-only and not accept comments or suggestions.


Guillaume.

On Mon, Feb 26, 2018 at 5:28 PM, Stephen Levine <slevine@...> wrote:
PCF Dev is already often (mistakenly) referred to as CF Dev, as `cf dev [command]` is the CLI invocation. We figured that calling this product CF Dev would give both products consistent names that make sense.

We considered the conflict with the list alias, but given that a mailing list alias and a software tool are significantly different things, and that CF Dev is already commonly used to refer to PCF Dev anyways, we decided not to change it.

On Mon, Feb 26, 2018 at 11:04 AM, Michael Maximilien <maxim@...> wrote:
We’ll definitely have to find better names as cf-dev is also this mailing list. Too many polymorphic usage of this one moniker. Let’s be creative!

dr.max
ibm ☁ 
silicon valley, ca



dr.max
ibm ☁ 
silicon valley, ca


On Feb 23, 2018, at 2:40 PM, Hjortshoj, Julian <Julian.Hjortshoj@...> wrote:

Is it too late to change the name?  I suspect that folks might not instantly understand that cf-dev and CF Dev are two entirely different things. 

From: <cf-dev@...> on behalf of Stephen Levine <slevine@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Friday, February 23, 2018 at 12:20 PM
To: "cf-dev@..." <cf-dev@...>
Cc: "Sisil, Scott (Pivotal)" <ssisil@...>, "Casey, Emily (Pivotal)" <ecasey@...>, Chip Childers <cchilders@...>, Michael Maximilien <maxim@...>
Subject: [cf-dev] Proposal for Incubation in the Extensions PMC: CF Dev

Hi All,


Pivotal is proposing CF Dev for inclusion in the Extensions PMC as a new incubating project.


CF Dev is a deployment of BOSH and cf-deployment that runs locally in Garden containers. It uses native hypervisors to start quickly with zero external dependencies. It also provides a fully functional BOSH director.


CF Dev is currently available on Github [1].


I would also like to introduce everyone to Scott Sisil, who is joining me as Co-PM on Pivotal's local and community developer initiatives. Please reach out to Scott and/or myself for questions about CF Dev.


Details:


Project Name: CF Dev

Project Proposal: See [2], and attached.

Proposed Project Leads: Stephen Levine, Pivotal & Scott Sisil Pivotal

Proposed Contributors: Emily Casey, Pivotal; Dave Protasowski, Pivotal; Stephen Hiehn, Pivotal

Proposed Scope: See [2], and attached.

Development Operating Model: Pairing (local + remote)

Technical Approach: CF CLI plugin that starts a VM using the OS native hypervisor.


Please let us know if you have any questions or feedback.


[1] https://github.com/pivotal-cf/cfdev

[2] https://docs.google.com/document/d/1QBTstRXN-1MmINZr1b1G5K6cM6bptQRvsafg_nyP8I8/edit#








1481 - 1500 of 9408