Date   

Re: User cannot do CF login when UAA is being updated

Yunata, Ricky <rickyy@...>
 

Hi Amit,

I have open up Github issue for about a week already now but I get no reply at all..
https://github.com/cloudfoundry/uaa/issues/229
I would appreciate if anyone can tell me whether this is the normal behaviour for UAA, or is it that I have a wrong configuration in my manifest file.

Regards,
Ricky


From: Amit Gupta [mailto:agupta(a)pivotal.io]
Sent: Wednesday, 23 September 2015 9:58 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: User cannot do CF login when UAA is being updated

Hi Ricky,

I reviewed the files you sent to Joseph (via Dies). It looks like you're experiencing several different issues (you have a deployment that has no login job, and then later does? you're doing "cf auth" in a loop and at some point the CLI complains that you never set the API?). Also looks like this is being done in a bunch of different scenarios: update stemcell, change flavour, etc. Finally, it's hard for the community to benefit from the investigation because the information is in files that aren't public.

Can I recommend the following courses of action:

* open up a Github issue (it is easier for the core developers to track, and @-mention developers from CLI and UAA, etc.)
* make sure there are separate issues created for each distinct error or deployment scenario; if two errors seem closely related, it's reasonable to mention them in the same issue, otherwise please create separate issues and provide links to other issues that are loosely related
* include any manifest, scripts, or terminal output in text format that can be copied, pasted, and searched. Sites like gist.github.com<http://gist.github.com> and pastebin make this easy, instead of using screenshots.

We look forward to helping you!

Best,
Amit

On Wed, Sep 16, 2015 at 2:07 AM, CF Runtime <cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>> wrote:
If you can't get the list to accept the attachment, you can give it to Dies and he should be able to get it to us.

Joseph
OSS Release Integration Team

On Tue, Sep 15, 2015 at 7:19 PM, Yunata, Ricky <rickyy(a)fast.au.fujitsu.com<mailto:rickyy(a)fast.au.fujitsu.com>> wrote:
Hi Joseph,

Yes that is the case. I have sent my test result but it seems that my e-mail does not get through. How can I sent attachment in this mailing list?

Regards,
Ricky


From: CF Runtime [mailto:cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>]
Sent: Tuesday, 15 September 2015 8:10 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Re: User cannot do CF login when UAA is being updated

Couple of updates here for clarity. No databases are stored on NFS in any default installation. NFS is only used to store blobstore data. If you are using the postgres job from cf-release, since it is single node there will be downtime during a stemcell deploy.

I talked with Dies from Fujitsu earlier and confirmed they are NOT using the postgres job but an external non-cf deployed postgres instance. So during a deploy, the UAA db should be up and available the entire time.

The issue they are seeing is that even though the database is up, and I'm guessing there is at least a single node of UAA up during the deploy, there are still login failures.

Joseph
OSS Release Integration Team

On Mon, Sep 14, 2015 at 6:39 PM, Filip Hanik <fhanik(a)pivotal.io<mailto:fhanik(a)pivotal.io>> wrote:
Amit, see previous comment.

Postgresql database is stored on NFS that is restarted during nfs job update.
UAA, while being up, is non functional while the NFS job is updated because it can't get to the DB.



On Mon, Sep 14, 2015 at 5:09 PM, Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> wrote:
Hi Ricky,

My understanding is that you still need help, and the issues Jiang and Alexander raised are different. To avoid confusion, let's keep this thread focused on your issue.

Can you confirm that you have two UAA VMs in separate bosh jobs, separate AZs, etc. Can you confirm that when you roll the UAAs, only one goes down at a time? The simplest way to affect a roll is to change some trivial property in the manifest for your UAA jobs. If you're using v215, any of the properties referenced here will do:

https://github.com/cloudfoundry/cf-release/blob/v215/jobs/uaa/spec#L321-L335

You should confirm that only one UAA is down at a time, and comes back up before bosh moves on to updating the other UAA.

While this roll is happening, can you just do `CF_TRACE=true cf auth USERNAME PASSWORD` in a loop, and if you see one that fails, post the output, along with noting the state of the bosh deploy when the error happens.

Thanks,
Amit

On Mon, Sep 14, 2015 at 10:51 AM, Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> wrote:
Ricky, Jiang, Alexander, are the three of you working together? It's hard to tell since you've got Fujitsu, Gmail, and Altoros email addresses. Are you folks talking about the same issue with the same deployment, or three separate issues.

Ricky, if you still need assistance with your issue, please let us know.

On Mon, Sep 14, 2015 at 10:16 AM, Lomov Alexander <alexander.lomov(a)altoros.com<mailto:alexander.lomov(a)altoros.com>> wrote:
Yes, the problem is that postgresql database is stored on NFS that is restarted during nfs job update. I’m sure that you’ll be able to run updates without outage with several customizations.

It is hard to tell without knowing your environment, but in common case steps will be following:


1. Add additional instances to nfs job and customize it to make replications (for instance use this docs for release customization [1])
2. Make your NFS job to update sequently without our jobs updates in parallel (like it is done for postgresql [2])
3. Check your options in update section [3].

[1] https://help.ubuntu.com/community/HighlyAvailableNFS
[2] https://github.com/cloudfoundry/cf-release/blob/master/example_manifests/minimal-aws.yml#L115-L116
[3] https://github.com/cloudfoundry/cf-release/blob/master/example_manifests/minimal-aws.yml#L57-L62

On Sep 14, 2015, at 9:47 AM, Yitao Jiang <jiangyt.cn(a)gmail.com<mailto:jiangyt.cn(a)gmail.com>> wrote:

