Date   

Re: Deploying CloudFoundry on AWS - Too many machines are being created

Josh Ghiloni
 

Look into using Terraform … they have a cf-aws-tiny release that only creates 4 or 5VMs (smaller than c3.large) plus DEAs.

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>

ECS Team
Technology Solutions Delivered
ECSTeam.com<http://ECSTeam.com>

On Jun 17, 2015, at 13:53, Flávio Henrique Schuindt da Silva <flavio.schuindt(a)gmail.com<mailto:flavio.schuindt(a)gmail.com>> wrote:

I succesfully deployed CF on aws using this tutorial: http://docs.cloudfoundry.org/deploying/ec2/aws_steps.html

But this tutorial is kind of expensive...It creates 13 machines (one for each cf component) and each one is c3.large! I would like to create maybe, let's say, 4 ~ 5 machines to have all CF components. Is it possible?

Thanks in advance, guys!
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Deploying CloudFoundry on AWS - Too many machines are being created

Flávio Henrique Schuindt da Silva <flavio.schuindt at gmail.com...>
 

I succesfully deployed CF on aws using this tutorial:
http://docs.cloudfoundry.org/deploying/ec2/aws_steps.html

But this tutorial is kind of expensive...It creates 13 machines (one for
each cf component) and each one is c3.large! I would like to create maybe,
let's say, 4 ~ 5 machines to have all CF components. Is it possible?

Thanks in advance, guys!


cf-acceptance-tests have moved in cf-release

Dan Wendorf
 

Hey everyone,

As of cf-release 212, we have moved the cf acceptance tests in cf release
from "cf-release/src/acceptance-tests" to "cf-release/src/
github.com/cloudfoundry/cf-acceptance-tests". Prior to the move, it was
necessary to symbolically link the CATs into your $GOPATH.

Once you upgrade to 212, you will be able to run the tests simply by
executing `bin/test` without any additional symlinks.

Thanks,
CF Runtime Team


Re: Need for machine-readable Application Interface

Deepak Vij
 

Hi Zak and Joseph, thanks for your response. Would this capability be available only for Cloud Controller API or for rest of the platform API set as well? Also, would the same capability be available for end application developers (PaaS developers) so that the same application interface metadata is generated across the board within CF PaaS environment - that was my key goal for this discussion (something like JSON Schema for Heroku).

As I mentioned earlier that having a standardized application interface such as WADL/JSON/Swagger/RAML allows us to enforce Deployment Governance at the time of deploying applications within Cloud Foundry. In order to be able to expose business capabilities such as Telecom APIs, Deployment Governance (i.e. API Versioning & Backward Compatibility, Dependency Management, and other API Policy Validations etc.) is very important requirement not just for telecom industry but for any industry planning to monetize their APIs created within CF PaaS environment. Thanks.

Regards,
Deepak Vij

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

