Date   

Re: uaa saml to ping-federate broke when upgrading from cf-226 to cf-227

Rich Wohlstadter
 

Thanks Sree,

We tried to send the new SP metadata over and Ping is complaining that it has an invalid signature. So is the current release of uaa in v228 the one that has bad/invalid signature? Just trying to understand if we need to wait for a newer release before the mismatched public/private key pair is fixed.

Rich


Re: Does standard service-registry service available in PWS?

Logan Lee
 

PWS is a commercial product offered by Pivotal. You can contact them via
their support site or you can connect with me directly.

This list is for open source cloud foundry project related topics.

On Jan 27, 2016, at 11:10 PM, Rajesh Bhojwani <rajesh.bhojwani(a)gmail.com>
wrote:

Hi,
Do we have standard service-registry service available in free version of
PWS?
I checked in marketplace and could not find. Is there a way to install it
there?

Please help if any idea. I want to try spring cloud services in PWS.


Re: uaa saml to ping-federate broke when upgrading from cf-226 to cf-227

Sree Tummidi
 

Hi Rich,

Please see my comments inline

1. When using cf login --sso, prompt no longer points to proper url but
defaults to localhost: One Time Code ( Get one at
http://localhost:8080/uaa/passcode )

We are addressing this issue as part of
https://www.pivotaltracker.com/story/show/112592967

2. When comparing the cf IP metadata, it differs now in the SignatureValue
field

We fixed an issue with mismatched public/private key pair which was causing
invalid signature to be generated.
Now the key set up is valid. Yes, you would need to change the PING side of
the configuration and update the SP metatdata

Thanks,
Sree Tummidi
Sr. Product Manager
Identity - Pivotal Cloud Foundry

On Thu, Jan 28, 2016 at 6:41 AM, Rich Wohlstadter <lethwin(a)gmail.com> wrote:

Hi There,

We have cloudfoundry uaa setup to authenticate users to our Identity
Provider ping-federate. After we upgraded to cf-227 this functionality
broke. Are there any know issues with saml setup when you moved over to
the uaa-release github? Some of the symptoms we see:

1. When using cf login --sso, prompt no longer points to proper url but
defaults to localhost: One Time Code ( Get one at
http://localhost:8080/uaa/passcode )
2. When comparing the cf IP metadata, it differs now in the SignatureValue
field

Wondering if we need to set the ping info back up due to a change with
this new release?

Here is the config we use for saml (stripped sensitive info):

saml:
entity_base_url: login.cf-np.threega.com
entityid: login
keystore_key: selfsigned
keystore_name: samlKeystore.jks
keystore_password: UGN9RbgNaMwp4Dnn
providers:
ping-federate:
assertionConsumerIndex: 0
idpMetadata: |+
<md:EntityDescriptor ID="qhotIfnybstUv02tsh8w2jvpJxF"
cacheDuration="PT1440M" entityID="company-t"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><ds:Signature xmlns:ds="
http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#qhotIfnybstUv02tsh8w2jvpJxF">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="
http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue>zzTEqNenEtq85owsS83D+YhJ3cU0Qfgr1bOWxoLssRI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
our_signature
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
our_certificate
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>

lZ4ZUFzYXubIUKmMrw+maVTrPGikviTfsJWAiPhuSL6qGnRVLorTTeUr/ynS++TdLpVkBLz0hqD/

yQvd1V3sgK6X22NGikLcmIrHRX69DLqB7IdC9HFlpz3yVWK0lIChVlrqgLX7/wEQpYwWLnnLXjz4

J3ce0mQ4Y4kmiBvhciqNEoqPK/g9wrkZKzMhLk3/CMtR/hDVurG/s+bnmYhbNb3pmHYBu5KnqmrJ

xHzxsxnBRF6V8fEXlmI7pqu9SV21p7dEW1VYi5p99lnFPkL1ic+dF4iIIWtggbq4Ue3qdl1bUoc8
y+iG5fRPSQJIGkmiAfQdTdxe8zc384gmf6IenQ==
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature><md:IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
WantAuthnRequestsSigned="true"><md:KeyDescriptor use="signing"><ds:KeyInfo
xmlns:ds="http://www.w3.org/2000/09/xmldsig#
"><ds:X509Data><ds:X509Certificate>MIIDUjCCAjqgAwIBAgIGAU1EsJejMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaXNzb3VyaTESMBAGA1UEBxMJU3QuIExvdWlzMREwDwYDVQQKEwhNb25zYW50bzEMMAoGA1UECxMDRUlTMRMwEQYDVQQDEwpNb25zYW50by10MB4XDTE1MDUxMTIwMzUzM1oXDTE3MDUxMDIwMzUzM1owajELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1pc3NvdXJpMRIwEAYDVQQHEwlTdC4gTG91aXMxETAPBgNVBAoTCE1vbnNhbnRvMQwwCgYDVQQLEwNFSVMxEzARBgNVBAMTCk1vbnNhbnRvLXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVnhlQXNhe5shQqYyvD6ZpVOs8aKS+JN+wlYCI+G5IvqoadFUuitNN5Sv/KdL75N0ulWQEvPSGoP/JC93VXeyArpfbY0aKQtyYisdFfr0MuoHsh0L0cWWnPfJVYrSUgKFWWuqAtfv/ARCljBYuectePPgndx7SZDhjiSaIG+FyKo0Sio8r+D3CuRkrMyEuTf8Iy1H+ENW6sb+z5ueZiFs1vemYdgG7kqeqasnEfPGzGcFEXpXx8ReWYjumq71JXbWnt0RbVViLmn32WcU+QvWJz50XiIgha2CBurhR7ep2XV
tShzzL6I
bl9E9JAkgaSaIB9B1N3F7zNzfziCZ/oh6dAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAG/MyUQ05U8Liqq85+xTY7WcUGiUAXv+/cSS7OLasoblDQ0iBxcpSkWvkGTVqR73QTRssIfnokG9GGJsSdyIcZzWoCLg2iTaJjRFEuI5oP9sy3QPeK66MeIdkkSGeEuHfNKloSoApxxocuDZuGTHCuU7dqXZe49hf1qiSvLbZHGZuksu4jBPN2qWqwe+v2TFM3AraakAwPbcYqir7c3nWAWkr4h/6KlmZwEo9gAFsMliUM0h9+AHVLyjRQfMlPeOP1N7zpNnMYr0JKJ9B7Rs2ebtCoHLLsyOVmiDiVJDRHVv04GBDSMXIkGcKY7ULLR9WiqMKfnkamGs1QOrQTIJZhU=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:ArtifactResolutionService
index="0" Location="https://test.amp.company.com/idp/ARS.ssaml2"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
isDefault="true"/><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="
https://test.amp.monsanto.com/idp/SSO.saml2"/><md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="
https://test.amp.monsanto.c
om/idp/S
SO.saml2"/><md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="
https://test.amp.monsanto.com/idp/SSO.saml2"/><md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="
https://test.amp.monsanto.com/idp/SSO.saml2"/></md:IDPSSODescriptor><md:ContactPerson
contactType="administrative"><md:Company>company</md:Company><md:GivenName>AMP</md:GivenName><md:SurName>Team</md:SurName><md:EmailAddress>
DL-AMPSUPPORT(a)company.com
</md:EmailAddress><md:TelephoneNumber>xxx-xxx-xxxx</md:TelephoneNumber></md:ContactPerson></md:EntityDescriptor>
linkText: Ping Identity
metadataTrustCheck: true
nameID: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
showSamlLoginLink: true


uaa saml to ping-federate broke when upgrading from cf-226 to cf-227

Rich Wohlstadter
 

Hi There,

We have cloudfoundry uaa setup to authenticate users to our Identity Provider ping-federate. After we upgraded to cf-227 this functionality broke. Are there any know issues with saml setup when you moved over to the uaa-release github? Some of the symptoms we see:

1. When using cf login --sso, prompt no longer points to proper url but defaults to localhost: One Time Code ( Get one at http://localhost:8080/uaa/passcode )
2. When comparing the cf IP metadata, it differs now in the SignatureValue field

Wondering if we need to set the ping info back up due to a change with this new release?

Here is the config we use for saml (stripped sensitive info):

saml:
entity_base_url: login.cf-np.threega.com
entityid: login
keystore_key: selfsigned
keystore_name: samlKeystore.jks
keystore_password: UGN9RbgNaMwp4Dnn
providers:
ping-federate:
assertionConsumerIndex: 0
idpMetadata: |+
<md:EntityDescriptor ID="qhotIfnybstUv02tsh8w2jvpJxF" cacheDuration="PT1440M" entityID="company-t" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#qhotIfnybstUv02tsh8w2jvpJxF">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>zzTEqNenEtq85owsS83D+YhJ3cU0Qfgr1bOWxoLssRI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
our_signature
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
our_certificate
</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
lZ4ZUFzYXubIUKmMrw+maVTrPGikviTfsJWAiPhuSL6qGnRVLorTTeUr/ynS++TdLpVkBLz0hqD/
yQvd1V3sgK6X22NGikLcmIrHRX69DLqB7IdC9HFlpz3yVWK0lIChVlrqgLX7/wEQpYwWLnnLXjz4
J3ce0mQ4Y4kmiBvhciqNEoqPK/g9wrkZKzMhLk3/CMtR/hDVurG/s+bnmYhbNb3pmHYBu5KnqmrJ
xHzxsxnBRF6V8fEXlmI7pqu9SV21p7dEW1VYi5p99lnFPkL1ic+dF4iIIWtggbq4Ue3qdl1bUoc8
y+iG5fRPSQJIGkmiAfQdTdxe8zc384gmf6IenQ==
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
</ds:Signature><md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true"><md:KeyDescriptor use="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIDUjCCAjqgAwIBAgIGAU1EsJejMA0GCSqGSIb3DQEBBQUAMGoxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaXNzb3VyaTESMBAGA1UEBxMJU3QuIExvdWlzMREwDwYDVQQKEwhNb25zYW50bzEMMAoGA1UECxMDRUlTMRMwEQYDVQQDEwpNb25zYW50by10MB4XDTE1MDUxMTIwMzUzM1oXDTE3MDUxMDIwMzUzM1owajELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1pc3NvdXJpMRIwEAYDVQQHEwlTdC4gTG91aXMxETAPBgNVBAoTCE1vbnNhbnRvMQwwCgYDVQQLEwNFSVMxEzARBgNVBAMTCk1vbnNhbnRvLXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVnhlQXNhe5shQqYyvD6ZpVOs8aKS+JN+wlYCI+G5IvqoadFUuitNN5Sv/KdL75N0ulWQEvPSGoP/JC93VXeyArpfbY0aKQtyYisdFfr0MuoHsh0L0cWWnPfJVYrSUgKFWWuqAtfv/ARCljBYuectePPgndx7SZDhjiSaIG+FyKo0Sio8r+D3CuRkrMyEuTf8Iy1H+ENW6sb+z5ueZiFs1vemYdgG7kqeqasnEfPGzGcFEXpXx8ReWYjumq71JXbWnt0RbVViLmn32WcU+QvWJz50XiIgha2CBurhR7ep2XVtShzzL6I
bl9E9JAkgaSaIB9B1N3F7zNzfziCZ/oh6dAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAG/MyUQ05U8Liqq85+xTY7WcUGiUAXv+/cSS7OLasoblDQ0iBxcpSkWvkGTVqR73QTRssIfnokG9GGJsSdyIcZzWoCLg2iTaJjRFEuI5oP9sy3QPeK66MeIdkkSGeEuHfNKloSoApxxocuDZuGTHCuU7dqXZe49hf1qiSvLbZHGZuksu4jBPN2qWqwe+v2TFM3AraakAwPbcYqir7c3nWAWkr4h/6KlmZwEo9gAFsMliUM0h9+AHVLyjRQfMlPeOP1N7zpNnMYr0JKJ9B7Rs2ebtCoHLLsyOVmiDiVJDRHVv04GBDSMXIkGcKY7ULLR9WiqMKfnkamGs1QOrQTIJZhU=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:ArtifactResolutionService index="0" Location="https://test.amp.company.com/idp/ARS.ssaml2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" isDefault="true"/><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://test.amp.monsanto.com/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://test.amp.monsanto.com/idp/S
SO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://test.amp.monsanto.com/idp/SSO.saml2"/><md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://test.amp.monsanto.com/idp/SSO.saml2"/></md:IDPSSODescriptor><md:ContactPerson contactType="administrative"><md:Company>company</md:Company><md:GivenName>AMP</md:GivenName><md:SurName>Team</md:SurName><md:EmailAddress>DL-AMPSUPPORT(a)company.com</md:EmailAddress><md:TelephoneNumber>xxx-xxx-xxxx</md:TelephoneNumber></md:ContactPerson></md:EntityDescriptor>
linkText: Ping Identity
metadataTrustCheck: true
nameID: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
showSamlLoginLink: true


Re: etcd fails to start when trying to deploy diego with

Martin Jackson
 

Thanks Amit,

You've put me back on track I have confused the mail CF etcd cluster with the new Diego one.

Regards

Martin


Re: Error 500 when testing new v229 CF deployment

Dieu Cao <dcao@...>
 

Sorry, I skimmed over that particular snippet.
Based on that description, perhaps then double checking your entry for
router.ssl_cert and router.ssl_key and comparing against your existing
deployment's manifest might help?

-Dieu
CF CAPI PM

On Wed, Jan 27, 2016 at 4:41 PM, James Leavers <james(a)cloudhelix.io> wrote:

Hi,

The cert in router.ssl_cert is a real, CA-signed cert that has been
successfully used in a previous CF install - the only thing that was
generated locally with openssl was the jwt signing keys, and consul
certs/keys using the provided script.

I have tried changing ssl.skip_cert_verify to false, but sadly no change.

Looking at the bug you mention, their logs have a clearer indication that
the invalid cert was to blame:

{"timestamp":1453748741.968373,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"Invalid SSL Cert for
https://uaa.system.cfyarn.cloud.kohavi.info/oauth/token. Use
'--skip-ssl-validation' to continue with an insecure target\

Whereas the error I'm getting is different, although I agree it must be
SSL-related in some way:

{"timestamp":1453833820.1408544,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"Neither PUB key nor PRIV key: header
too long\", \"error_code\"=>\"CF-RSAError\",

I have since tried changing pretty much every SSL-related property to
false / http in the manifest but nothing has made a difference so far.

Thanks
James


Does standard service-registry service available in PWS?

Rajesh Bhojwani <rajesh.bhojwani@...>
 

Hi,
Do we have standard service-registry service available in free version of
PWS?
I checked in marketplace and could not find. Is there a way to install it
there?

Please help if any idea. I want to try spring cloud services in PWS.


The M2M & IoT Ecosystem: 2015 – 2030 – Opportunities, Challenges, Strategies, Industry Verticals & Forecasts

SNS Research <e.hall@...>
 

The M2M, IoT & Wearable Technology Ecosystem: 2015 2030 Opportunities, Challenges, Strategies, Industry Verticals and Forecasts

Hello,
 
Hope you are doing well. 
I wanted to bring to your attention the latest SNS Research report in which you might be interested, " The M2M, IoT & Wearable Technology Ecosystem: 2015 2030 Opportunities, Challenges, Strategies, Industry Verticals and Forecasts." 

I believe this report will be highly applicable for you. If you would like to see the report sample or have any questions, please let me know.  

Report Information:

Release Date: November 2015
Number of Pages: 1,113
Number of Tables and Figures: 553

Report Overview:

As consumer voice and data service revenues reach their saturation point, mobile operators are keen to capitalize on other avenues to drive revenue growth. One such opportunity is providing network connectivity for M2M (Machine to Machine) devices like smart meters, connected cars and healthcare monitors. Despite its low ARPU, M2M connectivity has opened a multi-billion dollar revenue opportunity for mobile operators, MVNOs and service aggregators, addressing the application needs of several verticals markets. By enabling network connectivity among physical objects, M2M has also initiated the IoT (Internet of Things) vision - a global network of sensors, equipment, appliances, smart devices and applications that can communicate in real time.

Another key opportunity is the monetization of wearable technology. Mobile device OEMs are aggressively investing in wearable devices, in order to offset declining margins in their traditional smartphone and tablet markets. As a result, the market has been flooded with a variety of smart bands, smart watches and other wearable devices capable of collecting, sending and processing data over mobile applications.

Eyeing opportunities to route huge volumes of traffic from these wearable devices, many service providers are now seeking to fit wearable technology with their M2M offerings, targeting both consumer and vertical markets. SNS Research expects that M2M and wearable devices can help IoT service providers pocket as much as $231 Billion in service revenue by the end of 2020, following a CAGR of 40% between 2015 and 2020.

Spanning over 1,110 pages, the "M2M, IoT & Wearable Technology Ecosystem: 2015 2030 Opportunities, Challenges, Strategies, Industry Verticals and Forecasts" report package encompasses two comprehensive reports covering M2M, IoT and wearable technology:
  • The M2M & IoT Ecosystem: 2015 2030 - Opportunities, Challenges, Strategies, Industry Verticals and Forecasts
  • The Wearable Technology Ecosystem: 2015 2030 - Opportunities, Challenges, Strategies, Industry Verticals and Forecasts
This report package provides an in-depth assessment of the M2M, IoT and wearable technology ecosystem including enabling technologies, key trends, market drivers, challenges, vertical market applications, deployment case studies, collaborative initiatives, regulatory landscape, standardization, opportunities, future roadmap, value chain, ecosystem player profiles and strategies. The report also presents market size forecasts from 2015 till 2030. The forecasts are segmented into vertical, regional, technology and country submarkets.

The report package comes with an associated Excel datasheet suite covering quantitative data from all numeric forecasts presented in the two reports.

Topics Covered:
The report package covers the following topics:
  • M2M, IoT and wearable technology ecosystem
  • Market drivers and challenges
  • Enabling technologies and key trends
  • Network architecture and mobile operator business models 
  • Applications, opportunities and deployment case studies for a range of vertical markets including automotive & transportation, asset management & logistics, consumer, energy & utilities, healthcare, home automation, intelligent buildings & infrastructure, military, professional sports, public safety & security, retail and hospitality
  • Regulatory landscape, collaborative initiatives and standardization
  • Industry roadmap and value chain assessment
  • Profiles and strategies of over 600 leading ecosystem players including enabling technology providers, wearable/M2M device OEMs, mobile operators, MVNOs, aggregators, IoT platform providers, system integrators and vertical market specialists
  • Strategic recommendations for ecosystem players
  • Market analysis and forecasts from 2015 till 2030
Key Questions Answered:
The report package provides answers to the following key questions:
  • How big is the M2M, IoT and wearable technology ecosystem?
  • What trends, challenges and barriers are influencing its growth?
  • How is the ecosystem evolving by segment and region?
  • What will the market size be in 2020 and at what rate will it grow?
  • Which regions, countries and verticals will see the highest percentage of growth?
  • Who are the key market players and what are their strategies?
  • How will M2M and wearable devices drive investments in cloud based IoT platforms, Big Data, analytics, network security and other technologies? 
  • What are the growth prospects of cellular, satellite, LPWA, wireline and short range networking technologies? 
  • What are the key applications of M2M, IoT and wearable technology across industry verticals?
  • How can mobile operators capitalize on the growing popularity of smart glasses and other wearable devices?
  • What strategies should enabling technology providers, wearable/M2M device OEMs, mobile operators, MVNOs, aggregators, IoT platform providers and other ecosystem players adopt to remain competitive?
Report Pricing:

Single User License: USD 3,500

Company Wide License: USD 4,500


Ordering Process:

Please contact Emily Hall at e.hall@...

And provide the following information:
Report Title:
Report License (Single User/Company Wide):
Name:
Email:
Job Title:
Company:

Please contact me if you have any questions, or wish to purchase a copy.

I look forward to hearing from you.

Kind Regards,

Emily Hall

Sales Director 
Signals and Systems Research
Address: Reef Tower
Jumeirah Lake Towers
Sheikh Zayed Road
Dubai, UAE

To unsubscribe, please reply to this email with UNSUBSCRIBE in the subject line, or click Remove


Re: Enviroment variables HTTP_PROXY for CF CLI dosen't work

Yu, Yongcong <yuyc@...>
 

The proxy server is the same net(10.167.0.0) with the CF host, So I used the security group of the CF default "private_networks" as below.
################################################################
$ cf security-group private_networks
Getting info for security group private_networks as admin
OK

Name private_networks
Rules
[
{
"destination": "10.0.0.0-10.255.255.255",
"protocol": "all"
},
{
"destination": "172.16.0.0-172.31.255.255",
"protocol": "all"
},
{
"destination": "192.168.0.0-192.168.255.255",
"protocol": "all"
}
]

No spaces assigned

$ cf staging-security-groups
Acquiring staging security group as admin
OK

private_networks
################################################################

But it also doesn't work.
How to configure the security for my proxy server.


Re: Enviroment variables HTTP_PROXY for CF CLI doen't work

Koper, Dies <diesk@...>
 

Have you configured your security groups for the buildpack to be allowed access to your proxy server?
Check `cf staging-security-groups`.

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: Yu, Yongcong [mailto:yuyc(a)cn.fujitsu.com]
Sent: Thursday, January 28, 2016 12:22 PM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] Re: Re: Enviroment variables HTTP_PROXY for CF CLI doen't work

JT Archie

Thank you for your reply.
The environment variable HTTP_PROXY has been set , and the information of the environment variable as following.
#######################################################
Getting env variables for app business in org DevBox / space sp1 as admin...
OK

System-Provided:


{
"VCAP_APPLICATION": {
"application_id": "f860c7ed-8cf4-4c18-950f-d91ec582bbd6",
"application_name": "business",
"application_uris": [
"business.10.167.227.48.xip.io"
],
"application_version": "a93a1b8a-45da-483b-b978-cbe60d3a5651",
"limits": {
"disk": 1024,
"fds": 16384,
"mem": 256
},
"name": "business",
"space_id": "2d4b7770-aad9-404b-a906-5777302aa911",
"space_name": "sp1",
"uris": [
"business.10.167.227.48.xip.io"
],
"users": null,
"version": "a93a1b8a-45da-483b-b978-cbe60d3a5651"
}
}

User-Provided:
HTTPS_PROXY: http://10.167.227.38:1080
HTTP_PROXY: http://10.167.227.38:1080
no_proxy: 127.0.0.1,api.10.167.227.48.xip.io,doppler.10.167.227.48.xip.io,hm9000.10.167.227.48.xip.io,uaa.10.167.227.48.xip.io,loggregator.10.167.227.48.xip.io,business.10.167.227.48.xip.io

Running Environment Variable Groups:
HTTP_PROXY: http://10.167.227.38:1080

Staging Environment Variable Groups:
HTTP_PROXY: http://10.167.227.38:1080
#######################################################


Re: Enviroment variables HTTP_PROXY for CF CLI doen't work

Yu, Yongcong <yuyc@...>
 

JT Archie

Thank you for your reply.
The environment variable HTTP_PROXY has been set , and the information of the environment variable as following.
#######################################################
Getting env variables for app business in org DevBox / space sp1 as admin...
OK

System-Provided:


{
"VCAP_APPLICATION": {
"application_id": "f860c7ed-8cf4-4c18-950f-d91ec582bbd6",
"application_name": "business",
"application_uris": [
"business.10.167.227.48.xip.io"
],
"application_version": "a93a1b8a-45da-483b-b978-cbe60d3a5651",
"limits": {
"disk": 1024,
"fds": 16384,
"mem": 256
},
"name": "business",
"space_id": "2d4b7770-aad9-404b-a906-5777302aa911",
"space_name": "sp1",
"uris": [
"business.10.167.227.48.xip.io"
],
"users": null,
"version": "a93a1b8a-45da-483b-b978-cbe60d3a5651"
}
}

User-Provided:
HTTPS_PROXY: http://10.167.227.38:1080
HTTP_PROXY: http://10.167.227.38:1080
no_proxy: 127.0.0.1,api.10.167.227.48.xip.io,doppler.10.167.227.48.xip.io,hm9000.10.167.227.48.xip.io,uaa.10.167.227.48.xip.io,loggregator.10.167.227.48.xip.io,business.10.167.227.48.xip.io

Running Environment Variable Groups:
HTTP_PROXY: http://10.167.227.38:1080

Staging Environment Variable Groups:
HTTP_PROXY: http://10.167.227.38:1080
#######################################################


Re: AUFS bug in Linux kernel

Eric Malm <emalm@...>
 

Hi, Mike,

Warden also uses aufs for its containers' overlay filesystems, so we expect
the same issue to affect the DEAs on these stemcell versions. I'm not aware
of a deliberate attempt to reproduce it on the DEAs, though.

Thanks,
Eric

On Wed, Jan 27, 2016 at 4:08 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks Will. Does anyone know if this bug could also impacts Warden?

Mike

On Wed, Jan 27, 2016 at 9:50 AM, Will Pragnell <wpragnell(a)pivotal.io>
wrote:

A bug with AUFS [1] was introduced in version 3.19.0-40 of the linux
kernel. This bug can cause containers to end up with unkillable zombie
processes with high CPU usage. This can happen any time a container is
supposed to be destroyed.

This affects both Garden-Linux and Warden (and Docker). If you see
significant slowdown or increased CPU usage on DEAs or Diego cells, it
might well be this. It will probably build slowly up over time, so you may
not notice anything for a while depending on the rate of app instance churn
on your deployment.

The bad version of the kernel is present in stemcell 3160 and later. I
can't recommend using older stemcells because the bad kernel versions also
include fixes for several high severity security vulnerabilities (at least
[2-5], there may be others I've missed). Were it not for these, rolling
back to stemcell 3157 would be the fix.

We're waiting for a fix to make its way into the kernel, and the BOSH
team will produce a stemcell with the fix as soon as possible. In the
meantime, I'd suggest simply keeping a closer eye than usual on your DEAs
and Diego cells.

If this issue occurs, the only solution is to recreate that machine.
While we've not had any actual reports of this issue occurring for Cloud
Foundry deployments in the wild yet, we're confident that the issue will be
occurring. The Diego team have seen it in testing, and several teams have
encountered the issue with their Concourse workers, which also use
Garden-Linux.

As always, please get in touch out if you have any questions.

Will - Garden PM

[1]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043
[2]: http://www.ubuntu.com/usn/usn-2857-1/
[3]: http://www.ubuntu.com/usn/usn-2868-1/
[4]: http://www.ubuntu.com/usn/usn-2869-1/
[5]: http://www.ubuntu.com/usn/usn-2871-2/


Re: Error 500 when testing new v229 CF deployment

James Leavers
 

Hi,

The cert in router.ssl_cert is a real, CA-signed cert that has been successfully used in a previous CF install - the only thing that was generated locally with openssl was the jwt signing keys, and consul certs/keys using the provided script.

I have tried changing ssl.skip_cert_verify to false, but sadly no change.

Looking at the bug you mention, their logs have a clearer indication that the invalid cert was to blame:

{"timestamp":1453748741.968373,"message":"Request failed: 500: {\"code\"=>10001, \"description\"=>\"Invalid SSL Cert for https://uaa.system.cfyarn.cloud.kohavi.info/oauth/token. Use '--skip-ssl-validation' to continue with an insecure target\

Whereas the error I'm getting is different, although I agree it must be SSL-related in some way:

{"timestamp":1453833820.1408544,"message":"Request failed: 500: {\"code\"=>10001, \"description\"=>\"Neither PUB key nor PRIV key: header too long\", \"error_code\"=>\"CF-RSAError\",

I have since tried changing pretty much every SSL-related property to false / http in the manifest but nothing has made a difference so far.

Thanks
James


Re: AUFS bug in Linux kernel

Mike Youngstrom <youngm@...>
 

Thanks Will. Does anyone know if this bug could also impacts Warden?

Mike

On Wed, Jan 27, 2016 at 9:50 AM, Will Pragnell <wpragnell(a)pivotal.io> wrote:

A bug with AUFS [1] was introduced in version 3.19.0-40 of the linux
kernel. This bug can cause containers to end up with unkillable zombie
processes with high CPU usage. This can happen any time a container is
supposed to be destroyed.

This affects both Garden-Linux and Warden (and Docker). If you see
significant slowdown or increased CPU usage on DEAs or Diego cells, it
might well be this. It will probably build slowly up over time, so you may
not notice anything for a while depending on the rate of app instance churn
on your deployment.

The bad version of the kernel is present in stemcell 3160 and later. I
can't recommend using older stemcells because the bad kernel versions also
include fixes for several high severity security vulnerabilities (at least
[2-5], there may be others I've missed). Were it not for these, rolling
back to stemcell 3157 would be the fix.

We're waiting for a fix to make its way into the kernel, and the BOSH team
will produce a stemcell with the fix as soon as possible. In the meantime,
I'd suggest simply keeping a closer eye than usual on your DEAs and Diego
cells.

If this issue occurs, the only solution is to recreate that machine. While
we've not had any actual reports of this issue occurring for Cloud Foundry
deployments in the wild yet, we're confident that the issue will be
occurring. The Diego team have seen it in testing, and several teams have
encountered the issue with their Concourse workers, which also use
Garden-Linux.

As always, please get in touch out if you have any questions.

Will - Garden PM

[1]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533043
[2]: http://www.ubuntu.com/usn/usn-2857-1/
[3]: http://www.ubuntu.com/usn/usn-2868-1/
[4]: http://www.ubuntu.com/usn/usn-2869-1/
[5]: http://www.ubuntu.com/usn/usn-2871-2/


Re: Diego IAAS settings for vsphere

Shetty, Daya <Daya.Shetty@...>
 

Hi, Eric,

As per your suggestion I changed the logLevel=debug and did a tail on the auctioneer & bbs logs while doing a cf push of buildpack based app to diego. Unfortunately I still saw only LogLevel: 1 messsages on the Auctioneer logs but did see LogLevel 0,1 & 2 messages on the bbs logs.

I have attached the bbs.log. Here are some errors I see in the bbs log.


{"timestamp":"1453934586.220547676","source":"bbs","message":"bbs.actuallrp-handler.actual-lrp-groups.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1","index":5},"session":"3.19.1"}}

{"timestamp":"1453934586.224381685","source":"bbs","message":"bbs.task-handler.tasks.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1","index":5},"session":"7.25.1"}}

"timestamp":"1453934595.548539162","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.failed","log_level":2,"data":{"error":"100: Key not found (/v1/desired_lrp) [8]","process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-e42855a5-0122-4e1a-a003-a4eac1fe3deb","session":"6.19.1"}}

{"timestamp":"1453934595.548731089","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/desired_lrp","index":8},"process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-e42855a5-0122-4e1a-a003-a4eac1fe3deb","session":"6.19.1.1"}}

{"timestamp":"1453934595.735231638","source":"bbs","message":"bbs.actuallrp-handler.actual-lrp-groups.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/actual","index":9},"session":"3.20.1"}}

