hi Brian, the task shouldn't be so difficult.
Most languages already have some OAuth library to leverage that does all
the work for you. And even without a library, Oauth is pretty straight
forward. Just some HTTP calls with redirects.

Are you looking for an example?
pure HTTP example looks like:
https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/java/org/cloudfoundry/identity/uaa/integration/feature/ImplicitGrantIT.java#L78-L130

Filip


On Mon, May 4, 2015 at 9:08 PM, Brian Gaston <bgaston(a)learningsciences.com>
wrote:

Hello,


I hope I came to the right place. My apologies if I haven't. We are
working on a native mobile app and would like to leverage UAA for authz.
We have a multi-tenant environment and I was wondering how large of a task
it would be to get UAA implicit flow to work with client apps so we could
take full advantage of UAA's multi-tenancy support.


thanks so much.

Brian Gaston

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

I'm happy to see the size of the build packs dropping, but I have to ask
why do we bundle the build packs with a fixed set of binaries?

The build packs themselves are very small, it's the binaries that are
huge. It seems like it would make sense to handle them as separate
concerns.

I don't want to come off too harsh, but in addition to the size of the
build packs when bundled with binaries, there are some other disadvantages
to doing things this way.

- Binaries and build packs are updated at different rates. Binaries are
usually updated often, to pick up new runtimes versions & security fixes;
build packs are generally changed at a slower pace, as features or bug
fixes for them are needed. Bundling the two together, requires an operator
to update the build packs more often, just to get updated binaries. It's
been my experience that users don't (or forget) to update build packs which
means they're likely running with older, possibly insecure runtimes.

- It's difficult to bundle a set of runtime binaries that suite
everyone's needs, different users will update at different rates and will
want different sets of binaries. If build packs and binaries are packaged
together, users will end up needing to find a specific build pack bundle
that contains the runtime they want or users will need to build their own
custom bundles. If build packs and binaries are handled separately, there
will be more flexibility in what binaries a build pack has available as an
operator can manage binaries independently. Wayne's post seems to hit on
this point.

- At some point, I think this has already happened (jruby & java), build
packs are going to start having overlapping sets of binaries. If the
binaries are bundled with the build pack, there's no way that build packs
could ever share binaries.

My personal preference would be to see build packs bundled without binaries
and some other solution, which probably merits a separate thread, for
managing the binaries.

I'm curious to hear what others think or if I've missed something and
bundling build packs and binaries is clearly the way to go.

Dan

PS. If this is something that came up in the PMC, I apologize. I skimmed
the notes, but may have missed it.



On Mon, May 4, 2015 at 2:10 PM, Wayne E. Seguin <
wayneeseguin(a)starkandwayne.com> wrote:

Because of very good compatibility between versions (post 1.X) I would
like to make a motion to do the following:

Split the buildpack:

have the default golang buildpack track the latest golang version

Then handle older versions in one of two ways, either:

a) have a large secondary for older versions

or

b) have multiple, one for each version of golang, users can specify a
specific URL if they care about specific versions.

This would improve space/time considerations for operations. Personally I
would prefer b) because it allows you to enable supporting older go
versions out of the box by design but still keeping each golang buildpack
small.

~Wayne

Wayne E. Seguin <wayneeseguin(a)starkandwayne.com>
CTO ; Stark & Wayne, LLC

On May 4, 2015, at 12:40 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Hi Wayne,

On Fri, May 1, 2015 at 1:29 PM, Wayne E. Seguin <
wayneeseguin(a)starkandwayne.com> wrote:

What an incredible step in the right direction, Awesome!!!

Out of curiosity, why is the go buildpack still quite so large?

Thanks for asking this question.

Currently we're including the following binary dependencies in
`go-buildpack`:

```
cache $ ls -lSh *_go*
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 60M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.4.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.2.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 54M 2015-05-04 12:36
http___go.googlecode.com_files_go1.2.1.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.3.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 51M 2015-05-04 12:36
https___storage.googleapis.com_golang_go1.3.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.2.linux-amd64.tar.gz
-rw-r--r-- 1 flavorjones flavorjones 40M 2015-05-04 12:36
http___go.googlecode.com_files_go1.1.1.linux-amd64.tar.gz
```