On upgrading the deployment, the uaa not working due the uaadb filesystem hangup.Under my environment , the nfs-wal-server's ip changed which causing uaadb,ccdb hang up. Hard reboot the uaadb, restart uaa service solve the issue.

Hopes can help you.

On Mon, Sep 14, 2015 at 2:13 PM, Yunata, Ricky <rickyy(a)fast.au.fujitsu.com<mailto:rickyy(a)fast.au.fujitsu.com>> wrote:
Hello,

I have a question regarding UAA in Cloud Foundry. I’m currently running Cloud Foundry on Openstack.
I have 2 availability zones and redundancy of the important VMs including UAA.
Whenever I do an upgrade of either stemcell or CF release, user will not be able to do CF login when when CF is updating UAA VM.
My question is, is this a normal behaviour? If I have redundant UAA VM, shouldn’t user still be able to still login to the apps even though it’s being updated?
I’ve done this test a few times, with different CF version and stemcells and all of them are giving me the same result. The latest test that I’ve done was to upgrade CF version from 212 to 215.
Has anyone experienced the same issue?

Regards,
Ricky
Disclaimer

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


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


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




--

Regards,

Yitao
jiangyt.github.io<http://jiangyt.github.io/>





Disclaimer

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


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


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


Disclaimer

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


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


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


Re: cloud_controller_ng performance degrades slowly over time

Matt Cholick
 

Memory doesn't look problematic:

[image: Inline image 1]

On Thu, Oct 1, 2015 at 2:38 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey Matt,

Do you notice if the memory that the cc process is using increases by a
large amount over that time?

-Zach and Jeff


Proposing a change to the Project Lead for Logging and Metrics

Dieu Cao <dcao@...>
 

Hello All,

Pivotal has asked Erik Jasiak, the current Project Lead for the Logging and
Metrics team, to focus on another Pivotal project. Therefore, Pivotal
would like to nominate Jim Campbell as the new Project Lead for the team.

Jim's experience as a PM for Pivotal and his familiarity with the team's
working habits means he will maintain the team's velocity as they continue
to deliver on the backlog. Jim has worked as a PM on a variety of products
including virtual machines up through multi-tenant SaaS stacks. Jim's
command of both technical products and integrated systems will enable him
to establish command of the subject matter quickly.

We plan to propose this change at the Runtime PMC meeting next week.

-Dieu
Runtime PMC Lead


Re: cloud_controller_ng performance degrades slowly over time

Zach Robinson
 

Hey Matt,

Do you notice if the memory that the cc process is using increases by a large amount over that time?

-Zach and Jeff


Re: [cf-bosh] proposed stemcell network performance tuning

Benjamin Black
 

there are two problems:

1) certain load balancer versions and configurations have unexpected
behavior around tcp timestamps when there is a mix of windows and
non-windows clients (really a mix of timestamps and not-timestamps). the
result is the linux servers in cloud foundry sending resets long before
ports are exhausted.

2) to date, these parameters have been configured in an ad hoc fashion as
problems are encountered leading to a lot of variation in configuration
across the various cloud foundry components. the ad hoc solutions have in
some cases even been counter-productive: tcp_tw_recycle was previously
enabled on some components, exacerbating #1.

the changes amit proposes are not exhaustive, but rather conservative and
address exactly these two problems. other tuning might be beneficial to the
platform. such additional tuning is not required for these scenarios.


b

On Wed, Sep 30, 2015 at 6:05 PM, Joshua McKenty <jmckenty(a)pivotal.io> wrote:

Amit - I worry about changes to the former in the context of HTTP 1.0 and
1.1, especially without pipelining. What problem are you trying to solve?

If you’re having trouble initiating new sockets, there are other kernel
params we should adjust.


On Sep 29, 2015, at 5:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi all,

I'd like to propose tuning a couple kernel parameters related to tcp
performance:

# TCP_FIN_TIMEOUT
# This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse
# its resources. During this TIME_WAIT state, reopening the connection to
the client costs less than establishing
# a new connection. By reducing the value of this entry, TCP/IP can
release closed connections faster, making more
# resources available for new connections. Adjust this in the presence of
many connections sitting in the
# TIME_WAIT state:

echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout

# TCP_TW_REUSE
# This allows reusing sockets in TIME_WAIT state for new connections when
it is safe from protocol viewpoint.
# Default value is 0 (disabled). It is generally a safer alternative to
tcp_tw_recycle

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Currently, these parameters are set by certain jobs in cf-release,
diego-release, and perhaps others. Any VM needing to establish a high
number of incoming/outgoing tcp connections in a short period of time will
be unable to establish new connections without changing these parameters.

We believe these parameters are safe to change across the board, and will
be generally beneficial. The existing defaults made sense for much older
networks, but can be greatly optimized for modern systems.

Please share with the mailing lists if you have any questions or feedback
about this proposal. If you maintain a bosh release and would like to see
how these changes would affect your release, you can create a job which
simply does the above in its startup scripts, and colocate that job with
all the other jobs in a deployment of your release.

Thanks,

Amit Gupta
Cloud Foundry PM, OSS Release Integration team



Re: [cf-bosh] proposed stemcell network performance tuning

Amit Kumar Gupta
 

Hey Josh,

The problem we're trying to solve is that several components set those
parameters. Normally someone introduces a component, then at some later
point in time the component experiences a bunch of load that it can't
handle, and then eventually someone realizes they should set those
parameters. If it's safe to do so, seems better to just always have those
parameters tuned to more optimal values.