Message: 1
Date: Tue, 16 Jun 2015 15:04:53 -0700
From: CF Runtime <cfruntime(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] Need for machine-readable ?Application
Interface?
Message-ID:
<CAOb01c9s=qAG66YJ+vdh8g8R4=HU_BX3ee1_5msNPNt1QuNBQg(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

It is something we are thinking about for the V3 cloud controller API, but
no formal decisions have been made at this point. So feedback and
suggestions are certainly welcome.

Zak and Joseph
CF Runtime Team

On Tue, Jun 16, 2015 at 2:51 PM, Deepak Vij (A) <deepak.vij(a)huawei.com>
wrote:

Hi folks, I would like to start a thread on the need for
machine-readable ?*Application Interface*? supported at the platform
level. Essentially, this interface describes details such as available
methods/operations, inputs/outputs data types (schema), application
dependencies etc. Any standard specifications language can be used for
this purpose, as long as it clearly describes the schema of the requests
and responses ? one can use Web Application Description Language (WADL),
Swagger, RESTful API Modeling Language (RAML), JSON Schema (something like *JSON
Schema for Heroku Platform APIs*) or any other language that provides
similar functionality. These specifications are to be automatically derived
from the code and are typically part of the application development process
(e.g. generated by the build system).



Such functionality can have lots of usage scenarios:

1. First and foremost, Deployment Governance for API Management (our
main vested interest) ? API Versioning & Backward Compatibility,
Dependency Management and many more as part of the comprehensive telecom
API Management capabilities which we are currently in the process of
building out.

2. Auto-creating client libraries for your favorite programming
language.

3. Automatic generation of up-to-date documentation.

4. Writing automatic acceptance and integration tests etc.



From historical perspective, in the early 2000s when SOA started out, the
mindset was to author the application contract-first (application interface
using WSDL at that time) and subsequently generate and author code from the
application interface. With the advent of RESTful services, REST community
initially took a stand against such metadata for applications. Although, a
number of metadata standards have none-the-less emerged over the last
couple of years, mainly fueled by the use case scenarios described earlier.



Based on my knowledge, none of this currently exists within Cloud Foundry
at the platform level. It would be highly desirable to have a standard
common ?*application interface*? definition at the platform level,
agnostic of the underlying application development frameworks.



I hope this all makes sense. I think this is something could be very
relevant to the ?Utilities? PMC. I will also copy&paste this text under
?Utilities? PMC-notes on the github.



I would love to hear from the community on this. Thanks.



Regards,

Deepak Vij


cve-2015-1328 overlayfs vulnerability in ubuntu trusty stemcell

James Bayer
 

CVE-2015-1328Severity:

High
Vendor:

Canonical Ubuntu
Versions Affected:

Canonical Ubuntu 14.04 LTS with 3.16 kernel
Description:

Philip Pettersson discovered a privilege escalation when using overlayfs
mounts inside of user namespaces. A local user could exploit this flaw to
gain administrative privileges on the system.
Affected Pivotal Products and Versions:

-

Any BOSH deployments (including Cloud Foundry) with Ubuntu Trusty BOSH
stemcell prior to version 2989

Mitigation:

-

The Cloud Foundry project recommends upgrading to BOSH Ubuntu Trusty
stemcell version 2989 or later for all BOSH deployments. The 2989
stemcell has been certified with cf-release v211.

Credit:

Philip Pettersson
References: Canonical:

http://www.ubuntu.com/usn/usn-2646-1/
Other:

BOSH Stemcells <https://bosh.io/stemcells>

Cloud Foundry Release <https://github.com/cloudfoundry/cf-release>

Exploit details <http://seclists.org/oss-sec/2015/q2/717>

--
Thank you,

James Bayer


Re: CF CLI authentication issue

Benjamin Black
 

Stephan,

That's a lot of skew for ntp synchronized systems. I would expect them to
differ by less than a second. The problem you are having could be a result.


b


On Wed, Jun 17, 2015 at 8:51 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com>
wrote:

Hi Benjamin,

Sytems are synchronized by ntp. However, time of different machines
differs by a few seconds (5-20s). I am not sure how accurate ntp time sync
can be or should be.

Could that cause the issue?

Regards,
Stephan


Von: Benjamin Black
Antworten an: "Discussions about Cloud Foundry projects and the system
overall."
Datum: Dienstag, 16. Juni 2015 18:04
An: "Discussions about Cloud Foundry projects and the system overall."
Betreff: Re: [cf-dev] CF CLI authentication issue

Stephan,

Have you verified the clocks are in sync, perhaps using ntp, across all
the systems involved?


b


On Tue, Jun 16, 2015 at 8:42 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com
wrote:
Hi,

I am having a strange issue with the cf cli. Sometimes am doing a cf
login and then a cf push immediately as a next step. Then push fails and
reports "Authentication has expired. Please log back in to
re-authenticate." The behavior is completely random. Automized app
deployment triggered by CI jobs do fail very often.

I did an analysis of UAA logs and found the entries below. UAA means
that the password of user has changed because of last modified date of user
doesn't fit to issue date of token. Actually the user credentials are not
changed. At least not by purpose.

The CF version is 198.

Do you have any hints what could cause this issue? Any reply is welcome.

Regards,
Stephan



*[2015-06-16 13:00:52.885] uaa - 59331 [http-bio-8080-exec-1] ....
DEBUG --- UaaTokenServices: User was last modified at 2015-06-16
12:58:52.302 refresh token was issued at Tue Jun 16 12:58:03 UTC 2015*
*[2015-06-16 13:00:52.885] uaa - 59331 [http-bio-8080-exec-1] .... DEBUG
--- ExceptionHandlerExceptionResolver: Resolving exception from handler
[public
org.springframework.http.ResponseEntity<org.springframework.security.oauth2.common.OAuth2AccessToken>
org.springframework.security.oauth2.provider.endpoint.TokenEndpoint.getAccessToken(java.security.Principal,java.util.Map<java.lang.String,
java.lang.String>)]: error="invalid_token", error_description="Invalid
refresh token (password changed):
eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIyZjlhNGU2Ny0yYjY2LTQwMTItYjk1NC1jODg3OTMxN2I5ZDkiLCJzdWIiOiJlNDMwNzY1NS1lMTc2LTQ5Y2YtOGI5Mi04YjUxYWQ5ZTVmZDUiLCJzY29wZSI6WyJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLndyaXRlIiwicGFzc3dvcmQud3JpdGUiLCJvcGVuaWQiLCJjbG91ZF9jb250cm9sbGVyLnJlYWQiXSwiaWF0IjoxNDM0NDU5NDgzLCJleHAiOjE0MzcwNTE0ODMsImNpZCI6ImNmIiwiaXNzIjoiaHR0cHM6Ly91YWEuY2YubmVvLm9uZGVtYW5kLmNvbS9vYXV0aC90b2tlbiIsImdyYW50X3R5cGUiOiJwYXNzd29yZCIsInVzZXJfbmFtZSI6IlAxNDQ1NTM4MTkyIiwidXNlcl9pZCI6ImU0MzA3NjU1LWUxNzYtNDljZi04YjkyLThiNTFhZDllNWZkNSIsImF1ZCI6WyJjZiIsInNjaW0iLCJjbG91ZF9jb250cm9sbGVyIiwicGFzc3dvcmQiLCJvcGVuaWQiXX0.sYmE3J5_IjYPRTnLYFT9dJ2p7nDR1WDMhvT95Anr8qWdDHTBp-tXLmPOZ17v66RuGcZhFAmYEmJMuW1ggBnuOQAB5lCKvvjINdlWdjKIxRlD24eLkGsqV_9ENUFIweIfKtYTAdmlXySqg47ZgZLotT9UVTtfD9BwI-NAZLBN6Ro"*


_______________________________________________
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


Re: CF CLI authentication issue

Klevenz, Stephan <stephan.klevenz@...>
 

Hi Benjamin,

Sytems are synchronized by ntp. However, time of different machines differs by a few seconds (5-20s). I am not sure how accurate ntp time sync can be or should be.

Could that cause the issue?

Regards,
Stephan


Von: Benjamin Black
Antworten an: "Discussions about Cloud Foundry projects and the system overall."
Datum: Dienstag, 16. Juni 2015 18:04
An: "Discussions about Cloud Foundry projects and the system overall."
Betreff: Re: [cf-dev] CF CLI authentication issue

Stephan,

Have you verified the clocks are in sync, perhaps using ntp, across all the systems involved?


b

On Tue, Jun 16, 2015 at 8:42 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com<mailto:stephan.klevenz(a)sap.com>> wrote:
Hi,

I am having a strange issue with the cf cli. Sometimes am doing a cf login and then a cf push immediately as a next step. Then push fails and reports "Authentication has expired. Please log back in to re-authenticate." The behavior is completely random. Automized app deployment triggered by CI jobs do fail very often.

I did an analysis of UAA logs and found the entries below. UAA means that the password of user has changed because of last modified date of user doesn't fit to issue date of token. Actually the user credentials are not changed. At least not by purpose.

The CF version is 198.

Do you have any hints what could cause this issue? Any reply is welcome.

Regards,
Stephan



[2015-06-16 13:00:52.885] uaa - 59331 [http-bio-8080-exec-1] .... DEBUG --- UaaTokenServices: User was last modified at 2015-06-16 12:58:52.302 refresh token was issued at Tue Jun 16 12:58:03 UTC 2015
[2015-06-16 13:00:52.885] uaa - 59331 [http-bio-8080-exec-1] .... DEBUG --- ExceptionHandlerExceptionResolver: Resolving exception from handler [public org.springframework.http.ResponseEntity<org.springframework.security.oauth2.common.OAuth2AccessToken> org.springframework.security.oauth2.provider.endpoint.TokenEndpoint.getAccessToken(java.security.Principal,java.util.Map<java.lang.String, java.lang.String>)]: error="invalid_token", error_description="Invalid refresh token (password changed): eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiIyZjlhNGU2Ny0yYjY2LTQwMTItYjk1NC1jODg3OTMxN2I5ZDkiLCJzdWIiOiJlNDMwNzY1NS1lMTc2LTQ5Y2YtOGI5Mi04YjUxYWQ5ZTVmZDUiLCJzY29wZSI6WyJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLndyaXRlIiwicGFzc3dvcmQud3JpdGUiLCJvcGVuaWQiLCJjbG91ZF9jb250cm9sbGVyLnJlYWQiXSwiaWF0IjoxNDM0NDU5NDgzLCJleHAiOjE0MzcwNTE0ODMsImNpZCI6ImNmIiwiaXNzIjoiaHR0cHM6Ly91YWEuY2YubmVvLm9uZGVtYW5kLmNvbS9vYXV0aC90b2tlbiIsImdyYW50X3R5cGUiOiJwYXNzd29yZCIsInVzZXJfbmFtZSI6IlAxNDQ1NTM4MTkyIiwidXNlcl9pZCI6ImU0MzA3NjU1LWUxNzYtNDljZi04YjkyLThiNTFhZDllNWZkNSIsImF1ZCI6WyJjZiIsInNjaW0iLCJjbG91ZF9jb250cm9sbGVyIiwicGFzc3dvcmQiLCJvcGVuaWQiXX0.sYmE3J5_IjYPRTnLYFT9dJ2p7nDR1WDMhvT95Anr8qWdDHTBp-tXLmPOZ17v66RuGcZhFAmYEmJMuW1ggBnuOQAB5lCKvvjINdlWdjKIxRlD24eLkGsqV_9ENUFIweIfKtYTAdmlXySqg47ZgZLotT9UVTtfD9BwI-NAZLBN6Ro"


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


FIPS Compliance in CloudFoundry

Sandy Cash Jr <lhcash@...>
 

All:

I would like to put forward a proposal to implement FIPS-compliant
encryption in CloudFoundry. The proposal can be found at:

https://docs.google.com/document/d/13YX1SuVIxxveFiRKpk_xSrQOls5hYbayUzOA8a3AMAE/edit?usp=sharing

A specific aspect of the proposal which I would like to highlight is that
this would enable FIPS-compliant encryption but not mandate it - the
default configuration would be to use the encryption as implemented today,
while allowing those needing to adhere to FIPS 140-2 to do so in their CF
deployments.

I have done some basic analysis to identify areas where work needs to be
done, and I've attempted to capture some of this information in the
proposal as well. I would love to hear from the community on this
proposal.

Thanks,

-Sandy


--
Sandy Cash
Certified Senior IT Architect/Senior SW Engineer
IBM BlueMix
lhcash(a)us.ibm.com
(919) 543-0209

"I skate to where the puck is going to be, not to where it has been.” -
Wayne Gretzky


Utilities PMC - 2015-06-16 notes

Mike Dalessio
 

Hi all,

We had a meeting of the Utilities PMC yesterday, permanent notes are at:


https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-06-16-utilities.md

which I've copied into this email below.

Cheers,
-mike

----

*# Utilities PMC Meeting 2015-06-16*

*## Agenda*

1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Open Discussion


*## Attendees*

* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Ryan Morgan, Pivotal
* Greg Oehman, Pivotal
* Alex Tarpinian, IBM
* Michael Fraenkel, IBM


*## Update on CI tools (Mike Dalessio)*

- Greenhouse team started moving their builds to Concourse. Runtime
and BOSH are also in progress.

- Toolsmiths team taking over Krafa, which is a project (to-be-OSSed)
to manage a pool of CI environments. Currently being used internally
at Pivotal, but totally applicable to OSS as well.

- A pair is working for the next month on License Finder, which is an
OSS tool to examine a project's declared dependencies (via a package
manager) and discover licenses and changes in licensing. This should
be useful for the Foundation as well.


