Date   

Re: Understanding hard CPU limits

Dieu Cao <dcao@...>
 

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: cF CLI v6.36.0 Released - droplet upload, service bindings, disablekeepalives

Dr Nic Williams <drnicwilliams@...>
 

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?


cF CLI v6.36.1 Released Today; bug fix for bind-service

Abby Chau
 

Hi all,

The cf CLI team released cf CLI v6.36.1 today; please see release notes for full details. This release contains a bug fix for:
  • bind-service, whereby when a user attempts to bind a service to an app, an error message would be thrown stating --name requires a specific CF API version. This patch release fixes the issue. #1359
Please do not hesitate to reach out if you have any questions. 

Best,

Abby and the cf CLI team



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

Abby Chau
 

Hi Mike,

There's not a standard command to download a droplet from CC. We believe the cf-local plugin has this functionality. Let us know if you have any further questions, thanks.

Best,

Abby


On Thu, Apr 5, 2018 at 8:49 AM, Mike Youngstrom <youngm@...> wrote:
Interesting feature.  Is there a standard command to download a droplet from the CC?  I'm aware of the download-droplet plugin is that one recommended?

Mike

On Wed, Apr 4, 2018 at 1:25 PM, Abby Chau <achau@...> wrote:
Hi all,

The cf CLI team released cf CLI v6.36.0 yesterday; please see release notes for full details. 

Highlights include:

Enhancements:
  • Droplet Upload: Now you can push an app without staging it. The push command now has an optional --droplet flag that allows you to specify a path to a tgz file with a pre-staged app. This allows you to have more granular control over which droplet is being used. For example, you can put the exact version of the app from staging on production and get the results you expect. 
  • Name Service Bindings: We've updated the bind-service command by adding an optional --binding-name flag that allows you to assign a name to that binding. This feature provides app developers control and context on the app-service binding when they may not have control over other related names, such as the app or service instance. Thanks to the CAPI team for providing this feature through PR #1309. We've also updated the service command so you can view binding names, if any, for a specific service.

Fixed issues
  • Use DisableKeepAlives when closing Network connections: The cf CLI previously used just the Connection: close header when making certain API calls to the Cloud Controller and UAA. Now, DisableKeepAlives is set to true on the client side, to aid with closing connections with these requests. This should alleviate some networking issues with certain load balancers.
Bug Fixes
    • int64 support for cf/flags library, #1333
    • Debian package, #1336
    • Web action flag not working on CLI 0.6.5, #1337
    • When a cf push upload fails/Consul is down, a panic occurs, #1340 and #1351
    • Note: Colors in the terminal will auto-detect a TTY session - which is the default color if Color_Enabled is not set in the config or $CF_COLOR is empty.
Plugin Updates
    • Create Service Push v1.0.1 release, #214
    • Add Copy-Autoscaler 0.0.1, #216
    • Update CF Local to v0.19.0, #218
    • Update the Java plugin to version 2.0.0, #219
Please do not hesitate to reach out for any questions or clarifications.

Thanks,

Abby and the cf CLI team




[cncf-toc] Please take the Kubernetes Application Survey

Chip Childers <cchilders@...>
 

CFF community!

Caught this email from Alexis to the CNCF TOC list, and wanted to share here too.

This is probably interesting to any of you (especially users) that work with Kubernetes and CFAR together. We know that lots of the users on this list are using Kubernetes for packaged software, data services, etc... and the k8s community is looking for feedback around the application deployment / operations experience. Help them help you!

-chip

---------- Forwarded message ---------
From: alexis richardson <alexis@...>
Date: Thu, Apr 5, 2018 at 11:45 AM
Subject: [cncf-toc] Please take the Kubernetes Application Survey
To: <cncf-toc@...>


CNCF TOC,

Trying to get this survey to as many as possible hence posting here.


---------- Forwarded message ----------
From: Matt Farina <matt.farina@...>
Date: Thu, Apr 5, 2018 at 8:40 AM
Subject: Take the Kubernetes Application Survey
To: Kubernetes developer/contributor discussion
<kubernetes-dev@...>, kubernetes-sig-apps
<kubernetes-sig-apps@...>, kubernetes-wg-app-def
<kubernetes-wg-app-def@...>,
cncf-kubernetes-helm@...


The survey is available at https://goo.gl/forms/ht61kKETiqVR103v1

Backstory: For the past several months the App Def WG has been looking
at how people build applications to run on Kubernetes and tools to
work with them. In order to better understand end users a survey has
been created to learn from a broader audience. The questions have been
gathered from a variety of sources, including sub-project teams, and
the resulting data will be shared with the community at large.

