Date   

Re: Droplets and Stacks

Noburou TANIGUCHI
 

Hi Colin,

I'm sorry I can't read the two articles because of "Error establishing a
database connection".

http://www.cloudcredo.com/a-droplet-of-value/
http://www.cloudcredo.com/stacks-of-problems/
Is it just me?



Colin Humphreys wrote
Hi All,

I wrote a couple of articles about droplets and stacks.

http://www.cloudcredo.com/a-droplet-of-value/

http://www.cloudcredo.com/stacks-of-problems/

The droplet post is fairly self-explanatory, and enabling the choice of
shipping droplets or source is well on the way in Cloud Foundry
development.

I feel our story around stacks is far less complete. It seems to be an
overloaded concept inherited from Heroku and the contract with the stack
seems to cause issues for both app and buildpack developers.

I'd like to open the discussion on what the future should be for stacks,
or
if you think they're perfect as they are.

Cheers,
Colin

CloudCredo Cheerleader

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




-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Droplets-and-Stacks-tp946p1076.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: 答复: Garden is Moving!

Jack Cai
 

Cool. This a great move.

Jack


On Tue, Aug 4, 2015 at 4:58 AM, Tangshengjun (A) <tangshengjun(a)huawei.com>
wrote:

There is an sentence on my office wall, said: “You will never tire of
looking at the Garden”, personally, I like Warden because it let me know
very detail implement when construct a Container.(although this makes
Warden a little primitive compare to Docker).



Farewell, Garden-Linux, Thank you very much. (there is a word “pull down”
in the article, I think it means Goodbye, sorry if misunderstand for my
poor EnglishJ)




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

唐盛军
华为技术有限公司 Huawei Technologies Co., Ltd.
[image: Company_logo]

Phone: 13777864354
Fax:
Mobile: 13777864354
Email: tsjsdbd(a)huawei.com
地址:杭州市江虹路410号华为基地 邮编:310052
Huawei Technologies Co., Ltd.
JiangHong road 410,BingJiang District,Hangzhou 310052, P.R.China
http://www.huawei.com
------------------------------

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from
HUAWEI, which
is intended only for the person or entity whose address is listed above.
Any use of the
information contained herein in any way (including, but not limited to,
total or partial
disclosure, reproduction, or dissemination) by persons other than the
intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!

*发件人:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *代表 *Gwenn Etourneau
*发送时间:* 2015年8月3日 9:14
*收件人:* Discussions about Cloud Foundry projects and the system overall.
*主题:* Re: [cf-dev] Garden is Moving!



Awesome, yes it's a big win for everyome and according to Solomonstre
tweet is just natural things

"@chanezon <https://twitter.com/chanezon/> @wattersjames
<https://twitter.com/wattersjames/> @charlesfitz
<https://twitter.com/charlesfitz/> @diogomonica
<https://twitter.com/diogomonica/> @justinjsmith
<https://twitter.com/justinjsmith/> nice! We did runC partly based on
cloudfoundry feedback."



On Sat, Aug 1, 2015 at 12:47 PM, James Bayer <jbayer(a)pivotal.io> wrote:

thanks julz for summarizing all of this. i'm very excited that cloud
foundry will be able to use runc and contribute to the open container
initiative. by joining with the other members and working together, we'll
be able to use the same base runtime as docker, coreos and others. we'll
also preserve the flexibility to do the innovations and user experience we
want for CF users above the core container runtime. this seems like a big
win for everyone.



On Fri, Jul 31, 2015 at 3:06 PM, Deepak Vij (A) <deepak.vij(a)huawei.com>
wrote:

Hi Julz & the whole garden team, it is great to know that Garden Container
is moving towards Open-Container-Project (OCP) App-Container
specifications. Great work.

I am hoping that down the road we will also see App Container Pods
(Co-locating Containers) capabilities enabled as well. A pod is a list of
apps that will be launched together inside a shared execution context (
single Unit of Deployment, migration etc. sharing IP address Space, Storage
etc.). Kubernetes also supports similar Pod concept.

Pod architecture allows me to enable design patters such as Sidecar,
Ambassador & Adaptor. All of this is really helpful from the standpoint of
refactoring the core telecom capabilities such as vEPC (virtual Evolved
packet Core network) and many more NFV/telecom capabilities - Network
Function Virtualization.

- Deepak Vij

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

