cf-dev@lists.cloudfoundry.org

Utilities PMC - 2015-07-07 notes

Mike Dalessio

#689

Hi all,

We had a meeting of the Utilities PMC yesterday, permanent notes are at:

https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-07-07-utilities.md

which I've helpfully copied into this email below.

Cheers,
-mike

-----

*# Utilities PMC Meeting 2015-07-07*

*## Agenda*

1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Proposal to accept receptor-client into incubation
5. Open Discussion

*## Attendees*

* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Deepak Vij, Huawei

*## Update on CI tools (Mike Dalessio)*

- Krafa track of work has been broadly defined, and it's in the
  Toolsmiths [public backlog and icebox][toolsmiths-tracker].

- A pair is continuing work on [License Finder][lf], which is an OSS tool to
  examine a project's declared dependencies (via a package manager)
  and discover licenses and changes in licensing. This should be
  useful for the Foundation as well. (See [Tracker here][lf-tracker].)

*## Update on CLI (Greg Oehman)*

The CLI team released version 6.12.1 on 7/6/2015.  Release notes,
download instructions and binaries are available at
https://github.com/cloudfoundry/cli/releases

*## Update on Eclipse plugin and Java tools (Ryan Morgan)*

* Eclipse tooling 1.8.3 release (Nieraj posted notes about this to cf-dev).

*## Proposal to accept receptor-client into incubation*

Last meeting, Ryan Morgan [proposed receptor-client for
acceptance][receptor-client-proposal] into incubation.

No objections having been raised, on either the mailing list or in the
PMC meeting, this is now accepted into incubation.

*## Open Discussion*

None.

-----