If you build applications for Kubernetes or operates applications on
Kubernetes we ask that you take a few minutes to let us know what you
think.

If you would, please share this survey with your networks so we can
get input from a wide audience range.

Thank you.

--
You received this message because you are subscribed to the Google
Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to kubernetes-sig-apps+unsubscribe@....
To post to this group, send email to kubernetes-sig-apps@....
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2oYEfgWxt%3DHd7PQTE7TO%2BkSqWN-xc%2BzEjWxBBrm44drZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.



--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Cloud controller doesn't recover after database downtime

Mike Youngstrom
 

We have seen this same thing as well but haven't had time to dig into it deeper.  For us it isn't hard to reproduce.  Simply do a push on a loop while doing an update duplicates it for us.  You might have enough info here for an issue in the CC project if nobody from the team looks at this message.

Mike

On Thu, Apr 5, 2018 at 5:25 AM, Holger Oehm <holger.oehm@...> wrote:
Hi,

Today we saw in our productive system during the update of the
database instance (which hosts ccdb, uaadb, locketdb and diegodb)
an error during the push of an app.

That was to be expected. The unexpected thing was, that afterwards
(when the database instance was up and running again) further attempts
to push the same application also kept failing.
From the CF_TRACE we saw that a PUT to /v2/apps/<guid> got a response
with status code 400, with code 100001, description "The app is invalid: VCAP::CloudController::BuildCreate::StagingInProgress" and error_code "CF-AppInvalid".

This didn't recover by itself for 20 minutes. After that an operator did
a cf restage of the application and the problem disappeared.

Everything else worked as expected, also the diego-sync job was running
fine.

My guess is, that the database disappeared at an inconvenient point in
time. And this left an inconsistent state.

What looks strange to me is that a cf push of the same application
kept failing, but a cf restage fixed it. Shouldn't both commands
fix the situation?

Best Regards,
Holger.





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

Mike Youngstrom
 

Interesting feature.  Is there a standard command to download a droplet from the CC?  I'm aware of the download-droplet plugin is that one recommended?

Mike

On Wed, Apr 4, 2018 at 1:25 PM, Abby Chau <achau@...> wrote:
Hi all,

The cf CLI team released cf CLI v6.36.0 yesterday; please see release notes for full details. 

Highlights include:

Enhancements:
  • Droplet Upload: Now you can push an app without staging it. The push command now has an optional --droplet flag that allows you to specify a path to a tgz file with a pre-staged app. This allows you to have more granular control over which droplet is being used. For example, you can put the exact version of the app from staging on production and get the results you expect. 
  • Name Service Bindings: We've updated the bind-service command by adding an optional --binding-name flag that allows you to assign a name to that binding. This feature provides app developers control and context on the app-service binding when they may not have control over other related names, such as the app or service instance. Thanks to the CAPI team for providing this feature through PR #1309. We've also updated the service command so you can view binding names, if any, for a specific service.

Fixed issues
  • Use DisableKeepAlives when closing Network connections: The cf CLI previously used just the Connection: close header when making certain API calls to the Cloud Controller and UAA. Now, DisableKeepAlives is set to true on the client side, to aid with closing connections with these requests. This should alleviate some networking issues with certain load balancers.
Bug Fixes
    • int64 support for cf/flags library, #1333
    • Debian package, #1336
    • Web action flag not working on CLI 0.6.5, #1337
    • When a cf push upload fails/Consul is down, a panic occurs, #1340 and #1351
    • Note: Colors in the terminal will auto-detect a TTY session - which is the default color if Color_Enabled is not set in the config or $CF_COLOR is empty.
Plugin Updates
    • Create Service Push v1.0.1 release, #214
    • Add Copy-Autoscaler 0.0.1, #216
    • Update CF Local to v0.19.0, #218
    • Update the Java plugin to version 2.0.0, #219
Please do not hesitate to reach out for any questions or clarifications.

Thanks,

Abby and the cf CLI team



Cloud controller doesn't recover after database downtime

Holger Oehm
 

Hi,

Today we saw in our productive system during the update of the
database instance (which hosts ccdb, uaadb, locketdb and diegodb)
an error during the push of an app.

That was to be expected. The unexpected thing was, that afterwards
(when the database instance was up and running again) further attempts
to push the same application also kept failing.
From the CF_TRACE we saw that a PUT to /v2/apps/<guid> got a response
with status code 400, with code 100001, description "The app is invalid: VCAP::CloudController::BuildCreate::StagingInProgress" and error_code "CF-AppInvalid".

This didn't recover by itself for 20 minutes. After that an operator did
a cf restage of the application and the problem disappeared.

