Date   

Relation between Network property in Resource pool property and Network property in Actual Job block

Ronak Banka
 

Hello All,

I have a resource pool , let say small_z1

- name: small_z1
network: cf1
stemcell: stemcell-xyz
cloud_properties:
instance_type: m1.small
availability_zone: zone1

and a Job , router having two networks assigned to it

- name: router
instances: 1
networks:
- name: router_internal
default: [dns, gateway]
static_ips:
- xy.xy.xy.xy
- name: router_external
static_ips:
- yz.yz.yz.yz
gateway: yy.yy.yy.yy
networks:
apps: router_internal
management: router_internal
resource_pool: small_z1

With these properties there are no issues anywhere.

what is the network property in resource pool responsible for, if the
created job networks and not linked to the one in pool??

Regards,
Ronak




--
View this message in context: http://cf-bosh.70367.x6.nabble.com/Relation-between-Network-property-in-Resource-pool-property-and-Network-property-in-Actual-Job-block-tp649.html
Sent from the CF BOSH mailing list archive at Nabble.com.


Re: Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update

Ramesh Sambandan
 

I finally figured it out. It is my bad, I missed the properties.uaa.jwt.signing_key/verification_key in my manifest. It is something I thought I took care of it, but must have overwritten in subsequent edits.

The clue came from looking at the log files in router_api in api_z1 vm (/var/vcap/sys/log/router* folder)

And I successfully deployed cloud foundry in vsphere. :):)


Re: Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update

Parthiban Annadurai <senjiparthi@...>
 

Try after "bosh cck" and again re-deploy it.. Most of the Times it will
work..

On 8 September 2015 at 08:15, ronak banka <ronakbanka.cse(a)gmail.com> wrote:

You can create a gist of manifest from github and link it here.
On Sep 8, 2015 10:56, "Ramesh Sambandan" <rsamban(a)gmail.com> wrote:

I am using cf release 215.
I am trying to attach my manifest, but cannot figure out how to.


Re: Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update

Ronak Banka
 

You can create a gist of manifest from github and link it here.

On Sep 8, 2015 10:56, "Ramesh Sambandan" <rsamban(a)gmail.com> wrote:

I am using cf release 215.
I am trying to attach my manifest, but cannot figure out how to.


Re: Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update

Ramesh Sambandan
 

I am using cf release 215.
I am trying to attach my manifest, but cannot figure out how to.


Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update

Ramesh Sambandan
 

I am trying in deploy cloud foundry in vsphere and getting following error
Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update (00:10:31)

Following is entries in log file in api_z1/0 VM that I believe is pointing the cause.
vcap(a)6bd94f72-b20d-47a5-851d-d86e66b47df7:/var/vcap/sys/log$ tail -f nfs_mounter_ctl.err.log cloud_controller_ng_ctl.err.log
==> nfs_mounter_ctl.err.log <==
[2015-09-07 18:28:05+0000] mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
[2015-09-07 18:28:05+0000] mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 38896
[2015-09-07 18:53:58+0000] stop: Unknown instance:
[2015-09-07 18:53:58+0000] mount.nfs: mount(2): No such file or directory
[2015-09-07 18:53:59+0000] mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
[2015-09-07 18:53:59+0000] mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 38896
[2015-09-07 19:22:09+0000] stop: Unknown instance:
[2015-09-07 19:22:10+0000] mount.nfs: mount(2): No such file or directory
[2015-09-07 19:22:10+0000] mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
[2015-09-07 19:22:10+0000] mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 38896

