-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Linus,
On 9/28/15 2:37 AM, Linus Brimstedt wrote:
> On 27 September 2015 at 23:55, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>>
>> You have competing requirements:
>>
>> 1. All servers are the same
>>
> 2. Some subset users get a different version of the application
>>
>
> All servers would have all versions of the app, thats the whole
> point :) I.e. Instead of Server 1 - 3: App Version 001 Server 4 -
> 6: App Version 002
>
> I would have Server 1-6: App Version 001 + 002
>
> Parallel deployment makes this possible and simple to use.
Sure, you can push multiple versions of your application to all your
servers, but the caveat is that all new users will be using the new
application: you can't upgrade selected users (like your own QA
testers, for instance). So this isn't an ideal solution, regardless of
how simple it is.
>> Sounds like they can't co-exist without some kind of compromise.
>> We are offering one that works with currently-available
>> software.
>>
>
> Please elaborate
We've already explained:
1. Upgrade some load-balanced nodes
2. wait (???)
3. Profit
If you want your QA team to be able to use the new version of the
application but none of your "real" users, then try something like this:
1. Remove N/f from your load-balancer and upgrade using parallel
deplyment
(N = # of nodes and f=some factor of nodes you want to use for
testing)
(Existing users will still see version V-1 while new users will
see version V. The lb will not send new users to these servers,
so nobody will see version V at all.)
2. Configure your QA team's browsers so that the lb allows them to
go to the servers you have upgraded, and get version V
3. Proceed with testing
4. When you are satisfied, put the nodes from step #1 back into the lb
normal rotation
5. Upgrade the remaining nodes whenever you feel comfortable
This means that, for a time, not all servers are identical. But you do
achieve your primary objective: blue/green production deployment with
a private interstitial testing phase.
Your prior use of parallel deployment did not meet your primary
criterion: namely that it upgrades too many people at once.
I think you have to decide which requirement is more important: the
private testing phase (which my proposal achieves) or the consistent
configuration of all servers (which your proposal achieves).
I still believe your requirements are at odds with each other.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWCbxDAAoJEBzwKT+lPKRY1vsP/iu70XKXfhZVM4sTA+VsK220
keAIjTUESeSKCF3IZoOtMR/xaC+3rsgCGlVjtyS8JOOkQ5/nHvD+e3XktXL8WZo0
dvynCuFeLFBj89PY3pnDcYnr8AOxnbzlgvKC2dsvE1qKrII1/au9yz3juM2EpO5c
x4avtBklG7/+8hU7sTjpykOK5/7pMXLv5KsmeX6mzoJJky9f5WXuZ6K20jKc7m2b
zdjdgXG6hPvwoOh33ybO/vPPx0h0Ih6eflQqhqEblo2xb+XYWCeSTgMwrOR0nXWK
LXZh2Yyyt7AIozvI1abp97m6kFB9KLSX9QRIb1EmiAnfnkQYCfhWpAPeUcc3ZV/h
yh2h1qON8bCTeed97GWdpPu9o5l1l4EXIKgOk+iLV4rS0CjMQ/ybl6ePOrGApQs9
q7vncmX3V4fZGdYf1qXj7ME7RcgE7U+TwRuR40wPB8McU+BVtI3d/S4I5W+9DBF7
q9+B+EmZ1jCjrwzEot57TuYxM+oT8Lsykm43Esic3CeOxOBdp8phwe65AmZHTxJV
IIhTOdFuwZzL/n2dZx0dNspjc54Df1dgPoGw0OBa8c8BHPBz8ImskLONBQHZwRvy
ejwS00Pps7B/DeiquuZLOUilJo4UP5fS8NbpLPMt/5sBb4L9pgQRXs7jFwxQ0A1y
b6nF/Y5moFILPkWAfuB8
=w+9s
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