{"timestamp":"1453934595.738165140","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/desired_lrp","index":9},"filter":{"Domain":""},"session":"6.20.1.1"}}

{"timestamp":"1453934600.773372650","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/desired_lrp","index":9},"filter":{"Domain":"cf-apps"},"session":"6.21.1.1"}}

{"timestamp":"1453934610.201195955","source":"bbs","message":"bbs.converge-lrps.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/actual","index":9},"session":"111.1"}}

{"timestamp":"1453934610.205472708","source":"bbs","message":"bbs.converge-lrps.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/desired_lrp","index":9},"session":"111.2"}}

{"timestamp":"1453934616.234182835","source":"bbs","message":"bbs.actuallrp-handler.actual-lrp-groups.etcd-error.resource-not-found","log_level":0,"data":{"error":{"errorCode":100,"message":"Key not found","cause":"/v1/actual","index":9},"session":"3.21.1"}}

Regards
Daya


From: Daya Shetty <Daya.Shetty(a)bnymellon.com<mailto:Daya.Shetty(a)bnymellon.com>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Wednesday, January 27, 2016 at 2:00 PM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Diego IAAS settings for vsphere

Hi, Eric,

I tried to enable debug using the debugAddr but the log_level remained as 1. Not sure why?


curl -v http://0.0.0.0:17001/log-level -X PUT -d debug