One question we should ask, I think, is: should we still be supporting
golang 1.1 and 1.2? Dropping those versions would cut the size of the
buildpack in (approximately) half.

On May 1, 2015, at 11:54 , Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Skinny buildpacks have been cut for go, nodejs, php, python and ruby
buildpacks.

| | current | previous |
|--------+---------+----------|
| go | 442MB | 633MB |
| nodejs | 69MB | 417MB |
| php | 804MB | 1.1GB |
| python | 454MB | 654MB |
| ruby | 365MB | 1.3GB |
|--------+---------+----------|
| total | 2.1GB | 4.1GB |

for an aggregate 51% reduction in size. Details follow.
Next Steps

I recognize that every cloud operator may have a different policy on what
versions of interpreters and libraries they want to support, based on the
specific requirements of their users.

These buildpacks reflect a "bare mininum" policy for a cloud to be
operable, and I do not expect these buildpacks to be adopted as-is by many
operators.

These buildpacks have not yet been added to cf-release, specifically so
that the community can prepare their own buildpacks if necessary.

Over the next few days, the buildpacks core team will ship documentation
and tooling to assist you in packaging specific dependencies for your
instance of CF. I'll start a new thread on this list early next week to
communicate this information.
Call to Action

In the meantime, please think about whether the policy implemented in
these buildpacks ("last two patches (or teenies) on all supported
major.minor releases") is suitable for your users; and if not, think about
what dependencies you'll ideally be supporting.
go-buildpack v1.3.0

Release notes are here
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.

Size reduced 30% from 633MB
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.2.0> to
442MB <https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.3.0>.

Supports (full manifest here
<https://github.com/cloudfoundry/go-buildpack/blob/v1.3.0/manifest.yml>):

- golang 1.4.{1,2}
- golang 1.3.{2,3}
- golang 1.2.{1,2}
- golang 1.1.{1,2}

nodejs-buildpack v1.3.0

Full release notes are here
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.

Size reduced 83% from 417MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.2.1>
to 69MB
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.3.0>.

Supports (full manifest here
<https://github.com/cloudfoundry/nodejs-buildpack/blob/v1.3.0/manifest.yml>
):

- 0.8.{27,28}
- 0.9.{11,12}
- 0.10.{37,38}
- 0.11.{15,16}
- 0.12.{1,2}

php-buildpack v3.2.0

Full release notes are here
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>.

Size reduced 27% from 1.1GB
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.1.1> to
803MB <https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.2.0>
.

Supports: (full manifest here
<https://github.com/cloudfoundry/php-buildpack/blob/v3.2.0/manifest.yml>)

*PHP*:

- 5.6.{6,7}
- 5.5.{22,23}
- 5.4.{38,39}

*HHVM* (lucid64 stack):

- 3.2.0

*HHVM* (cflinuxfs2 stack):

- 3.5.{0,1}
- 3.6.{0,1}

*Apache HTTPD*:

- 2.4.12

*nginx*:

- 1.7.10
- 1.6.2
- 1.5.13

python-buildpack v1.3.0

Full release notes are here
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.

Size reduced 30% from 654MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.2.0>
to 454MB
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.3.0>.

Supports: (full manifest here
<https://github.com/cloudfoundry/python-buildpack/blob/v1.3.0/manifest.yml>
)

- 2.7.{8,9}
- 3.2.{4,5}
- 3.3.{5,6}
- 3.4.{2,3}

ruby-buildpack v1.4.0

Release notes are here
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.

Size reduced 71% from 1.3GB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.3.1> to
365MB
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.4.0>.

Supports: (full manifest here
<https://github.com/cloudfoundry/ruby-buildpack/blob/v1.4.0/manifest.yml>
)

*MRI*:

- 2.2.{1,2}
- 2.1.{5,6}
- 2.0.0p645

*JRuby*:

- ruby-1.9.3-jruby-1.7.19
- ruby-2.0.0-jruby-1.7.19
- ruby-2.2.0-jruby-9.0.0.0.pre1


---------- Forwarded message ----------
From: Mike Dalessio <mdalessio(a)pivotal.io>
Date: Wed, Apr 8, 2015 at 11:10 AM
Subject: Addressing buildpack size
To: vcap-dev(a)cloudfoundry.org


Hello vcap-dev!

This email details a proposed change to how Cloud Foundry buildpacks are
packaged, with respect to the ever-increasing number of binary dependencies
being cached within them.

This proposal's permanent residence is here:

https://github.com/cloudfoundry-incubator/buildpack-packager/issues/4

Feel free to comment there or reply to this email.
------------------------------
Buildpack SizesWhere we are today

Many of you have seen, and possibly been challenged by, the enormous
sizes of some of the buildpacks that are currently shipping with cf-release.

Here's the state of the world right now, as of v205:

php-buildpack: 1.1G
ruby-buildpack: 922M
go-buildpack: 675M
python-buildpack: 654M
nodejs-buildpack: 403M
----------------------
total: 3.7G

These enormous sizes are the result of the current policy of packaging
every-version-of-everything-ever-supported ("EVOEES") within the buildpack.

Most recently, this problem was exacerbated by the fact that buildpacks
now contain binaries for two rootfses.
Why this is a problem

If continued, buildpacks will only continue to increase in size, leading
to longer and longer build and deploy times, longer test times, slacker
feedback loops, and therefore less frequent buildpack releases.

Additionally, this also means that we're shipping versions of
interpreters, web servers, and libraries that are deprecated, insecure, or
both. Feedback from CF users has made it clear that many companies view
this as an unnecessary security risk.

This policy is clearly unsustainable.
What we can do about it

There are many things being discussed to ameliorate the impact that
buildpack size is having on the operations of CF.

Notably, Onsi has proposed a change to buildpack caching, to improve
Diego staging times (link to proposal
<https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/better-buildpack-caching.md>
).

However, there is an immediate solution available, which addresses both
the size concerns as well as the security concern: packaging fewer binary
dependencies within the buildpack.
The proposal

I'm proposing that we reduce the binary dependencies in each buildpack in
a very specific way.

Aside on terms I'll use below:

- Versions of the form "1.2.3" are broken down as: MAJOR.MINOR.TEENY.
Many language ecosystems refer to the "TEENY" as "PATCH" interchangeably,
but we're going to use "TEENY" in this proposal.
- We'll assume that TEENY gets bumped for API/ABI compatible changes.
- We'll assume that MINOR and MAJOR get bumped when there are API/ABI
*incompatible* changes.

I'd like to move forward soon with the following changes:

1. For language interpreters/compilers, we'll package the two
most-recent TEENY versions on each MAJOR.MINOR release.
2. For all other dependencies, we'll package only the single
most-recent TEENY version on each MAJOR.MINOR release.
3. We will discontinue packaging versions of dependencies that have
been deprecated.
4. We will no longer provide "EVOEES" buildpack releases.
5. We will no longer provide "online" buildpack releases, which
download dependencies from the public internet.
6. We will document the process, and provide tooling, for CF
operators to build their own buildpacks, choosing the dependencies that
their organization wants to support or creating "online" buildpacks at
operators' discretion.

An example for #1 is that we'll go from packaging 34 versions of node v0.10.x
to only packaging two: 0.10.37 and 0.10.38.

An example for #2 is that we'll go from packaging 3 versions of nginx 1.5
in the PHP buildpack to only packaging one: 1.5.12.

An example for #3 is that we'll discontinue packaging ruby 1.9.3 in the
ruby-buildpack, which reached end-of-life in February 2015.
Outcomes

With these changes, the total buildpack size will be reduced greatly. As
an example, we expect the ruby-buildpack size to go from 922M to 338M.

We also want to set the expectation that, as new interpreter versions are
released, either for new features or (more urgently) for security fixes,
we'll release new buildpacks much more quickly than we do today. My hope is
that we'll be able to do it within 24 hours of a new release.
Planning

These changes will be relatively easy to make, since all the buildpacks
are now using a manifest.yml file to declare what's being packaged. We
expect to be able to complete this work within the next two weeks.

Stories are in the Tracker backlog under the Epic named
"skinny-buildpacks", which you can see here:

https://www.pivotaltracker.com/epic/show/1747328

------------------------------

Please let me know how these changes will impact you and your
organizations, and let me know of any counter-proposals or variations you'd
like to consider.

Thanks,

-mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

The proposal will be reviewed on Thursday by the Services PMC. Thanks
Duncan!

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

On Mon, May 4, 2015 at 8:42 PM, Duncan Johnston Watt <
duncan.johnstonwatt(a)cloudsoftcorp.com> wrote:

Chip/All

Just following up on this proposal on the new list to get an update on its
status.

Best

Duncan


On 22 April 2015 at 14:49, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

General feedback is desired here from the whole community, so speak up!

After that feedback, we will work within the Services PMC to accept (or
deny) this code contribution into the incubator for that PMC.

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

On Wed, Apr 22, 2015 at 6:22 AM, Robert Moss <
robert.moss(a)cloudsoftcorp.com> wrote:

Hi All,

I've put together a proposal[1] to bring the Service Broker for Apache
Brooklyn and CLI-Plugin into the Incubator. If you haven't yet seen, I
wrote a series of blog posts with videos[2][3][4] describing them. Looking
forward to your feedback.

Robert

[1]
https://docs.google.com/a/cloudsoftcorp.com/document/d/15HuoflKjf5dbrbuTHGVE7kyniIBADUh24MmYBXU-CYw/edit#heading=h.qnq5iz827eiu
[2]
http://www.cloudsoftcorp.com/blog/2015/02/integrating-cloud-foundry-apache-brooklyn-part-1-service-broker/
[3]
http://www.cloudsoftcorp.com/blog/2015/02/integrating-cloud-foundry-apache-brooklyn-part-2-brooklyn-plugin/
[4]
http://www.cloudsoftcorp.com/blog/2015/04/integrating-cloud-foundry-with-apache-brooklyn-part-3-managing-services/

--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/318d03e2-581c-4cf1-93b5-1178defe38d7%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/318d03e2-581c-4cf1-93b5-1178defe38d7%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.

--
You received this message because you are subscribed to the Google Groups
"Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAD1Pwce9cTJtevYhozkzYen%3DmqF0rz0Xnq9OHG%2Bhv5AvcS%3DdHQ%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAD1Pwce9cTJtevYhozkzYen%3DmqF0rz0Xnq9OHG%2Bhv5AvcS%3DdHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.

--
Duncan Johnston-Watt
CEO | Cloudsoft Corporation

Twitter | @duncanjw
Mobile | +44 777 190 2653
Skype | duncan_johnstonwatt
Linkedin | www.linkedin.com/in/duncanjohnstonwatt

Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP

This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

All,

HP is proposing a sizable donation of code into the Cloud Foundry
Foundation's incubation program. This represents a collection of projects
that together provide support for a full stack of Microsoft technologies
for Cloud Foundry. This includes a Visual Studio Extension, MS Buildpack,
.NET SDK for the Cloud Controller API, Windows-based DEAs and a SQL Server
service broker implementation.

Gert Drapers (from HP) and I have been working with Mark Kropf, Mike
Dalessio and several members of the Greenhouse incubating project to plan
out how we can accept this into the incubator, as well as working with HP
on a plan to onboard their engineering team via the Dojo program.

I've grouped each repository that is being proposed for donation into the
applicable PMC and noted what project (existing or new) would manage the
code.

Comments are welcome, and we will be working with each PMC directly to
ensure consensus.

*Runtime PMC*

These two repositories would land in the existing Greenhouse incubating
project, and HP engineers will join that project via the Dojo program.
While this implementation is an alternative to the approach that is
currently being taken by the Greenhouse project, it is implemented for the
DEA architecture (vs. Diego). The work of the expanded Greenhouse project
will be to rationalize the multiple approaches and determine what the
combined architectural path will be for the future.

Windows Prison (isolation code)
https://github.com/hpcloud/cf-windows-prison

Windows Extensions (WinDEA for CFv2)
https://github.com/hpcloud/cf-windows-extensions

Additionally, there are two build packs being donated, which will (for now)
incubate within the runtime PMC’s Greenhouse project. The goal would be to
move these to the Buildpacks PMC at the same time that the Greenhouse work
moves from incubating to active.

Core build pack used by the DEA (Windows Extensions)
https://github.com/hpcloud/hp-buildpack-iis8, we should rename this to
cf-iis8-buildback or cf-buildpack-iis8

Static Windows executable build pack
https://github.com/hpcloud/cf-exe-buildpack

*Services PMC*

The SQL Server service broker proposed below would be a new incubating
project for the Services PMC. HP engineers would be the initial committers
for this project within the Services PMC. We will work to identify the
appropriate project lead for the new incubating project.

Microsoft SQL Server Service Broker (v2 broker written in go)
https://github.com/hpcloud/cf-mssql-broker

*Utilities PMC*

The .NET SDK and and Visual Studio Extension / MSBuild Tasks projects would
be two new incubating projects within the Utilities PMC, similar to how we
have the Java Tools and Eclipse Plugin projects today. HP engineers would
be the initial committers for these projects within the Utilities PMC. We
will work to identify the appropriate project lead for the new incubating
projects.

CF .NET SDK
https://github.com/hpcloud/cf-dotnet-sdk

CF Visual Studio Extension
https://github.com/hpcloud/cf-vs-extension-wpf will be renamed to
https://github.com/hpcloud/cf-vs-extension

CF MSBuild Tasks
https://github.com/hpcloud/cf-msbuild-tasks


-chip

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

Hi

I just looked at our disk usage on NFS server. We have used like 200G so
far, and I wonder if there's a systematic way to purge files we don't need
(or how do I know I don't need them)?

Similarly, if I were to replace NFS server with S3 instead, does the
existing process (if any) work with S3?

Thanks.

Hi

Is http://docs.cloudfoundry.org/concepts/high-availability.html up to date?

1) Why is collector listed 1 but in scalable process table?

2) How do you run a second Health Manager in standby mode if only 1 can run
at any time?

3) Do we still need clock job? Is it also 1 instance?

4) I notice I have a job called api_workers, and I believe that's
compilation machine. I run two of these 24x7, is that necessary? The doc
said it is active if we need to compile things (say deploying a new
release). Is that all? I don't think they handle application code
compilation.

