Date   

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


Re: CF CLI Async

Long Nguyen
 

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

On June 16, 2015 at 3:06:58 PM, Shannon Coen (scoen(a)pivotal.io) wrote:

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


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


Re: Proposal for incubation of receptor-client (Java client for receptor)

Mike Youngstrom
 

+1

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

Mike

On Tue, Jun 16, 2015 at 11:56 AM, Ryan Morgan <ryanmorgan(a)gmail.com> wrote:


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

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


Re: How random is Metron's Doppler selection?

Mike Youngstrom
 



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


Re: CF CLI Async

Shannon Coen
 

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


Ordering lists of objects in the CF CLI

Greg Oehmen
 

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


Re: How random is Metron's Doppler selection?

Stuart Charlton
 

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


Re: CF CLI authentication issue

Madhura Bhave
 

Hi Stephan,

Could you send us the entire log for the UAA?

Madhura

On Tue, Jun 16, 2015 at 9:04 AM, Benjamin Black <bblack(a)pivotal.io> wrote:

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


CF CLI Async

Long Nguyen
 

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


Proposal for incubation of receptor-client (Java client for receptor)

Ryan Morgan <ryanmorgan@...>
 

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


Re: Multi-node CCNG Problem

CF Runtime
 

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

On Mon, Jun 15, 2015 at 12:09 AM, tan_bw(a)163.com <tan_bw(a)163.com> wrote:

Hi there:
I deployed 2 CCNG nodes in my servers.Since they've connected to the
same database,they always pull a same asynchronous task from my DB.I
found it's hardly to do the synchronous job by the DB.Is there any good
idea?
------------------------------
tan_bw(a)163.com

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


Re: I: R: Re: Log connections from security groups - bosh lite

CF Runtime
 

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


Re: CF CLI authentication issue

Benjamin Black
 

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


Re: How random is Metron's Doppler selection?

Mike Youngstrom
 

Great! Thanks for the acknowledgement John. :) To be clear I'm not
proposing that stdout and stderr should be done away with and I'm now
trying not to say that adding a syslog endpoint is the best solution.

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.

You guys are the smart ones I'm just trying to communicate a pain point for
which I don't believe an adequate solution has been presented yet. :)

Is there a story in the tracker to look into this? I couldn't find one.

Mike

On Tue, Jun 16, 2015 at 8:50 AM, John Tuley <jtuley(a)pivotal.io> wrote:

Mike,

I'm not saying that we have a good solution to multi-line log messages.
It's definitely a challenge today.

It's my understanding that the reasons for providing the stdout/stderr
logging are:

- adherence to the 12 Factor App <http://12factor.net/logs> principles,
- zero-configuration, "just works" support for the broadest set of use
cases, and
- compatibility with other PaaS offerings (e.g. Heroku).

None of that is meant to disregard your use case. I completely agree that
it's difficult-to-impossible for Loggregator to play nice with multi-line
logs, and that to bypass it would eliminate the value that the system
provides. I also agree that, while line-by-line processing of the console
works fine for a human watching the logs in real-time, it makes storing and
processing messages more difficult.


– John Tuley

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

As far as your comment John about having our applications send their
syslogs to a remote syslog server. Though that would certainly provide a
way to get better logs into splunk it would eliminate all the value we get
from loggregator.

* cf logs won't work (unless we fork our logs)
* we won't get the redundancy and reliability of logging locally (same
reason why metron exists as an agent)
* Complex customer config for a solution that should for the most part
"just work"
* etc.

There are all kinds of hacks we can use to improve our multi-line
logging. But, they are all hacks that diminish the customer experience.

I understand that nobody here can "speculate as to the future of CF and
whether or not a particular feature will someday be included". All I'm
asking for is an acknowledgement from the LAMB team that draining
multi-line log messages is a point point for users and that the team would
consider investing some future time to a solution (any solution) for this
issue.

If the logging team really believes that the way multi-line log events
are currently handled isn't a problem then lets discuss that. I as a user
believe this is a problem that ought to be looked at some point in the
future.

Mike

On Mon, Jun 15, 2015 at 3:48 PM, Mike Heath <elcapo(a)gmail.com> wrote:

I think our situation is a little bit different since we have a custom
syslog server that send logs directly to our Splunk indexers rather than
going through a Splunk forwarder that can aggregate multiple syslog streams
into a single event. This is part of our Splunk magic that allows our users
to do Splunk searches based of their Cloud Foundry app name, space, org,
etc rather than GUIDs.

Regardless, we can fix this by having our developers format their stack
traces differently.

Thanks Stuart.

-Mike