Everything else worked as expected, also the diego-sync job was running
fine.

My guess is, that the database disappeared at an inconvenient point in
time. And this left an inconsistent state.

What looks strange to me is that a cf push of the same application
kept failing, but a cf restage fixed it. Shouldn't both commands
fix the situation?

Best Regards,
Holger.


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

Abby Chau
 

Hi all,

The cf CLI team released cf CLI v6.36.0 yesterday; please see release notes for full details. 

Highlights include:

Enhancements:
  • Droplet Upload: Now you can push an app without staging it. The push command now has an optional --droplet flag that allows you to specify a path to a tgz file with a pre-staged app. This allows you to have more granular control over which droplet is being used. For example, you can put the exact version of the app from staging on production and get the results you expect. 
  • Name Service Bindings: We've updated the bind-service command by adding an optional --binding-name flag that allows you to assign a name to that binding. This feature provides app developers control and context on the app-service binding when they may not have control over other related names, such as the app or service instance. Thanks to the CAPI team for providing this feature through PR #1309. We've also updated the service command so you can view binding names, if any, for a specific service.

Fixed issues
  • Use DisableKeepAlives when closing Network connections: The cf CLI previously used just the Connection: close header when making certain API calls to the Cloud Controller and UAA. Now, DisableKeepAlives is set to true on the client side, to aid with closing connections with these requests. This should alleviate some networking issues with certain load balancers.
Bug Fixes
    • int64 support for cf/flags library, #1333
    • Debian package, #1336
    • Web action flag not working on CLI 0.6.5, #1337
    • When a cf push upload fails/Consul is down, a panic occurs, #1340 and #1351
    • Note: Colors in the terminal will auto-detect a TTY session - which is the default color if Color_Enabled is not set in the config or $CF_COLOR is empty.
Plugin Updates
    • Create Service Push v1.0.1 release, #214
    • Add Copy-Autoscaler 0.0.1, #216
    • Update CF Local to v0.19.0, #218
    • Update the Java plugin to version 2.0.0, #219
Please do not hesitate to reach out for any questions or clarifications.

Thanks,

Abby and the cf CLI team


Re: Proposal for Incubation in the Extensions PMC: MultiApps

Michael Maximilien
 

Great feedback Guillaume. 

All, please consider this proposal and including feedback in the docs so that the team can address.

Please ensure your feedback is submitted before next CAB call (scheduled for week of CF summit in Boston).

Thanks,

Max


On Thu, Mar 22, 2018 at 9:18 AM Guillaume Berche <bercheg@...> wrote:
Hi Nikolay,

Thanks for sharing the MultiApp proposal and contributing this work to the community.

It seems MTA shares many objectives with the terraform providers for cloudfoundry [1], credhub [2] and uaa [3]  previous shared in [4], such as
- declarative model
- support for service instance provisionning
- expression dependencies across elements
- integration with secure credentials systems such as credhub or vault

Some objectives seem to differ though:
- terraform isn't designed to orchestrate expressed sequences of operations (and rather relies on external orchestrators for this),
- terraform isn't desired to monitoring state of resources once provisioned (e.g. starting/started/stopped/failed) nor displaying them to end-users

The TF provider seems broader in scope since in addition of the developer persona, it also addresses the cf admin and cf operators personas (i.e. full parity with CF CLI, and plans for handling some bosh resource in the future [5])

Leveraging terraform core and its ecosystem has provided many built-in, features without extra effort, e.g.:
- dry run
- partial update
- concurrent deployments
- templating (through modules)
- UI tooling (e.g. in intellij, atom)
- local or remote state management
- ability to combine multiple providers (e.g CF AR and CF CR)
- CI/CD integration (e.g. in concourse [6])

The TF provider contributors are now focussing towards having the provider join the list of official hashicorp providers [8], and has recently received some great SAP contributions [9].

You may reach out to the team on the terraform slack channel [7], we'd be happy to proceed with further exchanges around common and diverging use-cases.


On Tue, Mar 20, 2018 at 9:38 PM, Zach Robinson <zrobinson@...> wrote:
Excited to see this proposed Nikolay!

Nikolay has been sharing this project with some of the core teams over the last couple of months.  We have even been giving some thought to adopting some of the behaviors and/or code from this extension into core CF.

Some aspects I think are especially interesting:
- declarative manifest behavior
- an opinionated packaging structure
- deployment orchestration

CAPI is especially excited to see whether the community takes to some of this tooling as potential guidance for future roadmap.

-Zach
CAPI Project Lead


On Tue, Mar 20, 2018 at 9:35 AM Nikolay Valchev <nikolay.valchev@...> wrote:

Hi All,

 