5) What about syslog? Can it have 2? I understand we have to choose what to
be HA or not...I am not sure "the BOSH resurrector will recover the VM if
it becomes non-responsive" convinces me because all of these jobs are
deployed with BOSH but if BOSH is down I am facing some outage. I know Dr.
Nic has some article regarding HA bosh.


Correct me if I am wrong.

Thanks.

John

Onsi Fakhouri has resigned from the runtime PMC's Diego and Garden
incubating projects, given his new $dayjob responsibilities at Pivotal.

Eric Malm will be stepping in to take his place for the Diego project.

Will Pragnell will be stepping in to take his place for the Garden project.

Thanks!

-chip

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

We are looking at revamping the UAA integrations we are using for our
deployments.

Our enterprise authentication provider supports SAML and OpenID Connect for
single signon. I know that UAA supports SAML. Is it possible to use our
enterprise OpenID Connect provider to authenticate for UAA OAuth? Or
should I just use SAML?

Mike

Sounds good, thanks Sree!

Mike

Hi,

We upgrade from CF172 to CF197 and enable loggregator on CF197. But for application deployed to CF197 (with loggregator enabled), we DO NOT
see stdout.log and stderr.log anymore in application logs directory anymore. We can see logs/stdout.log and logs/stderr.log in CF172.