==> cloud_controller_ng_ctl.err.log <==
[2015-09-07 18:28:05+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 18:28:05+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 18:53:58+0000] ------------ STARTING cloud_controller_ng_ctl at Mon Sep 7 18:53:58 UTC 2015 --------------
[2015-09-07 18:53:59+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 18:53:59+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 18:53:59+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 19:22:09+0000] ------------ STARTING cloud_controller_ng_ctl at Mon Sep 7 19:22:09 UTC 2015 --------------
[2015-09-07 19:22:10+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 19:22:10+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted
[2015-09-07 19:22:10+0000] chown: changing ownership of ‘/var/vcap/nfs/shared’: Operation not permitted

Can somebody help.


Error: Public uaa token must be PEM encoded

JOSE FELIX HERNANDEZ BARRIO
 

Hi,

I'm trying to deploy cloudfoundry on openstack. I'm getting stuck at bosh deploy.

The result from bosh vms:

+------------------------------------+---------+---------------+---------------+
| Job/index | State | Resource Pool | IPs |
+------------------------------------+---------+---------------+---------------+
| api_worker_z1/0 | running | small_z1 | 10.2.0.105 |
| api_z1/0 | failing | large_z1 | 10.2.0.103 |
| clock_global/0 | running | medium_z1 | 10.2.0.104 |
| doppler_z1/0 | running | medium_z1 | 10.2.0.108 |
| etcd_z1/0 | running | medium_z1 | 10.2.0.58 |
| ha_proxy_z1/0 | running | router_z1 | 10.2.0.50 |
| | | | 192.168.1.203 |
| hm9000_z1/0 | running | medium_z1 | 10.2.0.106 |
| loggregator_trafficcontroller_z1/0 | running | small_z1 | 10.2.0.109 |
| nats_z1/0 | running | medium_z1 | 10.2.0.52 |
| nfs_z1/0 | running | medium_z1 | 10.2.0.53 |
| postgres_z1/0 | running | medium_z1 | 10.2.0.54 |
| router_z1/0 | running | router_z1 | 10.2.0.55 |
| runner_z1/0 | running | runner_z1 | 10.2.0.107 |
| stats_z1/0 | running | small_z1 | 10.2.0.101 |
| uaa_z1/0 | running | medium_z1 | 10.2.0.102 |
+------------------------------------+---------+---------------+---------------+


So i check monit summary at api_z1:

Process 'cloud_controller_ng' running
Process 'cloud_controller_worker_local_1' running
Process 'cloud_controller_worker_local_2' running
Process 'nginx_cc' running
Process 'cloud_controller_migration' running
Process 'routing-api' not monitored
Process 'metron_agent' running
Process 'statsd-injector' running
Process 'consul_agent' running
File 'nfs_mounter' accessible
System 'system_10391701-0eec-4e27-916b-5b9d95f86cbc' runnin


Then i check the log file /var/vcap/sys/log/routing-api/routing-api.log and it has the message:
{"timestamp":"1441587481.040446758","source":"routing-api","message":"routing-api.failed to check public token","log_level":2,"data":{"error":"Public uaa token must be PEM encoded"}}


what am i doing wrong in my cf-deployment.yml?

my cf-deployment.yml https://gist.github.com/josefhernandez/0f022c38f25539f9db7b



Best regards


Re: Deploy CF Diego Release on OpenStack

王天青 <wang.tianqing.cn at gmail.com...>
 

Thanks

Johannes Hiemer <jvhiemer(a)gmail.com>于2015年9月6日周日 下午5:14写道:

Hi Wang,
I wrote a blog post you can read about here:
http://www.evoila.de/cloud-foundry/adding-diego-release-to-cloud-foundry-release-v212/?lang=en

On Sun, Sep 6, 2015 at 7:02 AM, <wang.tianqing.cn(a)gmail.com> wrote:

Hi all,

When deploying Cloud Foundry on OpenStack using BOSH, there is a good
reference doc:
http://docs.cloudfoundry.org/deploying/openstack/install_cf_openstack.html
.

For Diego release, is there any similar docs? If more specifically, is
there any sample deployment manifest file? Like cf-stub.yml, thanks.

Best Regards!

$ ./generate_deployment_manifest openstack cf-stub.yml > cf-deployment.yml



--
Mit freundlichen Grüßen

Johannes Hiemer
--
Best Regards~!
Grissom


Re: Deploy CF Diego Release on OpenStack

Johannes Hiemer
 

On Sun, Sep 6, 2015 at 7:02 AM, <wang.tianqing.cn(a)gmail.com> wrote:

Hi all,

When deploying Cloud Foundry on OpenStack using BOSH, there is a good
reference doc:
http://docs.cloudfoundry.org/deploying/openstack/install_cf_openstack.html
.

For Diego release, is there any similar docs? If more specifically, is
there any sample deployment manifest file? Like cf-stub.yml, thanks.

Best Regards!

$ ./generate_deployment_manifest openstack cf-stub.yml > cf-deployment.yml


--
Mit freundlichen Grüßen

Johannes Hiemer


Deploy CF Diego Release on OpenStack

王天青 <wang.tianqing.cn at gmail.com...>
 

Hi all,

When deploying Cloud Foundry on OpenStack using BOSH, there is a good reference doc: http://docs.cloudfoundry.org/deploying/openstack/install_cf_openstack.html.

For Diego release, is there any similar docs? If more specifically, is there any sample deployment manifest file? Like cf-stub.yml, thanks.

Best Regards!
$ ./generate_deployment_manifest openstack cf-stub.yml > cf-deployment.yml


Re: health metrics via bosh

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

Thanks. I will have a look into this.

-- Stephan

Von: Dmitriy Kalinin
Antworten an: "Discussions about the Cloud Foundry BOSH project."
Datum: Dienstag, 1. September 2015 19:25
An: "Discussions about the Cloud Foundry BOSH project."
Betreff: [cf-bosh] Re: health metrics via bosh

It would be great to extend HM to support Riemann.

Please see hm's README: https://github.com/cloudfoundry/bosh/tree/master/bosh-monitor for how to extend it.

You can find all available plugins in here: https://github.com/cloudfoundry/bosh/tree/master/bosh-monitor/lib/bosh/monitor/plugins

On Tue, Sep 1, 2015 at 2:20 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com<mailto:stephan.klevenz(a)sap.com>> wrote:
Hi,

Some health metrics disappeared from our dashboard mentioned in this issue [1].

The proposal is to get these health metrics from bosh [2] instead. Do you have an example how bosh health monitor works and how metrics can be forwarded to a Riemann consumer?

Our current CF deployment is 211.

Thanks in advance.

Regards,
Stephan

[1] https://github.com/cloudfoundry/loggregator/issues/72
[2] https://bosh.io/docs/bosh-components.html#health-monitor


Re: Live Migrating OpenStack VMs between physical nodes

ramonskie
 

most of time with live migration you should only experience a few seconds of downtime

-----Original Message-----
From: Dmitriy Kalinin <dkalinin(a)pivotal.io<mailto:Dmitriy%20Kalinin%20%3cdkalinin(a)pivotal.io%3e>>
Reply-to: Discussions about the Cloud Foundry BOSH project. <cf-bosh(a)lists.cloudfoundry.org>
To: Discussions about the Cloud Foundry BOSH project. <cf-bosh(a)lists.cloudfoundry.org<mailto:%22Discussions%20about%20the%20Cloud%20Foundry%20BOSH%20project.%22%20%3ccf-bosh(a)lists.cloudfoundry.org%3e>>
Subject: [cf-bosh] Re: Re: Re: Live Migrating OpenStack VMs between physical nodes
Date: Wed, 2 Sep 2015 10:11:00 -0700

I am not too familiar with OpenStack's *live* migration. Do VMs lose connectivity when moved around by OpenStack?
On Wed, Sep 2, 2015 at 1:02 AM, Makkelie, R (ITCDCC) - KLM <Ramon.Makkelie(a)klm.com<mailto:Ramon.Makkelie(a)klm.com>> wrote:
when you want to migrate or evacuate hosts
you will notice that bosh will try to respawn the vms/jobs he created because of the health monitor

so what we normally do is disable the bosh health monitor until the the nodes are done

greetz
Ramonskie


-----Original Message-----
From: Dmitriy Kalinin <dkalinin(a)pivotal.io<mailto:Dmitriy%20Kalinin%20%3cdkalinin(a)pivotal.io%3e>>
Reply-to: Discussions about the Cloud Foundry BOSH project. <cf-bosh(a)lists.cloudfoundry.org<mailto:cf-bosh(a)lists.cloudfoundry.org>>
To: Discussions about the Cloud Foundry BOSH project. <cf-bosh(a)lists.cloudfoundry.org<mailto:%22Discussions%20about%20the%20Cloud%20Foundry%20BOSH%20project.%22%20%3ccf-bosh(a)lists.cloudfoundry.org%3e>>
Subject: [cf-bosh] Re: Live Migrating OpenStack VMs between physical nodes
Date: Tue, 1 Sep 2015 10:48:06 -0700

OpenStack CPI does not care / is not aware on which node VMs are running.

As long as VM remains powered on and accessible you should not have a problem. In practice you may run into certain OpenStack limitations which may prevent moving VMs around. I vaguely remember presence of a config drive (CPI is configured to bootstrap VMs via config drive) may limit VM relocation.
On Tue, Sep 1, 2015 at 10:12 AM, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote:
Hi All,


I've had a question from my client's IT department that I thought I would run by you before actually just trying it. We're running open source Cloud Foundry on OpenStack, and the admin was wondering if the CPI could handle a particular VM (or a set of vms) being transferred from one physical node to another for something like maintenance on the original node.


My first thought is that it shouldn't affect anything in the CPI, since OpenStack is handling the VM provisioning and locating, but I was curious if anyone had practical experience with this.


Thanks!

Josh Ghiloni

Senior Consultant

303.932.2202<tel:303.932.2202> o | 303.590.5427<tel:303.590.5427> m | 303.565.2794<tel:303.565.2794> f

jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>



ECS Team

Technology Solutions Delivered

ECSTeam.com<http://www.ecsteam.com/>






********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************



********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


Re: Bosh target password.

Guruprakash Srinivasamurthy <guruprakashsrinivasamurthy@...>
 

Thanks,Dmitriy. That helps.

On Wed, Sep 2, 2015 at 11:14 AM, Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

If you are able to upgrade (with bosh-init or micro deploy) to a newer
version of BOSH ( v177+ / 1.2999.0) you can redeploy your Director with
pre-configured users as explained in
https://bosh.io/docs/director-users.html#preconfigured. When
pre-configured users are enabled, database users are ignored.

We are actually planning to remove db users in favor of pre-configured
users or UAA provided users once I finish writing documentation about how
BOSH works with UAA.

On Wed, Sep 2, 2015 at 10:53 AM, Guruprakash Srinivasamurthy <
guruprakashsrinivasamurthy(a)gmail.com> wrote:

Hi,

We lost track of password for one of the micro bosh director and we are
unable to login to the target.

Is there a way we can reset the password that we use to target the bosh
director ?



Thanks,
Guru.


Re: Bosh target password.

Dmitriy Kalinin
 

If you are able to upgrade (with bosh-init or micro deploy) to a newer
version of BOSH ( v177+ / 1.2999.0) you can redeploy your Director with
pre-configured users as explained in
https://bosh.io/docs/director-users.html#preconfigured. When pre-configured
users are enabled, database users are ignored.

We are actually planning to remove db users in favor of pre-configured
users or UAA provided users once I finish writing documentation about how
BOSH works with UAA.

On Wed, Sep 2, 2015 at 10:53 AM, Guruprakash Srinivasamurthy <
guruprakashsrinivasamurthy(a)gmail.com> wrote:

Hi,

We lost track of password for one of the micro bosh director and we are
unable to login to the target.

Is there a way we can reset the password that we use to target the bosh
director ?



Thanks,
Guru.


Bosh target password.

Guruprakash Srinivasamurthy <guruprakashsrinivasamurthy@...>
 

Hi,

We lost track of password for one of the micro bosh director and we are
unable to login to the target.

Is there a way we can reset the password that we use to target the bosh
director ?



Thanks,
Guru.


Re: Live Migrating OpenStack VMs between physical nodes

Dmitriy Kalinin
 

I am not too familiar with OpenStack's *live* migration. Do VMs lose
connectivity when moved around by OpenStack?

On Wed, Sep 2, 2015 at 1:02 AM, Makkelie, R (ITCDCC) - KLM <
Ramon.Makkelie(a)klm.com> wrote:

when you want to migrate or evacuate hosts
you will notice that bosh will try to respawn the vms/jobs he created
because of the health monitor

so what we normally do is disable the bosh health monitor until the the
nodes are done

greetz
Ramonskie


-----Original Message-----
*From*: Dmitriy Kalinin <dkalinin(a)pivotal.io
<Dmitriy%20Kalinin%20%3cdkalinin(a)pivotal.io%3e>>
Reply-to: Discussions about the Cloud Foundry BOSH project. <
cf-bosh(a)lists.cloudfoundry.org>
*To*: Discussions about the Cloud Foundry BOSH project. <
cf-bosh(a)lists.cloudfoundry.org
<%22Discussions%20about%20the%20Cloud%20Foundry%20BOSH%20project.%22%20%3ccf-bosh(a)lists.cloudfoundry.org%3e>
*Subject*: [cf-bosh] Re: Live Migrating OpenStack VMs between physical
nodes
*Date*: Tue, 1 Sep 2015 10:48:06 -0700

OpenStack CPI does not care / is not aware on which node VMs are running.

As long as VM remains powered on and accessible you should not have a
problem. In practice you may run into certain OpenStack limitations which
may prevent moving VMs around. I vaguely remember presence of a config
drive (CPI is configured to bootstrap VMs via config drive) may limit VM
relocation.
On Tue, Sep 1, 2015 at 10:12 AM, Josh Ghiloni <jghiloni(a)ecsteam.com>
wrote:

Hi All,



I've had a question from my client's IT department that I thought I would
run by you before actually just trying it. We're running open source Cloud
Foundry on OpenStack, and the admin was wondering if the CPI could handle a
particular VM (or a set of vms) being transferred from one physical node to
another for something like maintenance on the original node.



My first thought is that it shouldn't affect anything in the CPI, since
OpenStack is handling the VM provisioning and locating, but I was curious
if anyone had practical experience with this.



Thanks!


*Josh *Ghiloni

Senior Consultant

303.932.2202 o | 303.590.5427 m | 303.565.2794 f

jghiloni(a)ecsteam.com



*ECS Team*

*Technology Solutions Delivered*

ECSTeam.com <http://www.ecsteam.com/>





********************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail or
any attachment may be disclosed, copied or distributed, and that any other
action related to this e-mail or attachment is strictly prohibited, and may
be unlawful. If you have received this e-mail by error, please notify the
sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission
of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered
number 33014286
********************************************************


Re: Live Migrating OpenStack VMs between physical nodes

ramonskie
 

when you want to migrate or evacuate hosts
you will notice that bosh will try to respawn the vms/jobs he created because of the health monitor

so what we normally do is disable the bosh health monitor until the the nodes are done

greetz
Ramonskie

-----Original Message-----
From: Dmitriy Kalinin <dkalinin(a)pivotal.io<mailto:Dmitriy%20Kalinin%20%3cdkalinin(a)pivotal.io%3e>>
Reply-to: Discussions about the Cloud Foundry BOSH project. <cf-bosh(a)lists.cloudfoundry.org>
To: Discussions about the Cloud Foundry BOSH project. <cf-bosh(a)lists.cloudfoundry.org<mailto:%22Discussions%20about%20the%20Cloud%20Foundry%20BOSH%20project.%22%20%3ccf-bosh(a)lists.cloudfoundry.org%3e>>
Subject: [cf-bosh] Re: Live Migrating OpenStack VMs between physical nodes
Date: Tue, 1 Sep 2015 10:48:06 -0700

OpenStack CPI does not care / is not aware on which node VMs are running.

As long as VM remains powered on and accessible you should not have a problem. In practice you may run into certain OpenStack limitations which may prevent moving VMs around. I vaguely remember presence of a config drive (CPI is configured to bootstrap VMs via config drive) may limit VM relocation.
On Tue, Sep 1, 2015 at 10:12 AM, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote:
Hi All,


I've had a question from my client's IT department that I thought I would run by you before actually just trying it. We're running open source Cloud Foundry on OpenStack, and the admin was wondering if the CPI could handle a particular VM (or a set of vms) being transferred from one physical node to another for something like maintenance on the original node.


My first thought is that it shouldn't affect anything in the CPI, since OpenStack is handling the VM provisioning and locating, but I was curious if anyone had practical experience with this.


Thanks!

Josh Ghiloni

Senior Consultant

303.932.2202<tel:303.932.2202> o | 303.590.5427<tel:303.590.5427> m | 303.565.2794<tel:303.565.2794> f

jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>



ECS Team

Technology Solutions Delivered

ECSTeam.com<http://www.ecsteam.com/>





********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************


Re: Live Migrating OpenStack VMs between physical nodes

Dmitriy Kalinin
 

OpenStack CPI does not care / is not aware on which node VMs are running.

As long as VM remains powered on and accessible you should not have a
problem. In practice you may run into certain OpenStack limitations which
may prevent moving VMs around. I vaguely remember presence of a config
drive (CPI is configured to bootstrap VMs via config drive) may limit VM
relocation.

On Tue, Sep 1, 2015 at 10:12 AM, Josh Ghiloni <jghiloni(a)ecsteam.com> wrote:

Hi All,

I've had a question from my client's IT department that I thought I would
run by you before actually just trying it. We're running open source Cloud
Foundry on OpenStack, and the admin was wondering if the CPI could handle a
particular VM (or a set of vms) being transferred from one physical node to
another for something like maintenance on the original node.

My first thought is that it shouldn't affect anything in the CPI, since
OpenStack is handling the VM provisioning and locating, but I was curious
if anyone had practical experience with this.

Thanks!


* Josh *Ghiloni

Senior Consultant

303.932.2202 o | 303.590.5427 m | 303.565.2794 f

jghiloni(a)ecsteam.com



*ECS Team*

*Technology Solutions Delivered*

ECSTeam.com <http://www.ecsteam.com/>


Re: health metrics via bosh

Dmitriy Kalinin
 

It would be great to extend HM to support Riemann.

Please see hm's README:
https://github.com/cloudfoundry/bosh/tree/master/bosh-monitor for how to
extend it.

You can find all available plugins in here:
https://github.com/cloudfoundry/bosh/tree/master/bosh-monitor/lib/bosh/monitor/plugins

On Tue, Sep 1, 2015 at 2:20 AM, Klevenz, Stephan <stephan.klevenz(a)sap.com>
wrote:

Hi,

Some health metrics disappeared from our dashboard mentioned in this issue
[1].

The proposal is to get these health metrics from bosh [2] instead. Do you
have an example how bosh health monitor works and how metrics can be
forwarded to a Riemann consumer?

Our current CF deployment is 211.

Thanks in advance.

Regards,
Stephan

[1] https://github.com/cloudfoundry/loggregator/issues/72
[2] https://bosh.io/docs/bosh-components.html#health-monitor


Live Migrating OpenStack VMs between physical nodes

Josh Ghiloni
 

Hi All,

I've had a question from my client's IT department that I thought I would run by you before actually just trying it. We're running open source Cloud Foundry on OpenStack, and the admin was wondering if the CPI could handle a particular VM (or a set of vms) being transferred from one physical node to another for something like maintenance on the original node.

My first thought is that it shouldn't affect anything in the CPI, since OpenStack is handling the VM provisioning and locating, but I was curious if anyone had practical experience with this.

Thanks!

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com

ECS Team
Technology Solutions Delivered
ECSTeam.com<http://www.ecsteam.com/>

2061 - 2080 of 2761