Message: 1
Date: Fri, 31 Jul 2015 18:49:25 +0100
From: Julz Friedman <julz.friedman(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Garden is Moving!
Message-ID:
<
CAHfHzfOrrdEn_QBZwnoq7qQtXbBW1K2fk-NbbqgLSKaacMcPsw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi cf-dev, I?d like to discuss some exciting changes the Garden team is
planning to make in Diego?s container subsystem, Garden.

Garden? What?s that?

Garden is the containerisation layer used by Diego. Garden provides a
platform-neutral, lightweight container abstraction that can be backed by
multiple backends (most importantly, a Linux backend and a Windows
backend). Currently the linux backend is based on our own code which
evolved from Warden and which has been used to power Cloud Foundry for many
years. Garden enables diego to support buildpack apps and docker apps (via
the Linux backend) and windows apps (via the Windows backend).

So: What's changing?

We're planning to use runC [1] as the Linux backend for Garden.

Why?

Garden has always been an unopinionated container system - we like to have
the opinionation happen at the higher levels (i.e. in Diego). Docker, on
the other hand, is quite an opinionated container technology: it tightly
couples containerisation and the user experience (which is one of the
reasons docker is so great to use, I?m not knocking docker here!).
Recently, docker and others (including IBM and Pivotal) have come together
under the Open Container Initiative to spin out an unopinionated common
containerisation runtime, ?runC?, which gives us a fantastic opportunity to
be part of this community while letting us ensure we can retain the
flexibility required by our broader use cases. RunC is a reference
implementation of the Open Container spec, which means both Docker and
Cloud Foundry will be running the same code, and both Docker and Cloud
Foundry apps will be using Open Containers.

Using runC as the garden backend has two major advantages. Firstly it lets
us reuse some awesome code and be part of the Open Container community.
Secondly it means CF applications will be using not only the same kernel
primitives as docker apps (as they already are today), but also the exact
same runtime container engine. This will minimise incompatibility for our
docker lifecycle and result in a first class experience for users, as well
as letting us reuse and contribute back to a great open-source code base.
We have some remaining features in the Garden Linux backend that we?d like
to see in RunC, but we?re excited to engage with the Open Container
community to close these gaps.

What about regular CF buildpack apps and the other nice features of Garden?

Moving to runC gives us all the above advantages without compromising our
ability to also deliver the buildpack-based platform-centric workflows that
make CF great. We will retain the garden abstraction to make it easy for
Diego to support both buildpack apps, windows apps and docker apps, and we
will maintain a small layer above runC to manage the containers, pull down
native warden and docker root filesystems, let us perform live upgrades and
so on.

Why not use the full docker-engine as the backend?

Docker-engine has both more capabilities than we need at the layer Garden
runs and different opinions than Cloud Foundry currently requires. This
means it?s harder for us to maintain (because it?s larger and does more
stuff), harder for us to contribute to (for similar reasons) and for some
of our use cases (particularly with Diego?s more generic lifecycles) we?d
have to actively work around things that would be quite easy to expose if
we use runC directly (for example docker-engine intentionally doesn?t
support signalling `docker exec`ed processes, which is required by
Diego[2]).

Most of the reasons you might want to use docker-engine (e.g. being able to
?docker push?) make much more sense to expose at the platform level in a
multi-host environment (you want to push to the cluster, not a single host)
or need to be integrated with multi-tenancy (which again should happen at
the platform level - you need access control on storage and networks to
integrate with the rest of a multi-tenant platform). For these reasons
Cloud Foundry prefers to implement many features at the Diego layer whereas
docker-engine implements some of these capabilities at the host layer. As
the capabilities for running distributed applications in containers
continue to evolve, CF prefers the flexibility to implement the opinions of
our developers and community for areas like networking and storage even if
those may differ from other orchestration solutions like docker-engine, and
in turn Garden needs to retain that flexibility.

We also note that many new features have come to runC first (e.g. criu
snapshot restore and - importantly for us - user namespaces were first
available in runC before being added to docker-engine; at the time of
writing these are still not fully available in docker-engine). We?d like to
be able to consume new features as they come out in runC, rather than
waiting for them to make it in to docker-engine. We also hope to be
contributing new features of our own and this is much easier for us to
accomplish against the smaller surface area of runC, and within the open
context of the Open Container Initiative.

When will this happen?

Our first goal is completing the work of improving Garden?s security
profile around supporting docker apps in production, we're about two weeks
out from this according to Tracker and plan to do this with the current
code. As soon as we hit this milestone we plan to shift our focus to runC.
We have an initial prototype working and will iterate quickly to bring this
to production quality and switch over when we feel confident.


I?m excited to hear the community?s views and input on this, so let us know

what you think!


Thanks!

- Julz, on behalf the Garden Team

[1]: https://github.com/opencontainers/runc

[2]: https://github.com/docker/docker/pull/9167,
https://github.com/docker/docker/pull/9402

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





--

Thank you,



James Bayer


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



Re: Soliciting feedback on a UX change for route services

Guillaume Berche
 

Thanks a lot Shannon.

I agree, the proposed "app activity/inactivity" measurements fed by router
service intercepted traffic could be averaged to average "route
activity/inactivity" for all apps that were mapped to these routes in a
given period. A bit more complex data processing, but doable if app_id
is'nt provided in routed traffic.

This brings me to two other corner cases for the route service specs:

1- ensure that the gorouter will indeed route traffic to route service even
if there are zero app instances available in all apps mapped to a route, or
if all mapped apps are in the stopped state.

2- As I understand current specs, route services don't currently get
notified when they get bound or unbound to a route. They can only discover
new routes their receive when they receive incoming traffic. I wonder
whether notifying route services through a variation of the binding [1] /
unbinding endpoint was considered. Some route service would benefit from
being notified in advance that traffic for new routes will arrive soon, or
will stop happening. For example, a caching route service might purge
caches associated with a route when being notified that it was unmapped
from that route. This might also be a nice way to support route services
implemented by external load balancer that Mike Y. was proposing.

Thanks again for the great feedback you provided in the autosleep design
doc.

Guillaume.

[1] http://docs.cloudfoundry.org/services/api.html#binding

On Tue, Aug 4, 2015 at 3:38 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Thank you for the interesting use case for route services, Guillaume! A
mechanism to halt idle apps does seem valuable.

I've recorded your request for including app_id and will keep an ear out
for other use cases that could leverage it, despite being out of date or
incorrect.

In the meantime, couldn't your service put to sleep all apps that share a
route, if no requests for the route are received in a given period?

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jul 30, 2015 at 3:23 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Shannon for your feedback.

I understand there is a small window into which the pre-determined app
might not exist anymore (e.g. during blue/green deployment traffic shift).
The default behavior you're suggesting (picking a different app instance)
seems sensible to me, even though it will lead to seldom false associations.

We can imagine to refine this behavior in a second step, when use-cases
of router service being sensitive to false associations become more
frequent: allow the gorouter to comply to hints provided by the route
service to tune the behavior in case the pre-determined app might not exist
anymore. The router service could for instance augment the router-service
HTTP header with hints fields:


- missing-app-policy with one of the following values:
- reassign-app: the router transparently route the request to
another app(default)
- reject: reject the request (e.g. 502 status code with a json
body providing the currently available app ids). In this case the route
service may reemit the request to the gorouter, specifying the second param
below
- route-to-app override the predetermined app to which to route
the traffic


I'm currently planning to implement a route-service that would leverage
the app_id in the request in an "autosleep", see [1]. The "reassign-app"
default policy seems fine as a first step. The reject policy would be a
nice refinement to close this corner case.

[1]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

Guillaume.

On Sat, Jul 18, 2015 at 12:08 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Guillaume,

Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s
rate-limiting

Besides, If the MVP does not include support for multiple route
services, route service implementers might be able to experiment with
supporting arbitrary params as a way for users to specify fine grain
options, possibly ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs
that end up being associated with the app that receive the associated
traffic (e.g. cache hit or cache miss for a specific incoming request).
With route services being associated to routes (and not being bound to app
instances anymore), I'd like to re-iterate the suggestion I made in the
design document (on Feb 17) to have the gorouter include the app_id in the
headers of the signed request it sends to route service(s). This will allow
for a route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.


On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io>
wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases
do you have in mind for associating a service instance with a route, but
not providing a forwarding address?

I would imagine you could bind a service to a route any time you want
to customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should
be made public facing. (Would require a broker to orchestrate stuff
outside of CF DNS, applying DoS security profiles to the route, force ssl
on the front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as
a proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect
on a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.

Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.

It also occurs to me that the only time chain ordering of route
services seems to be an issue is in the case of a proxy url. So, it is
unfortunate that I'd be limited to binding only one route service when I
may want to apply all kinds of functionality to a route not implemented as
a proxy because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a
generic solution to the kind of functionality applied above and that you
may not want to distract from the basic Route Services MVP to accommodate
these types of use cases. I guess I can only hope that you keep the
concept of applying non proxy functionality to a route in mind as you move
through your MVP.

Mike

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

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

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

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


Re: V3 API Style Guide

Dieu Cao <dcao@...>
 

At this point the style guide is in draft form. One pair had drafted this
to document the patterns that we've fleshed out so far in the v3 cc API.
We'll be iterating on it this week as other team members have a chance to
review for correctness so it is subject to fluidity.
Community comment via issues/prs on that repo is also welcome.

-Dieu
CF CAPI PM

On Tue, Aug 4, 2015 at 6:19 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

I noticed that the new CAPI team has published a v3 API style guide for
folks to comment on [1].

I don't know how much the CAPI team expects it to change but it's probably
worthwhile for those who have built their own client libraries or Web UI's
to review.

[1]: https://github.com/cloudfoundry/cc-api-v3-style-guide

--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: Service Discovery on CF for Custom buildpack

Amit Kumar Gupta
 

Hi Ronak,

The system etcd and consul should not be used for application service
discovery. There are various approaches to doing service discovery with cf
applications, but no solution out of the box. The staging process should
generally been seen as an implementation detail of a running application,
it is typically not an appropriate place for a hook for service
registration. Service discovery and registration should be done at
runtime. The typical solution involves binding multiple applications to a
common service instance, like a database or message queue. In the future,
there may be an etcd or consul service; there may also be some sort of
service discovery built into the CF routing layer at some point.

Best,
Amit

On Mon, Aug 3, 2015 at 11:57 PM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:

Hi,

We are trying to introduce a new component that will work together
with our custom buildpack to expose and secure APIs (you can think of
it as a Micro Gateway). In order to configure those gateways a new
webbased UI (our new web component) will be introduced that should
know about all our custom buildpack applications that are pushed to CF
and expose APIs. Ideally speaking every time an app gets pushed to CF
it should also notify the webbased UI that a new API is available
(something like service discovery).

I know CF has Etcd component which is used for Service Discovery but can
we use it to push application cluster details to this custom webbased UI ?

The other part of the question is that the webbased UI will create a
new app that will in turn expose an API as well. That new app will be
exposed to the outside world and route traffic to the pushed
application (our buildpack apps) offcourse after applying some
policies. Would that be possible to do with CF?

Can we setup a proxy for such requirement? which component of CF has to
be configured?


Thanks,
Ronak


Re: AWS deployment manifest with HAproxy

Amit Kumar Gupta
 

Hmm,

On your ha_proxy_z1 VM, what is in `ls /var/vcap/monit/jobs/*.monitrc`?

Amit

On Tue, Aug 4, 2015 at 10:08 AM, Christopher Piraino <cpiraino(a)pivotal.io>
wrote:

Stephen,

The haproxy monit file depends on the consul_agent process if the property
"cc.allow_app_ssh_access" is defined.[1]

What does your manifest look like for the haproxy job? It should be
something to the effect of:

```
- name: ha_proxy_z1
...
templates:
- name: haproxy
name: consul_agent
```

[1]:
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/haproxy/monit#L7

On Tue, Aug 4, 2015 at 2:57 AM, Stephen Knight <sknight(a)pivotal.io> wrote:

Thanks guys!

I am able to get to the deployment phase now, the VM's bind at least but
I hit this error:

Started preparing configuration > Binding configuration. Done (00:00:15)


Started updating job ha_proxy_z1 > ha_proxy_z1/0 (canary). Failed: Action
Failed get_task: Task 6d7541c8-0476-4177-436b-c1fc22c9c581 result:
Applying: Reloading jobSupervisor: Failed to reload monit:
before=1438680699 after=1438680699 (00:01:33)


Error 450001: Action Failed get_task: Task
6d7541c8-0476-4177-436b-c1fc22c9c581 result: Applying: Reloading
jobSupervisor: Failed to reload monit: before=1438680699 after=1438680699


When I do a "bosh ssh ha_proxy_z1/0" and try to run "monit summary" I
get presented with this error:


root(a)9b91249d-9700-4004-9706-f4d4f793206e:/var/vcap/monit# monit summary

monit: Error: Depend service 'consul_agent' is not defined in the control
file


I've checked my manifest has a specification for consul, as the default
it is there. But should I be defining something? My Consul parts look like
this:


consul:

agent:

log_level: null

servers:

lan: []

On Mon, Aug 3, 2015 at 11:56 AM, CF Runtime <cfruntime(a)gmail.com> wrote:

Also Stephen, the templates by default attempt to use an ELB named
cfrouter. So if you want to try to use an ELB again, just create one with
that name and when you deploy BOSH should connect it to your routers.

In either case, you shouldn't need to worry about the DEAs, those are
behind the routers. The only thing the load balancer talks to are the
routers.

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 12:50 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi Stephen,

You generally never want to alter the manifest templates unless you're
making a PR with general improvements to the templates. Customizing your
own deployment should be done either within your stub(s), or modifying your
spiff-generated manifest with your desired changes before deploying.

Try making the following additions to your stub:

jobs:
- name: ha_proxy_z1
instances: 1
networks:
- name: ha_proxy_z1_elastic
static_ips: [YOUR_STATIC_IP_HERE]
- name: cf1
default: [gateway, dns]

networks:
- name: ha_proxy_z1_elastic # Add this network to the existing cf1 and
cf2 networks, don't remove those
type: vip

resource_pools:
- name: router_z1
cloud_properties:
elbs: []
- name: router_z2
cloud_properties:
elbs: []

See if that works for you. You will need to make sure that you've
configured DNS records so that your system domain and app domains point to
YOUR_STATIC_IP for ha_proxy. If you're already using
YOUR_STATIC_IP.xip.io as your system and apps domains, then this will
work without having to create any DNS records.

Best,
Amit

On Sun, Aug 2, 2015 at 11:11 PM, Stephen Knight <sknight(a)pivotal.io>
wrote:

Hi All,

The default manifests for CF seem to use ELB's on AWS for load
balancing, I am still getting to grips with manifests so in the meantime,
can anyone tell me how you would insert an HAproxy with an elastic IP into
a standard manifest?

And should it go in the stub or in the cf-infrastructure-xxx.yml file?
As well as ensuring that the DEA pool goes behind the LB pair?

I'm using spiff as per the deployment instructions on Github, filling
out the spec/fixtures/stub but I still can't get HAproxy to deploy despite
trying to munge something together from other manifests.

Thx
Stephen

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

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

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


Re: AWS deployment manifest with HAproxy

Christopher Piraino <cpiraino@...>
 

Stephen,

The haproxy monit file depends on the consul_agent process if the
property "cc.allow_app_ssh_access"
is defined.[1]

What does your manifest look like for the haproxy job? It should be
something to the effect of:

```
- name: ha_proxy_z1
...
templates:
- name: haproxy
name: consul_agent
```

[1]:
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/haproxy/monit#L7

On Tue, Aug 4, 2015 at 2:57 AM, Stephen Knight <sknight(a)pivotal.io> wrote:

Thanks guys!

I am able to get to the deployment phase now, the VM's bind at least but I
hit this error:

Started preparing configuration > Binding configuration. Done (00:00:15)


Started updating job ha_proxy_z1 > ha_proxy_z1/0 (canary). Failed: Action
Failed get_task: Task 6d7541c8-0476-4177-436b-c1fc22c9c581 result:
Applying: Reloading jobSupervisor: Failed to reload monit:
before=1438680699 after=1438680699 (00:01:33)


Error 450001: Action Failed get_task: Task
6d7541c8-0476-4177-436b-c1fc22c9c581 result: Applying: Reloading
jobSupervisor: Failed to reload monit: before=1438680699 after=1438680699


When I do a "bosh ssh ha_proxy_z1/0" and try to run "monit summary" I get
presented with this error:


root(a)9b91249d-9700-4004-9706-f4d4f793206e:/var/vcap/monit# monit summary

monit: Error: Depend service 'consul_agent' is not defined in the control
file


I've checked my manifest has a specification for consul, as the default it
is there. But should I be defining something? My Consul parts look like
this:


consul:

agent:

log_level: null

servers:

lan: []

On Mon, Aug 3, 2015 at 11:56 AM, CF Runtime <cfruntime(a)gmail.com> wrote:

Also Stephen, the templates by default attempt to use an ELB named
cfrouter. So if you want to try to use an ELB again, just create one with
that name and when you deploy BOSH should connect it to your routers.

In either case, you shouldn't need to worry about the DEAs, those are
behind the routers. The only thing the load balancer talks to are the
routers.

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 12:50 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi Stephen,

You generally never want to alter the manifest templates unless you're
making a PR with general improvements to the templates. Customizing your
own deployment should be done either within your stub(s), or modifying your
spiff-generated manifest with your desired changes before deploying.

Try making the following additions to your stub:

jobs:
- name: ha_proxy_z1
instances: 1
networks:
- name: ha_proxy_z1_elastic
static_ips: [YOUR_STATIC_IP_HERE]
- name: cf1
default: [gateway, dns]

networks:
- name: ha_proxy_z1_elastic # Add this network to the existing cf1 and
cf2 networks, don't remove those
type: vip

resource_pools:
- name: router_z1
cloud_properties:
elbs: []
- name: router_z2
cloud_properties:
elbs: []

See if that works for you. You will need to make sure that you've
configured DNS records so that your system domain and app domains point to
YOUR_STATIC_IP for ha_proxy. If you're already using
YOUR_STATIC_IP.xip.io as your system and apps domains, then this will
work without having to create any DNS records.

Best,
Amit

On Sun, Aug 2, 2015 at 11:11 PM, Stephen Knight <sknight(a)pivotal.io>
wrote:

Hi All,

The default manifests for CF seem to use ELB's on AWS for load
balancing, I am still getting to grips with manifests so in the meantime,
can anyone tell me how you would insert an HAproxy with an elastic IP into
a standard manifest?

And should it go in the stub or in the cf-infrastructure-xxx.yml file?
As well as ensuring that the DEA pool goes behind the LB pair?

I'm using spiff as per the deployment instructions on Github, filling
out the spec/fixtures/stub but I still can't get HAproxy to deploy despite
trying to munge something together from other manifests.

Thx
Stephen

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

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

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


Re: CF-Abacus: incubation and inception meeting coming soon

Devin Davis <ddavis@...>
 

Hi All,

Due to additional attendees, we've shifted to a larger, new conference
room. This meeting will now take place in 14E. Please let me know if you
have any questions on that.

Best,
Devin


On Thu, Jul 30, 2015 at 2:31 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Here is pertinent information for CF-Abacus inception meeting next week.

Invites to those interested is sent. If you want to attend physically then ping me or Devin from CFF on CC: since
we need to add you to the list for the WeWork building.

---------
*Date:* Wednesday August 5th, 2015

*Time:* 9:30am - 12:30pm PDT

*Location:*
CloudFoundry Foundation Offices @ WeWork SF on Mission

WeWork
535 Mission St., *19th floor *
San Francisco, CA

*Room:* 19B

*Call info:*
IBM AT&T Conference Call
USA 888-426-6840; 215-861-6239 | Participant code: 1985291
All other countries, find number here: http://goo.gl/RnNfc1

*Hangout:* TBD
---------

Best,

------
dr.max
ibm cloud labs
silicon valley, ca
maximilien.org


*Michael Maximilien/Almaden/IBM*

07/29/2015 11:35 AM
To
"cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
cc
Subject
Re: CF-Abacus: incubation and inception meeting coming soon




Quick update on inception meeting.

To accommodate our friends and colleagues from Europe who would like to
attend, let's plan to move the meeting to 10a to 12:30p with the option of
lunch after at nearby location in SF.

Unless I hear any objections I will send the invites to those interested
parties who have already contacted me and confirm details here.

If you want to attend (local or remote) please remember to reply to me
with email so I can add you to invite list.

Best,

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

On Jul 28, 2015, at 10:15 PM, Michael Maximilien <*maxim(a)us.ibm.com*
<maxim(a)us.ibm.com>> wrote:

Hi, all,

Now that CF-Abacus is officially an incubator under the guidance of the
CFF, here are some quick updates:

1. The project official github moved to:

*https://github.com/cloudfoundry-incubator/cf-abacus*
<https://github.com/cloudfoundry-incubator/cf-abacus>

2. We are planning an inception next week Wednesday from 2p to 5p in SF.

We invite everyone interested to take a look at the repo, provide
feedback, or better, join us at the inception meeting. The location will be
either CFF, Pivotal, or IBM. All within a few blocks in downtown SF.

We will also have Google hangout and conference call for remote
participants.

If interested, then respond to me directly so I add you to the invite list.

Thanks and talk next week. Best,

CF-Abacus team

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone


--
*Devin Davis* : Senior Director of Marketing & Operations : Cloud Foundry
Foundation
510.508.7113 : ddavis(a)cloudfoundry.org


Re: AWS deployment manifest with HAproxy

CF Runtime
 

Hi Stephen,

The consul.agent.servers.lan array should be populated with the static IPs
of every consul server job you have deployed.
That being said, none of this will work if you have not colocated a
consul_agent on the various jobs that require it. Make sure that you have a
consul agent in the job templates for your ha_proxy jobs.

Zak and Joseph

On Tue, Aug 4, 2015 at 2:57 AM, Stephen Knight <sknight(a)pivotal.io> wrote:

Thanks guys!

I am able to get to the deployment phase now, the VM's bind at least but I
hit this error:

Started preparing configuration > Binding configuration. Done (00:00:15)


Started updating job ha_proxy_z1 > ha_proxy_z1/0 (canary). Failed: Action
Failed get_task: Task 6d7541c8-0476-4177-436b-c1fc22c9c581 result:
Applying: Reloading jobSupervisor: Failed to reload monit:
before=1438680699 after=1438680699 (00:01:33)


Error 450001: Action Failed get_task: Task
6d7541c8-0476-4177-436b-c1fc22c9c581 result: Applying: Reloading
jobSupervisor: Failed to reload monit: before=1438680699 after=1438680699


When I do a "bosh ssh ha_proxy_z1/0" and try to run "monit summary" I get
presented with this error:


root(a)9b91249d-9700-4004-9706-f4d4f793206e:/var/vcap/monit# monit summary

monit: Error: Depend service 'consul_agent' is not defined in the control
file


I've checked my manifest has a specification for consul, as the default it
is there. But should I be defining something? My Consul parts look like
this:


consul:

agent:

log_level: null

servers:

lan: []

On Mon, Aug 3, 2015 at 11:56 AM, CF Runtime <cfruntime(a)gmail.com> wrote:

Also Stephen, the templates by default attempt to use an ELB named
cfrouter. So if you want to try to use an ELB again, just create one with
that name and when you deploy BOSH should connect it to your routers.

In either case, you shouldn't need to worry about the DEAs, those are
behind the routers. The only thing the load balancer talks to are the
routers.

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 12:50 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi Stephen,

You generally never want to alter the manifest templates unless you're
making a PR with general improvements to the templates. Customizing your
own deployment should be done either within your stub(s), or modifying your
spiff-generated manifest with your desired changes before deploying.

Try making the following additions to your stub:

jobs:
- name: ha_proxy_z1
instances: 1
networks:
- name: ha_proxy_z1_elastic
static_ips: [YOUR_STATIC_IP_HERE]
- name: cf1
default: [gateway, dns]

networks:
- name: ha_proxy_z1_elastic # Add this network to the existing cf1 and
cf2 networks, don't remove those
type: vip

resource_pools:
- name: router_z1
cloud_properties:
elbs: []
- name: router_z2
cloud_properties:
elbs: []

See if that works for you. You will need to make sure that you've
configured DNS records so that your system domain and app domains point to
YOUR_STATIC_IP for ha_proxy. If you're already using
YOUR_STATIC_IP.xip.io as your system and apps domains, then this will
work without having to create any DNS records.

Best,
Amit

On Sun, Aug 2, 2015 at 11:11 PM, Stephen Knight <sknight(a)pivotal.io>
wrote:

Hi All,

The default manifests for CF seem to use ELB's on AWS for load
balancing, I am still getting to grips with manifests so in the meantime,
can anyone tell me how you would insert an HAproxy with an elastic IP into
a standard manifest?

And should it go in the stub or in the cf-infrastructure-xxx.yml file?
As well as ensuring that the DEA pool goes behind the LB pair?

I'm using spiff as per the deployment instructions on Github, filling
out the spec/fixtures/stub but I still can't get HAproxy to deploy despite
trying to munge something together from other manifests.

Thx
Stephen

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

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

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


Re: CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

CF Runtime
 

The app you are pushing is not being detected as a valid Python app by the
buildpack. The buildpack expects there to be a setup.py file in the root of
the app if you do not provide a requirements.txt. The easiest way around
this is simply to create a empty requirements.txt in your app directory.


Joseph & Zak

On Tue, Aug 4, 2015 at 4:22 AM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:

Thanks Joseph, it was really helpful.

I am pushing a python app and I can see a zip file for a python
buildpack when I did - 'cf buildpacks'. But its still cf push is not
able to identify python_buildpack.

Then I gave buildpack: python_buildpack in my manifest.yml it gave me
below error

--------------------------------------------------------------------
2015-08-04T10:45:24.93+0000 [API/0] OUT Created app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:25.40+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
({"route"=>"5ff72553-4031-4747-ad27-9102f00a3d3a"})
2015-08-04T10:45:31.78+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:32.78+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:45:32.88+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:45:33.47+0000 [STG/0] OUT Staging failed: An
application could not be detected by any available buildpack
2015-08-04T10:45:33.48+0000 [STG/0] ERR
2015-08-04T10:45:33.62+0000 [API/0] ERR encountered error: An app
was not successfully detected by any available buildpack
2015-08-04T10:51:17.31+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"https://github.com/cloudfoundry/buildpack-python.git",
"environment_json"=>"PRIVATE DATA HIDDEN"})
2015-08-04T10:51:27.64+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:51:28.84+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:51:29.86+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:51:29.94+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:51:30.01+0000 [STG/0] ERR Cloning into
'/tmp/buildpacks/buildpack-python'...
2015-08-04T10:51:30.98+0000 [STG/0] OUT Submodule
'compile-extensions'
(https://github.com/cloudfoundry-incubator/compile-extensions.git)
registered for path 'compile-extensions'
2015-08-04T10:51:31.02+0000 [STG/0] ERR Cloning into
'compile-extensions'...
2015-08-04T10:51:31.36+0000 [STG/0] OUT Submodule path
'compile-extensions': checked out
'ce9345a9a6e7b00266194cadd18dbef37e791a7b'
2015-08-04T10:51:31.48+0000 [STG/0] OUT -------> Buildpack version
1.5.0
2015-08-04T10:51:31.51+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:51:36.34+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:51:36.67+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:51:36.70+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:51:36.86+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T10:56:18.81+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T10:56:24.10+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:56:25.24+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:56:26.26+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:56:26.36+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:56:26.68+0000 [STG/0] OUT -------> Buildpack version
1.4.0
2015-08-04T10:56:26.71+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:56:31.21+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:56:31.99+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T10:56:31.99+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T10:56:32.43+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:56:32.46+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:56:32.60+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T11:00:56.58+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T11:01:01.91+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T11:01:03.53+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T11:01:04.55+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T11:01:04.63+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T11:01:04.94+0000 [STG/0] OUT -------> Buildpack version
1.4.0
2015-08-04T11:01:04.98+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T11:01:09.55+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

If I gave python buildpack url of git as buildpack: then
it gives below error

2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

I am just pushing this simple sample of python -

https://github.com/ihuston/python-cf-examples/tree/master/01-simple-python-app


Some messages being delayed on the mailing list.

Chip Childers <cchilders@...>
 

Hi all,

After the migration to the new mailing list system last night, it appears
that some messages are being held for moderation. If you get an auto-reply
saying that your email is held for moderation, rest assured that I'm
releasing them as soon as I can.

I've opened an issue with the IT team to figure out why this is happening.
In the meantime, please be patient.

-chip

Chip Childers | VP Technology | Cloud Foundry Foundation


Re: Application Configuration Management

James Bayer
 

CF's built-in app configuration is typically done with environment
variables or user-provided-services, but both of those are static and if
they change do not automatically update already running app instances with
new values.

if you want something that makes config changes available to already
running instances of an application, then something like Eureka, Consul,
etc that implements the CF Service interface would be a very natural way of
doing this.

On Tue, Aug 4, 2015 at 2:44 AM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:

Basically I am looking for - CF Integration with any application
configuration servers(like Sping-cloud-config-server) to allow central
management of application settings for Cloud Foundry apps.

On Tue, Aug 4, 2015 at 2:18 PM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:
Hi,

I need some help around application configuration management in CF,
using something like a Zookeeper or Doozered where I can manage all my
pushed application configuration details (app-url, port etc).

So if I make changes to any app configuration through lets say
zookeeper it should be taken care by app on cf push before getting
staged OR on cf restart app.

Can you please point me to some blog/sample to test it?

Thanks,
Ronak


--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com
--
Thank you,

James Bayer


Re: Php build pack offline version availability

Mike Dalessio
 

Hi Amishi,

The PHP buildpack is emitting misleading log messages here. In reality, if
the buildpack is built in "cached" (a.k.a. "offline") mode, then it will
not retrieve any of the binary dependencies from the internet. It will
either retrieve them from the buildpack itself, or fail.

I've created a bug to address these misleading log messages here:
https://www.pivotaltracker.com/story/show/100516510

In the meantime, if you stage your app in an unconnected environment, I
think you'll see that it retrieves and uses these binaries without
attempting to reach the public internet.

Apologies for the confusion,
-mike


On Mon, Aug 3, 2015 at 1:20 PM, Amishi Shah (amishish) <amishish(a)cisco.com>
wrote:

Hey James,

Thanks for replying.

Yes for the option 1, I did the same thing for the building.

I could see the below on the screen:

AMISHISH-M-91EG:php-buildpack ashah$ BUNDLE_GEMFILE=cf.Gemfile bundle exec
buildpack-packager cached

% Total % Received % Xferd Average Speed Time Time Time
Current

Dload Upload Total Spent Left
Speed

100 36.8M 100 36.8M 0 0 3451k 0 0:00:10 0:00:10 --:--:—
3874k



For the 2nd Option, I uploaded the buildpack just by downloading the
buildpack zip file from
https://github.com/cloudfoundry/php-buildpack/releases.

Thanks,
Amishi Shah

From: James Bayer <jbayer(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday, August 1, 2015 at 7:25 AM
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] Php build pack offline version availability

did you try building it with the "cached" option as referenced in the
readme [1]:

BUNDLE_GEMFILE=cf.Gemfile bundle exec buildpack-packager cached


[1] https://github.com/cloudfoundry/php-buildpack#building

On Fri, Jul 31, 2015 at 5:25 PM, Amishi Shah (amishish) <
amishish(a)cisco.com> wrote:

Hi team,

We are a team at Cisco trying to use the Buildpack for Php-Httpd. We
tried couple of ways,

1. Cloning a git repo and creating the build pack, uploading the same
and using the same for the app.
2. Downloading the readymade build pack available in the github
releases pages and uploading, using the same for the app.

What we are looking for is an offline version, both of these build packs
connects to internet while we are deploying the app.

The details are as below.

AMISHISH-M-91EG:webapp ashah$ cf push

Using manifest file
*/Users/ashah/workspace/Symphony/sample_httpd_app/webapp/manifest.yml*


Using stack *cflinuxfs2*...

*OK*

Creating app *sample_app* in org *admin* / space *skyfall* as *admin*...

*OK*


Using route *sample-app.203.35.248.123.xip.io
<http://sample-app.203.35.248.123.xip.io>*

Binding *sample-app.203.35.248.123.xip.io
<http://sample-app.203.35.248.123.xip.io>* to *sample_app*...

*OK*


Uploading *sample_app*...

Uploading app files from:
/Users/ashah/workspace/Symphony/sample_httpd_app/webapp

Uploading 185, 1 files

Done uploading

*OK*


Starting app *sample_app* in org *admin* / space *skyfall* as *admin*...

-----> Downloaded app package (4.0K)

-------> Buildpack version 4.0.0

Installing HTTPD

Downloaded [
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-2.4.12.tar.gz]
to [/tmp]

Installing PHP

PHP 5.5.27

Downloaded [
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.27/php-5.5.27.tar.gz]
to [/tmp]

Finished: [2015-07-31 21:28:46.871154]


-----> Uploading droplet (51M)


0 of 1 instances running, 1 down

0 of 1 instances running, 1 down

0 of 1 instances running, 1 down

0 of 1 instances running, 1 down

1 of 1 instances running


*App started*



*OK*


App *sample_app* was started using this command `$HOME/.bp/bin/start`


Showing health and status for app *sample_app* in org *admin* / space
*skyfall* as *admin*...

*OK*


*requested state:* started

*instances:* 1/1

*usage:* 64M x 1 instances

*urls:*sample-app.203.35.248.123.xip.io

*last uploaded:* Fri Jul 31 21:28:35 UTC 2015

*stack:* cflinuxfs2

*buildpack:* readymade_httpd_buildpack


*state* *since* *cpu* *memory*
*disk* *details*

*#0* running 2015-07-31 02:29:39 PM 0.0% 40.3M of 64M 136.6M
of 1G


Do we have any offline Php-httpd buildpack available? We want the build
pack which would be sufficient enough and it works even without the
internet connectivity.


Your timely response will be really appreciated.


Thanks,

Amishi Shah

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


--
Thank you,

James Bayer

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


Re: Droplets and Stacks

Mike Dalessio
 

Small correction below:

On Tue, Aug 4, 2015 at 9:52 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Hi Guillaume,

Thanks for asking these questions. Some comments inline.

On Mon, Aug 3, 2015 at 4:35 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Onsi for these precisions.

Similar to Colin's blog question, I'm wondering how much versionning is
currently provided to rootfs and buildpacks. In other words, when a rootfs
(say cflinuxfs2) gets patched (e.g. following CVE such as in [1]), what
support is provided in the platform to identify apps that are still running
an old version of cflinuxfs2 rootfs and require restaging ?
Just to clarify, applications intentionally do NOT require restaging to be
placed onto a new rootfs; a droplet is compatible with all future versions
of a specific rootfs.

When an operator deploys an update to CF with a new rootfs, the DEA VMs
get rolled, and all new application instances (when they come up) are
running on the new rootfs.



Am I right to assume that there will be multiple distinct stack instances
returned by cc api calls such as [3] (with distinct guid but same entity
names) and that stacks are indeed immutable (i.e. the field "updated_at"
will remain null in [4] ) ? Writing a cli plugin to identify apps that need
restaging following a rootfs patch (similar to [2] but for a minor version
of a given stack), would therefore browse all stacks using [5], and order
those with the same name to understand minor patch version ?

I recall similar discussion related to buildpack versionning, where it
was mentionned that the buildpacks were mutable, and the only strategy to
support multiple versions of a buildpack is to append version numbers to
the buildpack names (and rely on priority ordering to have most recent
version be picked first). This has the drawback that an app specifying a
buildpack (e.g. to deambiguate or fix an invalid detect phase) will then
need to manually update the buildpack reference to benefit from new version
(a restaging won't be sufficient).

Is this correct ? On CF instances that don't version buildpack names, how
can users know whether apps were stage a vulrenable version of an offline
buildpack, and require restaging ? Is it by comparing staging date, and
known rootfs patch date ?
It's possible that we're conflating rootfs patches with buildpack patches.
I tried to address rootfs patches above, and so will address buildpack
patches here.

It's possible to determine the buildpack used to stage an app via the CC
API, and in fact versions of the CLI 6.8.0[7] and later will display this
information in the output of `cf app`.
Actually, this is CLI version 6.12.0 and later:
https://github.com/cloudfoundry/cli/releases/tag/v6.12.0



However, that doesn't easily answer the question, "who's running a
vulnerable version of the nodejs interpreter?", or even harder to answer,
"who's running a vulnerable version of the bcrypt npm package?" which I
think is more along the lines of what you're asking.

Currently, there's an exploratory track of work in the Buildpacks public
tracker[8] that includes experimenting with hooks into the Buildpacks
staging life cycle. The intention is to provide extension points for both
application developers and operators to do things like this during staging:

* run static analysis
* run an OSS license scan
* capture the set of dependencies from the application's package manager
(pip, npm, maven, gradle, bundler, composer, etc.)
* look up the set of dependencies in the NIST vulnerability database

There's obviously a long way to go to get here, and it's not obvious how
we can implement some of this shared behavior across buildpacks and within
the buildpack app lifecycle; but we're putting a great deal of thought into
how we might make buildpacks much more flexible and extensible --
systemwide, and without having to fork them.

[7] https://www.pivotaltracker.com/story/show/96147958
[8] https://www.pivotaltracker.com/epic/show/1898760




Is there some improvements planned around this stack and buildpack
versionning by the CAPI team (in tracker [6] seems related, is there
something more specific planned) ?

Thanks,

Guillaume.

[1] https://www.pivotaltracker.com/n/projects/966314/stories/90428236
[2] https://github.com/simonleung8/cli-stack-changer
[3] http://apidocs.cloudfoundry.org/214/apps/get_app_summary.html
[4]
http://apidocs.cloudfoundry.org/214/stacks/retrieve_a_particular_stack.html
[5] http://apidocs.cloudfoundry.org/214/stacks/list_all_stacks.html
[6] https://www.pivotaltracker.com/story/show/91553650

On Wed, Jul 29, 2015 at 7:16 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Hey Colin,

Good stuff. I like to draw a circle around the rootfs, the buildpacks,
the generated droplet, the Task/LRP recipes, and the lifecycle binaries
that run inside containers to stage and launch droplets. You could label
that circle an application lifecycle. Diego currently supports three
application lifecycles and is loosely coupled to those lifecycles:

1. The Linux-Buildpack App lifecycle: includes the cflinuxfs2 rootfs,
the various buildpacks (including a known interface for building custom
buildpacks), the droplets (compiled artifacts guaranteed to run with
cflinuxfs2), two binaries: the builder (performs staging) and the launcher
(runs applications), and code that can convert CC requests for staging and
running instances to Diego Task/LRP recipes.

2. The Windows App lifecycle: includes the notion of a correctly
configured windows environment, a windows-compatible droplet, a builder, a
launcher, and code that can generate Tasks/LRPs. In this context we do not
yet have/need the notion of a buildpack though we are free to add one
later. The builder simply prepares the droplet from source and the
launcher knows how to invoke it.

3. The Docker App lifecycle: has no rootfs as the docker image provides
the entire rootfs, includes a builder to extract docker-metadata and send
it back to CC for safe-keeping, and a launcher to launch the requested
process *and* present it with a standard CF environment. Again,
there's also code that knows how to translate CC requests for a
docker-based application into Tasks and LRPs.

The cool thing is that Diego doesn't care about any of these details and
you are free to construct your own lifecycles and have your own contracts
within each lifecycle. You are spot on in noting that there is an implicit
contract between the buildpacks and the rootfs. I'd go further and say
that that implicit contract covers everything in the lifecycle circle (e.g.
the builder has a contract with the buildpacks, it expects `detect`,
`compile` and `release` to work a certain way, the recipes have a contract
with the builder/launcher, they expect particular command line arguments,
etc...)

This is one reason why we've recently transitioned the ownership of the
rootfs from the runtime team to the buildpack team - as the buildpack team
is best suited to define and maintain the contract between the buildpacks
and the rootfs. Would love to explore ways to make all these contracts
more explicit.

One last point. I didn't use the word "stack" in this e-mail until just
now. I agree that it's an overloaded concept that is easily and often
misunderstood ;)

Onsi

On Wed, Jul 29, 2015 at 9:51 AM, Colin Humphreys <colin(a)cloudcredo.com>
wrote:

Hi All,

I wrote a couple of articles about droplets and stacks.

http://www.cloudcredo.com/a-droplet-of-value/

http://www.cloudcredo.com/stacks-of-problems/

The droplet post is fairly self-explanatory, and enabling the choice of
shipping droplets or source is well on the way in Cloud Foundry development.

I feel our story around stacks is far less complete. It seems to be an
overloaded concept inherited from Heroku and the contract with the stack
seems to cause issues for both app and buildpack developers.

I'd like to open the discussion on what the future should be for
stacks, or if you think they're perfect as they are.

Cheers,
Colin

CloudCredo Cheerleader

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

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

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


Re: Droplets and Stacks

Mike Dalessio
 

Hi Guillaume,

Thanks for asking these questions. Some comments inline.

On Mon, Aug 3, 2015 at 4:35 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Onsi for these precisions.

Similar to Colin's blog question, I'm wondering how much versionning is
currently provided to rootfs and buildpacks. In other words, when a rootfs
(say cflinuxfs2) gets patched (e.g. following CVE such as in [1]), what
support is provided in the platform to identify apps that are still running
an old version of cflinuxfs2 rootfs and require restaging ?
Just to clarify, applications intentionally do NOT require restaging to be
placed onto a new rootfs; a droplet is compatible with all future versions
of a specific rootfs.

When an operator deploys an update to CF with a new rootfs, the DEA VMs get
rolled, and all new application instances (when they come up) are running
on the new rootfs.



Am I right to assume that there will be multiple distinct stack instances
returned by cc api calls such as [3] (with distinct guid but same entity
names) and that stacks are indeed immutable (i.e. the field "updated_at"
will remain null in [4] ) ? Writing a cli plugin to identify apps that need
restaging following a rootfs patch (similar to [2] but for a minor version
of a given stack), would therefore browse all stacks using [5], and order
those with the same name to understand minor patch version ?

I recall similar discussion related to buildpack versionning, where it was
mentionned that the buildpacks were mutable, and the only strategy to
support multiple versions of a buildpack is to append version numbers to
the buildpack names (and rely on priority ordering to have most recent
version be picked first). This has the drawback that an app specifying a
buildpack (e.g. to deambiguate or fix an invalid detect phase) will then
need to manually update the buildpack reference to benefit from new version
(a restaging won't be sufficient).

Is this correct ? On CF instances that don't version buildpack names, how
can users know whether apps were stage a vulrenable version of an offline
buildpack, and require restaging ? Is it by comparing staging date, and
known rootfs patch date ?
It's possible that we're conflating rootfs patches with buildpack patches.
I tried to address rootfs patches above, and so will address buildpack
patches here.

It's possible to determine the buildpack used to stage an app via the CC
API, and in fact versions of the CLI 6.8.0[7] and later will display this
information in the output of `cf app`.

However, that doesn't easily answer the question, "who's running a
vulnerable version of the nodejs interpreter?", or even harder to answer,
"who's running a vulnerable version of the bcrypt npm package?" which I
think is more along the lines of what you're asking.

Currently, there's an exploratory track of work in the Buildpacks public
tracker[8] that includes experimenting with hooks into the Buildpacks
staging life cycle. The intention is to provide extension points for both
application developers and operators to do things like this during staging:

* run static analysis
* run an OSS license scan
* capture the set of dependencies from the application's package manager
(pip, npm, maven, gradle, bundler, composer, etc.)
* look up the set of dependencies in the NIST vulnerability database

There's obviously a long way to go to get here, and it's not obvious how we
can implement some of this shared behavior across buildpacks and within the
buildpack app lifecycle; but we're putting a great deal of thought into how
we might make buildpacks much more flexible and extensible -- systemwide,
and without having to fork them.

[7] https://www.pivotaltracker.com/story/show/96147958
[8] https://www.pivotaltracker.com/epic/show/1898760




Is there some improvements planned around this stack and buildpack
versionning by the CAPI team (in tracker [6] seems related, is there
something more specific planned) ?

Thanks,

Guillaume.

[1] https://www.pivotaltracker.com/n/projects/966314/stories/90428236
[2] https://github.com/simonleung8/cli-stack-changer
[3] http://apidocs.cloudfoundry.org/214/apps/get_app_summary.html
[4]
http://apidocs.cloudfoundry.org/214/stacks/retrieve_a_particular_stack.html
[5] http://apidocs.cloudfoundry.org/214/stacks/list_all_stacks.html
[6] https://www.pivotaltracker.com/story/show/91553650

On Wed, Jul 29, 2015 at 7:16 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Hey Colin,

Good stuff. I like to draw a circle around the rootfs, the buildpacks,
the generated droplet, the Task/LRP recipes, and the lifecycle binaries
that run inside containers to stage and launch droplets. You could label
that circle an application lifecycle. Diego currently supports three
application lifecycles and is loosely coupled to those lifecycles:

1. The Linux-Buildpack App lifecycle: includes the cflinuxfs2 rootfs, the
various buildpacks (including a known interface for building custom
buildpacks), the droplets (compiled artifacts guaranteed to run with
cflinuxfs2), two binaries: the builder (performs staging) and the launcher
(runs applications), and code that can convert CC requests for staging and
running instances to Diego Task/LRP recipes.

2. The Windows App lifecycle: includes the notion of a correctly
configured windows environment, a windows-compatible droplet, a builder, a
launcher, and code that can generate Tasks/LRPs. In this context we do not
yet have/need the notion of a buildpack though we are free to add one
later. The builder simply prepares the droplet from source and the
launcher knows how to invoke it.

3. The Docker App lifecycle: has no rootfs as the docker image provides
the entire rootfs, includes a builder to extract docker-metadata and send
it back to CC for safe-keeping, and a launcher to launch the requested
process *and* present it with a standard CF environment. Again, there's
also code that knows how to translate CC requests for a docker-based
application into Tasks and LRPs.

The cool thing is that Diego doesn't care about any of these details and
you are free to construct your own lifecycles and have your own contracts
within each lifecycle. You are spot on in noting that there is an implicit
contract between the buildpacks and the rootfs. I'd go further and say
that that implicit contract covers everything in the lifecycle circle (e.g.
the builder has a contract with the buildpacks, it expects `detect`,
`compile` and `release` to work a certain way, the recipes have a contract
with the builder/launcher, they expect particular command line arguments,
etc...)

This is one reason why we've recently transitioned the ownership of the
rootfs from the runtime team to the buildpack team - as the buildpack team
is best suited to define and maintain the contract between the buildpacks
and the rootfs. Would love to explore ways to make all these contracts
more explicit.

One last point. I didn't use the word "stack" in this e-mail until just
now. I agree that it's an overloaded concept that is easily and often
misunderstood ;)

Onsi

On Wed, Jul 29, 2015 at 9:51 AM, Colin Humphreys <colin(a)cloudcredo.com>
wrote:

Hi All,

I wrote a couple of articles about droplets and stacks.

http://www.cloudcredo.com/a-droplet-of-value/

http://www.cloudcredo.com/stacks-of-problems/

The droplet post is fairly self-explanatory, and enabling the choice of
shipping droplets or source is well on the way in Cloud Foundry development.

I feel our story around stacks is far less complete. It seems to be an
overloaded concept inherited from Heroku and the contract with the stack
seems to cause issues for both app and buildpack developers.

I'd like to open the discussion on what the future should be for stacks,
or if you think they're perfect as they are.

Cheers,
Colin

CloudCredo Cheerleader

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

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

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


V3 API Style Guide

Matthew Sykes <matthew.sykes@...>
 

I noticed that the new CAPI team has published a v3 API style guide for
folks to comment on [1].

I don't know how much the CAPI team expects it to change but it's probably
worthwhile for those who have built their own client libraries or Web UI's
to review.

[1]: https://github.com/cloudfoundry/cc-api-v3-style-guide

--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

Ronak Agarwal <roagarwa@...>
 

Thanks Joseph, it was really helpful.

I am pushing a python app and I can see a zip file for a python
buildpack when I did - 'cf buildpacks'. But its still cf push is not
able to identify python_buildpack.

Then I gave buildpack: python_buildpack in my manifest.yml it gave me
below error

--------------------------------------------------------------------
2015-08-04T10:45:24.93+0000 [API/0] OUT Created app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:25.40+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
({"route"=>"5ff72553-4031-4747-ad27-9102f00a3d3a"})
2015-08-04T10:45:31.78+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:32.78+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:45:32.88+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:45:33.47+0000 [STG/0] OUT Staging failed: An
application could not be detected by any available buildpack
2015-08-04T10:45:33.48+0000 [STG/0] ERR
2015-08-04T10:45:33.62+0000 [API/0] ERR encountered error: An app
was not successfully detected by any available buildpack
2015-08-04T10:51:17.31+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"https://github.com/cloudfoundry/buildpack-python.git",
"environment_json"=>"PRIVATE DATA HIDDEN"})
2015-08-04T10:51:27.64+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:51:28.84+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:51:29.86+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:51:29.94+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:51:30.01+0000 [STG/0] ERR Cloning into
'/tmp/buildpacks/buildpack-python'...
2015-08-04T10:51:30.98+0000 [STG/0] OUT Submodule
'compile-extensions'
(https://github.com/cloudfoundry-incubator/compile-extensions.git)
registered for path 'compile-extensions'
2015-08-04T10:51:31.02+0000 [STG/0] ERR Cloning into
'compile-extensions'...
2015-08-04T10:51:31.36+0000 [STG/0] OUT Submodule path
'compile-extensions': checked out
'ce9345a9a6e7b00266194cadd18dbef37e791a7b'
2015-08-04T10:51:31.48+0000 [STG/0] OUT -------> Buildpack version 1.5.0
2015-08-04T10:51:31.51+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:51:36.34+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:51:36.67+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:51:36.70+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:51:36.86+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T10:56:18.81+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T10:56:24.10+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:56:25.24+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:56:26.26+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:56:26.36+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:56:26.68+0000 [STG/0] OUT -------> Buildpack version 1.4.0
2015-08-04T10:56:26.71+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:56:31.21+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:56:31.99+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T10:56:31.99+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T10:56:32.43+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:56:32.46+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:56:32.60+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T11:00:56.58+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T11:01:01.91+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T11:01:03.53+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T11:01:04.55+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T11:01:04.63+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T11:01:04.94+0000 [STG/0] OUT -------> Buildpack version 1.4.0
2015-08-04T11:01:04.98+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T11:01:09.55+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

If I gave python buildpack url of git as buildpack: then
it gives below error

2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

I am just pushing this simple sample of python -
https://github.com/ihuston/python-cf-examples/tree/master/01-simple-python-app


Re: CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

Ronak Agarwal <roagarwa@...>
 

Thanks Joseph, it was really helpful.

I am pushing a python app and I can see a zip file for a python
buildpack when I did - 'cf buildpacks'. But its still cf push is not
able to identify python_buildpack.

Then I gave buildpack: python_buildpack in my manifest.yml it gave me
below error

--------------------------------------------------------------------
2015-08-04T10:45:24.93+0000 [API/0] OUT Created app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:25.40+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
({"route"=>"5ff72553-4031-4747-ad27-9102f00a3d3a"})
2015-08-04T10:45:31.78+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:32.78+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:45:32.88+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:45:33.47+0000 [STG/0] OUT Staging failed: An
application could not be detected by any available buildpack
2015-08-04T10:45:33.48+0000 [STG/0] ERR
2015-08-04T10:45:33.62+0000 [API/0] ERR encountered error: An app
was not successfully detected by any available buildpack
2015-08-04T10:51:17.31+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"https://github.com/cloudfoundry/buildpack-python.git",
"environment_json"=>"PRIVATE DATA HIDDEN"})
2015-08-04T10:51:27.64+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:51:28.84+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:51:29.86+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:51:29.94+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:51:30.01+0000 [STG/0] ERR Cloning into
'/tmp/buildpacks/buildpack-python'...
2015-08-04T10:51:30.98+0000 [STG/0] OUT Submodule
'compile-extensions'
(https://github.com/cloudfoundry-incubator/compile-extensions.git)
registered for path 'compile-extensions'
2015-08-04T10:51:31.02+0000 [STG/0] ERR Cloning into
'compile-extensions'...
2015-08-04T10:51:31.36+0000 [STG/0] OUT Submodule path
'compile-extensions': checked out
'ce9345a9a6e7b00266194cadd18dbef37e791a7b'
2015-08-04T10:51:31.48+0000 [STG/0] OUT -------> Buildpack version 1.5.0
2015-08-04T10:51:31.51+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:51:36.34+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:51:36.67+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:51:36.70+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:51:36.86+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T10:56:18.81+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T10:56:24.10+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:56:25.24+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:56:26.26+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:56:26.36+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:56:26.68+0000 [STG/0] OUT -------> Buildpack version 1.4.0
2015-08-04T10:56:26.71+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:56:31.21+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:56:31.99+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T10:56:31.99+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T10:56:32.43+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:56:32.46+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:56:32.60+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T11:00:56.58+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T11:01:01.91+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T11:01:03.53+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T11:01:04.55+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T11:01:04.63+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T11:01:04.94+0000 [STG/0] OUT -------> Buildpack version 1.4.0
2015-08-04T11:01:04.98+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T11:01:09.55+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

If I gave python buildpack url of git as buildpack: then
it gives below error

2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

I am just pushing this simple sample of python -
https://github.com/ihuston/python-cf-examples/tree/master/01-simple-python-app


Re: CF push error - Not able to resolve - Error dialing loggregator server: Get https://loggregator.systemdomain.com

Ronak Agarwal <roagarwa@...>
 

Thanks Joseph, it was really helpful.

I am pushing a python app and I can see a zip file for a python
buildpack when I did - 'cf buildpacks'. But its still cf push is not
able to identify python_buildpack.

Then I gave buildpack: python_buildpack in my manifest.yml it gave me
below error

--------------------------------------------------------------------
2015-08-04T10:45:24.93+0000 [API/0] OUT Created app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:25.40+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78
({"route"=>"5ff72553-4031-4747-ad27-9102f00a3d3a"})
2015-08-04T10:45:31.78+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:45:32.78+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:45:32.88+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:45:33.47+0000 [STG/0] OUT Staging failed: An
application could not be detected by any available buildpack
2015-08-04T10:45:33.48+0000 [STG/0] ERR
2015-08-04T10:45:33.62+0000 [API/0] ERR encountered error: An app
was not successfully detected by any available buildpack
2015-08-04T10:51:17.31+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"https://github.com/cloudfoundry/buildpack-python.git",
"environment_json"=>"PRIVATE DATA HIDDEN"})
2015-08-04T10:51:27.64+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:51:28.84+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:51:29.86+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:51:29.94+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:51:30.01+0000 [STG/0] ERR Cloning into
'/tmp/buildpacks/buildpack-python'...
2015-08-04T10:51:30.98+0000 [STG/0] OUT Submodule
'compile-extensions'
(https://github.com/cloudfoundry-incubator/compile-extensions.git)
registered for path 'compile-extensions'
2015-08-04T10:51:31.02+0000 [STG/0] ERR Cloning into
'compile-extensions'...
2015-08-04T10:51:31.36+0000 [STG/0] OUT Submodule path
'compile-extensions': checked out
'ce9345a9a6e7b00266194cadd18dbef37e791a7b'
2015-08-04T10:51:31.48+0000 [STG/0] OUT -------> Buildpack version 1.5.0
2015-08-04T10:51:31.51+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:51:36.34+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:51:36.67+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:51:36.70+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:51:36.86+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T10:56:18.81+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T10:56:24.10+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T10:56:25.24+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T10:56:26.26+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T10:56:26.36+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T10:56:26.68+0000 [STG/0] OUT -------> Buildpack version 1.4.0
2015-08-04T10:56:26.71+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T10:56:31.21+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T10:56:31.99+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T10:56:31.99+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T10:56:32.43+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T10:56:32.46+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T10:56:32.60+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase
2015-08-04T11:00:56.58+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"name"=>"myapp",
"command"=>"PRIVATE DATA HIDDEN", "memory"=>128, "disk_quota"=>256,
"buildpack"=>"python_buildpack", "environment_json"=>"PRIVATE DATA
HIDDEN"})
2015-08-04T11:01:01.91+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STOPPED"})
2015-08-04T11:01:03.53+0000 [DEA/0] OUT Got staging request for
app with id 9bccc468-b1b4-413b-88f1-f8b510064d78
2015-08-04T11:01:04.55+0000 [API/0] OUT Updated app with guid
9bccc468-b1b4-413b-88f1-f8b510064d78 ({"state"=>"STARTED"})
2015-08-04T11:01:04.63+0000 [STG/0] OUT -----> Downloaded app
package (4.0K)
2015-08-04T11:01:04.94+0000 [STG/0] OUT -------> Buildpack version 1.4.0
2015-08-04T11:01:04.98+0000 [STG/0] OUT -----> Installing runtime
(python-2.7.10)
2015-08-04T11:01:09.55+0000 [STG/0] OUT -----> Installing
dependencies with pip
2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

If I gave python buildpack url of git as buildpack: then
it gives below error

2015-08-04T11:01:10.29+0000 [STG/0] ERR You are using pip version
7.0.1, however version 7.1.0 is available.
2015-08-04T11:01:10.29+0000 [STG/0] ERR You should consider
upgrading via the 'pip install --upgrade pip' command.
2015-08-04T11:01:10.73+0000 [STG/0] ERR Directory '.' is not
installable. File 'setup.py' not found.
2015-08-04T11:01:10.76+0000 [STG/0] OUT Staging failed: Buildpack
compilation step failed
2015-08-04T11:01:10.97+0000 [API/0] ERR encountered error: App
staging failed in the buildpack compile phase

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

I am just pushing this simple sample of python -
https://github.com/ihuston/python-cf-examples/tree/master/01-simple-python-app

On Mon, Aug 3, 2015 at 9:53 PM, CF Runtime <cfruntime(a)gmail.com> wrote:
The buildpacks didn't successfully upload, so you'll probably just need to
"bosh restart api_z1/0" which should cause the startup script to upload
them.

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 4:09 AM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:

I just disabled - source/destination checks

And able to curl 'google.com' now from private IP.

Should I need to again do - bosh deploy ?



On Mon, Aug 3, 2015 at 4:28 PM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:
If I restart my NAT vm and do curl google.com - I am getting response.

When I try ssh to any of the private VM (api_z1 IP) from this NAT vm
-> ssh -i "bosh.pem" vcap(a)10.10.17.0

" It is required that your private key files are NOT accessible by
others.
This private key will be ignored.
bad permissions: ignore key: bosh.pem
Permission denied (publickey). "

So I did - chmod 400 bosh.pem

Then tried again above ssh command and able to ssh that 10.10.17.0

But curl google.com not giving anything.





On Mon, Aug 3, 2015 at 3:50 PM, Ronak Agarwal <roagarwa(a)tibco.com>
wrote:
Thanks Joseph.

I am not clear at one point - I already have a NAT vm which I had just
stopped and again started, so are you asking me to create a new NAT vm
because I have stopped it earlier? because it maintains some
persistent data.

I just tried pushing a Java app because at api_z1, I can't find Java
buildpack error, but I am getting -

RESPONSE: [2015-08-03T10:13:42Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

FAILED
Error uploading application.
Server error, status code: 504, error code: 0, message:
FAILED
Error uploading application.
Server error, status code: 504, error code: 0, message:

I checked api_z1 logs and couldn't find any trace for this error, is
it moved to Cloud_Controller_Worker ? What could be the error? I have
good disk space available in api_z1.

cf logs appname --recent , gives below -
RESPONSE: [2015-08-03T10:19:07Z]
HTTP/1.1 200 OK
Content-Length: 6200
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Mon, 03 Aug 2015 10:19:05 GMT
Server: nginx
X-Cf-Requestid: 2a67e173-20bf-4f89-7b27-efd5b28461c6
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:

f7b15702-3650-4258-5b40-48efbd9ef271::230c52e3-52a7-4a81-82f4-4e1ed445082d

{
"total_results": 1,
"total_pages": 1,
"prev_url": null,
"next_url": null,
"resources": [
{
"metadata": {
"guid": "2ac4b290-fb0d-4273-940e-b2d1aeb31320",
"url": "/v2/apps/2ac4b290-fb0d-4273-940e-b2d1aeb31320",
"created_at": "2015-08-03T09:26:19Z",
"updated_at": "2015-08-03T10:12:40Z"
},
"entity": {
"name": "hello-spring-cloud",
"production": false,
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"stack_guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"buildpack": null,
"detected_buildpack": null,
"environment_json": {
"SPRING_PROFILES_DEFAULT": "cloud"
},
"memory": 512,
"instances": 1,
"disk_quota": 1024,
"state": "STOPPED",
"version": "3719a87d-98b8-4641-a613-c9730f132b5d",
"command": null,
"console": false,
"debug": null,
"staging_task_id": null,
"package_state": "PENDING",
"health_check_type": "port",
"health_check_timeout": null,
"staging_failed_reason": null,
"staging_failed_description": null,
"diego": false,
"docker_image": null,
"package_updated_at": null,
"detected_start_command": "",
"enable_ssh": true,
"docker_credentials_json": {
"redacted_message": "[PRIVATE DATA HIDDEN]"
},
"space_url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"space": {
"metadata": {
"guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"url": "/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"created_at": "2015-07-30T09:08:36Z",
"updated_at": null
},
"entity": {
"name": "ronak",
"organization_guid":
"66e33d43-92fa-4f30-809d-1f5d9adaf921",
"space_quota_definition_guid": null,
"allow_ssh": true,
"organization_url":
"/v2/organizations/66e33d43-92fa-4f30-809d-1f5d9adaf921",
"developers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/developers",
"managers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/managers",
"auditors_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/auditors",
"apps_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/apps",
"routes_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/routes",
"domains_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/domains",
"service_instances_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/service_instances",
"app_events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/app_events",
"events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/events",
"security_groups_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/security_groups"
}
},
"stack_url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"stack": {
"metadata": {
"guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"url": "/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"created_at": "2015-07-23T12:10:53Z",
"updated_at": null
},
"entity": {
"name": "cflinuxfs2",
"description": "Cloud Foundry Linux-based filesystem"
}
},
"events_url":
"/v2/apps/2ac4b290-fb0d-4273-940e-b2d1aeb31320/events",
"service_bindings_url":
"/v2/apps/2ac4b290-fb0d-4273-940e-b2d1aeb31320/service_bindings",
"service_bindings": [

],
"routes_url":
"/v2/apps/2ac4b290-fb0d-4273-940e-b2d1aeb31320/routes",
"routes": [
{
"metadata": {
"guid": "f44c4856-08c1-49f2-8e1b-a51e548adca6",
"url": "/v2/routes/f44c4856-08c1-49f2-8e1b-a51e548adca6",
"created_at": "2015-08-03T09:27:16Z",
"updated_at": null
},
"entity": {
"host": "hello-spring-cloud-unabsorbent-masculinization",
"path": "",
"domain_guid": "c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url":
"/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url":
"/v2/routes/f44c4856-08c1-49f2-8e1b-a51e548adca6/apps"
}
},
{
"metadata": {
"guid": "47a495d6-a484-48f0-ac12-6157282be1c4",
"url": "/v2/routes/47a495d6-a484-48f0-ac12-6157282be1c4",
"created_at": "2015-08-03T09:58:03Z",
"updated_at": null
},
"entity": {
"host":
"hello-spring-cloud-unascertainable-unmelodiousness",
"path": "",
"domain_guid": "c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url":
"/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url":
"/v2/routes/47a495d6-a484-48f0-ac12-6157282be1c4/apps"
}
},
{
"metadata": {
"guid": "f51fad6c-fd48-4dfb-b201-a756af14bd00",
"url": "/v2/routes/f51fad6c-fd48-4dfb-b201-a756af14bd00",
"created_at": "2015-08-03T10:12:40Z",
"updated_at": null
},
"entity": {
"host": "hello-spring-cloud-completive-hesperinos",
"path": "",
"domain_guid": "c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url":
"/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url":
"/v2/routes/f51fad6c-fd48-4dfb-b201-a756af14bd00/apps"
}
}
]
}
}
]
}
Connected, dumping recent logs for app hello-spring-cloud in org ronak
/ space ronak as admin...

FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=2ac4b290-fb0d-4273-940e-b2d1aeb31320:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).
FAILED
Error dialing loggregator server: Get

https://loggregator.cf.ronak.com:4443/recent?app=2ac4b290-fb0d-4273-940e-b2d1aeb31320:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).



On Mon, Aug 3, 2015 at 3:33 PM, CF Runtime <cfruntime(a)gmail.com> wrote:
Yeah, without the NAT vm nothing will be able to get out to the
internet.
They will be able to respond to external requests, such as a request
to the
api, or the login server, or an individual app. But if anything on the
inside tries to initiate a network connection, it has no route to the
internet.

Amazon has good generic documentation on how to create a NAT instance:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html#NATInstance

BOSH also has some documentation, although it doesn't tell you how to
create
the instance itself, but rather how to configure your private subnet
and
routing table to use the NAT instance:
http://bosh.io/docs/setup-aws.html#nat

In both sets of documentation, you may already have security groups,
routes
and subnets created from your previous NAT instance.

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 2:50 AM, Ronak Agarwal <roagarwa(a)tibco.com>
wrote:

I tried 'curl http://google.com' from my api_z1 instance but was
unable to get any response.

I create my NAT vm through 'bosh aws create' command, but by mistake
I
stopped that VM on AWS. So does stopping NAT VM is causing this issue
? It has any persistent data while setting NAT VM ?