CF197:
cf file <app> logs
Getting file contents... OK

staging_task.log 1.3K

Can you tell us what setting in CF 197 can affect stdout.log and stderr.log show up or not? How to let logs/stdout.log and logs/stderr.log show up?

Thanks,
Tina Zhang

Hi,

We held the first Runtime PMC bi-weekly meeting today.
Following on Mike D's lead, I'd like to share the notes from the meeting.
http://bit.ly/cf-runtime-pmc

-Dieu
CF Runtime PM

---

CF Runtime PMC

May 5, 2015

Attendees:

Chip Childers

Alex Tarpinian

Chris Sterling

Chris Ferris

Atul Kshirsagar

Michael Fraenkel

Steve Winkler

Mark Kropf

Zach Robinson

Erik Jasiak

Sree Tummidi

Dieu Cao

Eric Malm

Onsi Fakhouri


Proposal to move cfoundry to the cloudfoundy-attic

It’s not being maintained.

No objections raised during the PMC

Backlog reviews of:

Runtime

-

nearly complete with Route API and context path routing
-

Proposal to be sent out later this week for basic rate limiting for
cloud controller to protect against users DOS’ing cloud controller
-

Work planned soon to move to Concourse for CI
-

Inception on Friday for rate limiting for CC and route services

UAA

