Date   

Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

DHR
 

So I think your problem is that your gems are on the DEA at staging time but aren't being found by the Ruby layer, right?
If so the normal approach is to point to them via an env Var (eg BUNDLE_PATH, GEM_PATH), however your compile, detect, release scripts are already in Ruby (not bash) so perhaps you could load them using Gem.paths. Example on
http://stackoverflow.com/questions/28764389/set-gem-home-path-or-gem-path-programmatically

On 24 May 2016, at 18:08, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:

not an issue .Thanks Dan !!!

On Tue, May 24, 2016 at 4:56 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
OK, my fault. I misunderstood what you're trying to do here. I was thinking that your application needed the gems, but it's your build pack that needs them.

You originally said...

Example : Our modified java buildpack not running on existing stacks because of few of the ruby gems are missing in the file system. so we would require to install few ruby gem and use the modified java buildpack.
If the build pack needs additional gems then you would want to pack the gems with the build pack. I'm not sure what the best way to do this would be, I'm sure someone with more ruby experience can say. Ideas that come to mind: add it as a git submodule, vendor it (seems like what you're doing), maybe just copy the src in if it's small.

Basically the build pack needs to be self contained (especially so that it works in offline environments). Anything it needs, should be included with the build pack.

Dan



On Tue, May 24, 2016 at 1:37 AM, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:
yes Dan,


we have used below commands to package the buildpack .

bundle install
bundle exec rake package version=custom-java-buildpack

after that we will take the zip and create a offline buildpack using cf cli.

Regards
Lingesh M



On Mon, May 23, 2016 at 7:16 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
You need to bundle install the gem in the staging container. The build pack would generally do this.

Dan


On Mon, May 23, 2016 at 8:25 AM, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:
Hi Dan ,

yes I have installed the require gem via bundle install to specify the path of vendor staging directories which is available in below paths

/var/vcap/data/packages/dea_next/* /vendor/cache
/var/vcap/data/packages/warden/*/vendor/cache

using buildpack Gemfile.

Still I am not seeing these require gem is available in staging container. So staging container during compile phase.


Regards
Lingesh M

On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:
Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging directory , but it doesn't help. is this same way followed by existing cloudfoundry java buildpack ??
This is the way you should be doing it. What about this doesn't help / work for you?

Dan




@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com> wrote:
Hi

Enable cloning with repo an make auto update enabled this there is no need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:
Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in existing cf stacks (cflinuxf2) without creating new custom stacks ??

Example : Our modified java buildpack not running on existing stacks because of few of the ruby gems are missing in the file system. so we would require to install few ruby gem and use the modified java buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: can we externalize pivotal repository path in java buildpack??

DHR
 

You could change the config/repository.yml to point to a DNS name on your network. Then build out one or more local repositories on your network using the Java-buildpack-dependency-builder: https://github.com/cloudfoundry/java-buildpack-dependency-builder

And then alias that DNS onto your server(s).

On 24 May 2016, at 18:25, Lingesh Mouleeshwaran <lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

In java-buildpack ,https://download.run.pivotal.io URL is used for
default_repository_root for all binaries , but this URL may not be accessible or very slow in china network. Please can somebody suggest like how can we externalize this repository path so that one buildpack can switch to multiple repositories.


Regards,
Lingesh M


can we externalize pivotal repository path in java buildpack??

Lingesh Mouleeshwaran
 

Hi Cloudfoundry ,

In java-buildpack ,*https://download.run.pivotal.io
<https://download.run.pivotal.io> *URL is used for
default_repository_root for all binaries , but this URL may not be
accessible or very slow in china network. Please can somebody suggest like
how can we externalize this repository path so that one buildpack can
switch to multiple repositories.


Regards,
Lingesh M


Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Lingesh Mouleeshwaran
 

not an issue .Thanks Dan !!!

On Tue, May 24, 2016 at 4:56 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

OK, my fault. I misunderstood what you're trying to do here. I was
thinking that your application needed the gems, but it's your build pack
that needs them.

You originally said...

*Example :* Our modified java buildpack not running on existing stacks
because of few of the ruby gems are missing in the file system. so we would
require to install few ruby gem and use the modified java buildpack.

If the build pack needs additional gems then you would want to pack the
gems with the build pack. I'm not sure what the best way to do this would
be, I'm sure someone with more ruby experience can say. Ideas that come to
mind: add it as a git submodule, vendor it (seems like what you're doing),
maybe just copy the src in if it's small.

Basically the build pack needs to be self contained (especially so that it
works in offline environments). Anything it needs, should be included with
the build pack.

Dan



On Tue, May 24, 2016 at 1:37 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

yes Dan,


we have used below commands to package the buildpack .

bundle install
bundle exec rake package version=custom-java-buildpack

after that we will take the zip and create a offline buildpack using cf
cli.

Regards
Lingesh M



On Mon, May 23, 2016 at 7:16 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

You need to bundle install the gem in the staging container. The build
pack would generally do this.

Dan


On Mon, May 23, 2016 at 8:25 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Dan ,

yes I have installed the require gem via *bundle install* to specify
the path of vendor staging directories which is available in below paths

/var/vcap/data/packages/dea_next/* /vendor/cache
/var/vcap/data/packages/warden/*/vendor/cache

using buildpack Gemfile.

Still I am not seeing these require gem is available in staging
container. So staging container during compile phase.


Regards
Lingesh M

On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging
directory , but it doesn't help. is this same way followed by existing
cloudfoundry java buildpack ??
This is the way you should be doing it. What about this doesn't help
/ work for you?

Dan





@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <
cloudgrp.assist(a)gmail.com> wrote:

Hi

Enable cloning with repo an make auto update enabled this there is
no need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing
stacks because of few of the ruby gems are missing in the file system. so
we would require to install few ruby gem and use the modified java
buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: All-In-One Virtual Machine for CF

Gwenn Etourneau
 

You can take a look at https://github.com/pivotal-cf/pcfdev.

Thanks

On Tue, May 24, 2016 at 4:07 AM, Francesco D'Andria <fradandria(a)gmail.com>
wrote:

Hi all, sorry in advance of the maybe naif question.
I was wondering if I could find somewhere an all-In-One Virtual Machine
with the last version of CF like openshift origin.
thank you in advance and regards
Francesco



Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Daniel Mikusa
 

OK, my fault. I misunderstood what you're trying to do here. I was
thinking that your application needed the gems, but it's your build pack
that needs them.

You originally said...

*Example :* Our modified java buildpack not running on existing stacks
because of few of the ruby gems are missing in the file system. so we would
require to install few ruby gem and use the modified java buildpack.

If the build pack needs additional gems then you would want to pack the
gems with the build pack. I'm not sure what the best way to do this would
be, I'm sure someone with more ruby experience can say. Ideas that come to
mind: add it as a git submodule, vendor it (seems like what you're doing),
maybe just copy the src in if it's small.

Basically the build pack needs to be self contained (especially so that it
works in offline environments). Anything it needs, should be included with
the build pack.

Dan



On Tue, May 24, 2016 at 1:37 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

yes Dan,


we have used below commands to package the buildpack .

bundle install
bundle exec rake package version=custom-java-buildpack

after that we will take the zip and create a offline buildpack using cf
cli.

Regards
Lingesh M



On Mon, May 23, 2016 at 7:16 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

You need to bundle install the gem in the staging container. The build
pack would generally do this.

Dan


On Mon, May 23, 2016 at 8:25 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Dan ,

yes I have installed the require gem via *bundle install* to specify
the path of vendor staging directories which is available in below paths

/var/vcap/data/packages/dea_next/* /vendor/cache
/var/vcap/data/packages/warden/*/vendor/cache

using buildpack Gemfile.

Still I am not seeing these require gem is available in staging
container. So staging container during compile phase.


Regards
Lingesh M

On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging
directory , but it doesn't help. is this same way followed by existing
cloudfoundry java buildpack ??
This is the way you should be doing it. What about this doesn't help /
work for you?

Dan





@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com
wrote:
Hi

Enable cloning with repo an make auto update enabled this there is no
need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing
stacks because of few of the ruby gems are missing in the file system. so
we would require to install few ruby gem and use the modified java
buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


All-In-One Virtual Machine for CF

Francesco D'Andria
 

Hi all, sorry in advance of the maybe naif question.
I was wondering if I could find somewhere an all-In-One Virtual Machine with the last version of CF like openshift origin.
thank you in advance and regards
Francesco


Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Lingesh Mouleeshwaran
 

yes Dan,


we have used below commands to package the buildpack .

bundle install
bundle exec rake package version=custom-java-buildpack

after that we will take the zip and create a offline buildpack using cf cli.

Regards
Lingesh M

On Mon, May 23, 2016 at 7:16 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

You need to bundle install the gem in the staging container. The build
pack would generally do this.

Dan


On Mon, May 23, 2016 at 8:25 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Dan ,

yes I have installed the require gem via *bundle install* to specify the
path of vendor staging directories which is available in below paths

/var/vcap/data/packages/dea_next/* /vendor/cache
/var/vcap/data/packages/warden/*/vendor/cache

using buildpack Gemfile.

Still I am not seeing these require gem is available in staging
container. So staging container during compile phase.


Regards
Lingesh M

On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging
directory , but it doesn't help. is this same way followed by existing
cloudfoundry java buildpack ??
This is the way you should be doing it. What about this doesn't help /
work for you?

Dan





@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com>
wrote:

Hi

Enable cloning with repo an make auto update enabled this there is no
need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing
stacks because of few of the ruby gems are missing in the file system. so
we would require to install few ruby gem and use the modified java
buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: CVE-2016-0781 UAA Password Reset Vulnerability

Sree Tummidi
 

yes, there has been a typo. Thank you for pointing out !
The correct CVE number is : *CVE-2016-3084*



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


On Mon, May 23, 2016 at 10:05 AM, Graham Bleach <
graham.bleach(a)digital.cabinet-office.gov.uk> wrote:

Hi Chip,

On 23 May 2016 at 17:00, Chip Childers <cchilders(a)cloudfoundry.org> wrote:
CVE-2016-0781 UAA Password Reset Vulnerability
I think there might be a typo here as the CVE reference seems to be
the same as for the UAA persistent XSS vulnerability.

G


Re: CVE-2016-0781 UAA Password Reset Vulnerability

Graham Bleach
 

Hi Chip,

On 23 May 2016 at 17:00, Chip Childers <cchilders(a)cloudfoundry.org> wrote:
CVE-2016-0781 UAA Password Reset Vulnerability
I think there might be a typo here as the CVE reference seems to be
the same as for the UAA persistent XSS vulnerability.

G


CVE-2016-0781 UAA Password Reset Vulnerability

Chip Childers <cchilders@...>
 

CVE-2016-0781 UAA Password Reset VulnerabilitySeverity

Low
Vendor

Cloud Foundry Foundation
Versions Affected

-

Cloud Foundry release v236 and earlier versions
-

UAA release v3.3.0 and earlier versions
-

All versions of Login-server
-

UAA release v10 and earlier versions

Description

The UAA reset password flow is vulnerable to a brute force attack due to
multiple active codes at a given time. This vulnerability is applicable
only when using the UAA internal user store for authentication. Deployments
enabled for integration via SAML or LDAP are not affected.
Mitigation

Users are strongly encouraged to follow one of the mitigations below:


-

Upgrade to Cloud Foundry v237 [1] or later
-

For standalone UAA users
-

For users using UAA version 3.3.0 or prior, please upgrade to UAA
Release to v3.3.0.1 [2] or later
-

For users using standalone login-server 1.X, please upgrade to UAA
Release to v3.3.0.1 [2] or later
-

For users using UAA-Release (UAA bosh release), please upgrade to
UAA-Release v11 [3] or later


Credit

GE Digital Inc.
References

[1] https://github.com/cloudfoundry/cf-release/releases/tag/v237

[2] https://github.com/cloudfoundry/uaa/releases/tag/3.3.0.1

[3] https://github.com/cloudfoundry/uaa-release/releases/tag/v11
History

2016-Mar-23: Initial vulnerability report published


Re: DEA Monitoring Capabilities

Chawki, Amin <amin.chawki@...>
 

-What information were you trying to understand from mem_used_bytes?

We used mem_used_bytes and mem_free_bytes (currently metrics from bosh) to get an overview over the real overall memory usage of all apps as an approximation. This helps us to get a better understanding of the current overcommit factor.

-As far as the healthy metric from HM9000, it was quite misleading. It reported healthy as long as the metrics server was running which wasn't any indication of health. What exactly do you want to know?

Ah ok, I was not aware of that. Is there any reliable way to verify whether HM9000 is healthy?

Best Regards and Thanks,
Amin


From: Michael Fraenkel <michael.fraenkel(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Monday 23 May 2016 at 13:17
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: DEA Monitoring Capabilities

When 234 was released, we did not realize that Collector was creating additional metrics. Based on reports, we have added back any missing metrics that people felt were needed. Let me know if we still have missing metrics as you move beyond 234.

In 234, while we did not report available_memory_ratio, we do report remaining_memory. If your DEAs have the same amount of memory, the ratio can be computed or you can use the current value directly.

What information were you trying to understand from mem_used_bytes?

As far as the healthy metric from HM9000, it was quite misleading. It reported healthy as long as the metrics server was running which wasn't any indication of health. What exactly do you want to know?

- Michael

On 5/20/16 4:41 AM, Chawki, Amin wrote:
Hi,

by upgrading to CF v234 (including pre-release v232) we lost all our monitoring capabilities regarding DEA and HM9000 (we were still using Collector). By migrating to Firehose only a fraction of the metrics was available. Very important metrics for our productive systems like ‘available_memory_ratio’ were just added in CF v235. In the meantime, we were pretty much “flying blind”.

We replaced not existing metrics like ‘DEA…mem_used_bytes’ and ‘HM9000…healthy’, which were available via Collector, with metrics from Bosh. Is this the way to go or are there any plans to add them again?

Best Regards,
Amin


Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Daniel Mikusa
 

You need to bundle install the gem in the staging container. The build
pack would generally do this.

Dan


On Mon, May 23, 2016 at 8:25 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Dan ,

yes I have installed the require gem via *bundle install* to specify the
path of vendor staging directories which is available in below paths

/var/vcap/data/packages/dea_next/* /vendor/cache
/var/vcap/data/packages/warden/*/vendor/cache

using buildpack Gemfile.

Still I am not seeing these require gem is available in staging container.
So staging container during compile phase.


Regards
Lingesh M

On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging directory
, but it doesn't help. is this same way followed by existing cloudfoundry
java buildpack ??
This is the way you should be doing it. What about this doesn't help /
work for you?

Dan





@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com>
wrote:

Hi

Enable cloning with repo an make auto update enabled this there is no
need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing
stacks because of few of the ruby gems are missing in the file system. so
we would require to install few ruby gem and use the modified java
buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Lingesh Mouleeshwaran
 

Hi Dan ,

yes I have installed the require gem via *bundle install* to specify the
path of vendor staging directories which is available in below paths

/var/vcap/data/packages/dea_next/* /vendor/cache
/var/vcap/data/packages/warden/*/vendor/cache

using buildpack Gemfile.

Still I am not seeing these require gem is available in staging container.
So staging container during compile phase.


Regards
Lingesh M

On Mon, May 23, 2016 at 5:35 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging directory
, but it doesn't help. is this same way followed by existing cloudfoundry
java buildpack ??
This is the way you should be doing it. What about this doesn't help /
work for you?

Dan





@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com>
wrote:

Hi

Enable cloning with repo an make auto update enabled this there is no
need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing stacks
because of few of the ruby gems are missing in the file system. so we would
require to install few ruby gem and use the modified java buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Daniel Mikusa
 

On Mon, May 23, 2016 at 3:41 AM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging directory ,
but it doesn't help. is this same way followed by existing cloudfoundry
java buildpack ??
This is the way you should be doing it. What about this doesn't help /
work for you?

Dan





@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com>
wrote:

Hi

Enable cloning with repo an make auto update enabled this there is no
need to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing stacks
because of few of the ruby gems are missing in the file system. so we would
require to install few ruby gem and use the modified java buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: DEA Monitoring Capabilities

Michael Fraenkel <michael.fraenkel@...>
 

When 234 was released, we did not realize that Collector was creating
additional metrics. Based on reports, we have added back any missing
metrics that people felt were needed. Let me know if we still have
missing metrics as you move beyond 234.

In 234, while we did not report available_memory_ratio, we do report
remaining_memory. If your DEAs have the same amount of memory, the ratio
can be computed or you can use the current value directly.

What information were you trying to understand from mem_used_bytes?

As far as the healthy metric from HM9000, it was quite misleading. It
reported healthy as long as the metrics server was running which wasn't
any indication of health. What exactly do you want to know?

- Michael

On 5/20/16 4:41 AM, Chawki, Amin wrote:

Hi,

by upgrading to CF v234 (including pre-release v232) we lost all our
monitoring capabilities regarding DEA and HM9000 (we were still using
Collector). By migrating to Firehose only a fraction of the metrics
was available. Very important metrics for our productive systems like
‘available_memory_ratio’ were just added in CF v235. In the meantime,
we were pretty much “flying blind”.

We replaced not existing metrics like ‘DEA…mem_used_bytes’ and
‘HM9000…healthy’, which were available via Collector, with metrics
from Bosh. Is this the way to go or are there any plans to add them again?

Best Regards,

Amin


Re: can we install ruby gems in existing cf stacks (cflinuxfs2) without recreate stack

Lingesh Mouleeshwaran
 

Thanks DHR and Sunil ,

@ DHR , I have followed your way to install the gem on staging directory ,
but it doesn't help. is this same way followed by existing cloudfoundry
java buildpack ??


@ Sunil ,

Please could you elaborate more on your approach , I coudn't get your
suggestion.


Regards
Lingesh M

On Fri, May 20, 2016 at 7:56 AM, Sunil Babu <cloudgrp.assist(a)gmail.com>
wrote:

Hi

Enable cloning with repo an make auto update enabled this there is no need
to install


On Thursday, May 19, 2016, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:

Hi Cloudfoundry ,

Is there any simple way, we can update or install new libraries in
existing cf stacks (cflinuxf2) without creating new custom stacks ??

*Example :* Our modified java buildpack not running on existing stacks
because of few of the ruby gems are missing in the file system. so we would
require to install few ruby gem and use the modified java buildpack.

Share your thoughts and suggestions.

Regards
Lingesh M

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608


Re: Cloud Foundry API - Should users be able to remove themselves from an Org or Space?

Charles Wu
 

Nick,

The last two seem to be too strict. A user should be able to remove
themselves from spaces as long as the organization has an OrgManager who
has the power to reassign users to the space in the appropriate roles.
Curious how others look at it.

The policies otherwise described are consistent with what we permit on
Pivotal Web Services.

Charles Wu
Product Owner Pivotal Web Services
(run.pivotal.io)

On Fri, May 20, 2016 at 12:14 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi Cloud Foundry,

We have a request from an API client that would like for users to be able
to remove themselves from an Organization or Space. This allows
self-service without the app obtaining an admin token to remove the user.

Several restrictions that we might want to incorporate:

- Deny if the user is the last User in the org?
- Deny if the user is the last Org Manager in the org?
- Deny if the user is the last Billing Manager in the org?
- Deny if the user is the last User in the space?
- Deny if the user is the last SpaceManager in the space?


Any objections to this or any other restrictions we should consider?


Thanks,

Nick


Cloud Foundry API - Should users be able to remove themselves from an Org or Space?

Nicholas Calugar
 

Hi Cloud Foundry,

We have a request from an API client that would like for users to be able
to remove themselves from an Organization or Space. This allows
self-service without the app obtaining an admin token to remove the user.

Several restrictions that we might want to incorporate:

- Deny if the user is the last User in the org?
- Deny if the user is the last Org Manager in the org?
- Deny if the user is the last Billing Manager in the org?
- Deny if the user is the last User in the space?
- Deny if the user is the last SpaceManager in the space?


Any objections to this or any other restrictions we should consider?


Thanks,

Nick


Re: DEA Monitoring Capabilities

Jim CF Campbell
 

Looks like the Runtime team took some out in v234, added them back in in
v235.

From the Runtime Slack:




On Fri, May 20, 2016 at 11:47 AM, Jim CF Campbell <jcampbell(a)pivotal.io>
wrote:

Yep, I've had a back thread with Runtime OG who now has the DEA metrics
and who I thought had implemented all previous /varz (aka Collector)
metrics into the firehose. No answer from Mr Fraenkel yet.

On Fri, May 20, 2016 at 11:15 AM, Voelz, Marco <marco.voelz(a)sap.com>
wrote:

Including Jim Campbell to make sure this reaches him.



On 20/05/16 13:41, "Chawki, Amin" <amin.chawki(a)sap.com> wrote:



Hi,



by upgrading to CF v234 (including pre-release v232) we lost all our
monitoring capabilities regarding DEA and HM9000 (we were still using
Collector). By migrating to Firehose only a fraction of the metrics was
available. Very important metrics for our productive systems like
‘available_memory_ratio’ were just added in CF v235. In the meantime, we
were pretty much “flying blind”.



We replaced not existing metrics like ‘DEA…mem_used_bytes’ and
‘HM9000…healthy’, which were available via Collector, with metrics from
Bosh. Is this the way to go or are there any plans to add them again?



Best Regards,

Amin






--
Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963


--
Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963