Replace Environment solution stack is not what I expected
Closed this issue · 18 comments
We recently attempted to update the solution stack we use for our environments. When viewing the logs I found a warning from the following string (found in ReplaceEnvironmentMojo).
"(btw, we're launching with solutionStack/ set to '%s' instead of the default ('%s'). "
+ "If this is not the case, then we kindly ask you to file a bug report on the mailing list :)",
I took a brief look at the code. It appears that the plugin will get the solution stack from existing environments regardless of what this parameter is set to use. I found this behavior unintuitive. It also will make upgrading solutions stacks much more difficult than simply modifying the Maven POM settings.
Thats right - it doesn't allow you to perform an upgrade of the solution stack. The 1.4.0-SNAPSHOT series will allow some changes (by allowing you to use wildcards for this), but I'm closing as it works as intended.
OTOH, I might think about forcing and overriding to a platform stack. I'll leave it open, but make sure you track the activity on beanstalker-users mailing list.
Hi @aldrinleal, thanks for reconsidering. When do you expect the 1.4.0 version to be available? Waiting for that might be fine.
What is the URL of the beanstalker-users mailing list?
@aldrinleal It would be very helpful to be able to change the solution stack on a replace-environment deployment. While this makes perfect since for update environment operations (where the Solution Stack cannot be upgraded anyway), on a replace-environment when we're spinning up a new parallel stack and intend to swap DNS once it's healthy, it doesn't seem there is any advantage to being prevented from specifying the solution stack to use for the new environment.
It is possible (use a wildcard on the solution stack name)
-- Aldrin Leal, aldrin@leal.eng.br
Master your EC2-fu! Get the latest ekaterminal public beta
http://www.ingenieux.com.br/products/ekaterminal/
On Wed, Mar 25, 2015 at 6:00 PM, jedge-mgc notifications@github.com wrote:
@aldrinleal https://github.com/aldrinleal It would be very helpful to
be able to change the solution stack on a replace-environment deployment.
While this makes perfect since for update environment operations, where the
Solution Stack cannot be upgraded anyway, but on a replace-environment when
we're spinning up a new parallel stack and intend to swap DNS once it's
healthy, it doesn't seem there is any advantage to being prevented from
specifying the solution stack to use for the new environment.—
Reply to this email directly or view it on GitHub
#55 (comment)
.
@aldrinleal I'm unsure what the wildcard does for us. I don't want to change to a random solution stack that the wildcard matches, I want to specify one for the replacement environment w/ cname swap as @jedge-mgc mentioned.
My example is I'm moving from an old stack:
64bit Amazon Linux 2014.03 v1.0.7 running Tomcat 7 Java 7
to
64bit Amazon Linux 2015.03 v1.4.3 running Tomcat 7 Java 7
How would I specify a wildcard to make this specific transition happen?
** note to others having this issue, you can work around this by the following:
- set mockTerminateEnvironment to true (this prevents the current instance from shutting down)
- set maxAttempts to 0 ( this prevents cname swap)
- deploy the new replace-environment, it will come up with the bad/old solution stack
- update the solution stack on the new environment via the web app, wait for it to complete
- manually swap cname via the web app
- terminate the old environment
- set the two configuration variables back to their prior values.
@frankamp, wouldn't mvn -Pawseb clean deploy -Dbeanstalk.solutionStack='64bit Amazon Linux 2015.03 v1.4.3 running Tomcat 7 Java 7' do the trick?
Epic rant! 👏 👏 👏 :-) Thanks for working on this project.
I have a similar desire to go from EB platform version X to version Y w/out having to terminate the target environment or manually upgrade the target env via the console (which reaches a scalability limit at a certain number of EB apps). A forced override flag would be a totally workable solution. I can confirm passing the beanstalk.solutionStack system property on the command line results in the same plugin (v1.4.0) warning even when using wildcards (e.g. -Dbeanstalk.solutionStack='64bit Amazon Linux 2015.03 v2* running Docker *').
Looking at https://github.com/ingenieux/beanstalker/blob/master/beanstalk-maven-plugin/src/main/java/br/com/ingenieux/mojo/beanstalk/env/ReplaceEnvironmentMojo.java it seems like adding a override flag similar to "beanstalk.copyOptionSettings" would be a quick/simple change. If this seems acceptable I'd be happy to submit a pull request.
Which part of 'No' you didn't understand?
Hi @aldrinleal,
I think this maven plugin is great and I am volunteering to contribute back to the project. Are you saying "no" to the approach of a forced override which you proposed in Oct? "No" to supporting platform changes within the replace-environment mojo? "No" to modifications of any sort to the replace-environment mojo? "No" to future modifications of the plugin at all? "No" to contributions from external sources? I'd still like to improve the project and help fill a need that myself and others have expressed if that's an option.
Have you read my post? I mentioned that overriding it wouldnt work and
explained the reason (meaning #1 and #2)
otherwise, be my guest. I am open to a well written and documented patch.
Id suggest cloning replace-environment as, say, upgrade-environment though
On Sep 16, 2015 1:07 PM, "jwilmoth" notifications@github.com wrote:
Hi @aldrinleal https://github.com/aldrinleal,
I think this maven plugin is great and I am volunteering to contribute
back to the project. Are you saying "no" to the approach of a forced
override which you proposed in Oct? "No" to supporting platform changes
within the replace-environment mojo? "No" to modifications of any sort to
the replace-environment mojo? "No" to future modifications of the plugin at
all? "No" to contributions from external sources? I'd still like to improve
the project and help fill a need that myself and others have expressed if
that's an option.—
Reply to this email directly or view it on GitHub
#55 (comment)
.
I've submitted a PR that introduces a new configuration option on the replace-environment goal to override the default/current behavior to force a new solution stack to be used. I manually tested this and was able to upgrade an EB env from "64bit Amazon Linux 2015.03 v1.4.6 running Docker 1.6.2" —> "64bit Amazon Linux 2015.03 v2.0.2 running Docker 1.7.1".
@jwilmoth, I'll accept it as long as you sign a disclaimer accepting all the responsibility for opening the releasing all the worlds' evil by opening the Pandora Box. By accepting, this means I'll fwd and copy all the requests ok? :)
(and ensure you subscribe the beanstalker mailing lists)
I'll gladly update the docs for the property with known consequences of overriding the default behavior. Do you have specific scenarios in mind? The good news is the PR maintains the existing behavior and one has to consciously configure the new behavior.
Sent from my iPhone
On Sep 29, 2015, at 4:52 PM, Aldrin Leal notifications@github.com wrote:
@jwilmoth, I'll accept it as long as you sign a disclaimer accepting all the responsibility for opening the releasing all the worlds' evil by opening the Pandora Box. By accepting, this means I'll fwd and copy all the requests ok? :)
(and ensure you subscribe the beanstalker mailing lists)
—
Reply to this email directly or view it on GitHub.
I did, like the one I shown in the original post I've made. But lets keep
it, then
-- Aldrin Leal, aldrin@leal.eng.br / http://about.me/aldrinleal
On Tue, Sep 29, 2015 at 9:40 PM, jwilmoth notifications@github.com wrote:
I'll gladly update the docs for the property with known consequences of
overriding the default behavior. Do you have specific scenarios in mind?
The good news is the PR maintains the existing behavior and one has to
consciously configure the new behavior.Sent from my iPhone
On Sep 29, 2015, at 4:52 PM, Aldrin Leal notifications@github.com
wrote:@jwilmoth, I'll accept it as long as you sign a disclaimer accepting all
the responsibility for opening the releasing all the worlds' evil by
opening the Pandora Box. By accepting, this means I'll fwd and copy all the
requests ok? :)(and ensure you subscribe the beanstalker mailing lists)
—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#55 (comment)
.