-

wrapping up LDAP multi-tenancy support
-

starting on handling SAML attributes in tokens
-

password policies is up after SAML support

LAMB

-

Discovered dopplers were more cpu/thread-bound than thought
-

Needed to unwind some goals until doppler efficiency improved.
-

Fix is in progress and going well.
-

Up next #1 - Will bring back nozzles when pipeline can handle load
-

Up next #2 - Working with Runtime on etcd upgrade.
-

Up next #3 -


Diego

-

Completed 50-cell performance experiments and generated stories, will
start 100-cell one soon
-

SSH access to containers progressing, currently setting up
app/space/system access policies in CC and external routability
-

stories to come soon for versioning releases and schemas and improving
inter-component security

Greenhouse

-

Tracking the Diego release well and hopes to have their first release
coordinated with the first Diego release.
- Greenhouse team working with Century Link and HP to improve container
isolation.

1) I'll ask our doc team to clarify the title of the section.
It's not recommended to run more than 1 collector. This component collects
metrics from system components. We use it in combination with Datadog to
monitor the many components of cloud foundry. This component is not
strictly required for an HA system.

2) HM9000 can have multiple active instances. No need for a standby mode.

3) The Cloud Controller clock periodically schedules Cloud Controller clean
up tasks for app usage events, audit events, failed jobs, and more. Only
single instance of this job is necessary.

