Trying to create a dataset and template in a bitbucket pipeline using aws sam and it returns the error
Model validation failed (#: extraneous key [DataSourceArn] is not permitted
I've tried
xxxxDataset:
Type: AWS::QuickSight::DataSet
Properties:
AwsAccountId: !Ref "AWS::AccountId"
Name: !Sub 'xxxxDataset${PlatformParameter}'
ImportMode: 'DIRECT_QUERY'
PhysicalTableMap:
RelationalTable:
Catalog: 'AwsDataCatalog'
DataSourceArn: !Sub 'arn:aws:quicksight:${RegionParameter}:${AWS::AccountId}:datasource/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
and
xxxxDataset:
Type: AWS::QuickSight::DataSet
Properties:
AwsAccountId: !Ref "AWS::AccountId"
Name: !Sub 'xxxxDataset${PlatformParameter}'
ImportMode: 'DIRECT_QUERY'
S3Source:
DataSourceArn: !Sub 'arn:aws:quicksight:${RegionParameter}:${AWS::AccountId}:datasource/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
both give the same error while DataSourceArn is a valid key according to the documentation. I'm referring to cloudformation doc https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-quicksight-dataset.html but there may be differences with aws-sam for which I haven't found quicksight documentation...
Thanks any help appreciated
Related
I have been trying to create Schema in EventSchema registry using CloudFormation template
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
Test
Resources:
SchemaRegistry:
Type: AWS::EventSchemas::Registry
Properties:
RegistryName: macak
Schema1:
Type: AWS::EventSchemas::Schema
Properties:
RegistryName: !Ref SchemaRegistry
Type: OpenApi3
Content:
'Fn::Transform':
Name: AWS::Include
Parameters:
Location: ./schema.openapi.json
But I am getting following error during sam deploy
CREATE_FAILED AWS::EventSchemas::Schema Schema1 Property validation failure:
[Value of property
{/Content} does not match
type {String}]
ROLLBACK_IN_PROGRESS AWS::CloudFormation::Stack macak-test The following resource(s)
failed to create: [Schema1].
Rollback requested by user.
Is it possible to include file-contents into EventSchema without using some pre-processing like jinja or handlebars? I hoped this approach would work but I am not able to make it working.
Issue
I am trying to do a major version upgrade from Aurora Postgres 10.14 to 11.9 using Cloudformation. My template creates a DBCluster, a DBInstance, a DBClusterParameterGroup and a DBParameterGroup.
The problem is that when I try to update the stack and change the EngineVersion property for DBCluster from 10.14 to 11.9 and change the Family property for DBClusterParameterGroup and DBParameterGroup from aurora-postgresql10 to aurora-postgresql11, I get this error in CloudFormation:
Error
The following parameters are not defined for the specified group: enable_partitionwise_aggregate, enable_parallel_append, enable_partition_pruning, vacuum_cleanup_index_scale_factor, pg_bigm.last_update, apg_enable_semijoin_push_down, parallel_leader_participation, pg_bigm.enable_recheck, pg_bigm.gin_key_limit, max_parallel_maintenance_workers, pg_bigm.similarity_limit, enable_parallel_hash, enable_partitionwise_join (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue)
I think this is because, according to the AWS Documentation for RDS Parameter Groups:
The DB cluster parameter group family can't be changed when updating a DB cluster parameter group
So even though I am trying to update the Family property for DBClusterParameterGroup and DBParameterGroup, CloudFormation simply ignores that, and so it is trying to apply the aurora-postgresql10 Parameter group Family aurora-postgresql10 to a database now trying to run Aurora Postgres 11.9
What I've tried
Updating the Description property for
DBClusterParameterGroupandDBParameterGroupto include a reference to thepEngineVersion` parameter, as the AWS Documentation
says that will trigger a Replacement, but it does not actually do
this, and so I get the same error
Manually adding the parameters listed in the error to DBParameterGroup before running update. Got error "Unmodifiable DB Parameter: pg_bigm.last_update"
The only workaround I have found is clunky:
Manually update the database version in the console from 10.14 to 11.9, and change the DB cluster parameter group and Parameter group both to default.aurora-postgresql11 as well
Comment out the code for DBClusterParameterGroup and DBParameterGroup and update the stack with the updated EngineVersion 11.9 for DBCluster
Uncomment out the code for DBClusterParameterGroup and DBParameterGroup and update the stack again with the correct Family property aurora-postgresql11 on DBClusterParameterGroup and DBParameterGroup. Now the database is updated, it is using the custom parameter groups, and the stack is not drifting
Code
Parameters:
pEngineVersion:
Type: String
#currently '10.14'
#trying to change to '11.9'
pFamily:
Type: String
#currently 'aurora-postgresql10'
#trying to change to 'aurora-postgresql11'
Resources:
DBClusterParamGroup:
Type: AWS::RDS::DBClusterParameterGroup
Properties:
Description: !Sub 'AuroraDBClusterParamGroup-${AWS::Region}'
Family: !Ref pFamily
Parameters:
application_name: "App name"
log_statement: all
log_min_duration_statement: 0
DBParamGroup:
Type: AWS::RDS::DBParameterGroup
Properties:
Description: !Sub 'AuroraDBParamGroup-${AWS::Region}'
Family: !Ref pFamily
Parameters:
max_connections: 1000
AuroraDBCluster:
Type: AWS::RDS::DBCluster
Properties:
EngineVersion: !Ref pEngineVersion
Engine: aurora-postgresql
DBClusterParameterGroupName: !Ref 'DBClusterParamGroup'
#snipping unneccesary code#
AuroraDBInstance:
Type: AWS::RDS::DBInstance
Properties:
Engine: aurora-postgresql
DBParameterGroupName: !Ref 'DBParamGroup'
DBClusterIdentifier: !Ref 'AuroraDBCluster'
#snipping unneccesary code#
Any help would be very appreciated
Solution
This method worked for me (I've modified some things slightly to post in a public forum) EDIT: I have updated this to use the Blue/Green solution now that I have had the chance to test it.
Parameters:
[...]
DBEngineVersion:
Type: String
Description: "Choices are engine versions from Postgres 9/10/11, only newest and legacy deployed in Prod versions"
Default: 11.7
AllowedValues:
- 9.6.18
- 10.7
- 10.14
- 11.7
MajorVersionUpgrade:
Type: String
Description: Swap this between 'Blue' or 'Green' if we are doing a Major version upgrade
Default: Blue
AllowedValues:
- Blue
- Green
Conditions:
BlueDeployment: !Equals [!Ref MajorVersionUpgrade, "Blue"]
GreenDeployment: !Equals [!Ref MajorVersionUpgrade, "Green"]
Mappings:
EngineToPGFamily:
"9.6.18":
PGFamily: aurora-postgresql9.6
"10.7":
PGFamily: aurora-postgresql10
"10.14":
PGFamily: aurora-postgresql10
"11.7":
PGFamily: aurora-postgresql11
##### Keep parameters of both versions in sync ####
DBClusterParameterGroupBlue: #Keep parameters of both versions in sync
Type: "AWS::RDS::DBClusterParameterGroup"
Condition: BlueDeployment
Properties:
Description: !Sub "Postgres Cluster Parameter Group for ${InfrastructureStackName}"
Family: !FindInMap ['EngineToPGFamily', !Ref 'DBEngineVersion', 'PGFamily']
Parameters:
client_encoding: UTF8
idle_in_transaction_session_timeout: 60000
DBClusterParameterGroupGreen:
Type: "AWS::RDS::DBClusterParameterGroup"
Condition: GreenDeployment
Properties:
Description: !Sub "Postgres Cluster Parameter Group for ${InfrastructureStackName}"
Family: !FindInMap ['EngineToPGFamily', !Ref 'DBEngineVersion', 'PGFamily']
Parameters:
client_encoding: UTF8
idle_in_transaction_session_timeout: 60000
DBCluster:
Type: "AWS::RDS::DBCluster"
Properties:
DBClusterIdentifier: !Sub "${AWS::StackName}-cluster"
DBClusterParameterGroupName: !If [GreenDeployment, !Ref DBClusterParameterGroupGreen, !Ref DBClusterParameterGroupBlue]
Engine: aurora-postgresql
[...]
DBInstance1:
Type: "AWS::RDS::DBInstance"
Properties:
DBClusterIdentifier: !Ref DBCluster
EngineVersion: !Ref DBEngineVersion
Engine: aurora-postgresql
[...]
DBInstance2:
Type: "AWS::RDS::DBInstance"
Properties:
DBClusterIdentifier: !Ref DBCluster
EngineVersion: !Ref DBEngineVersion
Engine: aurora-postgresql
[...]
Usage and Methodology
This method will create a new ClusterParameterGroup that will be used during the upgrade (when doing a Major version upgrade), and clean up the original group when the upgrade is done. The advantage to this solution is that there is no version hardcoding in the group and the same template can be used for continuous lifecycle updates without additional changes needed (aside from desired Parameters updates).
Initial Setup
Initially, leave MajorVersionUpgrade set to Blue and the conditions will ensure that only the Blue ParameterGroup is created using the proper DB family.
Performing a Major Version Upgrade
Update the stack and set the DBEngineVersion to the new major version and MajorVersionUpgrade to Green if it is currently Blue (or Blue if it is currently Green). CloudFormation will:
Start by creating the new resources (which is the new parameter group referencing the new version)
Then it will update the Cluster and point to that new group
Finally, it will delete the old ParameterGroup (referncing the old version) during the cleanup phase since the Blue/Green Condition for that group no longer evaluates to true.
Important notes
The Parameters in both parameter groups must manually kept in sync
Obviously, update the DBEngineVersion AllowedValues list with versions as needed, just be sure to update the EngineToPGFamily Mappings to have a valid Postgres family value for that Engine version
Special care must be paid when implementing Parameters that are new to a DB Major version and don't exist in an older version, I have not tested this
You are correct that you cannot change the family on a DB Parameter Group that already has been created. That is why you get the error about the missing parameters, which isn't a great error response by AWS given the root cause.
Since DB Parameter Groups can be replaced without having to replace the DB Instance, you should change the Logical ID of the DB Parameter Group so it is detected as a new resource by CloudFormation, and removes the old v10 DB Parameter Group.
Example using your code:
Parameters:
pEngineVersion:
Type: String
Default: '11.9'
#currently '10.14'
#trying to change to '11.9'
pFamily:
Type: String
Default: 'aurora-postgresql11'
#currently 'aurora-postgresql10'
#trying to change to 'aurora-postgresql11'
Resources:
DBClusterParamGroup11:
Type: AWS::RDS::DBClusterParameterGroup
Properties:
Description: !Sub 'AuroraDBClusterParamGroup-${AWS::Region}'
Family: !Ref pFamily
Parameters:
application_name: "App name"
log_statement: all
log_min_duration_statement: 0
DBParamGroup11:
Type: AWS::RDS::DBParameterGroup
Properties:
Description: !Sub 'AuroraDBParamGroup-${AWS::Region}'
Family: !Ref pFamily
Parameters:
max_connections: 1000
AuroraDBCluster:
Type: AWS::RDS::DBCluster
Properties:
EngineVersion: !Ref pEngineVersion
Engine: aurora-postgresql
DBClusterParameterGroupName: !Ref 'DBClusterParamGroup'
#snipping unneccesary code#
AuroraDBInstance:
Type: AWS::RDS::DBInstance
Properties:
Engine: aurora-postgresql
DBParameterGroupName: !Ref 'DBParamGroup'
DBClusterIdentifier: !Ref 'AuroraDBCluster'
#snipping unneccesary code#
Notice how I renamed DBParamGroup to DBParamGroup11 and DBClusterParamGroup to DBClusterParamGroup11.
When creating a AWS::CodeDeploy::DeploymentGroup in CloudFormation, I get this error, even though I have no EC2TagFilters in my script:
For ECS deployment group, ec2TagFilters can not be specified (Service: AmazonCodeDeploy; Status Code: 400; Error Code: InvalidEC2TagException; Request ID: af5c3f68-6033-4df0-9f6f-ecd064ad6b7b; Proxy: null)
CodeDeploymentGroupDev:
Type: AWS::CodeDeploy::DeploymentGroup
DependsOn:
- CodeDeployApplication
Properties:
ApplicationName: !Ref ApplicationName
DeploymentConfigName: CodeDeployDefault.AllAtOnce
DeploymentGroupName: !Sub "${ApplicationName}-Dev"
DeploymentStyle:
DeploymentType: IN_PLACE
OnPremisesTagSet:
OnPremisesTagSetList:
- OnPremisesTagGroup:
- Key: !Ref OnPremisesTagKey
Type: KEY_AND_VALUE
Value: !Ref OnPremisesTagValue
ServiceRoleArn: !Sub 'arn:aws:iam::${AWS::AccountId}:role/CodeDeployServiceRole'
Is AWS::CodeDeploy::DeploymentGroup not implemented correctly in CloudFormation?
I can see that you are using OnPremisesTagSet which mean you should already register on-premises instances with CodeDeploy, see https://docs.aws.amazon.com/codedeploy/latest/userguide/instances-on-premises.html.
If you are using Ec2 then you need to use Ec2TagSet instead of OnPremisesTagSet.
This occurred because my corresponding AWS::CodeDeploy::Application was not configured correctly (not in original post, but shown below). I was attempting an onprem deploy using a registered agent. I had ECS for the compute platform, but it should have been Server:
CodeDeployApplication:
Type: AWS::CodeDeploy::Application
Properties:
ApplicationName: !Ref ApplicationName
ComputePlatform: Server // Allowed values: ECS | Lambda | Server
It worked, after I fixed that.
I would like to get the PrivateIP attribute of EC2s that i create via LaunchConfiguration.
I need that attribute so that i can assign a type A dns record to the instance for other purposes.
Here is my code:
Resources:
webLaunchConfig:
Type: 'AWS::AutoScaling::LaunchConfiguration'
Properties:
ImageId: !Ref webEc2AMI
InstanceType: !Ref ec2WebInstanceType
SecurityGroups: !Ref webEc2SG
UserData:
'Fn::Base64': !Sub >
#!/bin/bash -xe
apt update -y
dnsWebServerName:
Type: 'AWS::Route53::RecordSet'
Properties:
HostedZoneId: !Ref hostedZoneId
Comment: DNS name for my db server.
Name: !Ref dnsWebServerNamePar
Type: A
TTL: '900'
ResourceRecords:
- !GetAtt webLaunchConfig.PrivateIp
... and when i try to launch it i get this error:
Template contains errors.: Template error: resource webLaunchConfig
does not support attribute type PrivateIp in Fn::GetAtt
... indicating me that what i am trying to do is not supported. Though there must be a way to achieve this.
Do you know how to do it? Or a workaround for this?
Sadly you can't do this. AWS::AutoScaling::LaunchConfiguration is only a blueprint of an instance to be launched. Thus it does not provide information about instance PrivateIp. The get the PrivateIp you have to actually launch the instance.
To do so you have to use AWS::EC2::Instance. However AWS::EC2::Instance does not support launching from ``AWS::AutoScaling::LaunchConfiguration. So either you have to change your LaunchConfigurationintoLaunchTemplateor just create instance directly usingAWS::EC2::Instance` rather then any templates.
I have a cloud formation template (mainVPC) that creates few Subnets in a VPC and exports the subnets with names "PrivateSubnetA", "PrivateSubnetB" ...
I have a different cloud formation template that creates DBSubnetGroup. I want to use "PrivateSubnetA", "PrivateSubnetB" as default values if user does not provide data. CloundFormation does not support imported values in parameters. So I put some default value (XXXX) and had a condition section to see if the user has provided some input
Conditions:
userNotProvidedSubnetA: !Equals
- !Ref PrivateSubnetA
- XXXX
userNotProvidedSubnetB: !Equals
- !Ref PrivateSubnetB
- XXXX
This helps me in figuring out if the user has provided data. Now I want to use default values, if the user has not provided values, else use user-provided values.
below is code for that
DBSubnetGroup:
Type: 'AWS::RDS::DBSubnetGroup'
Properties:
DBSubnetGroupDescription: RDS Aurora Cluster Subnet Group
SubnetIds:
- !If
- userNotProvidedSubnetA
- Fn::ImportValue:
!Sub '${fmMainVpc}-PrivateSubnetA'
- !Ref PrivateSubnetA
- !If
- userNotProvidedSubnetB
- Fn::ImportValue:
!Sub '${fmMainVpc}-PrivateSubnetB'
- !Ref PrivateSubnetB
This fails with the error "Template error: the attribute in Fn::ImportValue must not depend on any resources, imported values, or Fn::GetAZs".
ImportValue is not used anywhere else in the template.
Is there a way for using exported values as default values ( the default values cannot be hardcoded, they come as exported values from a run of another stack), while providing an option for the users to provide their own values (to create resources).
Thanks.
This can also be caused by having a reference inside Fn::ImportValue to a parameter be misnamed. For example, if I have the following parameter NetworkStackName defined and I mis-reference it in the Fn::ImportValue statement (as NetworkName), I will get this error. I would need to change the NetworkName to match the value in Parameters, NetworkStackName to fix the error.
Parameters:
NetworkStackName:
Type: String
Default: happy-network-topology
Resources:
MySQLDatabase:
Type: AWS::RDS::DBInstance
Properties:
Engine: MySQL
DBSubnetGroupName:
Fn::ImportValue:
!Sub "${NetworkName}-DBSubnetGroup"
I had a problem where I needed to get my artifact bucket name from my prerequisite stack, I tried this:
Fn::ImportValue:
- 'arn:aws:s3:::${ArtifactStore}/*'
turns out you can do this and it will work. Hope his helps someone out one day!
- !Sub
- 'arn:aws:s3:::${BucketName}/*'
- BucketName : !ImportValue 'ArtifactStore'
Currently, Cloudformation didn't support dynamic default value. It's not possible to have a dynamic default value for CloudFormation. As the template has not executed at the time all parameters are being collected. However, you can use SSM parameter for as the workaround, something like below.
Parameters
PagerDutyUrl:
Type: AWS::SSM::Parameter::Value<String>
Description: The Pagerduty url
Going back to your current cloudformation, I am thinking that value ${fmMainVpc} might not be initialized correctly.
I'm my case, I had the follow resource:
# removed for brevity
Subnets:
- !ImportValue: parent-stack-subnet-a
- !ImportValue: parent-stack-subnet-b
I forgot to remove the : when changing the syntax from Fn::ImportValue to the shorthand !ImportValue. Confusing error message, but removing the : resolved it because that was incorrect usage on my part.