Hello Mike,

I thought I'd put this on the list in case others have similar use cases.

At summit you mentioned an interest in a variant of sticky session
behavior, and I wonder if you could provide some additional context.

You suggested it would be valuable if, where multiple apps were mapped to
the same route, all requests from a client were routed to the same app. I
believe the example you gave was where the two apps represent different
versions of a web UI. In this case all requests from the client could be
load balanced to any instance of the same app, for the life of the session.
This might be accomplished using a new cookie.

Do you imagine the application initiating this behavior as it does now? I
have some evidence for a feature to relieve apps of this responsibility, by
enabling developers to express that sticky sessions should be enabled for a
route; then the router could potentially handle returning cookies to
clients.

Do you imagine a developer being able to express that they want sticky
sessions enabled for a route in either an "app" or "instance" mode?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Hi Shannon,

Good question. I haven't really considered an app initiating this but I
think that could work.

The ultimate use case for this, in my mind, is to eventually support
transitioning http sessions from a blue app to a green app in a blue/green
deploy type of scenario.

I think this could be done with the a combination of a sticky app feature
and the request weight load feature you mentioned in your talk.

With those 2 features I could write my application to indicate to the
router that I wish to maintain sticky app. Then I could set request weight
to some percent (possibly even 100%) of load to the new app. That way
users would eventually and smoothly transition all new http sessions to the
new app.

So, to answer your question I think it quite reasonable to ask the
application itself, through cookie or something, to declare if it wants
instance, app, or no stickiness. However, I believe the mechanism to
declare how much load each app bound to a route should get would need to be
controlled outside the app, but, could potentially be the very same
mechanism you envisioned for the upcoming load weight feature.

Does that make sense?

Mike



On Thu, May 26, 2016 at 11:56 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Mike,

I thought I'd put this on the list in case others have similar use cases.

At summit you mentioned an interest in a variant of sticky session
behavior, and I wonder if you could provide some additional context.

You suggested it would be valuable if, where multiple apps were mapped to
the same route, all requests from a client were routed to the same app. I
believe the example you gave was where the two apps represent different
versions of a web UI. In this case all requests from the client could be
load balanced to any instance of the same app, for the life of the session.
This might be accomplished using a new cookie.

Do you imagine the application initiating this behavior as it does now? I
have some evidence for a feature to relieve apps of this responsibility, by
enabling developers to express that sticky sessions should be enabled for a
route; then the router could potentially handle returning cookies to
clients.

Do you imagine a developer being able to express that they want sticky
sessions enabled for a route in either an "app" or "instance" mode?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Hi Shannon,

Good question. I haven't really considered an app initiating this but I
think that could work.

The ultimate use case for this, in my mind, is to eventually support
transitioning http sessions from a blue app to a green app in a blue/green
deploy type of scenario.

I think this could be done with the a combination of a sticky app feature
and the request weight load feature you mentioned in your talk.

With those 2 features I could write my application to indicate to the
router that I wish to maintain sticky app. Then I could set request weight
to some percent (possibly even 100%) of load to the new app. That way
users would eventually and smoothly transition all new http sessions to the
new app.

So, to answer your question I think it quite reasonable to ask the
application itself, through cookie or something, to declare if it wants
instance, app, or no stickiness. However, I believe the mechanism to
declare how much load each app bound to a route should get would need to be
controlled outside the app, but, could potentially be the very same
mechanism you envisioned for the upcoming load weight feature.

Does that make sense?

Mike



On Thu, May 26, 2016 at 11:56 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Mike,

I thought I'd put this on the list in case others have similar use cases.

At summit you mentioned an interest in a variant of sticky session
behavior, and I wonder if you could provide some additional context.

You suggested it would be valuable if, where multiple apps were mapped to
the same route, all requests from a client were routed to the same app. I
believe the example you gave was where the two apps represent different
versions of a web UI. In this case all requests from the client could be
load balanced to any instance of the same app, for the life of the session.
This might be accomplished using a new cookie.

Do you imagine the application initiating this behavior as it does now? I
have some evidence for a feature to relieve apps of this responsibility, by
enabling developers to express that sticky sessions should be enabled for a
route; then the router could potentially handle returning cookies to
clients.

Do you imagine a developer being able to express that they want sticky
sessions enabled for a route in either an "app" or "instance" mode?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

+1 for app stickyness when a route us mapped to multiple apps, and sticky
sessions are requested (currently through j session is cookie)

I'd even suggest that app stickyness is the default when sticky sessions
are requested.

What would be use-cases for opting out of app stickyness ?

I'm not sure either about use cases for an app to control this behavior
(ie opt out). If needed, I'd rather see this as a property of the route
controlled by an operator (along with the weight, and potentially mutable).
Le 27 mai 2016 01:20, "Shannon Coen" <scoen(a)pivotal.io> a écrit :

