AWS subdomain change causes multiple scenarios to fail
jwilmoth opened this issue · comments
AWS recently changed the construct of the elasticbeanstalk.com URL. https://aws.amazon.com/releasenotes/AWS-Elastic-Beanstalk/0946276467984605 This change unfortunately breaks atleast two scenarios; replace-environment and swap-environments as both are expecting the cname prefix to be able to retrieve the environment ID. I don't have a solution at the moment, but wanted to provide visibility to something that may impact others. We working with our AWS account reps to see if this "feature" can be atleast temporarily disabled for our account. One thing that seems like an option atleast for the swap is to potentially leverage the environment name parameter option (http://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_SwapEnvironmentCNAMEs.html) instead of the ID which requires a lookup.
Yes! Patches are welcome! :)
Anyway, this is going to happen to all regions in the long term, so I'll enable a flag on the Mojos to change their behaviour on an impacted region (currently only us-east-2)
(compare this with the treatment they gave to EC2, warning and allowing optin - MONTHS - in advance)
The problem is with the transition in a seamless fashion. Would a single flag of off on to append the region work to replace an environment that has the old format with a new environment that will need the new format? Or swapping between old and new formats?
(The lack of head up is absolutely a pain!)
I believe that migrating will be best done manually, since it's only needed
to do it once on a region.
-- Aldrin Leal, aldrin@leal.eng.br / http://about.me/aldrinleal
On Fri, Jan 22, 2016 at 5:35 PM, jwilmoth notifications@github.com wrote:
The problem is with the transition in a seamless fashion. Would a single
flag of off on to append the region work to replace an environment that has
the old format with a new environment that will need the new format? Or
swapping between old and new formats?(The lack of head up is absolutely a pain!)
—
Reply to this email directly or view it on GitHub
#86 (comment)
.
Good morning. I tested the current 1.4.3-SNAPSHOT with cname swap and unfortunately it didn't work (failed to find the environment with the legacy EB URL format. Perhaps, it's just the CNAME swap scenario that needs to support both old and new simultaneous.
Are you talking about this guy?
Until tomorrow, it didn't use any CNAME URLs at all, instead relying on environmentNames. Now, it accept both environmentNames (as originally expected) as well as environmentReferences
What about replace-environment and blue-green? a-ok?
Yes, sort of :) I was using http://beanstalker.ingenieux.com.br/beanstalk-maven-plugin/swap-environment-cnames-mojo.html and specifically the Jenkins jobs we've already setup use the optional sourceEnvironmentCNamePrefix and
targetEnvironmentCNamePrefix configurations. That being said we've reached the decision internally to take a brief service outage and replace the environments that were launched with a legacy beanstalk CNAME (including prod), so I think atleast for us the current code base will work.
Sorry, I didn't get. What is the problem anyway? :)
-- Aldrin Leal, aldrin@leal.eng.br / http://about.me/aldrinleal
On Tue, Jan 26, 2016 at 2:24 PM, jwilmoth notifications@github.com wrote:
Yes, sort of :) I was using
http://beanstalker.ingenieux.com.br/beanstalk-maven-plugin/swap-environment-cnames-mojo.html
and specifically the Jenkins jobs we've already setup use the optional
sourceEnvironmentCNamePrefix and
targetEnvironmentCNamePrefix configurations. That being said we've reached
the decision internally to take a brief service outage and replace the
environments that were launched with a legacy beanstalk CNAME (including
prod), so I think atleast for us the current code base will work.—
Reply to this email directly or view it on GitHub
#86 (comment)
.
I believe the current issue is the cname prefix is being provided in a case-sensitive way, but the swap is forcing lower case. This results in the environment not being found.
beanstalk:swap-environment-cnames -Dbeanstalk.sourceEnvironmentCNamePrefix=fnd-sample-svc-perf-A -Dbeanstalk.targetEnvironmentCNamePrefix=fnd-sample-svc-si-e3
[INFO] --- beanstalk-maven-plugin:1.4.3-SNAPSHOT:swap-environment-cnames (default-cli) @ rspElasticBeanstalkAppDeploy ---
[INFO] Configuring Proxy. Proxy Host: webproxysea.nordstrom.net Proxy Port: 8181
[INFO] ... with cname belonging to fnd-sample-svc-perf-a.elasticbeanstalk.com or fnd-sample-svc-perf-a.us-west-2.elasticbeanstalk.com
[INFO] ... with status NOT set to 'Terminated'
[WARNING] FAILURE
org.apache.maven.plugin.MojoExecutionException: No environments found
at br.com.ingenieux.mojo.beanstalk.AbstractBeanstalkMojo.handleNonSingle(AbstractBeanstalkMojo.java:101)
at br.com.ingenieux.mojo.beanstalk.AbstractBeanstalkMojo.handleResults(AbstractBeanstalkMojo.java:93)
at br.com.ingenieux.mojo.beanstalk.AbstractBeanstalkMojo.lookupEnvironment(AbstractBeanstalkMojo.java:82)
at br.com.ingenieux.mojo.beanstalk.env.SwapEnvironmentCnamesMojo.executeInternal(SwapEnvironmentCnamesMojo.java:127)
at br.com.ingenieux.mojo.aws.AbstractAWSMojo.execute(AbstractAWSMojo.java:369)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
I think the issue is in the following method:
public static Predicate<EnvironmentDescription> getHostnamePredicate(Region region, String cnamePrefix) {
final Set<String> hostnamesToMatch = new TreeSet<String>();
hostnamesToMatch.add(format("%s.elasticbeanstalk.com", cnamePrefix).toLowerCase());
hostnamesToMatch.add(format("%s.%s.elasticbeanstalk.com", cnamePrefix, region.getName()).toLowerCase());
return new Predicate<EnvironmentDescription>() {
@Override
public boolean apply(EnvironmentDescription t) {
return hostnamesToMatch.contains(t.getCNAME());
}
@Override
public String toString() {
return format("... with cname belonging to %s", StringUtils.join(hostnamesToMatch.iterator(), " or "));
}
};
}
If the inputs are going to be forced into lower case the predicate likely needs to as well
return new Predicate<EnvironmentDescription>() {
@Override
public boolean apply(EnvironmentDescription t) {
**return hostnamesToMatch.contains(t.getCNAME().toLowerCase());**
}