On Sat, Jun 13, 2015 at 1:32 PM, Stuart Charlton <scharlton(a)pivotal.io>
wrote:

Mike,


Actually, this might explain why some of our customers are so
frustrated
trying to read their stack traces in Splunk. :\

So each line of a stack trace could go to a different Doppler. That
means
each line of the stack trace goes out to a different syslog drain
making it
impossible to consolidate that stack trace into a single logging event
when
passed off to a third-party logging system like Splunk. This sucks. To
be
fair, Splunk has never been any good at dealing with stack traces.

I'm not sure this is a specific issue with Doppler, as I've dealt with
syslog aggregated servers in the past with Splunk and generally I've been
able to merge stack traces (with some false mergers on corner cases) with
some props.conf voodoo setting up custom linebreaker clauses for Java stack
traces.

Usually Log4J or whatnot can be configured to emit a predictable field
like an extra timestamp ahead of any any app log messages so I can
differentiate a multi-line event from single.

Multiple syslog drains shouldn't be a problem because Splunk will merge
events based on the date you tell it to merge on.


--

Stuart Charlton

Pivotal Software | Field Engineering

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



_______________________________________________
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


CF CLI authentication issue

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

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"


Re: How random is Metron's Doppler selection?

John Tuley <jtuley@...>
 

Mike,

I'm not saying that we have a good solution to multi-line log messages.
It's definitely a challenge today.

It's my understanding that the reasons for providing the stdout/stderr
logging are:

- adherence to the 12 Factor App <http://12factor.net/logs> principles,
- zero-configuration, "just works" support for the broadest set of use
cases, and
- compatibility with other PaaS offerings (e.g. Heroku).

None of that is meant to disregard your use case. I completely agree that
it's difficult-to-impossible for Loggregator to play nice with multi-line
logs, and that to bypass it would eliminate the value that the system
provides. I also agree that, while line-by-line processing of the console
works fine for a human watching the logs in real-time, it makes storing and
processing messages more difficult.


– John Tuley

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

As far as your comment John about having our applications send their
syslogs to a remote syslog server. Though that would certainly provide a
way to get better logs into splunk it would eliminate all the value we get
from loggregator.

* cf logs won't work (unless we fork our logs)
* we won't get the redundancy and reliability of logging locally (same
reason why metron exists as an agent)
* Complex customer config for a solution that should for the most part
"just work"
* etc.

There are all kinds of hacks we can use to improve our multi-line
logging. But, they are all hacks that diminish the customer experience.

I understand that nobody here can "speculate as to the future of CF and
whether or not a particular feature will someday be included". All I'm
asking for is an acknowledgement from the LAMB team that draining
multi-line log messages is a point point for users and that the team would
consider investing some future time to a solution (any solution) for this
issue.

If the logging team really believes that the way multi-line log events are
currently handled isn't a problem then lets discuss that. I as a user
believe this is a problem that ought to be looked at some point in the
future.

Mike

On Mon, Jun 15, 2015 at 3:48 PM, Mike Heath <elcapo(a)gmail.com> wrote:

I think our situation is a little bit different since we have a custom
syslog server that send logs directly to our Splunk indexers rather than
going through a Splunk forwarder that can aggregate multiple syslog streams
into a single event. This is part of our Splunk magic that allows our users
to do Splunk searches based of their Cloud Foundry app name, space, org,
etc rather than GUIDs.

Regardless, we can fix this by having our developers format their stack
traces differently.

Thanks Stuart.

-Mike

On Sat, Jun 13, 2015 at 1:32 PM, Stuart Charlton <scharlton(a)pivotal.io>
wrote:

Mike,


Actually, this might explain why some of our customers are so frustrated
trying to read their stack traces in Splunk. :\

So each line of a stack trace could go to a different Doppler. That
means
each line of the stack trace goes out to a different syslog drain
making it
impossible to consolidate that stack trace into a single logging event
when
passed off to a third-party logging system like Splunk. This sucks. To
be
fair, Splunk has never been any good at dealing with stack traces.

I'm not sure this is a specific issue with Doppler, as I've dealt with
syslog aggregated servers in the past with Splunk and generally I've been
able to merge stack traces (with some false mergers on corner cases) with
some props.conf voodoo setting up custom linebreaker clauses for Java stack
traces.

Usually Log4J or whatnot can be configured to emit a predictable field
like an extra timestamp ahead of any any app log messages so I can
differentiate a multi-line event from single.

Multiple syslog drains shouldn't be a problem because Splunk will merge
events based on the date you tell it to merge on.


--

Stuart Charlton

Pivotal Software | Field Engineering

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



_______________________________________________
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

8941 - 8960 of 9426