SAP is proposing MultiApps (aka CF MTA deploy service) for inclusion in the Extensions PMC as a new incubating project.

MultiApps is envisioned to provide the missing higher-level lifecycle management capabilities for distributed applications in Cloud Foundry. It proposes a new declarative application model and corresponding tools helping developers achieve the following goals:

  1. Describe explicitly the structure of my application, its constituent CF-apps, routes, services and other technical artifacts. Tools, interpreting this model, would automate deployments, achieving unified lifecycle of all application components and ensuring the consistency and completeness of the distributed application.   
  2. Declare the resources (e.g. service instances or APIs from other apps) my application depends on at runtime and/or deployment time. Tools would then check existence of required service instances, possibly allocating the missing ones and making the needed app bindings. Additionally tools would resolve dependent apps API information and inject it in requiring app env.
  3. Declare configuration variables (and their relations) which distinguish different deployments of my application. Tools would bind sub-components, automate deployment based on default settings, or request missing mandatory values interactively.

MultiApps is currently available on GitHub [1].

 

Details:

Project Name: MultiApps

Project Proposal: See [2].

Proposed Project Leads: Nikolay Valchev, SAP

Proposed Scope: See [2]

Development Operating Model: Dedicated committers (local)

Technical Approach: CF CLI plugin and server application automating lifecycle operations

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

 

Best regards,

Nikolay Valchev

Development Architect and Product Owner, SAP

 

[1] https://github.com/SAP/cf-mta-deploy-service

[2] https://docs.google.com/document/d/1TCx_2gv2_n-StcV4lzbbaD4rma9HfaRG7O9wb6-egk4

 


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


Re: Understanding hard CPU limits

Marco Voelz
 


/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.com
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





Proposed BOSH logging interface

Jesse T. Alford
 

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.


Feedback on service instance sharing (experimental)

Matt McNeeney
 

I'm pleased to announce that the ability to share service instances across orgs and spaces has been released!

In order to use this feature, please make sure you are running:
To share a service instance from one space into another, you just need to run cf share-service SERVICE-INSTANCE -s SPACE

Note that this needs to be enabled by both admins (via a feature-flag) and by the author of the service you want to share.

For more information, please check out the following docs:

I'd encourage you all to try this out with a supportive service broker (like this example broker). This feature is currently experimental (beta), so feedback at this time would be extremely valuable.

Best wishes,
The CF Services API team


Re: Measuring cf push times end-to-end

Adam Hevenor
 

This is an interesting idea and related to a couple of feature ideas we (Loggregator) have been doing some research on. Ultimately you would likely want that metric to be available in Loggregator so you can sum, chart, and percentile the metric using existing metric store integrations. This is simple (and may already be present) for diego and CC related actions although it should probably have clearer tags for tracing and a better API for retrieving traces. Also, the client side metric would be valuable but there is not an established OSS Support path for getting that information into Loggregator at the moment. 


Understanding hard CPU limits

Grifalconi, Michael <michael.grifalconi@...>
 

Hi,

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

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


Measuring cf push times end-to-end

Steffen Uhlig
 

As part of developing and improving the bits-service, we would like to better understand what the overall app push times are that developers experience.
 
However, "cf push" is a concept only known to the CLI. The CC and other CF components are not aware of various requests that make up a single "cf push" (e.g. resource matching, building a package, droplet). As a result, we have not been able to identify a straightforward way to measure push times from a developer's perspective.
 
One potential approach is to determine push time at the client side and then (after cf push has completed) have the CLI submit this data to a new endpoint in CF.
 
What do people think about this? Are there better ways to get these numbers? If not, would the community be open for a new "telemetry" endpoint that accepts these measurements from the cli and/or other cf components?


Re: Proposal for Incubation in the Extensions PMC: MultiApps

Guillaume Berche
 

Hi Nikolay,

Thanks for sharing the MultiApp proposal and contributing this work to the community.

It seems MTA shares many objectives with the terraform providers for cloudfoundry [1], credhub [2] and uaa [3]  previous shared in [4], such as
- declarative model
- support for service instance provisionning
- expression dependencies across elements
- integration with secure credentials systems such as credhub or vault

Some objectives seem to differ though:
- terraform isn't designed to orchestrate expressed sequences of operations (and rather relies on external orchestrators for this),
- terraform isn't desired to monitoring state of resources once provisioned (e.g. starting/started/stopped/failed) nor displaying them to end-users

The TF provider seems broader in scope since in addition of the developer persona, it also addresses the cf admin and cf operators personas (i.e. full parity with CF CLI, and plans for handling some bosh resource in the future [5])

