Is there a way to concat a prefix for every value in an array? I want to avoid duplication in my configuration.
in service.yaml
cities:
- amsterdam
- brussels
- chicago
wanted output in packages/city-package.yaml
city_map:
- city_amsterdam
- city_brussels
- city_chicago
city_map: %cities% << concat 'city_'$value <----- something like this
Related
I have a list that is defined in my defaults
configuration file base_list:
list:
- 1
- 2
I know I can override the list values in the config file:
defaults:
- base_list
list:
- 3
- 4
which results
list:
- 3
- 4
However, I look for a way to extend the list, and the desired output is:
list:
- 1
- 2
- 3
- 4
Any idea how to do this?
This is not supported directly.
However, you can achieve the desired behavior using the built-in OmegaConf resolvers oc.dict.*.
Those resolvers allow you to access the keys or values of a config node as a list:
cfg = OmegaConf.create(
{
"workers": {
"node3": "10.0.0.2",
"node7": "10.0.0.9",
},
"nodes": "${oc.dict.keys: workers}",
"ips": "${oc.dict.values: workers}",
}
)
# Keys are copied from the DictConfig:
show(cfg.nodes)
# -> type: ListConfig, value: ['node3', 'node7']
# Values are dynamically fetched through interpolations:
show(cfg.ips)
# -> type: ListConfig, value: ['${workers.node3}', '${workers.node7}']
assert cfg.ips == ["10.0.0.2", "10.0.0.9"]
With this, you can compose a dictionary and have a node that access the values or keys as if they are a list.
I've found bits and pieces of documentation for traffic flow data, but I haven't stumbled on a comprehensive document that includes all of the elements and attributes. Does such a document exist? If not can you help clarify the definition of some of the attributes and elements below?
<RW LI="114+01594" DE="12th Ave" PBT="2019-06-13T16:35:58Z" mid="61fc647b-9e52-41d0-9e18-435ec64b2f8f">
<FIS>
<FI><TMC PC="11761" DE="SE Milwaukie Ave/SE Gideon St" QD="-" LE="0.02134"/><CF CN="0.83" FF="13.67" JF="2.00696" SP="8.51" SU="8.51" TY="TR"/></FI>
<FI><TMC PC="11762" DE="SE Morrison St" QD="-" LE="0.98349"/>
<CF CN="0.83" FF="21.62" JF="3.41486" SP="10.9" SU="10.9" TY="TR">
<SSS><SS FF="22.56" JF="2.28167" LE="0.68918" SP="16.38" SU="16.38"/><SS FF="19.68" JF="6.46892" LE="0.2943" SP="8.41" SU="8.41"/></SSS>
</CF>
</FI>
<FI><TMC PC="15730" DE="SE Sandy Blvd" QD="-" LE="0.38267"/><CF CN="0.72" FF="21.81" JF="3.64183" SP="10.41" SU="10.41" TY="TR"/></FI>
<FI><TMC PC="11763" DE="I-84/US-30/Irving St/NE Lloyd Blvd" QD="-" LE="0.4496"/>
<CF CN="0.79" FF="23.8" JF="3.21584" SP="12.75" SU="12.75" TY="TR">
<SSS><SS FF="24.38" JF="3.14159" LE="0.16714" SP="12.11" SU="12.11"/><SS FF="23.44" JF="2.41069" LE="0.28245" SP="16.66" SU="16.66"/></SSS>
</CF>
</FI>
</FIS>
</RW>
RW - Roadway
RW#LI - ?
RW#DE - Looks like the roadway name, but not sure what "DE" translates too.
RW#PBT - The timestamp the resource was requested/computed?
RW#mid - A unique id for the roadway?
FIS - Flow items
FI - Flow item
TMC - Some sort of region?
TMC#PC - ?
TMC#DE - Same as RW#DE, but for a segment of the RW?
TMC#QD - Queue direction +/-
TMC#LE - ?
CF - Current flow
CF#CN - Confidence attribute per this doc
CF#FF - ?
CF#JF - Jam factor
CF#SP - Documented here
CF#SU - Documented here
CF#TY - ?
SSS - Street segments?
SS - Street segment?
SS#FF - ?
SS#JF - Jam factor
SS#LE - ?
SS#SP - Same as Documented here
SS#SU - Same as Documented here
please see meta resources document page.
https://developer.here.com/documentation/traffic/topics/additional-parameters.html
you can request the definition of acronyms based on traffic or incidents api version.
Fro example below request will return a flow xsd.
https://traffic.api.here.com/traffic/6.0/xsd/flow.xsd
?app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
Happy coding!
I'm trying to modify the <config-profile> section of a ossc.conf file, including a grains content.
something like:
ossec-profiles:
- profile1
- profile2
and I want to modify the section <config-profile> from
<config-profile>centos, centos7</config-profile>
to
<config-profile>centos, centos7, profile1, profile2</config-profile>
in the ossec.conf file
Any idea?
This can be done by using file.replace module which makes you able to change a text in a file based on a pattern. So in your case you can do the following:
You need to select the pattern as regex group so you can use it later as shown below
configure_ossec:
file.replace:
- name: /path/to/ossec.conf
- pattern: '((<config-profile>.*?)[^<]*)'
- repl: {{ '\\1, ' + pillar['ossec-profiles'] | join(', ') }}
Or you might use this pattern to match only whatever inside config-profile tags then you will be able to call it again in the repl parameter:
(?<=<config-profile>)(.*)(?=<\/config-profile>)
Note: As pillar['ossec-profiles'] should return a list of profiles
then you have to use the join filter in order to separate the values
with comma as a delimiter
And finally the output expected to be something like this:
Changes:
----------
diff:
---
+++
## -1 +1 ##
-<config-profile>centos, centos7</config-profile>
+<config-profile>centos, centos7, profile1, profile2</config-profile>
Inherit properties from all the parents.
Consider I have a graph with below format. I want the properties of a node (which will be in account node, if it has a relation) to be inherited by its child node. Assume Parent and child node relationship is maintained by [r:CHILD] and account information by [r2:ACCOUNT]. If node has more than one parent, it needs to inherit from all its parent with the first account :
(a0:ACCOUNT)<-[:HAS_ACCOUNT]-Morpheus
\
(a1:ACCOUNT)<-[:HAS_ACCOUNT]-Neo
\
alpha
\
gamma beta - [:HAS_ACCOUNT]->(a2:ACCOUNT)
\ /
A
/ \
(a3:ACCOUNT)<-[:HAS_ACCOUNT]-B C
/ \ / \
D E F G
I want to extract the data from the above graph something like this:
Problem: Given a node, get all its children and also its account (if it has account , e.g: see node B) or its inherited account information. AccountID is part of account node
Consider input is node A
OUTPUT:
|Node | CurrentNode| Account |Inherited_Account|
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | A | - | a1.accountID ,|
| | | | a2.accountID |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | B | a3.accountID | - |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | D | | a3.accountID |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | E | | a3.accountID |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | C | | a1.accountID ,|
| | | | a2.accountID |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | F | | a1.accountID ,|
| | | | a2.accountID |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
| A | G | | a1.accountID ,|
| | | | a2.accountID |
- - - - - -- - - - - -- - - - - -- - - - - -- - - - -
This was my cypher to retrive that I came up with, gets me all the accounts of all the parents. It doesnt work sometimes
MATCH (node:Person{personID:"A"})
MATCH (account:ACCOUNT)
MATCH p =(parent:Person)-[:CHILD*1..]->(node)
where (parent)-[:HAS_ACCOUNT]->(account)
UNWIND RELATIONSHIPS(p) AS rel
WITH p, account, COUNT(DISTINCT rel) AS nRoutes
RETURN account,p, nRoutes
ORDER BY nRoutes
This is a tricky one.
A pure Cypher solution exists, but it's a complicated query and requires some potentially heavy filtering to weed out paths to account-holding nodes that are beyond closer account-holding nodes along the same path.
However, I've found a better alternate using Cypher and APOC's path expander, plus some pre-processing of adding a label to nodes that are account holders.
APOC's path expander has a means of expanding while respecting a label filter, and there is a means to define a label which should prune any further traversal, but be included as a solution. We'll use this to limit our expansion when getting account-holding ancestors for nodes.
Here's a creation query to recreate the graph in your example (though I'm labeling non-ACCOUNT nodes as :Node):
// create inherited account graph
create (morpheus:Node{name:'Morpheus'})
create (neo:Node{name:'Neo'})
create (alpha:Node{name:'alpha'})
create (gamma:Node{name:'gamma'})
create (beta:Node{name:'beta'})
create (A:Node{name:'A'})
create (B:Node{name:'B'})
create (C:Node{name:'C'})
create (D:Node{name:'D'})
create (E:Node{name:'E'})
create (F:Node{name:'F'})
create (G:Node{name:'G'})
create (morpheus)-[:CHILD]->(neo)
create (neo)-[:CHILD]->(alpha)
create (alpha)-[:CHILD]->(gamma)
create (gamma)-[:CHILD]->(A)
create (beta)-[:CHILD]->(A)
create (A)-[:CHILD]->(B)
create (A)-[:CHILD]->(C)
create (B)-[:CHILD]->(D)
create (B)-[:CHILD]->(E)
create (C)-[:CHILD]->(F)
create (C)-[:CHILD]->(G)
create (morpheus)-[:HAS_ACCOUNT]->(a0:ACCOUNT{name:'a0'})
create (neo)-[:HAS_ACCOUNT]->(a1:ACCOUNT{name:'a1'})
create (beta)-[:HAS_ACCOUNT]->(a2:ACCOUNT{name:'a2'})
create (B)-[:HAS_ACCOUNT]->(a3:ACCOUNT{name:'a3'})
Next, we label account-holding nodes.
MATCH (acc:ACCOUNT)
WITH acc
MATCH (acc)<-[:HAS_ACCOUNT]-(holder)
SET holder:ACCOUNT_HOLDER
Once that's in place, we can use the following query to get your desired output:
// parameterize this in your own query
with 'A' as nodeName
match (node:Node{name:nodeName})-[r:CHILD*0..]->(currentNode)
with node, currentNode, size(r) as distance
optional match (currentNode)-[:HAS_ACCOUNT]->(acc)
with node, currentNode, distance, collect(acc) as accounts
// we now have all child nodes of the given node and their accounts, if they exist.
// this expands up from each currentNode,
// stopping each expansion at the closest ACCOUNT_HOLDER node
call apoc.path.expand(currentNode, '<CHILD', '/ACCOUNT_HOLDER', -1, -1)
yield path
with node, currentNode, distance, accounts, last(nodes(path)) as holder
// get the account for each holder,
// but only if the current doesn't have its own accounts
optional match (holder)-[:HAS_ACCOUNT]->(acc)
where size(accounts) = 0
with node, currentNode, accounts, collect(acc) as inherited, distance
order by distance asc
return node, currentNode, accounts, inherited
However, note that even with this approach, the query will not build up and reuse solutions (for example, once we've found the account-holding ancestors for node A, that solution is not referenced or reused when we have to get the account-holding ancestors for nodes, C, F, or G). You may want to consider a custom procedure to perform this complicated matching operation in code rather than Cypher for maximum efficiency.
Consider my SLS file,
state1:
cmd.run:
- order: 1
- name: |
USER_NAME='username'
USERPWD='password'
DB_NAME='test'
USER_TOBE_CREATED='new_user'
PASSWORD='newpass'
mysql_user.present:
- order: 2
- host: localhost
- username: USER_TOBE_CREATED
- password: PASSWORD
- connection_user: USER_NAME
- connection_pass: USERPWD
- connection_charset: utf8
- saltenv:
- LC_ALL: "en_US.utf8"
mysql_grants.present:
- order: 3
- grant: all privileges
- database: DB_NAME.*
- user: USER_TOBE_CREATED
In the states mysql_user.present and mysql_grants.present I am using the variables USER_TOBE_CREATED,USER_NAME,USERPWD etc whose values are assigned in state cmd.run. How will I make these two following states to use the actual values of those variables?. Here it's taking variable name itself as the value.
You may want to declare the variables in the state file itself, i.e.:
{% set user_name = "name" %}
and:
state1:
cmd.run:
- order: 1
- name: |
USER_NAME='{{ user_name }}'
You can re-use the variable as many times as you want inside the state file.
Let me know if this helped.