If its because of stopping NAT Vm, so now what is the solution, do I
need to destroy everything and create entire environment again ?
Please suggest.

On Mon, Aug 3, 2015 at 2:53 PM, CF Runtime <cfruntime(a)gmail.com>
wrote:
It looks like the api instance is unable to upload the buildpacks
to the
blobstore. Perhaps the NAT (network NAT, not message bus NATS)
instance
is
not configured correctly.

Are you able to curl an external URL from the api instance?

Joseph
CF Release Integration Team

On Mon, Aug 3, 2015 at 2:12 AM, Ronak Agarwal <roagarwa(a)tibco.com>
wrote:

Its a fresh install.

I found few logs may be helpful to resolve this issue --

I found few logs on cloud_controller_ng as below -

Nodejs buildpack install fail :-
{"timestamp":1438583731.044699,"message":"Buildpack
nodejs_buildpack
failed to install or update. Error:



#","log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"} {"timestamp":1438583731.045526,"message":"Request
failed:
500: {\"code\"=>10001, \"description\"=>\"connect timeout
reached\",
\"error_code\"=>\"CF-Timeout\",
------------------------------------------ -> Fails at
nodejs_buildpack-cached-v1.4.0.zip




"log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/exception_catching_job.rb","lineno":24,"method":"log_error"}
{"timestamp":1438583731.0496318,"message":"(0.001478s) UPDATE
delayed_jobs SET guid = '82d9ebe1-7af0-4671-89a5-30146a5bb554',
created_at = '2015-08-03 06:27:26', updated_at =
CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---


!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:

!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: nodejs_buildpack\n file:



\\"/var/vcap/packages/buildpack_nodejs/nodejs_buildpack-cached-v1.4.0.zip\\"\n
opts: {}\n request_id: \n', last_error = NULL, run_at =
'2015-08-03
06:27:26', locked_at = '2015-08-03 06:31:30',failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.1', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An
unknown
error occurred.\ncode: 10001\n' WHERE (id = 971) LIMIT



1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block
in log_each"}

________________________________

go_buildpack failed to install

{"timestamp":1438583970.3534014,"message":"Buildpack go_buildpack
failed to install or update. Error:



#","log_level":"error","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}
{"timestamp":1438583970.3541129,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",



\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:135:in
rescue in block in connect'\",



\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:114:inblock
in connect'\"

________________________________

->go_buildpack-cached-v1.4.0.zip
,



"log_level":"error","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/exception_catching_job.rb","lineno":24,"method":"log_error"}
{"timestamp":1438583970.358118,"message":"(0.001543s) UPDATE
delayed_jobs SET guid = 'd559d276-c5a2-471c-aca1-ba25f4e9cd97',
created_at = '2015-08-03 06:27:26', updated_at =
CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---


!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:

!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: go_buildpack\n file:

\\"/var/vcap/packages/buildpack_go/go_buildpack-cached-v1.4.0.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:35:29', failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.2', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An
unknown
error occurred.\ncode: 10001\n' WHERE (id = 972) LIMIT



1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block
in log_each"}

________________________________

python_buildpack failed to install

{"timestamp":1438583971.811825,"message":"Buildpack
python_buildpack
failed to install or update. Error:



#","log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}
{"timestamp":1438583971.8125288,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",



\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:135:in
rescue in block in connect'\",



\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:114:inblock
in connect'\",

________________________________

->python_buildpack-cached-v1.4.0.zip




,"log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/exception_catching_job.rb","lineno":24,"method":"log_error"}

{"timestamp":1438583971.8163912,"message":"(0.001414s) UPDATE
delayed_jobs SET guid = '37f04f8f-2e1e-4096-8f5f-c10d8180a9fc',
created_at = '2015-08-03 06:27:26', updated_at =
CURRENT_TIMESTAMP,
priority = 0, attempts = 0,handler = '---


!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:

!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: python_buildpack\n file:



\\"/var/vcap/packages/buildpack_python/python_buildpack-cached-v1.4.0.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26',locked_at = '2015-08-03 06:35:31', failed_at =
NULL,locked_by = 'cc_api_worker.api_z1.0.1', queue =
'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An
unknown
error occurred.\ncode: 10001\n' WHERE (id = 973) LIMIT



1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":7030

php_buildpack failed to install

{"timestamp":1438584211.920127,"message":"Buildpack php_buildpack
failed to install or update. Error:



#","log_level":"error","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}

________________________________

->php_buildpack-cached-v3.3.0.zip

{"timestamp":1438584211.9250205,"message":"(0.001442s) UPDATE
delayed_jobs SET guid = '133a41bd-307f-4e2b-b70e-635f3dec60c4',
created_at = '2015-08-03 06:27:26', updated_at =
CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---


!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:

!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: php_buildpack\n file:


\\"/var/vcap/packages/buildpack_php/php_buildpack-cached-v3.3.0.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:39:30', failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.2', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An
unknown
error occurred.\ncode: 10001\n' WHERE (id = 974) LIMIT



1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,

________________________________

binary_buildpack failed to install

{"timestamp":1438584212.2200441,"message":"Buildpack
binary_buildpack
failed to install or update. Error:



#","log_level":"error","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":4360,"file":"/var/vcap/data/packages/cloud_controller_ng/a60643ffa860f4f065c25b6b99687b9d55067757.1-0e8fbd36253d4107c466281136ad267d0660bc51/cloud_controller_ng/app/jobs/runtime/buildpack_installer.rb","lineno":38,"method":"rescue
in perform"}

________________________________

->binary_buildpack-cached-v1.0.1.zip

{"timestamp":1438584212.2245483,"message":"(0.001381s) UPDATE
delayed_jobs SET guid = '7ea6156e-024c-4f2d-b574-ca9b218470cd',
created_at = '2015-08-03 06:27:26', updated_at =
CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---


!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:

!ruby/object:VCAP::CloudController::Jobs::Runtime::BuildpackInstaller\n
name: binary_buildpack\n file:



\\"/var/vcap/packages/buildpack_binary/binary_buildpack-cached-v1.0.1.zip\\"\n
opts: {}\n request_id: \n',last_error = NULL, run_at = '2015-08-03
06:27:26', locked_at = '2015-08-03 06:39:31', failed_at = NULL,
locked_by = 'cc_api_worker.api_z1.0.1', queue = 'cc-api_z1-0',
cf_api_error = '---\nerror_code: UnknownError\ndescription: An
unknown
error occurred.\ncode: 10001\n' WHERE (id = 975) LIMIT



1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70305412338480,"fiber_id":70305448717440,"process_id":436

________________________________

This seems to be timeout issue.

{"timestamp":1438585142.846115,"message":"Request failed: 500:
{\"code\"=>10001, \"description\"=>\"connect timeout reached\",
\"error_code\"=>\"CF-Timeout\",



\"backtrace\"=>[\"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/excon-0.44.1/lib/excon/socket.rb:135:in
`rescue in block in connect'

{"timestamp":1438585142.851403,"message":"(0.001378s) UPDATE
delayed_jobs SET guid = '6e4167d9-c7ee-4425-9049-e50971864a64',
created_at = '2015-08-03 06:55:01', updated_at =
CURRENT_TIMESTAMP,
priority = 0, attempts = 0, handler = '---


!ruby/object:VCAP::CloudController::Jobs::ExceptionCatchingJob\nhandler:
!ruby/object:VCAP::CloudController::Jobs::RequestJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::TimeoutJob\n handler:
!ruby/object:VCAP::CloudController::Jobs::Runtime::AppBitsPacker\n
app_guid: 41657738-cc7c-4237-ab52-e4f9683e16f4\n
uploaded_compressed_path:
\\"/var/vcap/data/cloud_controller_ng/tmp/uploads/0000000001\\"\n
fingerprints: []\n request_id:



64cc342c-9db9-495e-46d9-ce5e9331aa41::d6c111c3-79b1-4fec-8fa9-0d4be759bdd9\n',
last_error = NULL, run_at = '2015-08-03 06:55:01', locked_at =
'2015-08-03 06:55:02', failed_at = NULL,locked_by =
'cc_api_worker.api_z1.0.2', queue = 'cc-api_z1-0', cf_api_error =
'---\nerror_code: UnknownError\ndescription: An unknown error
occurred.\ncode: 10001\n' WHERE (id = 989) LIMIT



1","log_level":"debug2","source":"cc.background","data":{},"thread_id":70006300463920,"fiber_id":70006336842960,"process_id":4397,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.1.0/gems/sequel-4.21.0/lib/sequel/database/logging.rb","lineno":70,"method":"block
in log_each"}

________________________________

I will try to push Java app to verify if its getting pushed.

On Mon, Aug 3, 2015 at 2:19 PM, Gwenn Etourneau
<getourneau(a)pivotal.io>
wrote:
Btw CF-213 is a fresh install or update ??

On Mon, Aug 3, 2015 at 5:37 PM, Ronak Agarwal
<roagarwa(a)tibco.com>
wrote:

Hi,

Please go through all my instance info below and let me know
what
can
be done to resolve this issue??

I have deployed CF-213.yml release through microbosh on AWS.
I have installed latest CF CLI v6.12.2
I am able to do cf login using below endpoints -
/.cf/config.json
"Target": "https://api.cf.ronak.com",
"ApiVersion": "2.33.0",
"AuthorizationEndpoint": "https://login.cf.ronak.com",
"LoggregatorEndPoint": "wss://loggregator.cf.ronak.com:4443",
"DopplerEndPoint": "wss://doppler.cf.ronak.com:4443",
"UaaEndpoint": "https://uaa.cf.ronak.com",

Now when I am trying to push Nodejs app using -
cf push nodeapp -c "node main.js" -m 128M -b node_buildpack
OR
cf push nodeapp -c "node main.js"

both are failing .. gives unknown error.
When I do -> cf logs nodeapp --recent
It gives below error -
FAILED
Error dialing loggregator server: Get




https://loggregator.cf.ronak.com:4443/recent?app=05ea8bda-28c1-49ed-8c65-4625c77423be:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).






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

I am using ELB and my HA-proxy job is not running. Please let
me
know
how to overcome this challenge. I found lot of people have
faced it
but all of them I think are using HA-proxy and not ELB.

I have configured 4443 with SSL on ELB -

80 (HTTP) forwarding to 80 (HTTP),
443 (HTTPS, Certificate: cfrouter_cert) forwarding to 80
(HTTP),
4443 (SSL, Certificate: cfrouter_cert) forwarding to 80 (TCP)






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

Below are the vms/jobs which are running on AWS I dont see
login_z1/z2
in them, so do I need these jobs?

Job/index | State | Resource Pool | IPs |




+------------------------------------+---------+---------------+--------------+
| api_worker_z1/0 | running | small_z1 | 10.10.17.3 |
| api_worker_z2/0 | running | small_z2 | 10.10.81.0 |
| api_z1/0 | running | large_z1 | 10.10.17.1 |
| api_z2/0 | running | large_z2 | 10.10.80.255 |
| clock_global/0 | running | medium_z1 | 10.10.17.2 |
| doppler_z1/0 | running | medium_z1 | 10.10.17.6 |
| doppler_z2/0 | running | medium_z2 | 10.10.81.3 |
| etcd_z1/0 | running | medium_z1 | 10.10.16.20 |
| etcd_z1/1 | running | medium_z1 | 10.10.16.35 |
| etcd_z2/0 | running | medium_z2 | 10.10.80.19 |
| hm9000_z1/0 | running | medium_z1 | 10.10.17.4 |
| hm9000_z2/0 | running | medium_z2 | 10.10.81.1 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 |
10.10.17.7
|
| loggregator_trafficcontroller_z2/0 | running | small_z2 |
10.10.81.4
|
| nats_z1/0 | running | medium_z1 | 10.10.16.11 |
| nats_z2/0 | running | medium_z2 | 10.10.80.11 |
| nfs_z1/0 | running | medium_z1 | 10.10.16.36 |
| router_z1/0 | running | router_z1 | 10.10.16.15 |
| router_z2/0 | running | router_z2 | 10.10.80.15 |
| runner_z1/0 | running | runner_z1 | 10.10.17.5 |
| runner_z2/0 | running | runner_z2 | 10.10.81.2 |
| stats_z1/0 | running | small_z1 | 10.10.16.255 |
| uaa_z1/0 | running | medium_z1 | 10.10.17.0 |
| uaa_z2/0 | running | medium_z2 | 10.10.80.254 |





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

openssl s_client -connect api.cf.ronak.com:443
CONNECTED(00000003)
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, O = Pivotal, CN = *.cf.ronak.com

verify return:1

Certificate chain
0 s:/C=US/O=Pivotal/CN=*.cf.ronak.com

i:/C=US/O=Pivotal/CN=*.cf.ronak.com

Server certificate
-----BEGIN CERTIFICATE-----

MIIC6TCCAdGgAwIBAgIBADANBgkqhkiG9w0BAQUFADA4MQswCQYDVQQGEwJVUzEQ

MA4GA1UECgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wHhcNMTUw

NzE0MTAxNDA1WhcNMTgwNzE0MTAxNDA1WjA4MQswCQYDVQQGEwJVUzEQMA4GA1UE

CgwHUGl2b3RhbDEXMBUGA1UEAwwOKi5jZi5yb25hay5jb20wggEiMA0GCSqGSIb3

DQEBAQUAA4IBDwAwggEKAoIBAQDi2+NVSsR7/oCh40H+CfFWUS0BczyTubpV72Ir

6TCkjLitLdFgJFqNvaIcT0+2+rozxQs7Zr/IlH5OznYsFYNyOSx2l/xDKCqA7q4U

l6aGhFZSodIow6AKCRzVt2y5T/nmeRCWsVPjHMvANvJlM57PdWI1vIlaav3l3enF

FUs14MSEuXY+eWfeP74Sprg/Xc5TiD5RQPLZC8h2HeAmIMgTV5TAagWiGK5MUoQ9

hScJvsgBPKQuldRfRsk7NxuXmY+wdfOYKc5CZ7szl7QiLsT7Tdeei+UuhIAh874S

HjPP+JlFH4/whRJyDtv/h9rZzW1DJbx5ZeUtzFGv0jxmsvJrAgMBAAEwDQYJKoZI

hvcNAQEFBQADggEBAM7S9za5V2sJ8Gwb4QQ29F4bQxVNk5/u7AnbzvfmhcWgO9yt

oBUwtc04F/Ycz7sTlXXDe0f+nSo+Q0vowd4NmTSont5g8ZznD18k4krCcfvXCsAL

AvJ/yt2n+fW/gwZbZHS9kb4Esxu4SmjU8GFN10+DMRFaB9JkbRpJmRLsxZzE8w+E

MW7gi0V+IycOLyeJsfwXtjGZhKsLSq6fg/mwVax9Z0MsqVRbzO61RaJjMDiop+aN

kf/ktqGVBACwqvG7cxKu4/2cFMzi6dC9xEN7o5spinfdNt/uH3O0JHRcftUCICaL
ln6RtW7XXHNWnP2YfMXxPLvhjV/Cg49soz3D+os=
-----END CERTIFICATE-----
subject=/C=US/O=Pivotal/CN=*.cf.ronak.com

issuer=/C=US/O=Pivotal/CN=*.cf.ronak.com

No client certificate CA names sent

SSL handshake has read 1403 bytes and written 421 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID:

B845CA20842317DB12FB250C05D40686334A7C85D8BE2E5332B6C70632BF9256
Session-ID-ctx:
Master-Key:



3934F0F361C1A407B215D869F8142F3B3180BB8CD232D55D937430CDD3674F047A774594B6A3BA9DB7275D1E507AE0B5
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1b 21 b6 45 6b 48 d6 c5-6d 66 e4 97 58 ae 76 91
.!.EkH..mf..X.v.
0010 - 0c 85 3f 3b f8 79 3d 59-b5 55 57 bd a7 98 a2 90
..?;.y=Y.UW.....
0020 - 20 81 2b 0b 8a 6a 13 8c-1e e7 c4 d2 f7 d1 f6 5b
.+..j.........[
0030 - c7 d6 58 16 42 89 1e 51-01 7d 20 24 3f fa 2e f7
..X.B..Q.}
$?...
0040 - 76 06 d5 61 ff 4f 5c a1-46 77 41 62 fe fc c9 50
v..a.O.FwAb...P
0050 - 55 b6 00 98 15 22 8a 81-e2 e0 0e 9d da 83 fc 7b
U....".........{
0060 - ef 33 16 ec 88 60 ca 38-3f 35 85 6d fe 68 26 f6
.3...`.8?5.m.h&.
0070 - 24 48 65 47 8b c4 f6 20-f9 31 63 74 56 1a 67 d5 $HeG...
.1ctV.g.
0080 - 26 d1 4c 0d fa 5f 01 da-ec d9 a6 88 9d ab cd fa
&.L.._..........
0090 - 05 17 bd e4 b4 78 f4 02-6b 5e 86 83 04 b7 f2 33
.....x..k^.....3

Start Time: 1438453185
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)





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


I am using self signed certificate.. so if I have to continue
without
--skip-ssl-validation, I should add this ELB certificate in all
the
VMS as trusted keys. Is it correct ? OR anyother option ?





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


In CF-AWS-Stub.yml I found two -
a) jwt: signing_key & verification_key
b) router . ssl_cert & ssl_key
Both should be same as AWS ELB ssl certificate ??






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


I think core problem is cf push error which I mentioned above -

1) I can see in Response - "detected_buildpack": null, I am not
sure
why its null because I am uploading system buildpack app which
of
Nodejs and when I do - cf buildpacks I can see 4 buildpacks
below -

buildpack position enabled locked filename
staticfile_buildpack 1 true false
java_buildpack 2 true false
node_buildpack 3 true false
php_buildpack 6 true false

I am not sure why filename is null ??

2) Unknown Error Code - 10001 explained more below






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

'CF_TRACE=true cf push' gives below error -

REQUEST: [2015-08-02T10:40:17Z]
GET /v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5 HTTP/1.1
Host: api.cf.ronak.com
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.2-24abed3 / linux

RESPONSE: [2015-08-02T10:40:17Z]
HTTP/1.1 200 OK
Content-Length: 491
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:40:17 GMT
Server: nginx
X-Cf-Requestid: f423947e-8512-41f0-7fd1-21ba6b89178d
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:



aa782bd8-d758-4c65-505c-af71f2bc212d::a0ac2db0-3f3e-4a49-b011-2f9e7f02660b

{
"metadata": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"created_at": "2015-08-02T10:36:11Z",
"url": "/v2/jobs/fd682f50-c857-40dc-a190-abc0f59492c5"
},
"entity": {
"guid": "fd682f50-c857-40dc-a190-abc0f59492c5",
"status": "failed",
"error": "Use of entity>error is deprecated in favor of
entity>error_details.",
"error_details": {
"error_code": "UnknownError",
"description": "An unknown error occurred.",
"code": 10001
}
}
}
FAILED
Error uploading application.
An unknown error occurred.
FAILED
Error uploading application.
An unknown error occurred.

________________________________

I found post in which its mentioned - The point was that S3
buckets
name (specified by following options: resource_directory_key,
app_package_directory_key, droplet_directory_key, and
buildpack_directory_key) had dots in their names. Removing dots
from
this parameters will solve the problem.

I removing dots and replaced with '-' and again did 'bosh
deploy'
---
I can't find these directories getting created after deployment
under
S3 ?? is it normal ?
I tried cf push anyways to check if its working - but gave me
same
'Unkown Error code 10001.

Please help me to solve the problem.





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

cf logs nodeapp --recent

RESPONSE: [2015-08-02T10:41:51Z]
HTTP/1.1 200 OK
Content-Length: 4525
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Sun, 02 Aug 2015 10:41:50 GMT
Server: nginx
X-Cf-Requestid: c5508a55-a9f4-4be0-49a4-23a4f14fb5d3
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:



ae35d7fc-659f-4811-4d7c-077a78963951::4bae904f-6903-4a76-9d0e-314098266502

{
"total_results": 1,
"total_pages": 1,
"prev_url": null,
"next_url": null,
"resources": [
{
"metadata": {
"guid": "41657738-cc7c-4237-ab52-e4f9683e16f4",
"url": "/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4",
"created_at": "2015-08-02T10:36:10Z",
"updated_at": "2015-08-02T10:36:11Z"
},
"entity": {
"name": "nodeapp",
"production": false,
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"stack_guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"buildpack": null,
"detected_buildpack": null,
"environment_json": {

},
"memory": 1024,
"instances": 1,
"disk_quota": 1024,
"state": "STOPPED",
"version": "d2fa841d-17d6-4bae-9400-409966082443",
"command": "node main.js",
"console": false,
"debug": null,
"staging_task_id": null,
"package_state": "PENDING",
"health_check_type": "port",
"health_check_timeout": null,
"staging_failed_reason": null,
"staging_failed_description": null,
"diego": false,
"docker_image": null,
"package_updated_at": null,
"detected_start_command": "",
"enable_ssh": true,
"docker_credentials_json": {
"redacted_message": "[PRIVATE DATA HIDDEN]"
},
"space_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"space": {
"metadata": {
"guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"created_at": "2015-07-30T09:08:36Z",
"updated_at": null
},
"entity": {
"name": "ronak",
"organization_guid":
"66e33d43-92fa-4f30-809d-1f5d9adaf921",
"space_quota_definition_guid": null,
"allow_ssh": true,
"organization_url":
"/v2/organizations/66e33d43-92fa-4f30-809d-1f5d9adaf921",
"developers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/developers",
"managers_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/managers",
"auditors_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/auditors",
"apps_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/apps",
"routes_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/routes",
"domains_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/domains",
"service_instances_url":

"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/service_instances",
"app_events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/app_events",
"events_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/events",
"security_groups_url":

"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89/security_groups"
}
},
"stack_url":
"/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"stack": {
"metadata": {
"guid": "612874d8-144e-4599-88a7-e38e333ca93e",
"url":
"/v2/stacks/612874d8-144e-4599-88a7-e38e333ca93e",
"created_at": "2015-07-23T12:10:53Z",
"updated_at": null
},
"entity": {
"name": "cflinuxfs2",
"description": "Cloud Foundry Linux-based filesystem"
}
},
"events_url":
"/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/events",
"service_bindings_url":

"/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/service_bindings",
"service_bindings": [

],
"routes_url":
"/v2/apps/41657738-cc7c-4237-ab52-e4f9683e16f4/routes",
"routes": [
{
"metadata": {
"guid": "2489386f-973b-45db-bc86-412b57bfffb0",
"url":
"/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0",
"created_at": "2015-07-31T06:53:17Z",
"updated_at": null
},
"entity": {
"host": "nodeapp",
"path": "",
"domain_guid":
"c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_guid": "6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"domain_url":
"/v2/domains/c3c27b28-9fef-4130-8942-41dbeb8220a0",
"space_url":
"/v2/spaces/6ffcaf95-f30b-41b6-88ce-d67f59584e89",
"apps_url":
"/v2/routes/2489386f-973b-45db-bc86-412b57bfffb0/apps"
}
}
]
}
}

]
}
Connected, dumping recent logs for app nodeapp in org ronak /
space
ronak as admin...

FAILED
Error dialing loggregator server: Get




https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).
FAILED
Error dialing loggregator server: Get




https://loggregator.cf.ronak.com:4443/recent?app=41657738-cc7c-4237-ab52-e4f9683e16f4:
EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.ronak.com:4443).






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


Please go through all my above research and let me know what
can be
done to resolve this issue??


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


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


--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


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


--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


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


--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com


--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com


--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Regards,
Ronak Agarwal
(M) +91 8446044994
(O) +91 20 4150 7935
roagarwa(a)tibco.com


Re: CFF Mailman Upgrade - Monday August 3, 2015 at 7 PM PT

Dieu Cao <dcao@...>
 

So excited for this change!

On Mon, Aug 3, 2015 at 9:06 PM, Josh Farwell <jfarwell(a)linuxfoundation.org>
wrote:

Hello Folks,

The migration to Mailman 3 is complete. Welcome to your new mailing lists!

As chip mentioned, the URLs and email addresses for lists are the same.
The main difference besides the interface itself is the need for a Linux
Foundation ID in order to sign in and change your subscription settings,
or to post to the archives using the web interface.

If you already have a Linux Foundation ID associated with your email
address, you can just sign in with your username and password and you
should be good to go. If you don't, please create an account here:

https://identity.linuxfoundation.org

Please note that you WILL be able to send and receive email from the
list without setting up a Linux Foundation ID, though we recommend you
set one up as soon as possible.

If there are any questions. please email our helpdesk at:

helpdesk(a)cloudfoundry.org

Thank you!

--
Josh Farwell

8321 - 8340 of 9429