This answer here: Is there a way to parameterize cloud formation resource names? didn't really help as I am looking to set the physical name, not the logical one. I was hoping for something along the lines of setting a parameter in the parameters list like:
"ELBName": {
"Type": "String",
"Default": "xxx",
"Description": "The Production Number for this stack (e.g. xxx)"
}
and then
"LoadBalancerName": "prod" + {Ref: "ELBName"}
although that concatenation directly is not possible. Is there any way to do what I want? My end goal is to take a template I've created and use it to create many copies of itself, each with the same resources, but different names, possibly through a nested stack.
Use Fn::Join function to do this:
"LoadBalancerName":{
"Fn::Join":[
"",
[
"prod",
{
"Ref":"ELBName"
}
]
]
}
This will give the name as prod01 assuming ELBName parameter has been passed the value 01
Related
Ok, new to RESTapi so not sure if I am using the correct terminology for what I want to ask so bear with me. I believe what I am asking about is nested resources in a service but I want to ask specifically about using it for separating a blob of "closely related" content. It may be easier to provide an example. Let's say I have the following service that could output the following:
/Policy
"data": [ {
"name": "PolicyName1",
"description": "",
"size": 25000,
.... (bunch of other fields)
"specialEnablement": true,
“specialEnablementOptions”: { <-- options below valid only if specialEnablement is true
“optionType”: “TypeII”,
“optionFlagA”: false,
“optionFlagB”: true,
“optionFlagC”: false,
...(bunch of other options here)
}
},
{ . . . }],
The specialEnablementOptions are only used if specialEnablement is 'true'. It is all part of this /Policy service so has no primary key other than the policy "name" (and doesnt make sense to have to generate one) so does not fall under some of the other questions I have been reading about nested resources.
It does make it more readable to separate this set of information since there are 12 or so options but, this is REST so, maybe human readability does not weigh heavily here.
I am being told that, if we do it this way, it makes it more complex to work with during POST/PUT/PATCH commands. Specifically, it is being said in my group that if we do this, we should require two calls....one that creates the policy main information then the user must call a second time to PATCH the specialEnablementOptions (assuming specialEnablement is true). This seems kludgy to me.
I am looking for expert advise on what the best practice is.
My questions:
Does having the specialEnablementOptions nested in this way cause a
lot of complexity. Seems to me that either way we have to verify
that the settings are valid?
Does having the specialEnablementOptions nested in this way require
two calls? In other words, can a user not do a POST/PATCH/PUT for
all the fields including those in the specialEnablementOptions in
one call? We are planning to provide a way for the user to do a
PATCH of just the specialEnablementOptions options without changing
any of the first level for ease of use but is there something that
prevents them from creating or modifying all settings in one call?
Another option is to just get rid of the nested
specialEnablementOptions and put everything at the same level. I
dont have a problem with this but wasn't sure if this was just being
lazy. I dont mind doing this if the consensus is it is the best way
to do it....but I also have a second example that is similar to this
scenario but is a bit more complex where putting everything under the parent level is not really optimal (I will show in the next example)
So, my second example is as follows:
/anotherPolicy
"data": [ {
"name": "APolicyName1",
"description": "",
"count": 123,
"lastModified": "2022-05-17-20.37.27.000000",
[{
"ownerId": 1
"ownerCount": 1818181
"specialFlags": 'ABA'
},
{ . . . }]
},
{ . . . }],
The above 'count' is the total number associated to that policy and then there is a nested resource by owner where the count by owner can be seen..plus maybe other information specific to that owner. The SUM(ownerCount) would equal "count" above it. Does this scenario change any of the answers to the questions above?
I appreciate your help. I found a ton of information and reference on when to use or not use nested endpoints but all the examples seem to orient around subjects that seem like they could easily be separated into two resource...for instance whether to nest /employees under /departments or /comments under /posts. Also, they didn't deal with the complexities of having nested endpoints vs avoiding them. And last, if using nesting is unnecessary as a readability standpoint.
I can't create a queryPattern containing two Text fields, like so:
"parameters": [
{
"name": "text_a",
"type": "org.schema.type.Text"
},
{
"name": "text_b",
"type": "org.schema.type.Text"
}
],
"trigger": {
"queryPatterns": [
"add $org.schema.type.Text:text_b with $org.schema.type.Text:text_a",
"combine $org.schema.type.Text:text_b along with $org.schema.type.Text:text_a"
]
}
This will always result in a failure to match the intent (for example "add something with another").
However, I can use two Color types: If you change "Text" to "Color" in the above, and say "add red with blue" or "combine auburn along with green" then it matches and fires the intent.
I am creating deep-link intents only (i.e., commands, not a back-and-forth dialog), so I don't think DialogFlow will help me?
I suspect that the problem is that AoG is treating text parameters as "greedy", so a second parameter never matches because the first parameter has captured all the text. You don't see this with specific types, because it does more narrow matching for them.
You may actually try to use Dialogflow - it does work for deep linking Intents, although I don't know if it will behave the same way.
I have an entity called #spare_part and this entity has 4 values with the following example synonyms each:
both with synonyms filter, oil level indicator
not_defined with a synonym spare part
only_gear with synonyms valve, seal
whole_gear_box with a synonym complete set of gearbox
I want to be able to handle multiple entities given in the same input and address them later on, if needed. With this purpose I have coded the following in JSON editor:
{
"context": {
"sparepartrequest": "#spare_part.values"
},
"output": {
"generic": [
{
"values": [
{
"text": "You want an offer for the following parts: <?
$sparepartrequest.join(', ') ?>."
}
],
"response_type": "text",
"selection_policy": "sequential"
}
]
}
}
I have created a context variable called sparepartrequest as can be seen from the code lines above. For instance when the user says "I want an offer for a filter and a seal", the output of the bot is the following sentence:
You want an offer for the following parts: both, only_gear.
I don´t want the bot to prompt back the names of the values of the entity #spare_part, I rather want it to store the exact input of the user, for our case which would be filter and seal. So if the bot worked as I wanted it to, the output would look like the following:
You want an offer for the following parts: filter, valve.
Again, I believe that this can be handled with JSON Editor. Thank you !
Use two context variables. sparepartrequest as already done and sparepartrequest_literals as follows:
"sparepartrequest_literals":"<? entities['spare_part'].![literal].join(', ') ?>".
Then, in your text response call it by $sparepartrequest_literals to print the mentioned parts or use $sparepartrequest to refer to the detected values.
I have a pipeline with a ForEach loop that gets a list of cities to loop through and make a web service (HTTP source) call and writes to a database (sink).
It works great, however, the API does not return the city as part of the response so I wanted to pass the ForEach parameter (#{item().LocationName}) into the Copy task as part of the column mapping ie:
"columnMappings": {
"#{item().LocationName}": "location",
"blah": "blah",
"blah": "blah",
The 'problem' is that instead of mapping the value of #{item().LocationName} to be the written results, it uses the value of #{item().LocationName} as a column mapping name. ie. tries to find a column name "Vancouver" instead of passing the value "Vancouver" in to the location.
I would say the current behavior is not 'wrong', but looking for a way to pass a variable/parameter in as part of the copy task.
I've tried setting this at the source dataset level with no luck, and it just seems like the wrong location to be setting a variable anyways.
EDIT: I've also tried setting the #{item().LocationName} value in the Dataset in the connection in the JSONPath Expression section, it runs, but does not appear to set a value for location.
"typeProperties": {
"format": {
"type": "JsonFormat",
"filePattern": "setOfObjects",
"jsonPathDefinition": {
"location": "#{item().LocationName}"
I want to use the templating feature in Grafana with elastic search to create a set of 'dynamic' terms ("application")
To get the ist of terms from elasticsearch I'm useing:
{
"aggs" :
{
"applications" : {
"terms" : { "field" : "businessTransactions.application" }
}
}
}
When I use that query in the Templating Query variable settings as query Grafana tells me: "Template variables could not be initialized: Cannot read property 'then' of undefined"
I'm using grafana 3.1.0beta1
Maybe I'm completely off, but how would someone use a query to get different terms of a field as a template variable from elasticsearch?
Thanks!
First question: which version of Grafana are you using? Sorry just re-read and saw the answer, which is 3.1.0beta1.
The below works for me on 3.1.0 (not beta).
Second question: did you see this page: http://docs.grafana.org/datasources/elasticsearch/
Templating
The Elasticsearch datasource supports two types of queries
you can use to fill template variables with values.
Possible values for a field
{"find": "terms", "field": "#hostname"}
Fields filtered by type
{"find": "fields", "type": "string"}
Fields filtered by type, with filter {"find": "fields", "type": "string", "query": <lucene query>}
Multi format / All format