Date   

Re: Announcing the Cloud Foundry Java Client 2.0.0.M1

Ben Hale <bhale@...>
 

Any thoughts or plans for producing uaa and loggregator/firehose clients as well? Perhaps as separate modules? I see limited uaa auth and limited loggregator support in cloudfoundry-client.
In fact, the plan is currently to include both of those APIs. You can see the UAA is prioritized[1] and the DopplerClient is already[2] being worked.

I wonder if we could get more componentization in the client library by renaming "cloudfoundry-client" to "cloud-controller-client" and adding a "uaa-client (making it fully featured eventually)" and "loggregator-client" both probably included in "cloudfoundry-operations”
There will be a single API library and a single implementation library but there will be separate CloudFoundryClient, DopplerClient, and UaaClient’s (in addition to the CloudFoundryOperations and a likely UaaOperations). While the code will all exist in a pair of libraries, users are free to use only the components they wish. Keeping a small number of libraries reduces dependency complexity and makes it easier for us to managed the underlying common infrastructure that all of the implementations are built on.


-Ben Hale
Cloud Foundry Java Experience

[1]: https://www.pivotaltracker.com/n/projects/816799/search?q=label%3A%22uaa%22
[2]: https://github.com/cloudfoundry/cf-java-client/tree/doppler


Re: cf platform upgrade with 100% uptime for apps

Stephen Byers <smbyers@...>
 

Thanks, Gwenn, and I agree that a load balancer is needed here which is the
approach I have personally taken. The original question with haproxy was
from Ben and I think I would agree that there is no way to achieve 100%
uptime without having a separate CF installation where all traffic could be
directed while the other platform is upgraded.

Even with the load balancer solution, I am curious how the health checking
should (or if it could) be configured to achieve 100% uptime. There may be
some level of interruption until the load balance figures out that one of
the gorouters is down and takes it out of service. Load balancers are
certainly not my specialty, though.

Thanks

On Mon, Mar 14, 2016 at 1:39 AM Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Stephen,

Haproxy is clearly a SPOF here, that's why in production most of the
people use a load balancer with active health checking.




Thanks

On Mon, Mar 14, 2016 at 3:07 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Stephen, I think this is only possible if you deployed CF unto multiple
DCs. Same configuration, multiple DNSs


On Mon, Mar 14, 2016 at 3:55 AM, Stephen Byers <smbyers(a)gmail.com> wrote:

Agree. But the haproxy fronts the router so any client that is pinned to
the haproxy that is taken down will not make it to the router until its DNS
ttl is reached and it resolves to the other haproxy ip and even that may
not happen if this is a DNS round robin configuration.

I could be missing something?

On Sun, Mar 13, 2016, 8:44 PM Ben R <vagcom.ben(a)gmail.com> wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com>
wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

PS: I tried to install and use cf-cli 6.15 and had the same issue.


Re: Dial tcp: i/o timeout while pushing a sample app to Cloud Foundry BOSH-Lite deployment

Giovanni Napoli
 

Hi Rob, first of all thank you for your answer. I tried to look into /etc/resolv.conf file and the only nameserver is 127.0.1.1 that is my hostname. This morning, trying to do the same thing and using another time my cell phone and a hotspot, seems to be the same issue. I really don't know what cloud be the problem. I'll try to switch to CLI 1.5 and see if that resolves the issue.
However, have you got any other suggestions?


Using swift as a blobstore in cloud foundry with keystone v3

Altaf, Muhammad
 

Hi All,
I am trying to configure cloud foundry to use swift on OpenStack. I have followed the instructions at https://docs.cloudfoundry.org/deploying/openstack/using_swift_blobstore.html
When used keystone v2, I am able to start my apps on DEA which is good. However when using keystone V3, I am not able to start my apps. The error I am getting is:

“FAILED
Server error, status code: 400, error code: 170001, message: Staging error: failed to stage application:
Error downloading: HTTP status: 401”