Links:

  [toolsmiths-tracker]: https://www.pivotaltracker.com/n/projects/1042066
  [lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
  [lf]: https://github.com/pivotal/LicenseFinder
  [receptor-client-proposal]:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-for-incubation-of-receptor-client-Java-client-for-receptor-td440.html

attachment.html

Re: [cf-bosh] CAB call for July 2015 - moved to 7/15 @ 8a PDT

Casey West

#688

May I inquire as to the location of the public calendar, please? Thanks!

On Wed, Jul 8, 2015 at 7:17 AM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

Hi all,

I've updated the public calendar to reflect today's change.

The CAB will be on July 15.

-chip


Chip Childers | VP Technology | Cloud Foundry Foundation

On Tue, Jul 7, 2015 at 12:54 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

After conferring with James and Chip, we've agreed to move the call to
next week Wednesday @ same time (8a PDT).

This helps folks who have extended their July 4th holiday in U.S. and
hopefully is not inconvenient to others.

Finally, reminders:

1. Note the call information is relatively new (same as last time).
Please take note:

USA 888-426-6840; 215-861-6239 *| *Participant code: *1985291*
*Other countries: *http://goo.gl/RnNfc1

2. Please add to the agenda of you have something to discuss. I will send
reminders again early next week.

Agenda:
https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit

3. If you own any of the recurring meetings please update with above.

Thanks much. Best,

dr.max
ibm cloud labs
silicon valley, ca

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

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


-- 
Casey

attachment.html

Re: CAB call for July 2015 - moved to 7/15 @ 8a PDT

Chip Childers <cchilders@...>

#687

Hi all,

I've updated the public calendar to reflect today's change.

The CAB will be on July 15.

-chip


Chip Childers | VP Technology | Cloud Foundry Foundation

On Tue, Jul 7, 2015 at 12:54 PM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

After conferring with James and Chip, we've agreed to move the call to
next week Wednesday @ same time (8a PDT).

This helps folks who have extended their July 4th holiday in U.S. and
hopefully is not inconvenient to others.

Finally, reminders:

1. Note the call information is relatively new (same as last time). Please
take note:

USA 888-426-6840; 215-861-6239 *| *Participant code: *1985291*
*Other countries: *http://goo.gl/RnNfc1

2. Please add to the agenda of you have something to discuss. I will send
reminders again early next week.

Agenda:
https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit

3. If you own any of the recurring meetings please update with above.

Thanks much. Best,

dr.max
ibm cloud labs
silicon valley, ca

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

attachment.html

Service broker error: Gateway timeout (cf us FAILED) [cf-services-contrib-release]

Lukas Lehner <weblehner@...>

#686

Hi

I have the same issue like

http://stackoverflow.com/questions/30076193/gateway-timeout-when-creating-a-rabbitmq-cloud-foundry-service-instance

any idea howto fix that?
All bosh vms running, lots of capacity available and not much info in
/var/vcap/sys/log

Lukas

attachment.html

Re: Response.write issue on bluemix

Yitao Jiang

#685

Yes, under firefox esr 38.01, it works just as expected every 2 seconds

On Wed, Jul 8, 2015 at 1:56 PM, Gayathri Raghavendra prasad <
graghav(a)us.ibm.com> wrote:

Thank you! I am getting the response after certain delay (i.e, after the
buffer is full) and not after every 2 seconds.Could you please confirm if
you are able to see the response every 2 seconds?

Thanks,
Gayathri



From:        Yitao Jiang <jiangyt.cn(a)gmail.com>
To:        "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>,
Date:        07/07/2015 10:26 PM
Subject:        Re: [cf-dev] Response.write issue on bluemix
Sent by:        cf-dev-bounces(a)lists.cloudfoundry.org
------------------------------



I just deployed an application using your code . LGTM and BTW the same
release with you

On Wed, Jul 8, 2015 at 5:57 AM, Gayathri Raghavendra prasad <
*graghav(a)us.ibm.com* <graghav(a)us.ibm.com>> wrote:
Hello,

I wrote a simple app which writes continuous chunks of data using
response.write. The code is below. This works fine when I run it locally
but the output never shows when the app runs on bluemix.
The CF version on Bluemix : CF210.2 . Will appreciate any help on why this
behavior.

var app = require('express')(),
    http = require('http');

app.get('/', function(req, res){
    var timer = setInterval(function () {
    res.write('Hellooo\n\n')

     res.write('Hiii\n\n')

  }, 2000)

  res.on('close', function () {
    clearInterval(timer)
  })

});
http.createServer(app).listen(process.env.VCAP_APP_PORT || '2000',
function(){
    console.log('Express server listening on port
'+(process.env.VCAP_APP_PORT || '2000'));
});

Thanks,
Gayathri
_______________________________________________
cf-dev mailing list
*cf-dev(a)lists.cloudfoundry.org* <cf-dev(a)lists.cloudfoundry.org>
*https://lists.cloudfoundry.org/mailman/listinfo/cf-dev*
<https://lists.cloudfoundry.org/mailman/listinfo/cf-dev>




--

Regards,
Yitao(依涛 姜)
*jiangyt.github.io* <http://jiangyt.github.io/>
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


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


-- 

Regards,
Yitao(依涛 姜)
jiangyt.github.io

attachment.html

Re: Response.write issue on bluemix

Gayathri Raghavendra prasad <graghav@...>

#684

Thank you! I am getting the response after certain delay (i.e, after the 
buffer is full) and not after every 2 seconds.Could you please confirm if 
you are able to see the response every 2 seconds?

Thanks,
Gayathri



From:   Yitao Jiang <jiangyt.cn(a)gmail.com>
To:     "Discussions about Cloud Foundry projects and the system overall." 
<cf-dev(a)lists.cloudfoundry.org>, 
Date:   07/07/2015 10:26 PM
Subject:        Re: [cf-dev] Response.write issue on bluemix
Sent by:        cf-dev-bounces(a)lists.cloudfoundry.org



I just deployed an application using your code . LGTM and BTW the same 
release with you

Show quoted text

On Wed, Jul 8, 2015 at 5:57 AM, Gayathri Raghavendra prasad <
graghav(a)us.ibm.com> wrote:
Hello, 

I wrote a simple app which writes continuous chunks of data using 
response.write. The code is below. This works fine when I run it locally 
but the output never shows when the app runs on bluemix. 
The CF version on Bluemix : CF210.2 . Will appreciate any help on why this 
behavior. 

var app = require('express')(), 
    http = require('http'); 

app.get('/', function(req, res){ 
    var timer = setInterval(function () { 
    res.write('Hellooo\n\n') 
        
     res.write('Hiii\n\n') 

  }, 2000) 

  res.on('close', function () { 
    clearInterval(timer) 
  }) 

}); 
http.createServer(app).listen(process.env.VCAP_APP_PORT || '2000', 
function(){ 
    console.log('Express server listening on port 
'+(process.env.VCAP_APP_PORT || '2000')); 
}); 

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




-- 

Regards,
Yitao(依涛 姜)
jiangyt.github.io_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

attachment.html

Re: Response.write issue on bluemix

Yitao Jiang

#683

I just deployed an application using your code . LGTM and BTW the same
release with you

On Wed, Jul 8, 2015 at 5:57 AM, Gayathri Raghavendra prasad <
graghav(a)us.ibm.com> wrote:

Hello,

I wrote a simple app which writes continuous chunks of data using
response.write. The code is below. This works fine when I run it locally
but the output never shows when the app runs on bluemix.
The CF version on Bluemix : CF210.2 . Will appreciate any help on why this
behavior.

var app = require('express')(),
    http = require('http');

app.get('/', function(req, res){
    var timer = setInterval(function () {
    res.write('Hellooo\n\n')

     res.write('Hiii\n\n')

  }, 2000)

  res.on('close', function () {
    clearInterval(timer)
  })

});
http.createServer(app).listen(process.env.VCAP_APP_PORT || '2000',
function(){
    console.log('Express server listening on port
'+(process.env.VCAP_APP_PORT || '2000'));
});

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


-- 

Regards,
Yitao(依涛 姜)
jiangyt.github.io

attachment.html

Re: CF CLI Version 6.12.1

Gwenn Etourneau

#682

Thanks !
Some interesting feature and plugin.

Show quoted text

On Wed, Jul 8, 2015 at 2:54 AM, Greg Oehmen <goehmen(a)pivotal.io> wrote:

The CF CLI team released version 6.12.1 on 7/6/2015.  Release notes,
download instructions and binaries are available at:

https://github.com/cloudfoundry/cli/releases

Highlights of this release include:

Plugin API -
https://github.com/cloudfoundry/cli/blob/master/plugin_examples/DOC.md

Full Support for Service keys / Async Service Operations -
http://docs.cloudfoundry.org/services/asynchronous-operations.html

Full Support for Arbitrary Parameters for Service Instance Provisioning -
https://docs.google.com/document/d/1QYHH3T4Dy1tjLj-FrkrVhgfgCzQCyIlTCIPBe9RMFAs/edit

General UX Refinements

   -

   Allow `cf app` to display buildpack
   -

   Add Buildpack to `cf create-app-manifest`
   -

   Added support for “--no-hostname” attribute in `cf
   create-app-manifest` command
   -

   Removed ‘as admin’.. clause from create-user since it is confusing
   -

   Added fields to CLI MSI installer to show app/publisher name in windows
   -

   Removed Windows incompatible language test
   -

   Enabled full word ‘yes’ for confirmation when lang is not en_US
   -

   Enabled file reference containing JSON when creating a service instance
   -

   Support for godeps newest noaa package - new noaa.Close() method
   -

   Support for loggregator/Noaa endpoint Changes
   -

   Fixed bug: CLI upload fails at 2nd push with `EmptyDirError`
   -

   Fixed bug: index out of range panic when getting stats for Diego app
   while Diego stats endpoint is down
   -

   Fixed bug: do not create zip when no file to upload during cf push
   -

   Fixed bug: cf start uses old loggregator to tail logs, instead of noaa

Improvements to text output/error messaging

   -

   Fixed `cf push -p` help verbiage
   -

   Improved restage tip to include name of app
   -

   Rewrote cf update-service help text error to be more descriptive
   -

   Highlighted restage command in uups tip
   -

   Updated tip for updating UPSIs - UPSIs now propagate their credentials
   on update, so no need to unbind and rebind them.
   -

   Added error handling for when diego /instances is up but /noaa is
   down.

Pull Requests

#470 <https://github.com/cloudfoundry/cli/pull/470> - Fix flaky test for
go 1.4 where map iteration order is randomized.

#366 <https://github.com/cloudfoundry/cli/pull/366> -Fixed error message
when there is a mismatch in the order of arguments for create-buildpack

Additions to the CF-Community Plugin Repo:

cf-download - v1.0.0      Plugin for downloading your application contents
after staging

Scaleover    - v.0.1.0      Roll traffic from one app to another by
scaling over time

Diego-SSH  - v.0.1.2      Access Diego containers with SSH

Greg Oehmen
Cloud Foundry Product Manager

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

attachment.html

Response.write issue on bluemix

Gayathri Raghavendra prasad <graghav@...>

#681

Hello,

I wrote a simple app which writes continuous chunks of data using 
response.write. The code is below. This works fine when I run it locally 
but the output never shows when the app runs on bluemix.
The CF version on Bluemix : CF210.2 . Will appreciate any help on why this 
behavior.

var app = require('express')(),
    http = require('http');

app.get('/', function(req, res){
    var timer = setInterval(function () {
    res.write('Hellooo\n\n')
 
     res.write('Hiii\n\n')

  }, 2000)

  res.on('close', function () {
    clearInterval(timer)
  })

});
http.createServer(app).listen(process.env.VCAP_APP_PORT || '2000', 
function(){
    console.log('Express server listening on port 
'+(process.env.VCAP_APP_PORT || '2000'));
}); 

Thanks,
Gayathri

attachment.html

CF CLI Version 6.12.1

Greg Oehmen

#680

The CF CLI team released version 6.12.1 on 7/6/2015.  Release notes,
download instructions and binaries are available at:

https://github.com/cloudfoundry/cli/releases

Highlights of this release include:

Plugin API -
https://github.com/cloudfoundry/cli/blob/master/plugin_examples/DOC.md

Full Support for Service keys / Async Service Operations -
http://docs.cloudfoundry.org/services/asynchronous-operations.html

Full Support for Arbitrary Parameters for Service Instance Provisioning -
https://docs.google.com/document/d/1QYHH3T4Dy1tjLj-FrkrVhgfgCzQCyIlTCIPBe9RMFAs/edit

General UX Refinements

   -

   Allow `cf app` to display buildpack
   -

   Add Buildpack to `cf create-app-manifest`
   -

   Added support for “--no-hostname” attribute in `cf create-app-manifest`
   command
   -

   Removed ‘as admin’.. clause from create-user since it is confusing
   -

   Added fields to CLI MSI installer to show app/publisher name in windows
   -

   Removed Windows incompatible language test
   -

   Enabled full word ‘yes’ for confirmation when lang is not en_US
   -

   Enabled file reference containing JSON when creating a service instance
   -

   Support for godeps newest noaa package - new noaa.Close() method
   -

   Support for loggregator/Noaa endpoint Changes
   -

   Fixed bug: CLI upload fails at 2nd push with `EmptyDirError`
   -

   Fixed bug: index out of range panic when getting stats for Diego app
   while Diego stats endpoint is down
   -

   Fixed bug: do not create zip when no file to upload during cf push
   -

   Fixed bug: cf start uses old loggregator to tail logs, instead of noaa

Improvements to text output/error messaging

   -

   Fixed `cf push -p` help verbiage
   -

   Improved restage tip to include name of app
   -

   Rewrote cf update-service help text error to be more descriptive
   -

   Highlighted restage command in uups tip
   -

   Updated tip for updating UPSIs - UPSIs now propagate their credentials
   on update, so no need to unbind and rebind them.
   -

   Added error handling for when diego /instances is up but /noaa is down.

Pull Requests

#470 <https://github.com/cloudfoundry/cli/pull/470> - Fix flaky test for go
1.4 where map iteration order is randomized.

#366 <https://github.com/cloudfoundry/cli/pull/366> -Fixed error message
when there is a mismatch in the order of arguments for create-buildpack

Additions to the CF-Community Plugin Repo:

cf-download - v1.0.0      Plugin for downloading your application contents
after staging

Scaleover    - v.0.1.0      Roll traffic from one app to another by scaling
over time

Diego-SSH  - v.0.1.2      Access Diego containers with SSH

Greg Oehmen
Cloud Foundry Product Manager

attachment.html

Deprecating cloudfoundry/errors repo

Dan Wendorf

#679

Hi Cloud Foundry,

The Cloud Controller NG repo has errors as a submodule under the assumption
that other teams/projects may wish to share our error yml files. The CC
team would like to deprecate that repository and fold it into CC directly.
If we do this, it may affect any teams that are using cloudfoundry/errors.

Are you one of those teams? Please let us know if you have any use cases
for the errors repository before we deprecate it sometime in the next week.


Thanks,
Dan Wendorf & Liz Dahlstrom and the Cloud Controller team

attachment.html

CAB call for July 2015 - moved to 7/15 @ 8a PDT

Michael Maximilien

#678

Hi, all,

After conferring with James and Chip, we've agreed to move the call to next week Wednesday @ same time (8a PDT).

This helps folks who have extended their July 4th holiday in U.S. and hopefully is not inconvenient to others.

Finally, reminders:

1. Note the call information is relatively new (same as last time). Please take note:

USA 888-426-6840; 215-861-6239 | Participant code: 1985291
Other countries: http://goo.gl/RnNfc1

2. Please add to the agenda of you have something to discuss. I will send reminders again early next week.

Agenda: https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit

3. If you own any of the recurring meetings please update with above.

Thanks much. Best,

dr.max
ibm cloud labs
silicon valley, ca

dr.max
ibm cloud labs
silicon valley, ca

Sent from my iPhone

attachment.html

Re: cf restage and downtime

Mike Youngstrom <youngm@...>

#677

Good to hear.  Thanks Dieu!

Show quoted text

On Mon, Jul 6, 2015 at 11:44 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Yes, we think that with the initial scope of work for the v3 cc api that
we'll have the primitives to be able to orchestrate a rolling deploy.  In
v3, we've already separated out the staging step so that a new package can
be uploaded and staged without affecting the running app.

-Dieu

On Mon, Jul 6, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

At one point Diego was slated to look at support for rolling
restart/restage.  Is that still being considered in Diego's roadmap?  Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time.  It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to
our apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service
command and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts
the new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

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

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

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

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

attachment.html

Did anybody deploy a wiki as app to CF?

Stephan Weber

#676

Hi,

Did anybody deploy a wiki as app to CF?
Which one?
Can you point me to a ‘how-to’?

Best regards, Stephan

attachment.html

Re: cf restage and downtime

Dieu Cao <dcao@...>

#675

Yes, we think that with the initial scope of work for the v3 cc api that
we'll have the primitives to be able to orchestrate a rolling deploy.  In
v3, we've already separated out the staging step so that a new package can
be uploaded and staged without affecting the running app.

-Dieu

Show quoted text

On Mon, Jul 6, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

At one point Diego was slated to look at support for rolling
restart/restage.  Is that still being considered in Diego's roadmap?  Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time.  It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

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

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

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

attachment.html

Re: cf restage and downtime

Mike Youngstrom <youngm@...>

#674

At one point Diego was slated to look at support for rolling
restart/restage.  Is that still being considered in Diego's roadmap?  Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

Show quoted text

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time.  It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

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

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

attachment.html

Re: revrse proxy in CF

Sumanth Yamala

#673

Thanks Chris. Will keep you posted on how it goes.

Sumanth

From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Christopher Piraino
Sent: Monday, July 06, 2015 8:16 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

Hi Sumanth,

We recently added support for "Context Path Routing"<https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ> in both the GoRouter and CC API<http://apidocs.cloudfoundry.org/212/routes/creating_a_route.html>. I do not believe the cf CLI has implemented this feature yet.

This feature was added to address this exact use-case, we would love to receive feedback on it. Note that there is a current bug related to the use of context paths and session affinity<https://www.pivotaltracker.com/story/show/98068176> that we have in our backlog.

Let me know if that helps!

Best,
Chris Piraino, CF Routing Team

On Mon, Jul 6, 2015 at 2:41 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
The main goal is to have a  mapping from a top level url like   abc.com/app1<http://abc.com/app1>  abc.com/app2<http://abc.com/app2> getting mapped to the actual routes given by cf to the respective apps. So I was thinking of adding a reverse proxy in front of the router, similar to what you have done. Can this be accomplished with the go router or do we need a reverse proxy?

Thanks
Sumanth

From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>] On Behalf Of John Wong
Sent: Monday, July 06, 2015 4:32 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

What is the goal of your reversed proxy? Did you mean load balance of multiple instances of an app (cf push APPNAME -i 3 ==== having 3 instances of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is setup properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
Hi,

In an environment with multiple micro services being deployed in CF. Does the “go router” have the functionality of reverse proxy or should I configure httpd to sit in front of the go router.

Thanks,
Sumanth

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

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

attachment.html

Re: revrse proxy in CF

Christopher Piraino <cpiraino@...>

#672

Hi Sumanth,

We recently added support for "Context Path Routing"
<https://docs.google.com/document/d/1H_adSiY7wGR85av9YfxxPRylSO8Q8U0ANJJTg6wpYRQ>
in both the GoRouter and CC API
<http://apidocs.cloudfoundry.org/212/routes/creating_a_route.html>. I do
not believe the cf CLI has implemented this feature yet.

This feature was added to address this exact use-case, we would love to
receive feedback on it. Note that there is a current bug related to the use
of context paths and session affinity
<https://www.pivotaltracker.com/story/show/98068176> that we have in our
backlog.

Let me know if that helps!

Best,
Chris Piraino, CF Routing Team

On Mon, Jul 6, 2015 at 2:41 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

 The main goal is to have a  mapping from a top level url like
abc.com/app1  abc.com/app2 getting mapped to the actual routes given by
cf to the respective apps. So I was thinking of adding a reverse proxy in
front of the router, similar to what you have done. Can this be
accomplished with the go router or do we need a reverse proxy?

Thanks

Sumanth

*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *John Wong
*Sent:* Monday, July 06, 2015 4:32 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] revrse proxy in CF

What is the goal of your reversed proxy? Did you mean load balance of
multiple instances of an app (cf push APPNAME -i 3 ==== having 3 instances
of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is
setup properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and
then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

 Hi,

In an environment with multiple micro services being deployed in CF. Does
the “go router” have the functionality of reverse proxy or should I
configure httpd to sit in front of the go router.

Thanks,

Sumanth

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

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

attachment.html

Re: revrse proxy in CF

Sumanth Yamala

#671

The main goal is to have a  mapping from a top level url like   abc.com/app1  abc.com/app2 getting mapped to the actual routes given by cf to the respective apps. So I was thinking of adding a reverse proxy in front of the router, similar to what you have done. Can this be accomplished with the go router or do we need a reverse proxy?

Thanks
Sumanth

From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of John Wong
Sent: Monday, July 06, 2015 4:32 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] revrse proxy in CF

What is the goal of your reversed proxy? Did you mean load balance of multiple instances of an app (cf push APPNAME -i 3 ==== having 3 instances of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is setup properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:
Hi,

In an environment with multiple micro services being deployed in CF. Does the “go router” have the functionality of reverse proxy or should I configure httpd to sit in front of the go router.

Thanks,
Sumanth

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

attachment.html

Re: revrse proxy in CF

John Wong

#670

What is the goal of your reversed proxy? Did you mean load balance of
multiple instances of an app (cf push APPNAME -i 3 ==== having 3 instances
of APPNAME)?

Gorouter knows how to dispatch to app 1 or app2, for as long as cf is setup
properly and that there is a url mapping.

Where I work we also configure Nginx to handle the incoming traffic and
then proxy to gorouter.

On Mon, Jul 6, 2015 at 4:23 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

 Hi,



In an environment with multiple micro services being deployed in CF. Does
the “go router” have the functionality of reverse proxy or should I
configure httpd to sit in front of the go router.



Thanks,

Sumanth

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

attachment.html