Could you explain a bit more about what you mean with regards to HTTP
1.0/1.1 and pipelining?

Thanks,
Amit

On Thu, Oct 1, 2015 at 1:24 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey John,

Yes, that's come up a number of places now, and we plan on upping the
(userland) nf_conntrack_max parameter on the DEA as well, we're still
trying to figure out a sane default for that:

https://www.pivotaltracker.com/story/show/104554676

The tcp_fin_timeout and tcp_tw_reuse are separate kernel parameters that
need to be tuned as well, and currently the DEA (and a couple other
components) do this. But we think any BOSH-deployed service will need
something like this, hence the proposal to put it in the stemcell.

Thanks,
Amit

On Thu, Oct 1, 2015 at 1:07 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

My knowledge of linux networking could fit on a postage stamp, but this
thread reminded me of something we came across recently during performance
testing: "ip_conntrack: table full, dropping packet" errors on the DEA's.
No requests would make it to any app for a period and then a small portion
would make it through once closed tcp connections were released.

As a very short term fix we upped the ip_conntrack_max value on the dea's
to continue (we were focusing on the Gorouters and HAProxies primarily at
this time). We were running a small number of DEA's, far smaller than we
would run in production, so apps were concentrated on DEA's more than they
should be, and as such we have it logged as something to focus on in more
detail in the near future, but I am interested to see where network
performance tuning discussions go.

John

On Thu, Oct 1, 2015 at 2:05 AM, Joshua McKenty <jmckenty(a)pivotal.io>
wrote:

Amit - I worry about changes to the former in the context of HTTP 1.0
and 1.1, especially without pipelining. What problem are you trying to
solve?

If you’re having trouble initiating new sockets, there are other kernel
params we should adjust.


On Sep 29, 2015, at 5:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi all,

I'd like to propose tuning a couple kernel parameters related to tcp
performance:

# TCP_FIN_TIMEOUT
# This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse
# its resources. During this TIME_WAIT state, reopening the connection
to the client costs less than establishing
# a new connection. By reducing the value of this entry, TCP/IP can
release closed connections faster, making more
# resources available for new connections. Adjust this in the presence
of many connections sitting in the
# TIME_WAIT state:

echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout

# TCP_TW_REUSE
# This allows reusing sockets in TIME_WAIT state for new connections
when it is safe from protocol viewpoint.
# Default value is 0 (disabled). It is generally a safer alternative to
tcp_tw_recycle

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Currently, these parameters are set by certain jobs in cf-release,
diego-release, and perhaps others. Any VM needing to establish a high
number of incoming/outgoing tcp connections in a short period of time will
be unable to establish new connections without changing these parameters.

We believe these parameters are safe to change across the board, and
will be generally beneficial. The existing defaults made sense for much
older networks, but can be greatly optimized for modern systems.

Please share with the mailing lists if you have any questions or
feedback about this proposal. If you maintain a bosh release and would
like to see how these changes would affect your release, you can create a
job which simply does the above in its startup scripts, and colocate that
job with all the other jobs in a deployment of your release.

Thanks,

Amit Gupta
Cloud Foundry PM, OSS Release Integration team



Re: [cf-bosh] proposed stemcell network performance tuning

Amit Kumar Gupta
 

Hey John,

Yes, that's come up a number of places now, and we plan on upping the
(userland) nf_conntrack_max parameter on the DEA as well, we're still
trying to figure out a sane default for that:

https://www.pivotaltracker.com/story/show/104554676

The tcp_fin_timeout and tcp_tw_reuse are separate kernel parameters that
need to be tuned as well, and currently the DEA (and a couple other
components) do this. But we think any BOSH-deployed service will need
something like this, hence the proposal to put it in the stemcell.

Thanks,
Amit

On Thu, Oct 1, 2015 at 1:07 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

My knowledge of linux networking could fit on a postage stamp, but this
thread reminded me of something we came across recently during performance
testing: "ip_conntrack: table full, dropping packet" errors on the DEA's.
No requests would make it to any app for a period and then a small portion
would make it through once closed tcp connections were released.

As a very short term fix we upped the ip_conntrack_max value on the dea's
to continue (we were focusing on the Gorouters and HAProxies primarily at
this time). We were running a small number of DEA's, far smaller than we
would run in production, so apps were concentrated on DEA's more than they
should be, and as such we have it logged as something to focus on in more
detail in the near future, but I am interested to see where network
performance tuning discussions go.

John

On Thu, Oct 1, 2015 at 2:05 AM, Joshua McKenty <jmckenty(a)pivotal.io>
wrote:

Amit - I worry about changes to the former in the context of HTTP 1.0 and
1.1, especially without pipelining. What problem are you trying to solve?

If you’re having trouble initiating new sockets, there are other kernel
params we should adjust.


On Sep 29, 2015, at 5:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi all,

I'd like to propose tuning a couple kernel parameters related to tcp
performance:

# TCP_FIN_TIMEOUT
# This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse
# its resources. During this TIME_WAIT state, reopening the connection to
the client costs less than establishing
# a new connection. By reducing the value of this entry, TCP/IP can
release closed connections faster, making more
# resources available for new connections. Adjust this in the presence of
many connections sitting in the
# TIME_WAIT state:

echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout

# TCP_TW_REUSE
# This allows reusing sockets in TIME_WAIT state for new connections when
it is safe from protocol viewpoint.
# Default value is 0 (disabled). It is generally a safer alternative to
tcp_tw_recycle

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Currently, these parameters are set by certain jobs in cf-release,
diego-release, and perhaps others. Any VM needing to establish a high
number of incoming/outgoing tcp connections in a short period of time will
be unable to establish new connections without changing these parameters.