Yes, thanks for the clarification Mike.


Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, May 26, 2016 at 2:38 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Hi Shannon,

Good question. I haven't really considered an app initiating this but I
think that could work.

The ultimate use case for this, in my mind, is to eventually support
transitioning http sessions from a blue app to a green app in a blue/green
deploy type of scenario.

I think this could be done with the a combination of a sticky app feature
and the request weight load feature you mentioned in your talk.

With those 2 features I could write my application to indicate to the
router that I wish to maintain sticky app. Then I could set request weight
to some percent (possibly even 100%) of load to the new app. That way
users would eventually and smoothly transition all new http sessions to the
new app.

So, to answer your question I think it quite reasonable to ask the
application itself, through cookie or something, to declare if it wants
instance, app, or no stickiness. However, I believe the mechanism to
declare how much load each app bound to a route should get would need to be
controlled outside the app, but, could potentially be the very same
mechanism you envisioned for the upcoming load weight feature.

Does that make sense?

Mike



On Thu, May 26, 2016 at 11:56 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Mike,

I thought I'd put this on the list in case others have similar use cases.

At summit you mentioned an interest in a variant of sticky session
behavior, and I wonder if you could provide some additional context.

You suggested it would be valuable if, where multiple apps were mapped
to the same route, all requests from a client were routed to the same app.
I believe the example you gave was where the two apps represent different
versions of a web UI. In this case all requests from the client could be
load balanced to any instance of the same app, for the life of the session.
This might be accomplished using a new cookie.

Do you imagine the application initiating this behavior as it does now?
I have some evidence for a feature to relieve apps of this responsibility,
by enabling developers to express that sticky sessions should be enabled
for a route; then the router could potentially handle returning cookies to
clients.

Do you imagine a developer being able to express that they want sticky
sessions enabled for a route in either an "app" or "instance" mode?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

[Retrying with less typing errors, sorry]

+1 for app stickyness when a route is mapped to multiple apps, and sticky
sessions are requested (currently through jsessionid cookie).

I'd even suggest that app stickyness is the default when sticky sessions
are requested.

What would be use-cases for opting out of app stickyness when sticky
sessions are requested ?

I'm not sure either about use cases for an app to control this behavior.
If needed to opt-in (eg when sticky sessions are not requested), I'd rather
see this as a property of the route controlled by an operator (along with
the weight, and potentially mutable/dynamic).
Le 27 mai 2016 11:24, "Guillaume Berche" <bercheg(a)gmail.com> a écrit :

+1 for app stickyness when a route us mapped to multiple apps, and sticky
sessions are requested (currently through j session is cookie)

I'd even suggest that app stickyness is the default when sticky sessions
are requested.

What would be use-cases for opting out of app stickyness ?

I'm not sure either about use cases for an app to control this behavior
(ie opt out). If needed, I'd rather see this as a property of the route
controlled by an operator (along with the weight, and potentially mutable).
Le 27 mai 2016 01:20, "Shannon Coen" <scoen(a)pivotal.io> a écrit :

Yes, thanks for the clarification Mike.


Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, May 26, 2016 at 2:38 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Hi Shannon,

Good question. I haven't really considered an app initiating this but I
think that could work.

The ultimate use case for this, in my mind, is to eventually support
transitioning http sessions from a blue app to a green app in a blue/green
deploy type of scenario.

I think this could be done with the a combination of a sticky app
feature and the request weight load feature you mentioned in your talk.

With those 2 features I could write my application to indicate to the
router that I wish to maintain sticky app. Then I could set request weight
to some percent (possibly even 100%) of load to the new app. That way
users would eventually and smoothly transition all new http sessions to the
new app.

So, to answer your question I think it quite reasonable to ask the
application itself, through cookie or something, to declare if it wants
instance, app, or no stickiness. However, I believe the mechanism to
declare how much load each app bound to a route should get would need to be
controlled outside the app, but, could potentially be the very same
mechanism you envisioned for the upcoming load weight feature.

Does that make sense?

Mike



On Thu, May 26, 2016 at 11:56 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Mike,

I thought I'd put this on the list in case others have similar use
cases.

At summit you mentioned an interest in a variant of sticky session
behavior, and I wonder if you could provide some additional context.

You suggested it would be valuable if, where multiple apps were mapped
to the same route, all requests from a client were routed to the same app.
I believe the example you gave was where the two apps represent different
versions of a web UI. In this case all requests from the client could be
load balanced to any instance of the same app, for the life of the session.
This might be accomplished using a new cookie.

Do you imagine the application initiating this behavior as it does now?
I have some evidence for a feature to relieve apps of this responsibility,
by enabling developers to express that sticky sessions should be enabled
for a route; then the router could potentially handle returning cookies to
clients.

Do you imagine a developer being able to express that they want sticky
sessions enabled for a route in either an "app" or "instance" mode?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.