* Hostname was NOT found in DNS cache

* Trying 0.0.0.0...

* Connected to 0.0.0.0 (127.0.0.1) port 17001 (#0)

PUT /log-level HTTP/1.1
User-Agent: curl/7.35.0
Host: 0.0.0.0:17001
Accept: */*
Content-Length: 5
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 5 out of 5 bytes

< HTTP/1.1 200 OK

< Date: Wed, 27 Jan 2016 21:44:44 GMT

< Content-Length: 0

< Content-Type: text/plain; charset=utf-8

<

* Connection #0 to host 0.0.0.0 left intact

var/vcap/packages/auctioneer/bin/auctioneer -bbsClientCert=/var/vcap/jobs/auctioneer/config/certs/bbs/client.crt -bbsClientKey=/var/vcap/jobs/auctioneer/config/certs/bbs/client.key -bbsCACert=/var/vcap/jobs/auctioneer/config/certs/bbs/ca.crt -bbsAddress=https://bbs.service.cf.internal:8889 -consulCluster=http://127.0.0.1:8500 -debugAddr=0.0.0.0:17001 -listenAddr=0.0.0.0:9016 -logLevel=info

I will restart the processes mentioned, with —logLevel=debug by changing rhe relevant _ctl files, In the meantime here is the snapshot of the auctioneer log while trying to start a buildpack based app.


Here is the auctioneer.stdout log

root(a)fb99aa6d-3a9a-48c5-b6e9-dccfbc035c7a:/var/vcap/data/sys/log/auctioneer# !ta

tail -f auctioneer.stdout.log

{"timestamp":"1453931031.236279488","source":"auctioneer","message":"auctioneer.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"36"}}

{"timestamp":"1453931031.236993074","source":"auctioneer","message":"auctioneer.auction.fetching-cell-reps","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.240644693","source":"auctioneer","message":"auctioneer.auction.fetched-cell-reps","log_level":1,"data":{"cell-reps-count":1,"session":"37"}}

{"timestamp":"1453931031.240906715","source":"auctioneer","message":"auctioneer.auction.fetching-zone-state","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.248399019","source":"auctioneer","message":"auctioneer.auction.zone-state","log_level":1,"data":{"cell-count":1,"session":"37","zone":"z1"}}

{"timestamp":"1453931031.249227762","source":"auctioneer","message":"auctioneer.auction.fetched-zone-state","log_level":1,"data":{"cell-state-count":1,"duration":"6.511719ms","num-failed-requests":0,"session":"37"}}

{"timestamp":"1453931031.249767065","source":"auctioneer","message":"auctioneer.auction.fetching-auctions","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.250007153","source":"auctioneer","message":"auctioneer.auction.fetched-auctions","log_level":1,"data":{"lrp-start-auctions":0,"session":"37","task-auctions":1}}

{"timestamp":"1453931031.250244141","source":"auctioneer","message":"auctioneer.auction.scheduling","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.250724792","source":"auctioneer","message":"auctioneer.auction.scheduled","log_level":1,"data":{"failed-lrp-start-auctions":0,"failed-task-auctions":1,"session":"37","successful-lrp-start-auctions":0,"successful-task-auctions":0}}

{"timestamp":"1453931106.945099831","source":"auctioneer","message":"auctioneer.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"38"}}

{"timestamp":"1453931106.946578026","source":"auctioneer","message":"auctioneer.request.task-auction-handler.create.submitted","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"38.1.1","tasks":["da383b70-f3da-4248-86b5-9a82e6d7d809-2d07956c22c142849c2b160c46ddb480"]}}

{"timestamp":"1453931106.948045492","source":"auctioneer","message":"auctioneer.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"38"}}

{"timestamp":"1453931106.948791265","source":"auctioneer","message":"auctioneer.auction.fetching-cell-reps","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.952327490","source":"auctioneer","message":"auctioneer.auction.fetched-cell-reps","log_level":1,"data":{"cell-reps-count":1,"session":"39"}}

{"timestamp":"1453931106.952946186","source":"auctioneer","message":"auctioneer.auction.fetching-zone-state","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.959112644","source":"auctioneer","message":"auctioneer.auction.zone-state","log_level":1,"data":{"cell-count":1,"session":"39","zone":"z1"}}

{"timestamp":"1453931106.959350586","source":"auctioneer","message":"auctioneer.auction.fetched-zone-state","log_level":1,"data":{"cell-state-count":1,"duration":"5.455613ms","num-failed-requests":0,"session":"39"}}

{"timestamp":"1453931106.959569216","source":"auctioneer","message":"auctioneer.auction.fetching-auctions","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.959800005","source":"auctioneer","message":"auctioneer.auction.fetched-auctions","log_level":1,"data":{"lrp-start-auctions":0,"session":"39","task-auctions":1}}

{"timestamp":"1453931106.960027695","source":"auctioneer","message":"auctioneer.auction.scheduling","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.960274935","source":"auctioneer","message":"auctioneer.auction.scheduled","log_level":1,"data":{"failed-lrp-start-auctions":0,"failed-task-auctions":1,"session":"39","successful-lrp-start-auctions":0,"successful-task-auctions":0}}

Regards
Daya


From: Eric Malm <emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Wednesday, January 27, 2016 at 12:29 PM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Diego IAAS settings for vsphere

Hi, Daya,

Thanks for the log entries and the state response from the cell. It does look like that cell should have sufficient capacity to take on the staging task. From the BBS logs for the 'da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8' task guid, it does look like the task is getting saved in the BBS, and then failed by something else (presumably the auctioneer) almost immediately thereafter. Could you also look at the auctioneer logs for that period of time?

Also, it might help to turn on debug logging dynamically on these components: if you do a `netstat -anp` on the bosh VM, you'll see each Diego component process listening on a port 170XX in the 17000 range. If you then run `curl http://localhost:170XX/log-level -X PUT -d debug` on that VM, that will change the log-level on that component to 'debug' (it normally defaults to 'info'). So if we're not seeing anything useful at the info/error level for this period of time, you could switch the active bbs and auctioneer to the debug log-level, start tailing their logs in real-time with `tail –f`, and try submitting another staging task.

Thanks,
Eric

On Wed, Jan 27, 2016 at 11:31 AM, Daya Shetty <daya.shetty(a)bnymellon.com<mailto:daya.shetty(a)bnymellon.com>> wrote:
Hi, Eric,

I further checked the logs you mentioned and can't see what could be the problem.

I only have one instance of cell running and here is the state info:
curl 0.0.0.0:1800/state<http://0.0.0.0:1800/state>
{"RootFSProviders":{"docker":{"type":"arbitrary"},"preloaded":{"set":{"cflinuxfs2":{}},"type":"fixed_set"}},"AvailableResources":{"MemoryMB":7984,"DiskMB":24263,"Containers":256},"TotalResources":{"MemoryMB":7984,"DiskMB":24263,"Containers":256},"LRPs":[],"Tasks":null,"Zone":"z1","Evacuating":false}


I see TLS handshake errors in the bbs.stderr.log, don't know if this can be the cause for" Insufficient resources"
2016/01/27 19:12:03 http: TLS handshake error from 127.0.0.1:50475<http://127.0.0.1:50475>: EOF
2016/01/27 19:12:06 http: TLS handshake error from 127.0.0.1:50477<http://127.0.0.1:50477>: EOF

Not able to deduce anything from the bbs.stdout.log here is a snapshot. Will dig further.

"timestamp":"1453921657.161973238","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19946"}}
{"timestamp":"1453921657.162120819","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19947"}}
{"timestamp":"1453921657.167166233","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19947"}}
{"timestamp":"1453921657.167504787","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19946"}}
{"timestamp":"1453921674.952786684","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19948"}}
{"timestamp":"1453921674.953184366","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19949"}}
{"timestamp":"1453921674.953428984","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.start","log_level":1,"data":{"filter":{"Domain":""},"session":"6.3791.1"}}
{"timestamp":"1453921674.954186201","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.complete","log_level":1,"data":{"filter":{"Domain":""},"session":"6.3791.1"}}
{"timestamp":"1453921674.954262018","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19949"}}
{"timestamp":"1453921674.959604502","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19948"}}
{"timestamp":"1453921681.551017284","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/desire","session":"19950"}}
{"timestamp":"1453921681.551474571","source":"bbs","message":"bbs.task-handler.desire-task.desire-task.starting","log_level":1,"data":{"session":"7.5881.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.561704636","source":"bbs","message":"bbs.task-handler.desire-task.desire-task.finished","log_level":1,"data":{"session":"7.5881.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.561844826","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/desire","session":"19950"}}
{"timestamp":"1453921681.575248480","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/fail","session":"19951"}}
{"timestamp":"1453921681.575376987","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.starting","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.575446367","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.getting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.577617884","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.succeeded-getting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.578390121","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.persisting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.582517862","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.succeded-persisting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.583042145","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.task-client-completing-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.583634138","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.finished","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.583706856","source":"bbs","message":"bbs.resolving-task","log_level":1,"data":{"task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.584264040","source":"bbs","message":"bbs.resolving-task.starting","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.584349394","source":"bbs","message":"bbs.resolving-task.getting-task","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.584867001","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/fail","session":"19951"}}
{"timestamp":"1453921681.587889433","source":"bbs","message":"bbs.resolving-task.succeeded-getting-task","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.591948748","source":"bbs","message":"bbs.resolving-task.finished","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.629187346","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp/remove","session":"19952"}}
{"timestamp":"1453921681.629388809","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.starting","log_level":1,"data":{"process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-c398c85b-3965-4fd7-91e9-3112bafe3394","session":"6.3792.1"}}
{"timestamp":"1453921681.630566120","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.failed","log_level":2,"data":{"error":"100: Key not found (/v1/desired_lrp) [64]","process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-c398c85b-3965-4fd7-91e9-3112bafe3394","session":"6.3792.1"}}
{"timestamp":"1453921681.631013870","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.complete","log_level":1,"data":{"process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-c398c85b-3965-4fd7-91e9-3112bafe3394","session":"6.3792.1"}}
{"timestamp":"1453921681.631548882","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp/remove","session":"19952"}}
{"timestamp":"1453921681.639199495","source":"bbs","message":"bbs.delete-task.starting","log_level":1,"data":{"callback_url":"http://stager.service.cf.internal:8888/v1/staging/da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8/completed","session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8/completed","status_code":200,"task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921686.492143154","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/lrps/converge","session":"19953"}}
{"timestamp":"1453921686.492546797","source":"bbs","message":"bbs.converge-lrps.starting-convergence","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.492759466","source":"bbs","message":"bbs.converge-lrps.gathering-and-pruning-actual-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.493501425","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/converge","session":"19955"}}
{"timestamp":"1453921686.493688107","source":"bbs","message":"bbs.task-handler.converge-tasks.converge-tasks.starting-convergence","log_level":1,"data":{"session":"7.5883.1"}}
{"timestamp":"1453921686.495135784","source":"bbs","message":"bbs.converge-lrps.actual-lrp-schema-root-not-found","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.495184660","source":"bbs","message":"bbs.converge-lrps.succeeded-gathering-and-pruning-actual-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.495222807","source":"bbs","message":"bbs.converge-lrps.gathering-desired-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.499060631","source":"bbs","message":"bbs.converge-lrps.actual-lrp-schema-root-not-found","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.499403954","source":"bbs","message":"bbs.converge-lrps.succeeded-gathering-desired-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.501797915","source":"bbs","message":"bbs.task-handler.converge-tasks.converge-tasks.finished-convergence","log_level":1,"data":{"session":"7.5883.1"}}
{"timestamp":"1453921686.502251863","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/converge","session":"19955"}}
{"timestamp":"1453921686.504722357","source":"bbs","message":"bbs.converge-lrps.calculate-convergence.start","log_level":1,"data":{"session":"19954.3"}}
{"timestamp":"1453921686.504907846","source":"bbs","message":"bbs.converge-lrps.calculate-convergence.done","log_level":1,"data":{"session":"19954.3"}}
{"timestamp":"1453921686.505190134","source":"bbs","message":"bbs.converge-lrps.finished-convergence","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.505403280","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/lrps/converge","session":"19953"}}
{"timestamp":"1453921687.169877052","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19956"}}
{"timestamp":"1453921687.171530724","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19956"}}
{"timestamp":"1453921687.172345877","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19957"}}
{"timestamp":"1453921687.176663637","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19957"}}
{"timestamp":"1453921692.995214939","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19958"}}
{"timestamp":"1453921692.995497704","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.start","log_level":1,"data":{"filter":{"Domain":"cf-apps"},"session":"6.3793.1"}}
{"timestamp":"1453921692.996849060","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.complete","log_level":1,"data":{"filter":{"Domain":"cf-apps"},"session":"6.3793.1"}}
{"timestamp":"1453921692.997039795","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19958"}}


The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.

The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.


Re: Diego IAAS settings for vsphere

Shetty, Daya <Daya.Shetty@...>
 

Hi, Eric,

I tried to enable debug using the debugAddr but the log_level remained as 1. Not sure why?


curl -v http://0.0.0.0:17001/log-level -X PUT -d debug

* Hostname was NOT found in DNS cache

* Trying 0.0.0.0...

* Connected to 0.0.0.0 (127.0.0.1) port 17001 (#0)

PUT /log-level HTTP/1.1
User-Agent: curl/7.35.0
Host: 0.0.0.0:17001
Accept: */*
Content-Length: 5
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 5 out of 5 bytes

< HTTP/1.1 200 OK

< Date: Wed, 27 Jan 2016 21:44:44 GMT

< Content-Length: 0

< Content-Type: text/plain; charset=utf-8

<

* Connection #0 to host 0.0.0.0 left intact

var/vcap/packages/auctioneer/bin/auctioneer -bbsClientCert=/var/vcap/jobs/auctioneer/config/certs/bbs/client.crt -bbsClientKey=/var/vcap/jobs/auctioneer/config/certs/bbs/client.key -bbsCACert=/var/vcap/jobs/auctioneer/config/certs/bbs/ca.crt -bbsAddress=https://bbs.service.cf.internal:8889 -consulCluster=http://127.0.0.1:8500 -debugAddr=0.0.0.0:17001 -listenAddr=0.0.0.0:9016 -logLevel=info

I will restart the processes mentioned, with —logLevel=debug by changing rhe relevant _ctl files, In the meantime here is the snapshot of the auctioneer log while trying to start a buildpack based app.


Here is the auctioneer.stdout log

root(a)fb99aa6d-3a9a-48c5-b6e9-dccfbc035c7a:/var/vcap/data/sys/log/auctioneer# !ta

tail -f auctioneer.stdout.log

{"timestamp":"1453931031.236279488","source":"auctioneer","message":"auctioneer.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"36"}}

{"timestamp":"1453931031.236993074","source":"auctioneer","message":"auctioneer.auction.fetching-cell-reps","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.240644693","source":"auctioneer","message":"auctioneer.auction.fetched-cell-reps","log_level":1,"data":{"cell-reps-count":1,"session":"37"}}

{"timestamp":"1453931031.240906715","source":"auctioneer","message":"auctioneer.auction.fetching-zone-state","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.248399019","source":"auctioneer","message":"auctioneer.auction.zone-state","log_level":1,"data":{"cell-count":1,"session":"37","zone":"z1"}}

{"timestamp":"1453931031.249227762","source":"auctioneer","message":"auctioneer.auction.fetched-zone-state","log_level":1,"data":{"cell-state-count":1,"duration":"6.511719ms","num-failed-requests":0,"session":"37"}}

{"timestamp":"1453931031.249767065","source":"auctioneer","message":"auctioneer.auction.fetching-auctions","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.250007153","source":"auctioneer","message":"auctioneer.auction.fetched-auctions","log_level":1,"data":{"lrp-start-auctions":0,"session":"37","task-auctions":1}}

{"timestamp":"1453931031.250244141","source":"auctioneer","message":"auctioneer.auction.scheduling","log_level":1,"data":{"session":"37"}}

{"timestamp":"1453931031.250724792","source":"auctioneer","message":"auctioneer.auction.scheduled","log_level":1,"data":{"failed-lrp-start-auctions":0,"failed-task-auctions":1,"session":"37","successful-lrp-start-auctions":0,"successful-task-auctions":0}}

{"timestamp":"1453931106.945099831","source":"auctioneer","message":"auctioneer.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"38"}}

{"timestamp":"1453931106.946578026","source":"auctioneer","message":"auctioneer.request.task-auction-handler.create.submitted","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"38.1.1","tasks":["da383b70-f3da-4248-86b5-9a82e6d7d809-2d07956c22c142849c2b160c46ddb480"]}}

{"timestamp":"1453931106.948045492","source":"auctioneer","message":"auctioneer.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks","session":"38"}}

{"timestamp":"1453931106.948791265","source":"auctioneer","message":"auctioneer.auction.fetching-cell-reps","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.952327490","source":"auctioneer","message":"auctioneer.auction.fetched-cell-reps","log_level":1,"data":{"cell-reps-count":1,"session":"39"}}

{"timestamp":"1453931106.952946186","source":"auctioneer","message":"auctioneer.auction.fetching-zone-state","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.959112644","source":"auctioneer","message":"auctioneer.auction.zone-state","log_level":1,"data":{"cell-count":1,"session":"39","zone":"z1"}}

{"timestamp":"1453931106.959350586","source":"auctioneer","message":"auctioneer.auction.fetched-zone-state","log_level":1,"data":{"cell-state-count":1,"duration":"5.455613ms","num-failed-requests":0,"session":"39"}}

{"timestamp":"1453931106.959569216","source":"auctioneer","message":"auctioneer.auction.fetching-auctions","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.959800005","source":"auctioneer","message":"auctioneer.auction.fetched-auctions","log_level":1,"data":{"lrp-start-auctions":0,"session":"39","task-auctions":1}}

{"timestamp":"1453931106.960027695","source":"auctioneer","message":"auctioneer.auction.scheduling","log_level":1,"data":{"session":"39"}}

{"timestamp":"1453931106.960274935","source":"auctioneer","message":"auctioneer.auction.scheduled","log_level":1,"data":{"failed-lrp-start-auctions":0,"failed-task-auctions":1,"session":"39","successful-lrp-start-auctions":0,"successful-task-auctions":0}}

Regards
Daya


From: Eric Malm <emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Wednesday, January 27, 2016 at 12:29 PM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Diego IAAS settings for vsphere

Hi, Daya,

Thanks for the log entries and the state response from the cell. It does look like that cell should have sufficient capacity to take on the staging task. From the BBS logs for the 'da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8' task guid, it does look like the task is getting saved in the BBS, and then failed by something else (presumably the auctioneer) almost immediately thereafter. Could you also look at the auctioneer logs for that period of time?

Also, it might help to turn on debug logging dynamically on these components: if you do a `netstat -anp` on the bosh VM, you'll see each Diego component process listening on a port 170XX in the 17000 range. If you then run `curl http://localhost:170XX/log-level -X PUT -d debug` on that VM, that will change the log-level on that component to 'debug' (it normally defaults to 'info'). So if we're not seeing anything useful at the info/error level for this period of time, you could switch the active bbs and auctioneer to the debug log-level, start tailing their logs in real-time with `tail –f`, and try submitting another staging task.

Thanks,
Eric

On Wed, Jan 27, 2016 at 11:31 AM, Daya Shetty <daya.shetty(a)bnymellon.com<mailto:daya.shetty(a)bnymellon.com>> wrote:
Hi, Eric,

I further checked the logs you mentioned and can't see what could be the problem.

I only have one instance of cell running and here is the state info:
curl 0.0.0.0:1800/state<http://0.0.0.0:1800/state>
{"RootFSProviders":{"docker":{"type":"arbitrary"},"preloaded":{"set":{"cflinuxfs2":{}},"type":"fixed_set"}},"AvailableResources":{"MemoryMB":7984,"DiskMB":24263,"Containers":256},"TotalResources":{"MemoryMB":7984,"DiskMB":24263,"Containers":256},"LRPs":[],"Tasks":null,"Zone":"z1","Evacuating":false}


I see TLS handshake errors in the bbs.stderr.log, don't know if this can be the cause for" Insufficient resources"
2016/01/27 19:12:03 http: TLS handshake error from 127.0.0.1:50475<http://127.0.0.1:50475>: EOF
2016/01/27 19:12:06 http: TLS handshake error from 127.0.0.1:50477<http://127.0.0.1:50477>: EOF

Not able to deduce anything from the bbs.stdout.log here is a snapshot. Will dig further.

"timestamp":"1453921657.161973238","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19946"}}
{"timestamp":"1453921657.162120819","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19947"}}
{"timestamp":"1453921657.167166233","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19947"}}
{"timestamp":"1453921657.167504787","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19946"}}
{"timestamp":"1453921674.952786684","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19948"}}
{"timestamp":"1453921674.953184366","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19949"}}
{"timestamp":"1453921674.953428984","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.start","log_level":1,"data":{"filter":{"Domain":""},"session":"6.3791.1"}}
{"timestamp":"1453921674.954186201","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.complete","log_level":1,"data":{"filter":{"Domain":""},"session":"6.3791.1"}}
{"timestamp":"1453921674.954262018","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19949"}}
{"timestamp":"1453921674.959604502","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19948"}}
{"timestamp":"1453921681.551017284","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/desire","session":"19950"}}
{"timestamp":"1453921681.551474571","source":"bbs","message":"bbs.task-handler.desire-task.desire-task.starting","log_level":1,"data":{"session":"7.5881.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.561704636","source":"bbs","message":"bbs.task-handler.desire-task.desire-task.finished","log_level":1,"data":{"session":"7.5881.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.561844826","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/desire","session":"19950"}}
{"timestamp":"1453921681.575248480","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/fail","session":"19951"}}
{"timestamp":"1453921681.575376987","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.starting","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.575446367","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.getting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.577617884","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.succeeded-getting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.578390121","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.persisting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.582517862","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.succeded-persisting-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.583042145","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.task-client-completing-task","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.583634138","source":"bbs","message":"bbs.task-handler.fail-task.fail-task.finished","log_level":1,"data":{"session":"7.5882.1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.583706856","source":"bbs","message":"bbs.resolving-task","log_level":1,"data":{"task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.584264040","source":"bbs","message":"bbs.resolving-task.starting","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.584349394","source":"bbs","message":"bbs.resolving-task.getting-task","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.584867001","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/fail","session":"19951"}}
{"timestamp":"1453921681.587889433","source":"bbs","message":"bbs.resolving-task.succeeded-getting-task","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.591948748","source":"bbs","message":"bbs.resolving-task.finished","log_level":1,"data":{"session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921681.629187346","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp/remove","session":"19952"}}
{"timestamp":"1453921681.629388809","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.starting","log_level":1,"data":{"process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-c398c85b-3965-4fd7-91e9-3112bafe3394","session":"6.3792.1"}}
{"timestamp":"1453921681.630566120","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.failed","log_level":2,"data":{"error":"100: Key not found (/v1/desired_lrp) [64]","process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-c398c85b-3965-4fd7-91e9-3112bafe3394","session":"6.3792.1"}}
{"timestamp":"1453921681.631013870","source":"bbs","message":"bbs.desiredlrp-handler.remove-desired-lrp.remove-desired-lrp.complete","log_level":1,"data":{"process-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-c398c85b-3965-4fd7-91e9-3112bafe3394","session":"6.3792.1"}}
{"timestamp":"1453921681.631548882","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp/remove","session":"19952"}}
{"timestamp":"1453921681.639199495","source":"bbs","message":"bbs.delete-task.starting","log_level":1,"data":{"callback_url":"http://stager.service.cf.internal:8888/v1/staging/da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8/completed","session":"1","task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8/completed","status_code":200,"task-guid":"da383b70-f3da-4248-86b5-9a82e6d7d809-6db1e598fc2f466287a8f29c01a71bd8"}}
{"timestamp":"1453921686.492143154","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/lrps/converge","session":"19953"}}
{"timestamp":"1453921686.492546797","source":"bbs","message":"bbs.converge-lrps.starting-convergence","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.492759466","source":"bbs","message":"bbs.converge-lrps.gathering-and-pruning-actual-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.493501425","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/converge","session":"19955"}}
{"timestamp":"1453921686.493688107","source":"bbs","message":"bbs.task-handler.converge-tasks.converge-tasks.starting-convergence","log_level":1,"data":{"session":"7.5883.1"}}
{"timestamp":"1453921686.495135784","source":"bbs","message":"bbs.converge-lrps.actual-lrp-schema-root-not-found","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.495184660","source":"bbs","message":"bbs.converge-lrps.succeeded-gathering-and-pruning-actual-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.495222807","source":"bbs","message":"bbs.converge-lrps.gathering-desired-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.499060631","source":"bbs","message":"bbs.converge-lrps.actual-lrp-schema-root-not-found","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.499403954","source":"bbs","message":"bbs.converge-lrps.succeeded-gathering-desired-lrps","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.501797915","source":"bbs","message":"bbs.task-handler.converge-tasks.converge-tasks.finished-convergence","log_level":1,"data":{"session":"7.5883.1"}}
{"timestamp":"1453921686.502251863","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/converge","session":"19955"}}
{"timestamp":"1453921686.504722357","source":"bbs","message":"bbs.converge-lrps.calculate-convergence.start","log_level":1,"data":{"session":"19954.3"}}
{"timestamp":"1453921686.504907846","source":"bbs","message":"bbs.converge-lrps.calculate-convergence.done","log_level":1,"data":{"session":"19954.3"}}
{"timestamp":"1453921686.505190134","source":"bbs","message":"bbs.converge-lrps.finished-convergence","log_level":1,"data":{"session":"19954"}}
{"timestamp":"1453921686.505403280","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/lrps/converge","session":"19953"}}
{"timestamp":"1453921687.169877052","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19956"}}
{"timestamp":"1453921687.171530724","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/tasks/list","session":"19956"}}
{"timestamp":"1453921687.172345877","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19957"}}
{"timestamp":"1453921687.176663637","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/actual_lrp_groups/list","session":"19957"}}
{"timestamp":"1453921692.995214939","source":"bbs","message":"bbs.request.serving","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19958"}}
{"timestamp":"1453921692.995497704","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.start","log_level":1,"data":{"filter":{"Domain":"cf-apps"},"session":"6.3793.1"}}
{"timestamp":"1453921692.996849060","source":"bbs","message":"bbs.desiredlrp-handler.desired-lrps.desired-lrp-scheduling-infos.complete","log_level":1,"data":{"filter":{"Domain":"cf-apps"},"session":"6.3793.1"}}
{"timestamp":"1453921692.997039795","source":"bbs","message":"bbs.request.done","log_level":1,"data":{"method":"POST","request":"/v1/desired_lrp_scheduling_infos/list","session":"19958"}}