4) Likely the job called api_workers is actually the cloud controller
workers. These are not compilation vms.
Cloud Controller worker processes background tasks submitted via clients of
the api.

5) I'm not sure what you mean by this. Do you mean loggregator? or doppler?

-Dieu
CF Runtime PM

I'm trying to get the introduction to spring cloud
<https://spring.io/blog/2014/06/03/introducing-spring-cloud> app working
with an instance of Cloud Foundry that I'm running on my machine. I tried
to push the app and I get this message:

Could not find service postgres-service to bind to
hello-spring-cloud

That makes sense to me so I started tracking down the postgres service.
When I run `cf marketplace`, I get:

service plans description
mongodb default MongoDB NoSQL database
postgresql default PostgreSQL database
rabbitmq default RabbitMQ message queue
redis default Redis key-value store

When I try to create a service instance of the postgresql service and I
get:

$ cf create-service postgresql default postgresql-service
Creating service instance postgresql-service in org xyz / space
development as admin...
FAILED
Server error, status code: 500, error code: 10001, message: Service
broker error: Not authorized

Here are the permissions for the space:

Getting users in org xyz / space development as admin

SPACE MANAGER
admin

SPACE DEVELOPER
Admin

The cf service-access command doesn¹t yield anything interesting:

$ cf service-access
Getting service access as admin

Then it shows nothing on the terminal. So I tried to enable service access