*## Update on CLI (Greg Oehman)*

- New pair rolled on from IBM, who ramped up quickly and are contributing;
team velocity is up.
- There is ongoing track of work around the plugin API.
- Another track of work on PRs and Issues was successful at cleaning up
some old stories.

- Next release will be 6.12.0.
- Deprecate "codegangsta" library which is used for feature flags

- Working with IBM designers on user testing "help" with a mock
terminal emulator. Community members have offered to be a part of
that user testing

- Upcoming tracks:
- Syntax change from "verb noun" to "noun verb" (e.g., "create-service"
to "service-create")
- Improving CLI installers


*## Update on Eclipse plugin and Java tools (Ryan Morgan)*

* Push to move to the Eclipse Foundation continues.


*## Open Discussion*

* Proposal to accept receptor-client into incubation. See:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-for-incubation-of-receptor-client-Java-client-for-receptor-td440.html


Re: CfSummit slides

Guillaume Berche
 

no worries, thanks for your help Craig

Guillaume.

On Wed, Jun 17, 2015 at 12:44 AM, C. Craig Ross <ccr(a)linuxfoundation.org>
wrote:

Hi Guillaume,

Regrettably there was some confusion and some speakers submitted them
slides via the CFP system instead of emailing them. The former is the
normal behavior for the majority of our events but the CF Summit slides
needed to be uploaded separately by our events team.

