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