I have the below step function and I'm trying to pass the ARN to the StartProjectVersion step in the "test" variable using "ProjectVersionArn": "$.test". Every time I execute the step functions, StartProjectVersion fails with:
2 validation errors detected: Value '$.test' at 'projectVersionArn'
failed to satisfy constraint: Member must satisfy regular expression
pattern: (^arn:[a-z\d-]+:rekognition
How can I set the ARN using $.test? Thank you.
Parameters: For key-value pairs where the value is selected using a path, the key name must end in .$.
"ProjectVersionArn.$": "$.test"
Writing a CFN for ACM, but don't know the difference between
CommaDelimitedList and List<CommaDelimitedList>
According to the aws doc
https://docs.amazonaws.cn/en_us/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html
CommaDelimitedList
An array of literal strings that are separated by commas. The total number of strings should be one more than the total number of commas. Also, each member string is space trimmed.
For example, users could specify "test,dev,prod", and a Ref would result in ["test","dev","prod"].
So what is the difference between them
SubjectAlternativeName:
Type: List<CommaDelimitedList>
Description: Alternative sub-domain names that will be covered in your certificate.
So in the actual input when creating the resource, what should be the data for correct type?
Is below correct? for CommaDelimitedList or ?
Answer to my question:
They can be used interchangeably
List<CommaDelimitedList> and CommaDelimitedList
Also 'List<String>'
In term of the input for these types List<CommaDelimitedList> and CommaDelimitedList
Example as below
I'm trying to run a dataflow job using cloud build
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args:
dataflow
jobs
run
google-template-job
--gcs-location=gs://dataflow-templates/latest/PubSub_Subscription_to_BigQuery
--parameters=inputSubscription='projects/$PROJECT_ID/subscriptions/messages'
--parameters=outputTableSpec="$PROJECT_ID:beam_samples.streaming_beam"
--staging-location=gs://cloudbuild-dataflow-testproject123456789-313307/tmp'
--region=us-central1
Every time I trigger the build I get the following error
ERROR: (gcloud.dataflow.jobs.run) INVALID_ARGUMENT: The template parameters are invalid.
- '#type': type.googleapis.com/google.dataflow.v1beta3.InvalidTemplateParameters
parameterViolations:
- description: 'Unmatched regex: ^projects\/[^\n\r\/]+\/subscriptions\/[^\n\r\/]+$'
parameter: inputSubscription
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/gcloud" failed: step exited with non-zero status: 1
My project id has a ' - ' in it so if I replace the $PROJECT_ID with the value of project id, I still get the same error, is there any workaround for this. I don't have any control over stopping the regex check since it's a google provided template.
How do I get past this
Got it. It's only a command interpreter issue. If you put single quote, you prevent any evaluation of the inside string.
In you case
--parameters=inputSubscription='projects/$PROJECT_ID/subscriptions/messages'
the value 'projects/$PROJECT_ID/subscriptions/messages' is taken as is and therefore the project ID contain uppercase and underscore, that violate the regex pattern.
Change for double quote and it should work great!
--parameters=inputSubscription="projects/$PROJECT_ID/subscriptions/messages"
I'm trying to run a nested stack with the root stack that creates multiple resources including S3 buckets and a Cognito User Pool. The issue is:
S3 bucket name doesn't allow Capitalised letters.
Cognito Identity Pool name doesn't allow dashes -.
I want to name my resources with the same/similar name ${AWS::StackName}-then-some-string so they're recognised as parts of one application.
Is there a way to remove dashes from parameters inside cloudformation? I know I can use Fn::Split to split the string with - then use Fn::Select to select specific elements then Fn::Join but that will only work for a stack name with a certain amount of dashes -.
I can't find any resource anywhere on how to change the - to empty string or something else using some sort of function or regex.
You're nearly there - use Fn::Split and Fn::Join, no select needed.
SomeKey:
Fn::Join:
- ''
- Fn::Split:
- '-'
- !Ref YourParam
Split returns an array. Join takes a join string and an array of items to join. So just split on the hyphen/dash, then join the parts back together with an empty string, thereby eliminating the hyphens.
I have encountered problem in yaml-cpp parser. When I try to load following definition:
DsUniversity:
university_typ: {type: enum, values:[Fachhochschule, Universitat, Berufsakademie]}
students_at_university: {type: string(50)}
I'm getting following error:
Error: yaml-cpp: error at line 2, column 39: end of map flow not found
I tried to verify yaml validity on http://yaml-online-parser.appspot.com/ and http://yamllint.com/ and both services reports yaml as valid.
Problem is caused by missing space after "values:" definition. When yaml is updated to following format:
DsUniversity:
university_typ: {type: enum, values: [Fachhochschule, Universitat, Berufsakademie]}
students_at_university: {type: string(50)}
everything works as expected.
Is there any way how to configure/update/fix yaml-cpp parser to proceed also yamls with missing space after colon?
Added:
It seems that problem is caused by requirement for empty char as separator. When I simplified testing snippet to
DsUniversity:[Fachhochschule, Universitat, Berufsakademie]
yaml-cpp parser reads it as one scalar value "DsUniversity:[Fachhochschule, Universitat, Berufsakademie]". When empty char is added after colon, yaml-cpp correctly loads element with sequence.
yaml-cpp is correct here, and those online validators are incorrect. From the YAML 1.2 spec:
7.4.2. Flow Mappings
Normally, YAML insists the “:” mapping value indicator be separated from the value by white space. A benefit of this restriction is that the “:” character can be used inside plain scalars, as long as it is not followed by white space. This allows for unquoted URLs and timestamps. It is also a potential source for confusion as “a:1” is a plain scalar and not a key: value pair.
...
To ensure JSON compatibility, if a key inside a flow mapping is JSON-like, YAML allows the following value to be specified adjacent to the “:”. This causes no ambiguity, as all JSON-like keys are surrounded by indicators. However, as this greatly reduces readability, YAML processors should separate the value from the “:” on output, even in this case.
In your example, you're in a flow mapping (meaning a map surrounded by {}), but your key is not JSON-like: you just have a plain scalar (values is unquoted). To be JSON-like, the key needs to be either single- or double-quoted, or it can be a nested flow sequence or map itself.
In your simplified example,
DsUniversity:[Fachhochschule, Universitat, Berufsakademie]
both yaml-cpp and the online validators parse this correctly as a single scalar - in order to be a map, as you intend, you're required a space after the :.
Why does YAML require that space?
In the simple plain scalar case:
a:b
could be ambiguous: it could be read as either a scalar a:b, or a map {a: b}. YAML chooses to read this as a scalar so that URLs can be easily embedded in YAML without quoting:
http://stackoverflow.com
is a scalar (like you'd expect), not a map {http: //stackoverflow.com}!
In a flow context, there's one case where this isn't ambiguous: when the key is quoted, e.g.:
{"a":b}
This is called JSON-like because it's similar to JSON, which requires quotes around all scalars. In this case, YAML knows that the key ends at the end-quote, and so it can be sure that the value starts immediately.
This behavior is explicitly allowed because JSON itself allows things like
{"a":"b"}
Since YAML 1.2 is a strict superset of JSON, this must be legal in YAML.
I think it would be beneficial to parse scalar/keys differently immediately inside a flow map{, if you agree, vote here please.
https://github.com/yaml/yaml-spec/issues/267