We believe these parameters are safe to change across the board, and will
be generally beneficial. The existing defaults made sense for much older
networks, but can be greatly optimized for modern systems.

Please share with the mailing lists if you have any questions or feedback
about this proposal. If you maintain a bosh release and would like to see
how these changes would affect your release, you can create a job which
simply does the above in its startup scripts, and colocate that job with
all the other jobs in a deployment of your release.

Thanks,

Amit Gupta
Cloud Foundry PM, OSS Release Integration team



Re: [cf-bosh] proposed stemcell network performance tuning

john mcteague <john.mcteague@...>
 

My knowledge of linux networking could fit on a postage stamp, but this
thread reminded me of something we came across recently during performance
testing: "ip_conntrack: table full, dropping packet" errors on the DEA's.
No requests would make it to any app for a period and then a small portion
would make it through once closed tcp connections were released.

As a very short term fix we upped the ip_conntrack_max value on the dea's
to continue (we were focusing on the Gorouters and HAProxies primarily at
this time). We were running a small number of DEA's, far smaller than we
would run in production, so apps were concentrated on DEA's more than they
should be, and as such we have it logged as something to focus on in more
detail in the near future, but I am interested to see where network
performance tuning discussions go.

John

On Thu, Oct 1, 2015 at 2:05 AM, Joshua McKenty <jmckenty(a)pivotal.io> wrote:

Amit - I worry about changes to the former in the context of HTTP 1.0 and
1.1, especially without pipelining. What problem are you trying to solve?

If you’re having trouble initiating new sockets, there are other kernel
params we should adjust.


On Sep 29, 2015, at 5:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi all,

I'd like to propose tuning a couple kernel parameters related to tcp
performance:

# TCP_FIN_TIMEOUT
# This setting determines the time that must elapse before TCP/IP can
release a closed connection and reuse
# its resources. During this TIME_WAIT state, reopening the connection to
the client costs less than establishing
# a new connection. By reducing the value of this entry, TCP/IP can
release closed connections faster, making more
# resources available for new connections. Adjust this in the presence of
many connections sitting in the
# TIME_WAIT state:

echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout

# TCP_TW_REUSE
# This allows reusing sockets in TIME_WAIT state for new connections when
it is safe from protocol viewpoint.
# Default value is 0 (disabled). It is generally a safer alternative to
tcp_tw_recycle

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Currently, these parameters are set by certain jobs in cf-release,
diego-release, and perhaps others. Any VM needing to establish a high
number of incoming/outgoing tcp connections in a short period of time will
be unable to establish new connections without changing these parameters.

We believe these parameters are safe to change across the board, and will
be generally beneficial. The existing defaults made sense for much older
networks, but can be greatly optimized for modern systems.

Please share with the mailing lists if you have any questions or feedback
about this proposal. If you maintain a bosh release and would like to see
how these changes would affect your release, you can create a job which
simply does the above in its startup scripts, and colocate that job with
all the other jobs in a deployment of your release.

Thanks,

Amit Gupta
Cloud Foundry PM, OSS Release Integration team



Re: [abacus] Adding metering resource

Piotr Przybylski <piotrp@...>
 

Hi Sebastien,
thanks, that worked well for several resources though the planned API will
make it simpler and more dynamic.

Piotr





