orchestration

[Tyler Couto]

Hi all,

I¹m having trouble with orchestration. I¹m trying to write a single
Œdeploy¹ sls to deploy new artifacts to our infrastructure. I expect it to
be run on the salt minions, but it seems like it¹s being run on the salt
master. Here¹s a gist of what I¹m doing:

https://gist.github.com/onlyanegg/2779479652b7e5d50b5c819f92441a94


I was also wondering if it¹s possible to specify a pillar file in yaml
format from the command line instead of raw json pillar data.

Thanks,
Tyler

[Thomas Phipps]

the issue is you are running test=true which will test just the orchestration level of the runner. [not the states within] and orchestration does run on the master. you want to add - test: true

to you orchestration stanza, then run it without the test=true on the cli

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thomas Phipps

Linux/Openstack/Logstash

(702) 518-0131

[tco...@certain.com]

Hi, Thomas. Thanks for your answer. I think the problem was that my minion running masterless which is how I usually have it for my test environment.

Now I'm running up against another error: 

Rendering SLS 'common:deploy.external_services' failed: Jinja variable 'salt.utils.context.NamespacedDictWrapper object' has no attribute 'deploy'

I'm passing this 'deploy' pillar on the command line, but I suppose it doesn't propagate to the the state sls files; is that true? Is there a way to pass pillars to the state sls files from the 'salt-run state.orchestrate' command?

Thanks again, 

Tyler

[Thomas Phipps]

you are correct in your assumption. your pillar is being passed to the orch, but not through to the states after words. salt.state has a - pillar argument that allows passing through. basicly take the rendered pillar data from orch and pass it through in - pillar

you should probley take a look at what other options salt.state has 

here is the documentation page for it https://docs.saltstack.com/en/latest/ref/states/all/salt.states.saltmod.html#salt.states.saltmod.state

[Tyler Couto]

Ok, I’m taking a look at that, but I’m pretty confused about how to use it. I got this example https://github.com/mitodl/salt-ops/blob/master/salt/orchestrate/operations/services/consul.sls on line 98, but when I try to do something similar, I get the following: 

     Warnings: 'deploy.external_services.branch',

              'deploy.external_services.revision',

              'deploy.internal_services.branch' and

              'deploy.internal_services.revision' are invalid keyword arguments

              for 'salt.state'. If you were trying to pass additional data to be

              used in a template context, please populate 'context' with 'key:

              value' pairs. Your approach will work until Salt Carbon is out.

              Please update your state files.

And

[ERROR   ] Data passed to highstate outputter is not a valid highstate return: {'plat01.pod1.local.or.certainaws.com': ["Rendering SLS 'common:deploy.internal_services' failed: Jinja variable 'salt.utils.context.NamespacedDictWrapper object' has no attribute 'deploy'", "Rendering SLS 'common:deploy.external_services' failed: Jinja variable 'salt.utils.context.NamespacedDictWrapper object' has no attribute 'deploy'”]}

My orchestrate runner now looks like this: 

 deploy_internal_and_external_services:

   salt.state:

     - tgt: plat[0-9]{2,3}.{{ pod }}.{{ pillar.deploy.environment }}.*

     - tgt_type: pcre

     - saltenv: common

     - batch: 50%

     - sls:

       - deploy.internal_services

       - deploy.external_services

     - pillar:

       deploy.internal_services.revision: {{ pillar.deploy.internal_services.revision }}

       deploy.external_services.revision: {{ pillar.deploy.external_services.revision }}

       deploy.internal_services.branch: {{ pillar.deploy.internal_services.branch }}

       deploy.external_services.branch: {{ pillar.deploy.external_services.branch }}

And I’ve tried accessing the variables in the state file as {{ pillar.deploy.internal_services.revision }} and as {{ deploy.internal_services.revision }}

deploy_new_{{ artifact }}:

   cmd.run:

     - name: curl --user '{{ pillar.bamboo.user }}:{{ pillar.bamboo.passwd }}' --insecure {{ pillar.bamboo.url }}/PRODUCTION-PLATFORM-{{ pillar.deploy.internal_services.revision }}/artifact/shared/dist/{{ artifact }}.zip --fail -o {{ artifact }}.zip

You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/8htKpFvdLn8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Thomas Phipps]

what is the command you are using to pass in pillar data. 

[Tyler Couto]

salt-run state.orchestrate deploy saltenv=common pillar='{"deploy":{"environment":"local","pods":["pod1"],"internal_services":{"revision":825,"branch":"minor"},"external_services":{"revision":825,"branch":"minor"}}}'

[tco...@certain.com]

Hey, Thomas. I found a work around for this. 

Now I'm copying my deploy pillar to a pillar file named deploy.sls, and I give that to all my minions in the top file. Now I don't have to worry about passing the pillar on the command line. 

Thanks again!

Tyler

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thomas Phipps

Linux/Openstack/Logstash

(702) 518-0131

--

You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/8htKpFvdLn8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to salt-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thomas Phipps

Linux/Openstack/Logstash

(702) 518-0131

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/8htKpFvdLn8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to salt-users+unsubscribe@googlegroups.com.

[Peeter U]

Hi
I got also this error:
SaltRenderError: Jinja variable 'salt.utils.context.NamespacedDictWrapper object' has no attribute 'elasticsearch'

and traced it to a line in my sls that was commented out:
# Cluster: {{ grains['elasticsearch']['cluster'] }}

so removing the line resolved the problem.

[Mrten]

jinja comments are {# #} so jinja still saw the {{ }} replacement as-is.

M.