Leveraging terraform core and its ecosystem has provided many built-in, features without extra effort, e.g.:
- dry run
- partial update
- concurrent deployments
- templating (through modules)
- UI tooling (e.g. in intellij, atom)
- local or remote state management
- ability to combine multiple providers (e.g CF AR and CF CR)
- CI/CD integration (e.g. in concourse [6])

The TF provider contributors are now focussing towards having the provider join the list of official hashicorp providers [8], and has recently received some great SAP contributions [9].

You may reach out to the team on the terraform slack channel [7], we'd be happy to proceed with further exchanges around common and diverging use-cases.

On Tue, Mar 20, 2018 at 9:38 PM, Zach Robinson <zrobinson@...> wrote:
Excited to see this proposed Nikolay!

Nikolay has been sharing this project with some of the core teams over the last couple of months.  We have even been giving some thought to adopting some of the behaviors and/or code from this extension into core CF.

Some aspects I think are especially interesting:
- declarative manifest behavior
- an opinionated packaging structure
- deployment orchestration

CAPI is especially excited to see whether the community takes to some of this tooling as potential guidance for future roadmap.

-Zach
CAPI Project Lead


On Tue, Mar 20, 2018 at 9:35 AM Nikolay Valchev <nikolay.valchev@...> wrote:

Hi All,

 

SAP is proposing MultiApps (aka CF MTA deploy service) for inclusion in the Extensions PMC as a new incubating project.

MultiApps is envisioned to provide the missing higher-level lifecycle management capabilities for distributed applications in Cloud Foundry. It proposes a new declarative application model and corresponding tools helping developers achieve the following goals:

  1. Describe explicitly the structure of my application, its constituent CF-apps, routes, services and other technical artifacts. Tools, interpreting this model, would automate deployments, achieving unified lifecycle of all application components and ensuring the consistency and completeness of the distributed application.   
  2. Declare the resources (e.g. service instances or APIs from other apps) my application depends on at runtime and/or deployment time. Tools would then check existence of required service instances, possibly allocating the missing ones and making the needed app bindings. Additionally tools would resolve dependent apps API information and inject it in requiring app env.
  3. Declare configuration variables (and their relations) which distinguish different deployments of my application. Tools would bind sub-components, automate deployment based on default settings, or request missing mandatory values interactively.

MultiApps is currently available on GitHub [1].

 

Details:

Project Name: MultiApps

Project Proposal: See [2].

Proposed Project Leads: Nikolay Valchev, SAP

Proposed Scope: See [2]

Development Operating Model: Dedicated committers (local)

Technical Approach: CF CLI plugin and server application automating lifecycle operations

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

 

Best regards,

Nikolay Valchev

Development Architect and Product Owner, SAP

 

[1] https://github.com/SAP/cf-mta-deploy-service

[2] https://docs.google.com/document/d/1TCx_2gv2_n-StcV4lzbbaD4rma9HfaRG7O9wb6-egk4

 



Re: A New Packaging Approach - CLI Tools Pushing Apps and the Story about the #loggregator “space drain” experiment #loggregator

Mike Youngstrom
 

Yeah. Currently the user name / password is simply passed into the app. I expect well at least implement a better hook into CUPS next and for user roles that can create users we could shell out and create a strong user-name password combo. This could be pretty elegant and allow for (automated) cred rotation. 

Sounds good.  Currently in my environment we disable user account creation instead using enterprise LDAP or OAuth.  Supporting internal users and external users isn't something I've considered in my deployments.  Might not be a problem.  Just not something I've considered before.

Thanks,
Mike
 


Re: A New Packaging Approach - CLI Tools Pushing Apps and the Story about the #loggregator “space drain” experiment #loggregator

Adam Hevenor
 

Yeah. Currently the user name / password is simply passed into the app. I expect well at least implement a better hook into CUPS next and for user roles that can create users we could shell out and create a strong user-name password combo. This could be pretty elegant and allow for (automated) cred rotation. 

The service broker approach is definitely an option to consider long term, but I'd like to try and figure out a way to do this within the scope the CC and UAA provide if it all possible. 


CF Networking support for CNI plugin chaining question

Amelia Downs
 

Hi CF,

We on the Container Networking Team are working on an epic to enable CNI plugin chaining.  

If this is of interest to you, we would like your feedback on our following proposal. 

In the spirit of doing the simplest thing, we would like to reduce the complexity of possible configurations. We want to allow users to EITHER provide a conf for a non-chaining CNI plugin OR provide a conflist for CNI plugin chaining.

Does anyone have any use cases that wouldn’t fit this model? 

Thanks,
The CF Networking Team

1481 - 1500 of 9378