Tried to debug by adding some ‘puts’ statements in openstack/core.rb file and it looks like tokens are being generated successfully so there is no problem with the authentication. The generated response to auth request shows that the user has “ResellerAdmin” role as well.

When I look into runner_z1/0 /var/vcap/data/dea_next/tmp/ app-package-download.tgz2016*, I find error saying: “401 Unauthorized: Temp URL invalid xxxxx”

/var/vcap/sys/log/dea_next/dea_next.log shows some download URLs, and if I curl those URLs, I get exact same error message. Below are the fog_connection settings in cloud foundry manifest:

fog_connection: &fog_connection
provider: 'OpenStack'
openstack_username: 'cf-admin2'
openstack_tenant: 'cf2'
openstack_project_name: 'cf2'
openstack_api_key: 'passw0rd'
openstack_auth_url: 'http://<OPENSTACK_IP>:5000/v3/auth/tokens'
openstack_domain_name: 'cf_domain'
openstack_user_domain_name: 'cf_domain'
openstack_temp_url_key: 'b3968d0207b54ece87cccc06515a89d4'


Account has a valid temp_url_key configured. Please see below:
curl -v -X GET http://SWIFT_IP:SWIFT_PORT/v2/Auth_b34a51e551ec4796a461168c886c734f -H "X-Auth-Token: TOKEN"
* Hostname was NOT found in DNS cache
* Trying SWIFT_IP...
* Connected to SWIFT_IP (SWIFT_IP) port SWIFT_PORT (#0)
GET /v2/Auth_b34a51e551ec4796a461168c886c734f HTTP/1.1
User-Agent: curl/7.35.0
Host: SWIFT_IP:SWIFT_PORT
Accept: */*
X-Auth-Token: TOKEN
< HTTP/1.1 204 No Content
< Content-Length: 0
< X-Account-Object-Count: 0
< X-Timestamp: 1457918518.21777
< X-Account-Meta-Temp-Url-Key: b3968d0207b54ece87cccc06515a89d4
< X-Account-Bytes-Used: 0
< X-Account-Container-Count: 0
< Content-Type: text/plain; charset=utf-8
< Accept-Ranges: bytes
< X-Trans-Id: txfc362c27bdda4355a942a-0056e65d93
< Date: Mon, 14 Mar 2016 06:43:31 GMT
<
* Connection #0 to host SWIFT_IP left intact

Also, I can see that the containers are created on swift, so obviously it is able to authenticate.
$ openstack container list
+---------------+
| Name |
+---------------+
| cc-buildpacks |
| cc-droplets |
| cc-packages |
| cc-resources |
+---------------+

I would appreciate if someone can help me fixing this issue.

Regards,
Muhammad Altaf
Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd
14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9067 F +61 2 9975 2899
Muhammada(a)fast.au.fujitsu.com<mailto:Muhammada(a)fast.au.fujitsu.com>
fastware.com.au<http://fastware.com.au>

[cid:image001.jpg(a)01D17E18.3B68BDD0]
[cid:image002.jpg(a)01D17E18.3B68BDD0]
Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(a)fast.au.fujitsu.com


Re: cf platform upgrade with 100% uptime for apps

Gwenn Etourneau
 

Stephen,

Haproxy is clearly a SPOF here, that's why in production most of the people
use a load balancer with active health checking.




Thanks

On Mon, Mar 14, 2016 at 3:07 PM, Kayode Odeyemi <dreyemi(a)gmail.com> wrote:

Stephen, I think this is only possible if you deployed CF unto multiple
DCs. Same configuration, multiple DNSs


On Mon, Mar 14, 2016 at 3:55 AM, Stephen Byers <smbyers(a)gmail.com> wrote:

Agree. But the haproxy fronts the router so any client that is pinned to
the haproxy that is taken down will not make it to the router until its DNS
ttl is reached and it resolves to the other haproxy ip and even that may
not happen if this is a DNS round robin configuration.

I could be missing something?

On Sun, Mar 13, 2016, 8:44 PM Ben R <vagcom.ben(a)gmail.com> wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com>
wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.


Re: cf platform upgrade with 100% uptime for apps

Paul Bakare
 

Stephen, I think this is only possible if you deployed CF unto multiple
DCs. Same configuration, multiple DNSs

On Mon, Mar 14, 2016 at 3:55 AM, Stephen Byers <smbyers(a)gmail.com> wrote:

Agree. But the haproxy fronts the router so any client that is pinned to
the haproxy that is taken down will not make it to the router until its DNS
ttl is reached and it resolves to the other haproxy ip and even that may
not happen if this is a DNS round robin configuration.

I could be missing something?

On Sun, Mar 13, 2016, 8:44 PM Ben R <vagcom.ben(a)gmail.com> wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com> wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.


Re: Can resources of a IDLE application be shared by others?

Stanley Shen <meteorping@...>
 

Thanks for information.

I said "pre-allocated" because after I pushed an APP with 5G memory specified, if I go to Cell VM, and I notice the available memory is 5G less than totally memory via "curl -s http://localhost:1800/state" on Cell VM.

I think overcommit factor is not very suitable in my case, but "resource reclamation and predictive analytics" are quite helpful, and it's a quite useful/flexible mechanism.

Do we have any plan on such cool ideas?

Hi Stanley,

No physical memory is actually pre-allocated, it's simply a maximum used to
determine if the container needs to be killed when it exceeds it. However,
since your VM has some fixed amount of physical memory (e.g. 7.5G), the
operator will want to be able to make some guarantees that the VM doesn't
run a bunch of apps that consume the entire physical memory even if the
apps don't individually exceed their maximum memory limit. This is
especially important in a multi-tenant scenario.

One mechanism to deal with this is an "over-commit factor". This is what
Dan Mikusa's link was about in case you didn't read it yet. If you want
absolute guarantees that the VM will only have work scheduled on it such
that applications cannot consume more memory than what's "guaranteed" to
them by whatever their max memory limits are set to, you'll want an
overcommit factor on memory of 1. An overcommit factor of 2 means that on
a 7.5G VM, you could allocate containers whose sum total of their max
memory limits was up to 15G, and you'd be fine as long as you can trust the
containers to not consume, in total, more than 7.5G of real memory.

The DEA architecture supports setting the overcommit factors, I'm not sure
whether Diego supports this (yet).

The two concepts Deepak brings up, resource reclamation and predictive
analytics, are both pretty cool ideas. But these are not currently
supported in Cloud Foundry.

Best,
Amit

On Thu, Mar 10, 2016 at 7:54 AM, Stanley Shen <meteorping(a)gmail.com&gt; wrote:


Re: cf platform upgrade with 100% uptime for apps

Stephen Byers <smbyers@...>
 

Agree. But the haproxy fronts the router so any client that is pinned to
the haproxy that is taken down will not make it to the router until its DNS
ttl is reached and it resolves to the other haproxy ip and even that may
not happen if this is a DNS round robin configuration.

I could be missing something?

On Sun, Mar 13, 2016, 8:44 PM Ben R <vagcom.ben(a)gmail.com> wrote:

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben


On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com> wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.


Re: cf platform upgrade with 100% uptime for apps

Vik R <vagcom.ben@...>
 

I think one (or two) of the routers help in this situation even if one
haproxy is out of service.

Ben

On Sun, Mar 13, 2016 at 6:32 PM, Stephen Byers <smbyers(a)gmail.com> wrote:

Will that solve the problem? BOSH will only take one haproxy out of
service at a time but those clients that resolved the DNS name to the IP of
the haproxy that is taken out of service for upgrade will be impacted,
correct?

Thanks

On Sun, Mar 13, 2016, 8:25 PM Amit Gupta <agupta(a)pivotal.io> wrote:

In your case, 2 HAProxys with DNS configured to point at both.