We will get your slides and the others up on the site in the next 24hrs.
Our apologies for the trouble and thanks for bringing this to our attention.

Cheers,

C.

On Tue, Jun 16, 2015 at 6:12 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thank Angela for your response. I wonder whether the CFP system is
properly listing speaker submitted slides, as for example my two sessions
indeed have their slides attached to their associated proposal [1-4], and
they don't yet appear into [5].

Are there some other speakers on the cf-dev list that had their slides
posted on the cfp system and don't yet see them published onto [5] ?

Thanks,

Guillaume.

[1]
http://events.linuxfoundation.org/sites/events/files/slides/orange_case_study_0.pdf
[2] http://events.linuxfoundation.org/cfp/proposals/5249/4719
[3]
http://events.linuxfoundation.org/sites/events/files/slides/adapting_cf_to_org_reqs.pdf
[4] http://events.linuxfoundation.org/cfp/proposals/5249/4721
[5] http://www.cfsummit.com/program/slides

Guillaume.


On Thu, Jun 11, 2015 at 1:42 AM, CF Events <events(a)cloudfoundry.org>
wrote:

Hello Guillaume,

On Wed, Jun 10, 2015 at 5:09 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Thanks again to the CF Foundation for the great cf summit, and for
publishing so promptly the video recordings on youtube. The sessions
content is great to watch, and I'm sometimes lacking the high resolution
slides display, and ability to use the slides as a reference.

There is currently 12 slide decks onto [1] over the 38 sessions
presented. Is there somewhere else they can be accessed, or any way for the
foundation to publish the ones speakers have already posted on the CFP
system ?
I will double check with our content manager, but typically if slides
are missing it is because the speakers did not share the with us. If we do
still have some that have not been posted, I'll make sure that happens by
Monday.

Thank you,

Angela


Thanks in advance,

Guillaume.

[1] http://www.cfsummit.com/program/slides


--
Cloud Foundry Summit Events Team
Cloud Foundry Foundation
events(a)cloudfoundry.org

--
C. Craig Ross
Director of Creative Services & Developer Programs
The Linux Foundation
http://www.linuxfoundation.org/


Re: Ordering lists of objects in the CF CLI

Tammer Saleh
 

I agree with Mike.

Cheers,
Tammer Saleh
Director of Product, Pivotal CF, London
http://pivotal.io | http://tammersaleh.com | +44 7463 939332

