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

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

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.

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

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.

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

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

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

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

Hey Shannon,
   I have some legacy service broker that take quite a long time to create service. I’ve set “cc.broker_client_timeout_seconds to 5 mins but this is ignored because of accepts_incomplete=true it seems. The timeout seem to be 60 seconds. When using older CLI it works. I’m looking for possible workarounds for this. I would rather not be stuck on using v6.8.0 cli. 

Long

+1

I'd like to see even more first class Java clients for Cloud Foundry APIs
be promoted.

Mike

I think the challenge here is being able to distinguish between events
that are emitted by an App log vs. a multi-line event. Only the app
really would know this information, wouldn't it? i.e. it has to be done at
the app level? This may not be too hard with the common logger frameworks,
and perhaps documenting the pattern in a blog post for developers to
reference.

I agree. The app knows what is multi line and what isn't. So, the problem
is what is the most appropriate way for the application to communicate to
loggregator what should be multi-line and what shouldn't be. The '\' was
just a thought that it might be a less heavy way compared to syslog to give
an application a way to communicate this intent with loggregator. Using a
more rich endpoint like syslog might be another approach.

Either way I think us as loggregator users need some help from the
loggregator team to improve this scenario.

Mike

Hello Long,

There is not currently a way to prevent CLI from sending the
accepts_incomplete=true parameter.

Could you help me understand your use cases for wanting this?

Thank you!

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Jun 16, 2015 at 11:15 AM, Long Nguyen <long.nguyen11288(a)gmail.com>
wrote:

Is there a way to turn off async when creating service? It seem like on
v6.11.3 the post is "/v2/service_instances?accepts_incomplete=true” is
there a way to disable this?

Thanks,
Long


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

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

Hi Mike (Youngstrom),


On Tue, Jun 16, 2015 at 11:46 AM, <cf-dev-request(a)lists.cloudfoundry.org>
wrote:

Perhaps the solution could be as simple as supporing escaping the end of a
line with '\' to represent a log event that should include the next line?
Something like that might be good enough.

I think the challenge here is being able to distinguish between events that
are emitted by an App log vs. a multi-line event. Only the app really
would know this information, wouldn't it? i.e. it has to be done at the
app level? This may not be too hard with the common logger frameworks, and
perhaps documenting the pattern in a blog post for developers to reference.

--

Stuart Charlton

Pivotal Software | Field Engineering

Mobile: 403-671-9778 | Email: scharlton(a)pivotal.io

Hi Stephan,

Could you send us the entire log for the UAA?

Madhura

Is there a way to turn off async when creating service? It seem like on v6.11.3 the post is "/v2/service_instances?accepts_incomplete=true” is there a way to disable this?

Thanks,
Long

Hello,

At Pivotal we have been working on a Java client for receptor. We would
like to propose the receptor-client for official incubation into the Cloud
Foundry Foundation. The receptor-client is a Java client for communicating
with Diego's Restful API.

This project was started by Mark Fisher and the repository can be found at:
https://github.com/markfisher/receptor-client.

This is the only Java client for receptor that we're aware of, we believe
that others will find it useful and placing it into incubation will help
grow awareness. This library is already being used in several Pivotal
projects that use Lattice as a deployment target.

There is a branch prepared that updates all the package names to
org.cloudfoundry. Subject to approval, we are ready to move this repository
as soon as possible.

There has been some discussion on whether this best fits under the umbrella
of the Runtime or Utilities PMCs, with the latter being the general
consensus.

I look forward to comments/questions.

Thank you,
-Ryan

Are you talking about internal Cloud Controller tasks scheduled using
Delayed Job? The workers that process those jobs should lock the job before
performing any work. Is this not what you are seeing?

Joseph & Zak
CF Runtime Team

We had similar problems on Bosh Lite. Because of the way containers are
made, this feature won't work on a Bosh Lite environment.

Zak & Joseph
CF Runtime Team

On Sun, Jun 14, 2015 at 11:25 PM, Michael Grifalconi <
michael.grifalconi(a)studenti.unimi.it> wrote:

Hello all,

as I had no response, and I wasn't able to progress, I'm bumping this
email from last week

Thank you!

Best regards,
Michael

-------- Messaggio originale --------
Da: *"Michael Grifalconi" *<michael.grifalconi(a)studenti.unimi.it>
Data: 08/giu/15 9:31:55 m.
Oggetto: R: Re: [cf-dev] Log connections from security groups - bosh lite
A: Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>