$ cf enable-service-access postgresql
Enabling access to all plans of service postgresql for all orgs as
admin...
All plans of the service are already accessible for all orgs
OK

For the life of me, I can¹t figure out what¹s going on. I posted a
question to Stack Overflow <
http://stackoverflow.com/questions/30034143/cant-create-service-instance-in-cloud-foundry>
and was referred here after some debugging
attempts were fruitless. Anybody got any ideas?

The UAA team is currently upgrading Spring Framework dependencies in order
to stay up to date and be able to receive security and feature updates
faster.

With the story
https://www.pivotaltracker.com/story/show/93706906

the spring framework has dropped support for Jackson 1
(org.codehaus.jackson).
We have decided to follow the same path, rather than increasing our testing
matrix and try to be backwards compatible,.

With this upgrade, we instead will be supporting Jackson 2,
https://github.com/cloudfoundry/uaa/issues/108
directly from our classes.

While we attempt to be backwards compatible in most of our upgrade
scenarios, this one was instance we decided against it since Jackson 1 has
not had any software releases since 2013, and we most likely can't expect
any fixes against this library.

Feel free to ask any questions or raise any concerns. As a result, next UAA
release will be bumped to 2.3.x

Filip

Hey everyone,

We held the first Utilities PMC meeting yesterday; I'd like to share the
agenda and notes.

For reference, all agendas notes for the Utilities PMC will be kept in a
public Google Drive folder at this URL:

http://bit.ly/cf-utilities-pmc


I realize GDrive isn't the most convenient medium for some in the CF
community; I'd love to hear how we can better support transparency for
everyone.

Please feel free to respond with comments and questions!

Cheers,
-m

---

*Attendees:*

- Chip Childers, Cloud Foundry Foundation
- Mike Dalessio, Pivotal (PMC lead)
- Christopher Ferriss, IBM
- Michael Fraenkel, IBM
- James Bayer, Pivotal
- Greg Oehmen, Pivotal
- Ryan Morgan, PIvotal


Utilities PMC Agenda and Notes - 2015-05-05


1.

Update on CI tools (Mike Dalessio)
2.

Update on CLI (Greg Oehman)
3.

Update on Eclipse plugin and Java tools (Ryan Morgan)
4.

Open Discussion



Update on CI tools (Mike Dalessio)

GoCD <http://www.go.cd/> still in use for some projects, but there’s
movement towards Concourse <http://concourse.ci/> and teams are
enthusiastic about it. Currently Diego, Garden, BOSH-lite, Loggregator, and
CLI have converted to Concourse; and BOSH, Services API, and Buildpacks are
in progress.

Timeline is open for individual teams to move to Concourse; some teams may
decide not to. Having a heterogenous CI environment is OK, as both GoCD and
Concourse can integrate via S3 buckets, which is where generated artifacts
are generally kept.


Update on CLI (Greg Oehmen)


Released 6.11.0 - 4/17

Released 6.11.1 - 4/20

Released 6.11.2 - 4/28

Big uptick in issues/PRs

Plugin API feature

Look Ahead:

1. help refactor work,

- refactor help

- invert syntax (object - action)

- tab/bash completion

2. support the move to cc API 3.0 and services api changes

3. the user security work (pwd expiration, inactivity-based session
timeout, RBAC maturation, etc.)

4. installer emphasis

- Auto-update within CLI

- signed mac installer

- signed windows installer

- etc

5. APM integration - something like blessed-contrib:
https://github.com/yaronn/blessed-contrib


Update on Eclipse plugin and Java tools (Ryan Morgan)

CF Eclipse Tooling: (1 dev at Pivotal, 4 splitting time at IBM)

-

1.8.0 (Released Feb 13th)
-

New Service wizard allowing for multiple service creation
-

Remote debug support via ngrok.com
-

1.8.1 (Released March 25th)
-

Map/Unmap project feature to map an existing eclipse workspace to an
app
-

Update password fixes
-

Free service plans now marked in the UI and preferred over paid plans
-

1.8.2 (Release imminent)
-

JRebel support
-

Working on some last minute UI changes
-