From: Jean-Sebastien Delfino <jsdelfino(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 09/30/2015 01:20 PM
Subject: [cf-dev] Re: [abacus] Adding metering resource



Hey Piotr,

We're currently registering our sample resource configs in
lib/config/resource/src/index.js [1]. To register yours you can just add
one line like this:

'<your resource_id>': require('<your resource config script>'),

... to that script [1] along with the other sample configs.

Your config doesn't need to be in the resources dir, anywhere on the
node.js require() path should work.

This rudimentary registration mechanism is temporary until we add a
resource config management API to allow service and runtime providers to
register their resource configs externally without having to fiddle with
the Abacus scripts. I believe the plan is to have that API very soon, and
that work is tracked under user story #101019374 [2].

[1]
https://github.com/cloudfoundry-incubator/cf-abacus/blob/master/lib/config/resource/src/index.js#L17
[2] https://www.pivotaltracker.com/story/show/101019374

HTH

-- Jean-Sebastien

On Wed, Sep 30, 2015 at 11:56 AM, Piotr Przybylski <piotrp(a)us.ibm.com>
wrote:
Hi,
I would like to add a new resource, similar to linux-container. What is a
correct way to register that resource ? The resource files are located in
cf-abacus/lib/config/resource/src/resources,
however adding resource file there does not add new resource_id to
resource enumerations (e.g. in
cf-abacus/lib/config/resource/src/index.js).

Thank you

Piotr


Re: Information about bugs in UAA,CF

Filip Hanik
 

https://github.com/cloudfoundry/uaa/issues

and in the issues you will also find a link to the tracker

On Thu, Oct 1, 2015 at 8:16 AM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

Can you please provide more specifics. If you have encountered an issue ,
you can log that against the UAA project under Cloud Foundry on Github

Thanks,
Sree

Sent from my iPhone

On Oct 1, 2015, at 5:31 AM, Kartik N Mujumdar <
kartikmujumdar(a)outlook.com> wrote:

Hello people, Can anybody help me out to get information about bugs
present in UAA in the present version? My team is looking forward to
contribute, by fixing one of the bugs(may be more than one). Please help me
out.


Re: cloud_controller_ng performance degrades slowly over time

Matt Cholick
 

Yes, we see similar behavior. The top slowest calls (with average times):

* GET v2/organizations/([^/?#]+)/users (9s)
* GET v2/organizations/([^/?#]+)/managers (7.48s)
* GET v2/spaces/([^/?#]+)/managers (6.45s)
* PUT v2/service_brokers/([^/?#]+) (6.25s)
* GET v2/spaces/([^/?#]+)/developers (5.81s)
* DELETE v2/spaces/([^/?#]+) (5.66s)
* POST v2/service_instances (4.95s)
* GET v2/apps/([^/?#]+)/summary (4.21s)

service_brokers, delete spaces, and service_instances all communicate with
a service broker which in turn communicates with external services: slow
does seem legitimate there. apps/summary is slow in a similar way around
communication with hm9000:

[image: Inline image 2]

It definitely looks like network, but that wouldn't explain why things get
immediately better after restarting the controller (a monit restart on the
job, not restarting the whole vm). If network is the cause, I would also
expect Postgres to be slow as those machines are next to everything else in
the network (though that's private, internal IP based rather than public
IP, so the path is a bit different).

I've tried looking back a bit through history, but the response time of
those users/managers/developers endpoints vary so much based on the number
of users in the organization that the averages over time don't show any
meaningful trend: we just start hearing from users when it gets really
slow, as those are the endpoints that have a lot of paging for the big orgs.

-Matt


Re: Information about bugs in UAA,CF

Sree Tummidi
 

Can you please provide more specifics. If you have encountered an issue , you can log that against the UAA project under Cloud Foundry on Github

Thanks,
Sree

Sent from my iPhone

On Oct 1, 2015, at 5:31 AM, Kartik N Mujumdar <kartikmujumdar(a)outlook.com> wrote:

Hello people, Can anybody help me out to get information about bugs present in UAA in the present version? My team is looking forward to contribute, by fixing one of the bugs(may be more than one). Please help me out.


Unable to deliver your item, #00000711647

FedEx International MailService <dan.lloyd@...>
 

Dear Customer,

We could not deliver your parcel.
You can review complete details of your order in the find attached.

Kind regards,
Dan Lloyd,
Sr. Support Manager.


Re: PHP extension 'gettext' doesn't work?

Daniel Mikusa
 

Thanks! See comment inline...

On Thu, Oct 1, 2015 at 2:21 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com> wrote:

Hi.
Thanks a lot for your detailed checks and comments.

Could you include your sample PHP code?
Could you try with the latest build pack? That would rule out any issues
that have been already addressed.
Yes, I'll show my sample code and its results. Please see the
following.

So, I take it "hello-world" should be replaced with a localized version?
Yes, I think it should be replaced the other word written in
`message.po` file.
It is true that PHP extension 'gettext' is being installed correctly,
but perhaps it seemed that 'gettext' function doesn't work well.


********** my sample source code **********
URL: https://github.com/hiroakiukaji/php-gettext-test

$ tree
.
├── index.php
└── locale
└── ja_JP.UTF-8
└── LC_MESSAGES
├── messages.mo
└── messages.po


$ vi index.php
I think you need to additionally set an environment variable here. See
this note from the PHP docs.

Note:

Setting a language isn't enough for some systems and the putenv()
<http://php.net/manual/en/function.putenv.php> should be used to define the
current locale.

http://php.net/manual/en/function.gettext.php

and the first comment on that page.

ex:

putenv("LC_ALL=$lang");
setlocale(LC_ALL, $lang);

Give that a try and let me know how it goes.

Dan


<?php

$lang = "ja_JP.UTF-8";
$domain = "messages";

setlocale(LC_ALL, $lang);
bindtextdomain($domain, "./locale/");
textdomain($domain);

// message
echo _("hello world");


$ vi locale/ja_JP.UTF-8/LC_MESSAGES/messages.po
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL(a)ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-09-29 09:47+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL(a)ADDRESS>\n"
"Language-Team: LANGUAGE <LL(a)li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: index.php:7
msgid "hello world"
msgstr "konnnichiwa sekai"
********************

When we operate the above codes in my local machine, we get following
result.

********** result with my local machine (apache2+php5.5.29 on
Ubuntu14.04)**********
$ curl 127.0.0.1:80
konnnichiwa sekai
********************

In my local environment, the message "hello world" is translated into
japanese sentence, "konnnichiwa sekai".



The results on cloud foundry with 'latest' buildpack is as follows.
(php-buildpack v4.1.4 / cf-release v211 / bosh-lite #552dc68696 / cf-cli
v6.12.0)

********** full output of `cf push` (latest buildpack) **********
$ cf push php-get-test-v4.1.4 -b
https://github.com/cloudfoundry/php-buildpack
Creating app php-get-test-v4.1.4 in org ukaji / space default as ukaji...
OK

Creating route php-get-test-v414.10.244.0.34.xip.io...
OK

Binding php-get-test-v414.10.244.0.34.xip.io to php-get-test-v4.1.4...
OK

Uploading php-get-test-v4.1.4...
Uploading app files from: /home/ukaji/php-gettext-test
Uploading 2.4K, 8 files
Done uploading
OK

Starting app php-get-test-v4.1.4 in org ukaji / space default as ukaji...
-----> Downloaded app package (4.0K)
Cloning into '/tmp/buildpacks/php-buildpack'...
Submodule 'compile-extensions'
(https://github.com/cloudfoundry/compile-extensions) registered for path
'compile-extensions'
Cloning into 'compile-extensions'...
Submodule path 'compile-extensions': checked out
'450ef697e1ea234add05121fbeb5d05b056133c6'
-------> Buildpack version 4.1.4
Installing HTTPD
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/httpd/httpd-2.4.16-linux-x64.tgz
]
to [/tmp]
Installing PHP
PHP 5.5.29
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/php/php-5.5.29-linux-x64-1442441030.tgz
]
to [/tmp]
Finished: [2015-10-01 06:09:34.369789]
-----> Uploading droplet (41M)

1 of 1 instances running

App started


OK

App php-get-test-v4.1.4 was started using this command
`$HOME/.bp/bin/start`

Showing health and status for app php-get-test-v4.1.4 in org ukaji / space
default as ukaji...
OK

requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: php-get-test-v414.10.244.0.34.xip.io
last uploaded: Thu Oct 1 06:08:49 UTC 2015
stack: cflinuxfs2
buildpack: https://github.com/cloudfoundry/php-buildpack

state since cpu memory disk
details
#0 running 2015-10-01 03:09:48 PM 0.0% 53.6M of 256M 0 of 1G
********************

********** result (latest buildpack) **********
$ curl php-get-test-v414.10.244.0.34.xip.io
hello world
********************

********** `cf logs` when I access a page (latest buildpack) **********
2015-10-01T15:12:19.33+0900 [RTR/0] OUT
php-get-test-v414.10.244.0.34.xip.io - [01/10/2015:06:12:19 +0000] "GET /
HTTP/1.1" 200 0 11 "-" "curl/7.35.0" 10.0.2.15:42716
x_forwarded_for:"192.168.50.1, 10.0.2.15"
vcap_request_id:1ae938d2-0d2c-45b7-4bd5-cfbbccb721e3
response_time:0.007400870 app_id:917e3e17-a77e-4b67-8776-bd0f938132f5
2015-10-01T15:12:19.35+0900 [App/0] OUT 06:12:19 httpd |
192.168.50.1
- - [01/Oct/2015:06:12:19 +0000] "GET / HTTP/1.1" 200 11
vcap_request_id=1ae938d2-0d2c-45b7-4bd5-cfbbccb721e3 peer_addr=10.0.2.15
********************

The results on cloud foundry with 'v211 default' buildpack is as follows.
(php-buildpack v3.2.1 / cf-release v211 / bosh-lite #552dc68696 / cf-cli
v6.12.0)

********** full output of `cf push` (cf v211 default buildpack) **********
$ cf push php-get-test-v3.2.1
Creating app php-get-test-v3.2.1 in org ukaji / space default as ukaji...
OK

Creating route php-get-test-v321.10.244.0.34.xip.io...
OK

Binding php-get-test-v321.10.244.0.34.xip.io to php-get-test-v3.2.1...
OK

Uploading php-get-test-v3.2.1...
Uploading app files from: /home/ukaji/php-gettext-test
Uploading 2.4K, 8 files
Done uploading
OK

Starting app php-get-test-v3.2.1 in org ukaji / space default as ukaji...
-----> Downloaded app package (4.0K)
-------> Buildpack version 3.2.1
Installing HTTPD
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 1534k 100 1534k 0 0 340M 0 --:--:-- --:--:-- --:--:--
340M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 14682 100 14682 0 0 106M 0 --:--:-- --:--:-- --:--:--
106M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_unixd-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 19969 100 19969 0 0 264M 0 --:--:-- --:--:-- --:--:--
264M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_setenvif-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 137k 100 137k 0 0 243M 0 --:--:-- --:--:-- --:--:--
243M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_proxy-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 16787 100 16787 0 0 181M 0 --:--:-- --:--:-- --:--:--
181M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_dir-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 20550 100 20550 0 0 222M 0 --:--:-- --:--:-- --:--:--
222M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_reqtimeout-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 42000 100 42000 0 0 90.0M 0 --:--:-- --:--:-- --:--:--
90.0M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_log_config-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 28927 100 28927 0 0 125M 0 --:--:-- --:--:-- --:--:--
125M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_authz_core-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 25276 100 25276 0 0 68.0M 0 --:--:-- --:--:-- --:--:--
68.0M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_mime-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 31561 100 31561 0 0 136M 0 --:--:-- --:--:-- --:--:--
136M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_proxy_fcgi-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 17805 100 17805 0 0 95.9M 0 --:--:-- --:--:-- --:--:--
95.9M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_remoteip-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 13323 100 13323 0 0 98.4M 0 --:--:-- --:--:-- --:--:--
98.4M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_env-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 72297 100 72297 0 0 325M 0 --:--:-- --:--:-- --:--:--
325M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_mpm_event-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 82878 100 82878 0 0 367M 0 --:--:-- --:--:-- --:--:--
367M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_rewrite-2.4.12.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 16145 100 16145 0 0 112M 0 --:--:-- --:--:-- --:--:--
112M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/httpd/2.4.12/httpd-mod_authz_host-2.4.12.tar.gz
]
to [/tmp]
Installing PHP
PHP 5.5.23
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 5000k 100 5000k 0 0 490M 0 --:--:-- --:--:-- --:--:--
490M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.23/php-5.5.23.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 8640k 100 8640k 0 0 549M 0 --:--:-- --:--:-- --:--:--
549M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.23/php-fpm-5.5.23.tar.gz
]
to [/tmp]
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 18857 100 18857 0 0 224M 0 --:--:-- --:--:-- --:--:--
224M
Downloaded
[
https://pivotal-buildpacks.s3.amazonaws.com/php/binaries/trusty/php/5.5.23/php-gettext-5.5.23.tar.gz
]
to [/tmp]
Finished: [2015-10-01 06:00:02.620608]
-----> Uploading droplet (16M)

1 of 1 instances running

App started


OK

App php-get-test-v3.2.1 was started using this command
`$HOME/.bp/bin/start`

Showing health and status for app php-get-test-v3.2.1 in org ukaji / space
default as ukaji...
OK

requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: php-get-test-v321.10.244.0.34.xip.io
last uploaded: Thu Oct 1 05:59:53 UTC 2015
stack: cflinuxfs2
buildpack: PHP

state since cpu memory disk
details
#0 running 2015-10-01 03:00:12 PM 0.0% 26.7M of 256M 0 of 1G
********************

********** result (cf v211 default buildpack) **********
$ curl php-get-test-v321.10.244.0.34.xip.io
hello world
********************

********** `cf logs` when I access a page (cf v211 default buildpack)
**********
2015-10-01T15:05:31.87+0900 [RTR/0] OUT
php-get-test-v321.10.244.0.34.xip.io - [01/10/2015:06:05:31 +0000] "GET /
HTTP/1.1" 200 0 11 "-" "curl/7.35.0" 10.0.2.15:38404
x_forwarded_for:"192.168.50.1, 10.0.2.15"
vcap_request_id:426677e4-e17f-4e0e-5142-75700cd9a33b
response_time:0.003993564 app_id:471f624e-fe67-458e-b788-f131aa271650
2015-10-01T15:05:31.88+0900 [App/0] OUT 06:05:31 httpd |
192.168.50.1
- - [01/Oct/2015:06:05:31 +0000] "GET / HTTP/1.1" 200 11
vcap_request_id=426677e4-e17f-4e0e-5142-75700cd9a33b peer_addr=10.0.2.15
********************

Thanks.

Hiroaki UKAJI



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984p2027.html
Sent from the CF Dev mailing list archive at Nabble.com.


Information about bugs in UAA,CF

Kartik N Mujumdar
 

Hello people, Can anybody help me out to get information about bugs present in UAA in the present version? My team is looking forward to contribute, by fixing one of the bugs(may be more than one). Please help me out.


Re: New Cloud Foundry team in Germany and initial working proposal

Paul Bakare
 

Thanks Simon. Looking forward to this.

And congrats on the team name; Flintstone. Hmm, easy to remember! :)

A classic use case for us is within UAA. Hence, I'm hoping the UAA team
would find this
feature useful and happy to integrate :)

On Thu, Oct 1, 2015 at 1:58 PM, Simon D Moser <SMOSER(a)de.ibm.com> wrote:

Hi cloud foundry community,

it is my pleasure to announce a new cloud foundry team. The main focus of
this new team in the first few months will be on Performance as well as
developing an Event Broadcasting mechanism, which abbreviates to "PEB".
Since PEB is pretty meaningless and the closest real word we found is
"pebble", the team decided to name itself "Team Flintstone", because
pebbles is a famous cartoon personality from the Flintstones series (
https://en.wikipedia.org/wiki/Pebbles_Flintstone). Flintstone also has a
nice connotation with "Sparks" and "Inceptions", so we really like the name
:-)

I would also like the opportunity to point the community to a google doc
proposal for the event broadcasting work - following a thread that I
attached below. We have been putting together the first of a series of
proposals to implement this capability at:


https://docs.google.com/document/d/1GrIAf8EjW_mz3HUg5Nn4R43d28IkeqH2iYQZHQLfDDQ/edit?pli=1#

Kind regards

Simon Moser

IBM Master Inventor / Bluemix Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Dieu Cao <dcao(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 04/09/2015 16:59
Subject: [cf-dev] Re: Notifications for service brokers
------------------------------



To follow up on this, I've been working with Simon Moser on an initial
proposal for this and he is now taking lead on it. Simon just completed a
PM dojo at the end of August.

Dieu


On Tuesday, August 18, 2015, Dieu Cao <*dcao(a)pivotal.io* <dcao(a)pivotal.io>>
wrote:
I planned to put together a proposal for this a couple of weeks ago as a
strawman to describe use cases, but just have not had the time.
I still hope to tackle this in the next week or so and will post to this
list.

For reference, see this thread [1] where this was previously discussed.

-Dieu
CF CAPI PM

[1]
*http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tt827.html#none*
<http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tt827.html#none>

On Tue, Aug 18, 2015 at 5:47 PM, Vineet Banga <*vineetbanga1(a)gmail.com*>
wrote:
Thanks Juan, I will try to setup a poller for this to achieve similar
functionality. Do you know if there is already proposal for the better
notifications - if yes, could you point me to it? I Would like to see if
it would meet our needs at some point in the future.

On Fri, Aug 14, 2015 at 4:26 PM, Juan Pablo Genovese <
*juanpgenovese(a)gmail.com*> wrote:
Vineet,

there is some proposals to add better notifications to CF in general and
the CC in particular, but for now you can poll the CC API to get those
events. See *http://apidocs.cloudfoundry.org/214/*
<http://apidocs.cloudfoundry.org/214/>

Thanks!

2015-08-14 18:31 GMT-03:00 Vineet Banga <*vineetbanga1(a)gmail.com*>:
Is there any notification pub/sub mechanism in cloud foundry when services
are created/updated/deleted. We are exposing few services in CF using
service brokers and we would like some common actions to occur when our
services are created/delete/updated.



--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
*http://www.jpgenovese.com* <http://www.jpgenovese.com/>





New Cloud Foundry team in Germany and initial working proposal

Simon D Moser
 

Hi cloud foundry community,

it is my pleasure to announce a new cloud foundry team. The main focus of
this new team in the first few months will be on Performance as well as
developing an Event Broadcasting mechanism, which abbreviates to "PEB".
Since PEB is pretty meaningless and the closest real word we found is
"pebble", the team decided to name itself "Team Flintstone", because
pebbles is a famous cartoon personality from the Flintstones series (
https://en.wikipedia.org/wiki/Pebbles_Flintstone ). Flintstone also has a
nice connotation with "Sparks" and "Inceptions", so we really like the
name :-)

I would also like the opportunity to point the community to a google doc
proposal for the event broadcasting work - following a thread that I
attached below. We have been putting together the first of a series of
proposals to implement this capability at:

https://docs.google.com/document/d/1GrIAf8EjW_mz3HUg5Nn4R43d28IkeqH2iYQZHQLfDDQ/edit?pli=1#

Kind regards

Simon Moser

IBM Master Inventor / Bluemix Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Dieu Cao <dcao(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Date: 04/09/2015 16:59
Subject: [cf-dev] Re: Notifications for service brokers



To follow up on this, I've been working with Simon Moser on an initial
proposal for this and he is now taking lead on it. Simon just completed a
PM dojo at the end of August.

Dieu

On Tuesday, August 18, 2015, Dieu Cao <dcao(a)pivotal.io> wrote:
I planned to put together a proposal for this a couple of weeks ago as a
strawman to describe use cases, but just have not had the time.
I still hope to tackle this in the next week or so and will post to this
list.

For reference, see this thread [1] where this was previously discussed.

-Dieu
CF CAPI PM

[1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Notifications-on-ORG-SPACE-and-USER-modifications-tt827.html#none

On Tue, Aug 18, 2015 at 5:47 PM, Vineet Banga <vineetbanga1(a)gmail.com>
wrote:
Thanks Juan, I will try to setup a poller for this to achieve similar
functionality. Do you know if there is already proposal for the better
notifications - if yes, could you point me to it? I Would like to see if
it would meet our needs at some point in the future.

On Fri, Aug 14, 2015 at 4:26 PM, Juan Pablo Genovese <
juanpgenovese(a)gmail.com> wrote:
Vineet,

there is some proposals to add better notifications to CF in general and
the CC in particular, but for now you can poll the CC API to get those
events. See http://apidocs.cloudfoundry.org/214/

Thanks!

2015-08-14 18:31 GMT-03:00 Vineet Banga <vineetbanga1(a)gmail.com>:
Is there any notification pub/sub mechanism in cloud foundry when services
are created/updated/deleted. We are exposing few services in CF using
service brokers and we would like some common actions to occur when our
services are created/delete/updated.



--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
http://www.jpgenovese.com


Re: Instance rolling restart feature in CC

Paul Bakare
 

Thank you very much

On Thu, Oct 1, 2015 at 1:31 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Checkout auto pilot plugin here
https://plugins.cloudfoundry.org/ui/
On Oct 1, 2015 20:16, "Kayode Odeyemi" <dreyemi(a)gmail.com> wrote:

Thanks Gents.

@ronak, Are you referring to this:
https://github.com/cloudfoundry-incubator/cli-plugin-repo ?

On Thu, Oct 1, 2015 at 12:05 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.
On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name
and then, after the push is successfull, just switch the route to the app
with the temp name. Not sure there is a built-in feature that allows that,
but you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there
a rolling restart feature in CC

Appreciate your input.




Re: Instance rolling restart feature in CC

Ronak Banka
 

Checkout auto pilot plugin here
https://plugins.cloudfoundry.org/ui/

On Oct 1, 2015 20:16, "Kayode Odeyemi" <dreyemi(a)gmail.com> wrote:

Thanks Gents.

@ronak, Are you referring to this:
https://github.com/cloudfoundry-incubator/cli-plugin-repo ?

On Thu, Oct 1, 2015 at 12:05 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.
On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name and
then, after the push is successfull, just switch the route to the app with
the temp name. Not sure there is a built-in feature that allows that, but
you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there
a rolling restart feature in CC

Appreciate your input.




Re: Instance rolling restart feature in CC

Paul Bakare
 

Thanks Gents.

@ronak, Are you referring to this:
https://github.com/cloudfoundry-incubator/cli-plugin-repo ?

On Thu, Oct 1, 2015 at 12:05 PM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi kayode,

You can take a look at cf plugin repo , there is already a plugin for no
downtime deployment which is designed based on what simon described .

Ronak Banka
Rakuten, Inc.
On Oct 1, 2015 18:34, "Simon D Moser" <SMOSER(a)de.ibm.com> wrote:

Hi Kayode,

what you can do to avoid downtime is to push your app to a temp name and
then, after the push is successfull, just switch the route to the app with
the temp name. Not sure there is a built-in feature that allows that, but
you can easily write a push script that does what I just described.

Mit freundlichen Grüßen / Kind regards

Simon Moser

IBM Master Inventor / Cloud Computing Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Kayode Odeyemi <dreyemi(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 01/10/2015 11:24
Subject: [cf-dev] Instance rolling restart feature in CC
------------------------------



Hi

Is it possible to 'cf push' without killing all app instances? Is there a
rolling restart feature in CC

Appreciate your input.



7361 - 7380 of 9425