Hello, I post some more info:



- Kernel logging is enabled because inside the DEA, i can see:


*cat /etc/rsyslog.conf*
*[...]*
*$IncludeConfig /etc/rsyslog.d/*.conf*

*cat /etc/rsyslog.d/enable-kernel-logging.conf*

*$ModLoad imklog*



- after pushing an app, I see on the DEA the correct rules:



-A warden-i-18nvgifiemi -p tcp -m tcp --dport 80 -g
warden-i-18nvgifiemi-log
-A warden-i-18nvgifiemi-log -p tcp -m conntrack --ctstate
INVALID,NEW,UNTRACKED -j LOG --log-prefix "warden-i-18nvgifiemi "



- but on */var/log/messages* I only get:

*Jun 8 07:03:26 localhost kernel: [ 3256.433021] IPv6:
ADDRCONF(NETDEV_CHANGE): w-18nvgifiemg-0: link becomes ready*


- the php application pushed:


*xx(a)boshClient:~/myPhpApp$ cat index.php*
*<html>*
* <head>*
* <title>PHP Test</title>*
* </head>*

* <body>*
* <?php*
* echo '<p>Hello PHP from the server
at:</p>';*
* echo $_SERVER['SERVER_ADDR'];*
* echo '<p>hi from hostname:</p>';*
* $curl = curl_init();*
*curl_setopt($curl, CURLOPT_URL, 'http://xxxxxxx <http://xxxxxxx>');*
*$result = curl_exec($curl);*
* echo gethostname();*
* ?>*
* </body>*

*</html>*



- When I browse this application page, I see the page from the
webserver on xxxx called from curl, but I don't get ant log.



- *bosh stemcells*



*+---------------------------------------------+---------+--------------------------------------+*
*| Name | Version | CID
|*

*+---------------------------------------------+---------+--------------------------------------+*
*| bosh-warden-boshlite-ubuntu-trusty-go_agent | 2776* |
c5ac6590-13ec-4ba2-6fa9-e78cf553c4e6 |*

*+---------------------------------------------+---------+--------------------------------------+*
--------------------------------------------------------------------

- *xx(a)boshClient:~$ cf security-groups*

*Getting security groups as admin*
*OK*

* Name Organization Space*
*#0 public_networks*
*#1 dns*
*#2 logging myOrg myDevSpace*




- *xx(a)boshClient:~$ cf security-group logging*

*Getting info for security group logging as admin*
*OK*

*Name logging*
*Rules*
* [*
* {*
* "destination": "0.0.0.0/0 <http://0.0.0.0/0>",*
* "log": true,*
* "ports": "80",*
* "protocol": "tcp"*
* }*
* ]*

* Organization Space*
*#0 myOrg myDevSpace*



- *tried with protocol: all and :tcp and the port where my local
apache server on LAN is listening.*



Any suggestion is appreciated!

Regards,
Michael


Il 06/06/15 09:25, *Dieu Cao * <dcao(a)pivotal.io> ha scritto:

Yes, I do recall that the feature did not work on bosh-lite but that was
when kernel logging was disabled on the trusty stemcell.

Michael, could you send the json for the application security group you've
applied to the space you're looking at?

-Dieu
CF Runtime PM

On Fri, Jun 5, 2015 at 5:48 PM, James Bayer <jbayer(a)pivotal.io> wrote:

i seem to remember something about app security group logging having an
issue with bosh-lite that isn't present when you have a DEA in a VM. i
remember something about that. i'll see if dieu remembers.

On Fri, Jun 5, 2015 at 1:06 PM, Michael <
michael.grifalconi(a)studenti.unimi.it> wrote:

Hello,


as you suggested, I looked deeper in this matter, and I can see that on
the DEA VM:


I get the right iptables rules, but I still can not see the logs on
/var/log/messages


[Im using bosh-lite, latest stemcell, CF version 207]


Do you know what should I do to allow this information to be logged?


ref:https://www.pivotaltracker.com/n/projects/966314/stories/90078842


Thank you!


Best regards,

Michael



****************
Per destinare il 5x1000 all'Universita' degli Studi di Milano: indicare
nella dichiarazione dei redditi il codice fiscale 80012650158.


http://www.unimi.it/13084.htm?utm_source=firmaMail&utm_medium=email&utm_content=linkFirmaEmail&utm_campaign=5xmille

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

--
Thank you,

James Bayer

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

_______________________________________________
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

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