tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Linus Brimstedt <linus.brimst...@viskan.se>
Subject Re: Parallel Deployment: Can I request a specific webapp version?
Date Thu, 01 Oct 2015 11:27:23 GMT
Hi,

Ok, so to conclude this is not possible at the moment.

Thanks for the input and clarifications as well as the suggested ways to
work :)

br
/Linus

On 29 September 2015 at 00:16, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----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 <
> > chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 

*Linus Brimstedt *
CTO
+46 70 - 683 98 54
linus.brimstedt@viskan.se

*Viskan Distanshandel System AB*
Druveforsvägen 8
504 33 Borås, Sweden
+46 33 - 20 60 20
www.viskan.se

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message