On Tue, Jun 16, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like option #2 but I wouldn't even worry about adding a --asc or native
order flag until someone requests it.

My biggest issue with it not being ordered is it makes it harder to find
an item in a list once it become 20-30 items big. So, I vote for a single
consistent easy to follow list order which I believe alphabetical
descending would provide.

Also, don't forget about ordering the lists of orgs and spaces presented
to the user during login.

Mike

On Tue, Jun 16, 2015 at 12:42 PM, Greg Oehmen <goehmen(a)pivotal.io> wrote:

Hey All:

The CLI team has recently been chewing on ordering sets of objects like
orgs and apps. We've gotten a couple PRs [0] recently related to this.
I've been asking internally around CF teams about the value here with mixed
results and would like to hear some input from the OSS community.

Currently, lists are returned in ccdb insert order which basically means
oldest (first inserted) to newest (most recently inserted). The CC API has
an order-direction parameter which enables you to reverse that order and
see objects newest to oldest.

If we wanted to enable the ordering of a return set, there are a couple
options:


1. Keep the default order as it currently is natively sent by the CC
API. Add two flags to any 'list' command for desc & asc:

`cf orgs --asc` --> sorts in (A-Z, 1-9) order
`cf orgs --desc` --> sorts in (Z-A, 9-1) order



2. Change the default order to descending in the CF CLI and add a
single flag to reverse order (see --asc in option 1 above). This would
mean that the object list is always returned to the CLI user in descending
order. But is there any value here? How often would you use the '--asc'
flag? In this scenario, would you then want the CLI to include a flag to
return object lists in the order that is native to the CC API?


Then there is always the option to do nothing. If there is not as much
perceived value here in the OSS community, then not changing anything is
always an option.


Here is the set of all CF CLI commands that return lists of objects. If
we opt for 1 or 2 above, we would apply that option to this entire set
(which is ironically not in any sort order).

apps
stacks
services
service-keys
orgs
spaces domains
routes
buildpacks
org-users
space-users
quotas
space-quotas
service-auth-tokens
service-brokers
security-groups
staging-security-groups
running-security-groups
plugins
list-plugin-repos
repo-plugins



Also - I know that the desc & asc sort order is more complex than my
example above (a-z, 0-9) due to upper/lower case, non-alphanumeric, etc.
We will follow standard linux sort order convention.


Last thing - Conversations so far have not even taken CF CLI
internationalization into account. This may turn out to be waaaaaay harder
than it seemed. That's why I'm trying to gauge perceived value. Will this
change make your life easier and make you a more effective user of the CF
CLI?

Thanks

[0] https://github.com/cloudfoundry/cli/pull/481,
https://github.com/cloudfoundry/cli/pull/457

Greg Oehmen
Cloud Foundry Product Manager
415.205.6596


_______________________________________________
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


Re: Reserved routes

Dieu Cao <dcao@...>
 

For now, we recommend using a different system domain and app domain so
that the overlap does not occur.
For example, system.example.com for the system domain and apps.example.com
as the apps domain.

-Dieu

On Tue, Jun 16, 2015 at 5:57 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Agreed. Might make a good issue for the CC to not allow routes to be
created that exist in the new Route API or something like that.

Mike

On Tue, Jun 16, 2015 at 3:03 PM, Mike Jacobi <jacobi(a)adobe.com> wrote:

Thanks, Mike. I implemented and tested the second option and so far it
appears to be working great.

A side note: It’s a bit surprising CF allows names like api and uaa
when the platform is using the same domain considering, theoretically, a
user could create apps and routes for those services and capture sensitive
info.

-Mike

On Jun 15, 2015, at 2:32 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Two thoughts:
* Put your private system domain in an Org that users you don't trust
won't have access to.
* Create routes without an app for the names you wish to "reserve"

Mike


On Mon, Jun 15, 2015 at 3:30 PM, Mike Jacobi <jacobi(a)adobe.com> wrote:

It appears users can create their own routes named the same as
critical endpoints such as api, doppler, loggregator, uaa, etc. In fact, I
just created an app with routes doppler and loggregator and the platform
did nothing to prevent me from doing so. The “cf logs” behavior was then
unpredictable.



Is there some way to prevent this? Am I missing something?



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



_______________________________________________
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


Re: Reserved routes

Mike Youngstrom
 

Agreed. Might make a good issue for the CC to not allow routes to be
created that exist in the new Route API or something like that.

Mike

On Tue, Jun 16, 2015 at 3:03 PM, Mike Jacobi <jacobi(a)adobe.com> wrote:

Thanks, Mike. I implemented and tested the second option and so far it
appears to be working great.

A side note: It’s a bit surprising CF allows names like api and uaa when
the platform is using the same domain considering, theoretically, a user
could create apps and routes for those services and capture sensitive info.

-Mike

On Jun 15, 2015, at 2:32 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Two thoughts:
* Put your private system domain in an Org that users you don't trust
won't have access to.
* Create routes without an app for the names you wish to "reserve"

Mike


On Mon, Jun 15, 2015 at 3:30 PM, Mike Jacobi <jacobi(a)adobe.com> wrote:

It appears users can create their own routes named the same as critical
endpoints such as api, doppler, loggregator, uaa, etc. In fact, I just
created an app with routes doppler and loggregator and the platform did
nothing to prevent me from doing so. The “cf logs” behavior was then
unpredictable.



Is there some way to prevent this? Am I missing something?



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



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


Re: CfSummit slides

Cornelia Davis <cdavis@...>
 

So sorry to ask a lame question, even after all of this discussion - what
is the preferred way to submit slides? Email to whom? Or CFPs if still
available?

On Tue, Jun 16, 2015 at 3:44 PM, C. Craig Ross <ccr(a)linuxfoundation.org>
wrote:

Hi Guillaume,

Regrettably there was some confusion and some speakers submitted them
slides via the CFP system instead of emailing them. The former is the
normal behavior for the majority of our events but the CF Summit slides
needed to be uploaded separately by our events team.

We will get your slides and the others up on the site in the next 24hrs.
Our apologies for the trouble and thanks for bringing this to our attention.

Cheers,

C.

On Tue, Jun 16, 2015 at 6:12 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thank Angela for your response. I wonder whether the CFP system is
properly listing speaker submitted slides, as for example my two sessions
indeed have their slides attached to their associated proposal [1-4], and
they don't yet appear into [5].

Are there some other speakers on the cf-dev list that had their slides
posted on the cfp system and don't yet see them published onto [5] ?

Thanks,

Guillaume.

[1]
http://events.linuxfoundation.org/sites/events/files/slides/orange_case_study_0.pdf
[2] http://events.linuxfoundation.org/cfp/proposals/5249/4719
[3]
http://events.linuxfoundation.org/sites/events/files/slides/adapting_cf_to_org_reqs.pdf
[4] http://events.linuxfoundation.org/cfp/proposals/5249/4721
[5] http://www.cfsummit.com/program/slides

Guillaume.


On Thu, Jun 11, 2015 at 1:42 AM, CF Events <events(a)cloudfoundry.org>
wrote:

Hello Guillaume,

On Wed, Jun 10, 2015 at 5:09 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Thanks again to the CF Foundation for the great cf summit, and for
publishing so promptly the video recordings on youtube. The sessions
content is great to watch, and I'm sometimes lacking the high resolution
slides display, and ability to use the slides as a reference.

There is currently 12 slide decks onto [1] over the 38 sessions
presented. Is there somewhere else they can be accessed, or any way for the
foundation to publish the ones speakers have already posted on the CFP
system ?
I will double check with our content manager, but typically if slides
are missing it is because the speakers did not share the with us. If we do
still have some that have not been posted, I'll make sure that happens by
Monday.

Thank you,

Angela


Thanks in advance,

Guillaume.

[1] http://www.cfsummit.com/program/slides


--
Cloud Foundry Summit Events Team
Cloud Foundry Foundation
events(a)cloudfoundry.org

--
C. Craig Ross
Director of Creative Services & Developer Programs
The Linux Foundation
http://www.linuxfoundation.org/

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


Re: CfSummit slides

C. Craig Ross <ccr@...>
 

Hi Guillaume,

Regrettably there was some confusion and some speakers submitted them
slides via the CFP system instead of emailing them. The former is the
normal behavior for the majority of our events but the CF Summit slides
needed to be uploaded separately by our events team.

We will get your slides and the others up on the site in the next 24hrs.
Our apologies for the trouble and thanks for bringing this to our attention.

Cheers,

C.

On Tue, Jun 16, 2015 at 6:12 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thank Angela for your response. I wonder whether the CFP system is
properly listing speaker submitted slides, as for example my two sessions
indeed have their slides attached to their associated proposal [1-4], and
they don't yet appear into [5].

Are there some other speakers on the cf-dev list that had their slides
posted on the cfp system and don't yet see them published onto [5] ?

Thanks,

Guillaume.

[1]
http://events.linuxfoundation.org/sites/events/files/slides/orange_case_study_0.pdf
[2] http://events.linuxfoundation.org/cfp/proposals/5249/4719
[3]
http://events.linuxfoundation.org/sites/events/files/slides/adapting_cf_to_org_reqs.pdf
[4] http://events.linuxfoundation.org/cfp/proposals/5249/4721
[5] http://www.cfsummit.com/program/slides

Guillaume.


On Thu, Jun 11, 2015 at 1:42 AM, CF Events <events(a)cloudfoundry.org>
wrote:

Hello Guillaume,

On Wed, Jun 10, 2015 at 5:09 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Thanks again to the CF Foundation for the great cf summit, and for
publishing so promptly the video recordings on youtube. The sessions
content is great to watch, and I'm sometimes lacking the high resolution
slides display, and ability to use the slides as a reference.

There is currently 12 slide decks onto [1] over the 38 sessions
presented. Is there somewhere else they can be accessed, or any way for the
foundation to publish the ones speakers have already posted on the CFP
system ?
I will double check with our content manager, but typically if slides are
missing it is because the speakers did not share the with us. If we do
still have some that have not been posted, I'll make sure that happens by
Monday.

Thank you,

Angela


Thanks in advance,

Guillaume.

[1] http://www.cfsummit.com/program/slides


--
Cloud Foundry Summit Events Team
Cloud Foundry Foundation
events(a)cloudfoundry.org
--
C. Craig Ross
Director of Creative Services & Developer Programs
The Linux Foundation
http://www.linuxfoundation.org/


Re: CfSummit slides

Guillaume Berche
 

Thank Angela for your response. I wonder whether the CFP system is properly
listing speaker submitted slides, as for example my two sessions indeed
have their slides attached to their associated proposal [1-4], and they
don't yet appear into [5].

Are there some other speakers on the cf-dev list that had their slides
posted on the cfp system and don't yet see them published onto [5] ?

Thanks,

Guillaume.

[1]
http://events.linuxfoundation.org/sites/events/files/slides/orange_case_study_0.pdf
[2] http://events.linuxfoundation.org/cfp/proposals/5249/4719
[3]
http://events.linuxfoundation.org/sites/events/files/slides/adapting_cf_to_org_reqs.pdf
[4] http://events.linuxfoundation.org/cfp/proposals/5249/4721
[5] http://www.cfsummit.com/program/slides

Guillaume.

On Thu, Jun 11, 2015 at 1:42 AM, CF Events <events(a)cloudfoundry.org> wrote:

Hello Guillaume,

On Wed, Jun 10, 2015 at 5:09 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Thanks again to the CF Foundation for the great cf summit, and for
publishing so promptly the video recordings on youtube. The sessions
content is great to watch, and I'm sometimes lacking the high resolution
slides display, and ability to use the slides as a reference.

There is currently 12 slide decks onto [1] over the 38 sessions
presented. Is there somewhere else they can be accessed, or any way for the
foundation to publish the ones speakers have already posted on the CFP
system ?
I will double check with our content manager, but typically if slides are
missing it is because the speakers did not share the with us. If we do
still have some that have not been posted, I'll make sure that happens by
Monday.

Thank you,

Angela


Thanks in advance,

Guillaume.

[1] http://www.cfsummit.com/program/slides


--
Cloud Foundry Summit Events Team
Cloud Foundry Foundation
events(a)cloudfoundry.org


Re: Need for machine-readable “Application Interface”

CF Runtime
 

It is something we are thinking about for the V3 cloud controller API, but
no formal decisions have been made at this point. So feedback and
suggestions are certainly welcome.

Zak and Joseph
CF Runtime Team

On Tue, Jun 16, 2015 at 2:51 PM, Deepak Vij (A) <deepak.vij(a)huawei.com>
wrote:

Hi folks, I would like to start a thread on the need for
machine-readable “*Application Interface*” supported at the platform
level. Essentially, this interface describes details such as available
methods/operations, inputs/outputs data types (schema), application
dependencies etc. Any standard specifications language can be used for
this purpose, as long as it clearly describes the schema of the requests
and responses – one can use Web Application Description Language (WADL),
Swagger, RESTful API Modeling Language (RAML), JSON Schema (something like *JSON
Schema for Heroku Platform APIs*) or any other language that provides
similar functionality. These specifications are to be automatically derived
from the code and are typically part of the application development process
(e.g. generated by the build system).



Such functionality can have lots of usage scenarios:

1. First and foremost, Deployment Governance for API Management (our
main vested interest) – API Versioning & Backward Compatibility,
Dependency Management and many more as part of the comprehensive telecom
API Management capabilities which we are currently in the process of
building out.

2. Auto-creating client libraries for your favorite programming
language.

3. Automatic generation of up-to-date documentation.

4. Writing automatic acceptance and integration tests etc.



From historical perspective, in the early 2000s when SOA started out, the
mindset was to author the application contract-first (application interface
using WSDL at that time) and subsequently generate and author code from the
application interface. With the advent of RESTful services, REST community
initially took a stand against such metadata for applications. Although, a
number of metadata standards have none-the-less emerged over the last
couple of years, mainly fueled by the use case scenarios described earlier.



Based on my knowledge, none of this currently exists within Cloud Foundry
at the platform level. It would be highly desirable to have a standard
common “*application interface*” definition at the platform level,
agnostic of the underlying application development frameworks.



I hope this all makes sense. I think this is something could be very
relevant to the “Utilities” PMC. I will also copy&paste this text under
“Utilities” PMC-notes on the github.



I would love to hear from the community on this. Thanks.



Regards,

Deepak Vij

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


Need for machine-readable “Application Interface”

Deepak Vij
 

Hi folks, I would like to start a thread on the need for machine-readable “Application Interface” supported at the platform level. Essentially, this interface describes details such as available methods/operations, inputs/outputs data types (schema), application dependencies etc. Any standard specifications language can be used for this purpose, as long as it clearly describes the schema of the requests and responses – one can use Web Application Description Language (WADL), Swagger, RESTful API Modeling Language (RAML), JSON Schema (something like JSON Schema for Heroku Platform APIs) or any other language that provides similar functionality. These specifications are to be automatically derived from the code and are typically part of the application development process (e.g. generated by the build system).

Such functionality can have lots of usage scenarios:

1. First and foremost, Deployment Governance for API Management (our main vested interest) – API Versioning & Backward Compatibility, Dependency Management and many more as part of the comprehensive telecom API Management capabilities which we are currently in the process of building out.

2. Auto-creating client libraries for your favorite programming language.

3. Automatic generation of up-to-date documentation.

4. Writing automatic acceptance and integration tests etc.

From historical perspective, in the early 2000s when SOA started out, the mindset was to author the application contract-first (application interface using WSDL at that time) and subsequently generate and author code from the application interface. With the advent of RESTful services, REST community initially took a stand against such metadata for applications. Although, a number of metadata standards have none-the-less emerged over the last couple of years, mainly fueled by the use case scenarios described earlier.

Based on my knowledge, none of this currently exists within Cloud Foundry at the platform level. It would be highly desirable to have a standard common “application interface” definition at the platform level, agnostic of the underlying application development frameworks.

I hope this all makes sense. I think this is something could be very relevant to the “Utilities” PMC. I will also copy&paste this text under “Utilities” PMC-notes on the github.

I would love to hear from the community on this. Thanks.

Regards,
Deepak Vij


Re: Reserved routes

MJ
 

Thanks, Mike. I implemented and tested the second option and so far it appears to be working great.

A side note: It’s a bit surprising CF allows names like api and uaa when the platform is using the same domain considering, theoretically, a user could create apps and routes for those services and capture sensitive info.

-Mike

On Jun 15, 2015, at 2:32 PM, Mike Youngstrom <youngm(a)gmail.com<mailto:youngm(a)gmail.com>> wrote:

Two thoughts:
* Put your private system domain in an Org that users you don't trust won't have access to.
* Create routes without an app for the names you wish to "reserve"

Mike


On Mon, Jun 15, 2015 at 3:30 PM, Mike Jacobi <jacobi(a)adobe.com<mailto:jacobi(a)adobe.com>> wrote:
It appears users can create their own routes named the same as critical endpoints such as api, doppler, loggregator, uaa, etc. In fact, I just created an app with routes doppler and loggregator and the platform did nothing to prevent me from doing so. The “cf logs” behavior was then unpredictable.

Is there some way to prevent this? Am I missing something?

Thanks,
Mike

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


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


Re: Ordering lists of objects in the CF CLI

Mike Youngstrom
 

I like option #2 but I wouldn't even worry about adding a --asc or native
order flag until someone requests it.

My biggest issue with it not being ordered is it makes it harder to find an
item in a list once it become 20-30 items big. So, I vote for a single
consistent easy to follow list order which I believe alphabetical
descending would provide.

Also, don't forget about ordering the lists of orgs and spaces presented to
the user during login.

Mike

On Tue, Jun 16, 2015 at 12:42 PM, Greg Oehmen <goehmen(a)pivotal.io> wrote:

Hey All:

The CLI team has recently been chewing on ordering sets of objects like
orgs and apps. We've gotten a couple PRs [0] recently related to this.
I've been asking internally around CF teams about the value here with mixed
results and would like to hear some input from the OSS community.

Currently, lists are returned in ccdb insert order which basically means
oldest (first inserted) to newest (most recently inserted). The CC API has
an order-direction parameter which enables you to reverse that order and
see objects newest to oldest.

If we wanted to enable the ordering of a return set, there are a couple
options:


1. Keep the default order as it currently is natively sent by the CC
API. Add two flags to any 'list' command for desc & asc:

`cf orgs --asc` --> sorts in (A-Z, 1-9) order
`cf orgs --desc` --> sorts in (Z-A, 9-1) order



2. Change the default order to descending in the CF CLI and add a single
flag to reverse order (see --asc in option 1 above). This would mean that
the object list is always returned to the CLI user in descending order.
But is there any value here? How often would you use the '--asc' flag? In
this scenario, would you then want the CLI to include a flag to return
object lists in the order that is native to the CC API?


Then there is always the option to do nothing. If there is not as much
perceived value here in the OSS community, then not changing anything is
always an option.


Here is the set of all CF CLI commands that return lists of objects. If
we opt for 1 or 2 above, we would apply that option to this entire set
(which is ironically not in any sort order).

apps
stacks
services
service-keys
orgs
spaces domains
routes
buildpacks
org-users
space-users
quotas
space-quotas
service-auth-tokens
service-brokers
security-groups
staging-security-groups
running-security-groups
plugins
list-plugin-repos
repo-plugins



Also - I know that the desc & asc sort order is more complex than my
example above (a-z, 0-9) due to upper/lower case, non-alphanumeric, etc.
We will follow standard linux sort order convention.


Last thing - Conversations so far have not even taken CF CLI
internationalization into account. This may turn out to be waaaaaay harder
than it seemed. That's why I'm trying to gauge perceived value. Will this
change make your life easier and make you a more effective user of the CF
CLI?

Thanks

[0] https://github.com/cloudfoundry/cli/pull/481,
https://github.com/cloudfoundry/cli/pull/457

Greg Oehmen
Cloud Foundry Product Manager
415.205.6596


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

8921 - 8940 of 9421