Working on a proposal to move the Eclipse tooling to the Eclipse
Foundation
-

Should have a proposal for review mid-late May. Targeting Eclipse
4.5 SR1 update in the fall. Lots of work to be done to make
that deadline.


CF Java Client: (1 dev at Pivotal, splitting time)

-

1.1.2 Released April 13th
-

No active development, PRs and Issues reviewed on-demand
-

Support of CC v3
-

Removal of Spring dependencies (v2.0 item)



Open Discussion

Please add any other suggested agenda topics for discussion here:

*Imminent additions to the Utilities PMC from HP (Chip).*

Voting took place via email on 2015-05-05 with unanimous consent to add the
following to the Utilities PMC as incubating projects:


- CF .NET SDK https://github.com/hpcloud/cf-dotnet-sdk
- CF Visual Studio Extension
https://github.com/hpcloud/cf-vs-extension-wpf
(will be renamed to https://github.com/hpcloud/cf-vs-extension)
- CF MSBuild Tasks https://github.com/hpcloud/cf-msbuild-tasks

Hi Dieu

Thank you for the answers. They are very helpful.

Regarding #4, you are right, I believe when I do CF deployment I get these
short-lived VMs that compile different CF jobs.

Regarding #5, I think it is doppler in our latest deployment (v193, I know
still behind the most current version). I think in very old CF version
there used to be

loggreator_traffic
loggreator
syslog_loggreator

(as seen in the documentation mentions syslog loggreator).

So we probably don't need to worry about syslog then.


It seems like these are the one we can run >=2
NAT
DEA
UAA
HM9000
CC
Workers
Doppler
Log traffic controller
Gorouter
NFS (use s3 in our case)
Postgres (use RDS in our case)


These are the one not to run with > 1
collector
bosh
clock


Not sure:
stats server (metro agent?)


Thanks.

John

I've created Nabble archives of the CF lists here:

http://cf-bosh.70367.x6.nabble.com/
http://cf-dev.70369.x6.nabble.com/
http://cf-lattice.70370.x6.nabble.com/

The archives are searchable and allow web viewing of the mailing list without subscribing via email. There is also an RSS feed for each list.

Aaron

+1
Nice work Aaron!

On Wed, May 6, 2015 at 1:28 PM, Huber, Aaron M <aaron.m.huber(a)intel.com>
wrote:

I’ve created Nabble archives of the CF lists here:



http://cf-bosh.70367.x6.nabble.com/

http://cf-dev.70369.x6.nabble.com/

http://cf-lattice.70370.x6.nabble.com/



The archives are searchable and allow web viewing of the mailing list
without subscribing via email. There is also an RSS feed for each list.



Aaron

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

Thanks Aaron!

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

On Wed, May 6, 2015 at 4:28 PM, Huber, Aaron M <aaron.m.huber(a)intel.com>
wrote:

I’ve created Nabble archives of the CF lists here:



http://cf-bosh.70367.x6.nabble.com/

http://cf-dev.70369.x6.nabble.com/

http://cf-lattice.70370.x6.nabble.com/



The archives are searchable and allow web viewing of the mailing list
without subscribing via email. There is also an RSS feed for each list.



Aaron

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

+! nice job!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Cloud
IBM Software Group, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402



From: Chip Childers <cchilders(a)cloudfoundry.org>
To: "Huber, Aaron M" <aaron.m.huber(a)intel.com>
Cc: "cf-dev(a)lists.cloudfoundry.org"
<cf-dev(a)lists.cloudfoundry.org>,
"cf-lattice(a)lists.cloudfoundry.org"
<cf-lattice(a)lists.cloudfoundry.org>,
"cf-bosh(a)lists.cloudfoundry.org"
<cf-bosh(a)lists.cloudfoundry.org>
Date: 05/06/2015 01:51 PM
Subject: Re: [cf-dev] [cf-bosh] Links to Nabble archives of the CF lists
Sent by: cf-dev-bounces(a)lists.cloudfoundry.org



Thanks Aaron!

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation