Closed dwallraff closed 9 years ago
in "./opsmgr.py settings dwallraff-rebel" output (careful, it contains keys), is the infrastructure section present, and does it have availability_zones in it?
On Wed, Nov 11, 2015 at 12:00 PM, Dave Wallraff notifications@github.com wrote:
Lemme know if you need some more logs.
~/code/rebel (master) > ./cf.py config dwallraff-rebel 1.6.1 Creating folder for product elastic-runtime Downloading file elastic-runtime/cf-1.6.1.pivotal Importing file elastic-runtime/cf-1.6.1.pivotal Traceback (most recent call last): File "./cf.py", line 186, in
cli.cli(sys.argv, commands) File "/Users/dwallraff/code/rebel/cli.py", line 34, in cli result = command"func" File "./cf.py", line 178, in config_cmd settings = cf_config(stack, version) File "./cf.py", line 49, in cf_config elastic_runtime["availability_zone_references"] = [ az["guid"] for az in infrastructure["availability_zones"]] KeyError: 'availability_zones' — Reply to this email directly or view it on GitHub https://github.com/guidowb/rebel/issues/17.
Yes it does.
"infrastructure": {
"availability_zones": [
{
"guid": "e98f67a70e18480cae20",
"iaas_identifier": "us-east-1b"
}
],
Full output sent OOB.
With output from print json.dumps(infrastructure, indent=4)
~/code/rebel (master) > ./cf.py config hryan 1.5.4
{
"vm_password_type": "generate",
"type": "aws",
"director_configuration": {
"database_type": "internal",
"blobstore_type": "local",
"resurrector_enabled": false
},
"iaas_configuration": {
"encrypted": false
}
}
Traceback (most recent call last):
File "./cf.py", line 187, in <module>
cli.cli(sys.argv, commands)
File "/Users/dwallraff/code/rebel/cli.py", line 34, in cli
result = command["func"](argv[1:])
File "./cf.py", line 179, in config_cmd
settings = cf_config(stack, version)
File "./cf.py", line 50, in cf_config
elastic_runtime["availability_zone_references"] = [ az["guid"] for az in infrastructure["availability_zones"]]
KeyError: 'availability_zones'
The root cause of this was that the director tile was never configured due to an error in the previous step. That error, in turn, was caused by a bug in 1.6.x support introduced when back-level support for 1.5.x was added. Fixed now. Could definitely use some more work to make it more robust against failures, in general.
Lemme know if you need some more logs.