Does anyone know of one? The docs simply say
Length Constraints: Maximum length of 32.
Required: Yes
but they seem to have a regular form; e.g. only upper-case letters and numbers, starting with Z etc.
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.
Can I convert a parameter of type string to number in Cloudformation ?
The situation is,
I want to define DedicatedMasterCount in AWS Elasticsearch resource and it needs a Number.
I define a parameter called DedicatedMasterCount with type Number. then refers to it
for example:
DedicatedMasterCount:
Fn::If:
- isDedicatedMasterEnabled
- !Ref DedicatedMasterCount
- AWS::NoValue
but !Ref converts Number directly to String automatically, which cause a error "Encountered non numeric value" resulting a failure by building stack
I have simple ask, how do I create a Amazon Lex slot for Alphanumeric values.
So far I have tried -
AMAZON.Number: only takes decimal numbers
AMAZON.PostalAdress: takes
everything except numbers
Custom Slot with no values: Only numbers
Is there any way to create a slot which takes alphanumeric values?
Thanks
You can use a custom slot type.
Remember you don't need to enumerate all possible values, just provide enough training data so patterns match. Try giving it around 20-30 values and see if that's enough to train the slot type.
There is no particular datatype to take alphanumberic values.
AMAZON.NUMBER: accepts only numbers
AMAZON.US_FIRST_NAME: accepts only letters
As part of creating a chatbot in Amazon Lex, I have used AMAZON.Movie to accept both letters and numbers(alphanumberic values) it worked for me. As movie name can have alphanumberic values (Ex: The Incredibles2). I hope it works for you too.
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