The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.


Re: Migration endpoint removed in 226 :(

Mike Youngstrom <youngm@...>
 

That's ok. Just felt like venting a little is all. The simple revert
worked. I'm probably the only one user still converting v1 services
anyway. :)

Mike

On Wed, Jan 27, 2016 at 2:44 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Apologies Mike.

It was my understanding that the endpoint was incomplete/non functional
and as it was marked experimental, was okay to remove.

Dieu
CF CAPI PM


On Wednesday, January 27, 2016, Mike Youngstrom <youngm(a)gmail.com> wrote:

For anyone else that runs into this. I was able to revert
https://github.com/cloudfoundry/cloud_controller_ng/commit/94ab558675641c8b325f821f9823721569c44fab
from v227's CC commit a07fcc957ecf07d6c0f81d8f154b2b7bb8613f05 and the
migrate functionality appears to work fine again.

Mike

On Wed, Jan 27, 2016 at 12:18 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Not very nice removing the v1 service migration endpoint before actually
removing v1 service support. Do you see any issue with my reverting that
commit on the CC that went into v227?

https://www.pivotaltracker.com/story/show/102725918

I don't see any issues using this for services that don't have any
gateway data I'm not aware of? I used it with other simple v1 services
successfully.

Mike



Re: Migration endpoint removed in 226 :(

Dieu Cao <dcao@...>
 

Apologies Mike.

It was my understanding that the endpoint was incomplete/non functional and
as it was marked experimental, was okay to remove.

Dieu
CF CAPI PM

On Wednesday, January 27, 2016, Mike Youngstrom <youngm(a)gmail.com> wrote:

For anyone else that runs into this. I was able to revert
https://github.com/cloudfoundry/cloud_controller_ng/commit/94ab558675641c8b325f821f9823721569c44fab
from v227's CC commit a07fcc957ecf07d6c0f81d8f154b2b7bb8613f05 and the
migrate functionality appears to work fine again.

Mike

On Wed, Jan 27, 2016 at 12:18 PM, Mike Youngstrom <youngm(a)gmail.com
<javascript:_e(%7B%7D,'cvml','youngm(a)gmail.com');>> wrote:

Not very nice removing the v1 service migration endpoint before actually
removing v1 service support. Do you see any issue with my reverting that
commit on the CC that went into v227?

https://www.pivotaltracker.com/story/show/102725918

I don't see any issues using this for services that don't have any
gateway data I'm not aware of? I used it with other simple v1 services
successfully.

Mike



Re: *.cf.internal on diego windows

Edward Hill
 

Thanks Matthew, yeah it's no real hassle to manually add


Re: Migration endpoint removed in 226 :(

Mike Youngstrom <youngm@...>
 

For anyone else that runs into this. I was able to revert
https://github.com/cloudfoundry/cloud_controller_ng/commit/94ab558675641c8b325f821f9823721569c44fab
from v227's CC commit a07fcc957ecf07d6c0f81d8f154b2b7bb8613f05 and the
migrate functionality appears to work fine again.

Mike

On Wed, Jan 27, 2016 at 12:18 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Not very nice removing the v1 service migration endpoint before actually
removing v1 service support. Do you see any issue with my reverting that
commit on the CC that went into v227?

https://www.pivotaltracker.com/story/show/102725918

I don't see any issues using this for services that don't have any gateway
data I'm not aware of? I used it with other simple v1 services
successfully.

Mike


5861 - 5880 of 9429