Re: [ansible-project] Re: Variable concatenation in when statement
definitely cleaner IMO, thanks! On Wednesday, August 29, 2018 at 10:32:57 AM UTC-4, Kai Stian Olstad wrote: > > On 29.08.2018 15:56, yaakov.kuperman via Ansible Project wrote: > > Answering my own question: I got it to work properly by doing this: > > > > when: '"".join(["vmlinuz-", kernel_version]) not in > > default_kernel.stdout' > > > > > > Would be happy to hear of any other, cleaner ways of doing it. > > If it's cleaner or not I leave it to you to decide > > when: "'vmlinuz' ~ kernel_version not in default_kernel.stdout" > > -- > Kai Stian Olstad > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/dbb2aa69-7bbb-49eb-9b06-ae55e1b27911%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ansible-project] Re: Variable concatenation in when statement
Answering my own question: I got it to work properly by doing this:
when: '"".join(["vmlinuz-", kernel_version]) not in default_kernel.stdout'
Would be happy to hear of any other, cleaner ways of doing it.
On Wednesday, August 29, 2018 at 9:52:21 AM UTC-4, yaakov@sparkpost.com
wrote:
>
> Hi all, I'm running this task:
>
> - name: assert version
>
> fail:
>
> msg: "'vmlinuz-{{ kernel_version }}' not found in default
> kernel output: '{{ default_kernel.stdout }}'"
>
> when: '"vmlinuz-{{kernel_version}}" not in
> default_kernel.stdout'
>
>
>
>
> The key part being that I want to have the fail message concatenate the
> string literal 'vmlinuz-' with the 'kernel_version' variable. When I do
> this, I get this error:
>
>
> * [WARNING]: when statements should not include jinja2 templating
> delimiters such as {{ }} or {% %}. Found: "vmlinuz-{{kernel_version}}"*
>
> *not in default_kernel.stdout*
>
>
> What's the appropriate way to do this?
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/242ab11f-16f7-4677-9e5a-b11ac306fc0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ansible-project] Variable concatenation in when statement
Hi all, I'm running this task:
- name: assert version
fail:
msg: "'vmlinuz-{{ kernel_version }}' not found in default
kernel output: '{{ default_kernel.stdout }}'"
when: '"vmlinuz-{{kernel_version}}" not in default_kernel.stdout'
The key part being that I want to have the fail message concatenate the
string literal 'vmlinuz-' with the 'kernel_version' variable. When I do
this, I get this error:
* [WARNING]: when statements should not include jinja2 templating
delimiters such as {{ }} or {% %}. Found: "vmlinuz-{{kernel_version}}"*
*not in default_kernel.stdout*
What's the appropriate way to do this?
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/56ca60bf-0d88-46ec-960b-064e38d6f2b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] No longer able to apply commands to AWS instances after upgrade to 2.5
Part of the problem is that important new functionality and modules come out, but aren't backported, so if you want to be able to do everything you need to do, you either need to do extra work to backport it yourself (when possible), or deal with the upgrades. It'd be nice if non-breaking updates were brought to stable long-term releases by default. I don't think general flakiness is a good excuse for the instability - ansible could be the one that *doesn't* cause problems in that case. It'd be a sign of the tool's maturity. I don't mind submitting a proposal and advocating for it, where do I sign? On Friday, August 17, 2018 at 12:23:49 PM UTC-4, Stephen Granger wrote: > > It's almost fundamental that you treat all of your deployment and systems > tools in the same way, they are flaky and will introduce drastic changes > that will almost always cause system outages on upgrade (similar to public > cloud infrastructure, it fails a LOT). Every tool, (ansible role) playbook > and inventory, api reference, software package EVERYTHING needs to be > versioned. Blind updates are going to wipe you out and if other people > (business revenue too :) ) rely on the system it's even more critical to > lock everything down to a version. > > You will experience this time and time again with various tools, OS's, a > lot of Ansible users already have and this is why they are using Ansible in > the first place to enforce Ansible version. > > > https://www.jeffgeerling.com/blog/2016/require-minimum-ansible-version-your-playbook > This is along the line of what you can implement to ensure Ansible is at a > specific version. You can use this outage as an excuse to implement this > check across all of your playbooks. This is a hard lesson to learn and a > lot of other infrastructure tools take the same approach enforcing a > version, especially those still considered beta i.e. terraform. > > Good luck! > > On Fri, 17 Aug 2018 at 08:42, Ilsa Loving > wrote: > >> And yes, I know that. Now. >> >> My point is that that's not good enough. It's not acceptable to make >> wide-ranging fundamental changes to the system, and then say "It's in the >> docs. You need to read the docs." >> >> If Ansible is going to make changes so significant that it is guaranteed >> to break existing playbooks, then it *cannot* follow the traditional >> upgrade path where you simply update the version number of the >> rpm/deb/whatever, and toss it into the pile for upgrading. Each release >> needs it's own versioning as part of the name (ie: have ansible2.5, >> ansible2.6, etc.) so that people can be assured that when they do a yum >> update, then their stuff will still work afterwards. Apache did this when >> they went from 2.2 to 2.4. People had plenty of issues during the >> transition, but surprise upgrades that broke their infrastructure wasn't >> one of them. >> >> I've been doing a lot of reading, and have come across a very large >> number of people who share the same frustrations. Ansible is supposed to >> make sysadmin lives easier. Instead, people have had to resort to >> version-locking Ansible (as we have done), or implementing entire >> continuous delivery paths just for Ansible. Or they've given up on it >> entirely and reverted back to bash scripts, cause bash scripts don't break >> every 3-6 months. >> >> IMO that is absolutely absurd. Infrastructure is not software. It's >> infrastructure. It has to be solid, because everything else depends on >> it. If Ansible is to be a key element in managing infrastructure, it too >> has to be solid. Why should I use something that adds to my workload >> instead of reduces it? >> >> Ilsa >> >> On Friday, 17 August 2018 11:14:32 UTC-4, Jonathan Lozada De La Matta >> wrote: >>> >>> I think you misunderstood our comment and taking it a little far. They >>> are going to be changes to software, all of them makes changes. But, like >>> mentioned before we have docs and notices for this exact reason. >>> >>> On Fri, Aug 17, 2018 at 10:51 AM Ilsa Loving wrote: >>> The issue was that the person that originally wrote the scripts quit, and we were parachuted in as emergency resources to try to get everything going. And Ansible just happened to put out an update to 2.5 in the same time frame, so when we did 'yum install ansible', we had no way of knowing that the version we were installing was different from the one he was using. But you're right, it was completely our fault. We should have known (apparently by osmosis) that Ansible changes it's APIs capriciously with every single version, that backward compatibility is for losers, and that all Ansible packages are treated as minor in-place updates so if you haven't locked down the version ahead of time, a routine yum update will break your entire setup. I mean, heaven forbid that someone might expect a critical oper
[ansible-project] Re: Restart server playbook fails on one set of targets, but not on another.
one more thing - I'm doing something similar and I've found it necessary to
use wait_for: to determine that port 22 actually went down before I wait
for it to come up again. I've also used wait_for_conection: to wait for it
to come all the way back before I proceed.
On Thursday, August 16, 2018 at 3:14:56 PM UTC-4, Patrick Hunt wrote:
>
> I have the following playbook snippet
>
> ---
>
>
> - hosts: collector
> become: true
> become_method: su
> become_user: root
>
>
> tasks:
>
>
> - name: restart server, if kernel updated
> command: reboot
> async: 1
> poll: 0
> ignore_errors: true
> notify:
> - wait for server to restart
>
>
> handlers:
> - name: wait for server to restart
> wait_for:
> host: "{{ ansible_default_ipv4.address }}"
> port: 22
> state: started
> delay: 25
> timeout: 300
> become: false
> delegate_to: localhost
>
>
> ...
>
>
>
> This is really part of a much larger maintenance playbook. My problem is
> that in our Test environment (RHEL 6 & 7) this succeeds, in our Dev
> environment (CentOS 7) this fails. When the play fails ansible will
> connect and gather facts, when the play to restart is executed it will
> state that the server is unreachable, however the task has been executed
> and the server *is* restarted if you check the actual VM. It seems that
> the execution of the tasks completes before ansible is able to recognize
> this fact, so it never gets to the point where it waits for the server to
> restart and fails as unreachable instead.
>
> The ansible.cfg files are identical. The inventory (hosts) files do not
> have any additional variables/connection information other than hostnames
> and groups defined.
>
> In the dev environment the playbook is executed as root, and in the Test
> environment the playbook is executed as a user.
>
> Both environments are running ansible 2.6.2
>
> The dev environment functioned properly for a year or more until about 2-3
> months ago when this restart task began to fail.
>
> Any ideas?
>
>
> Thanks,
> Patrick
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/e3dd9b44-c3d7-4676-9e5e-7f38be8ce188%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[ansible-project] Re: Restart server playbook fails on one set of targets, but not on another.
Check out
https://stackoverflow.com/questions/29955605/how-to-reboot-centos-7-with-ansible
On Thursday, August 16, 2018 at 3:14:56 PM UTC-4, Patrick Hunt wrote:
>
> I have the following playbook snippet
>
> ---
>
>
> - hosts: collector
> become: true
> become_method: su
> become_user: root
>
>
> tasks:
>
>
> - name: restart server, if kernel updated
> command: reboot
> async: 1
> poll: 0
> ignore_errors: true
> notify:
> - wait for server to restart
>
>
> handlers:
> - name: wait for server to restart
> wait_for:
> host: "{{ ansible_default_ipv4.address }}"
> port: 22
> state: started
> delay: 25
> timeout: 300
> become: false
> delegate_to: localhost
>
>
> ...
>
>
>
> This is really part of a much larger maintenance playbook. My problem is
> that in our Test environment (RHEL 6 & 7) this succeeds, in our Dev
> environment (CentOS 7) this fails. When the play fails ansible will
> connect and gather facts, when the play to restart is executed it will
> state that the server is unreachable, however the task has been executed
> and the server *is* restarted if you check the actual VM. It seems that
> the execution of the tasks completes before ansible is able to recognize
> this fact, so it never gets to the point where it waits for the server to
> restart and fails as unreachable instead.
>
> The ansible.cfg files are identical. The inventory (hosts) files do not
> have any additional variables/connection information other than hostnames
> and groups defined.
>
> In the dev environment the playbook is executed as root, and in the Test
> environment the playbook is executed as a user.
>
> Both environments are running ansible 2.6.2
>
> The dev environment functioned properly for a year or more until about 2-3
> months ago when this restart task began to fail.
>
> Any ideas?
>
>
> Thanks,
> Patrick
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/402dea11-43c6-4a93-8c16-a99666a53b28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] Is there a way to check if a service is already enabled on a linux machine?
done, for both: https://github.com/ansible/ansible/issues/43641 https://github.com/ansible/ansible/issues/43642 On Friday, August 3, 2018 at 9:43:39 AM UTC-4, Adam Miller wrote: > > On Fri, Aug 3, 2018 at 8:29 AM yaakov.kuperman via Ansible Project > > wrote: > > > > I was actually thinking of trying to change that, but I'm short on time. > Should I log a ticket or is that out of scope for the module? > > > > I was also thinking about making it possible for service_facts to > operate only on a single service, in order to save time on data collection. > Same question - should I log something for that or is it out of scope? > > Please file an issue ticket, that's something the module should > probably be providing. I actually thought it did (which I'm apparently > mistaken on). > > -AdamM > > > > > On Friday, August 3, 2018 at 9:24:42 AM UTC-4, Pavel Cahyna wrote: > >> > >> On Fri, Aug 03, 2018 at 08:14:15AM -0500, Adam Miller wrote: > >> > On Fri, Aug 3, 2018 at 7:52 AM yaakov.kuperman via Ansible Project > >> > wrote: > >> > > > >> > > Awesome! Thanks! > >> > > >> > As an option, you can also use the service_facts module to inspect > >> > service state: > https://docs.ansible.com/ansible/latest/modules/service_facts_module.html#service-facts-module > > >> > >> You can not, because the facts do not tell whether a service is enabled > >> or disabled. > >> > >> P. > >> > >> > > >> > -AdamM > >> > > >> > > > >> > > YK > >> > > On Thursday, August 2, 2018 at 6:04:12 PM UTC-4, Brian Coca wrote: > >> > >> > >> > >> You can use the appropriate service module: > >> > >> > >> > >> - service: name=myservice enabled=yes > >> > >> check_mode: true > >> > >> register: isit > >> > >> > >> > >> - fail: msg=its not enabled > >> > >> when: isit is changed > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> -- > >> > >> Brian Coca > >> > > > >> > > -- > >> > > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > >> > > To unsubscribe from this group and stop receiving emails from it, > send an email to ansible-proje...@googlegroups.com. > >> > > To post to this group, send email to ansible...@googlegroups.com. > >> > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/b54af985-206c-4fe3-a5ad-a0286e2f27ff%40googlegroups.com. > > > >> > > For more options, visit https://groups.google.com/d/optout. > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to ansible-proje...@googlegroups.com. > >> > To post to this group, send email to ansible...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAH-D1xd9HU8_jnGCWEH%3DkhtJqfQA8MtC_auJX9cao70FC3eG5Q%40mail.gmail.com. > > > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to ansible-proje...@googlegroups.com . > > To post to this group, send email to ansible...@googlegroups.com > . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/9a9ff7f5-4714-437d-bff6-61f8913dc2ad%40googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f5d8118e-060f-421b-a8f9-f5e5ff89dfc4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] Is there a way to check if a service is already enabled on a linux machine?
I was actually thinking of trying to change that, but I'm short on time. Should I log a ticket or is that out of scope for the module? I was also thinking about making it possible for service_facts to operate only on a single service, in order to save time on data collection. Same question - should I log something for that or is it out of scope? On Friday, August 3, 2018 at 9:24:42 AM UTC-4, Pavel Cahyna wrote: > > On Fri, Aug 03, 2018 at 08:14:15AM -0500, Adam Miller wrote: > > On Fri, Aug 3, 2018 at 7:52 AM yaakov.kuperman via Ansible Project > > > wrote: > > > > > > Awesome! Thanks! > > > > As an option, you can also use the service_facts module to inspect > > service state: > https://docs.ansible.com/ansible/latest/modules/service_facts_module.html#service-facts-module > > > You can not, because the facts do not tell whether a service is enabled > or disabled. > > P. > > > > > -AdamM > > > > > > > > YK > > > On Thursday, August 2, 2018 at 6:04:12 PM UTC-4, Brian Coca wrote: > > >> > > >> You can use the appropriate service module: > > >> > > >> - service: name=myservice enabled=yes > > >> check_mode: true > > >> register: isit > > >> > > >> - fail: msg=its not enabled > > >> when: isit is changed > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> -- > > >> Brian Coca > > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to ansible-proje...@googlegroups.com . > > > To post to this group, send email to ansible...@googlegroups.com > . > > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/b54af985-206c-4fe3-a5ad-a0286e2f27ff%40googlegroups.com. > > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to ansible-proje...@googlegroups.com . > > To post to this group, send email to ansible...@googlegroups.com > . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAH-D1xd9HU8_jnGCWEH%3DkhtJqfQA8MtC_auJX9cao70FC3eG5Q%40mail.gmail.com. > > > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/9a9ff7f5-4714-437d-bff6-61f8913dc2ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ansible-project] Is there a way to check if a service is already enabled on a linux machine?
Awesome! Thanks! YK On Thursday, August 2, 2018 at 6:04:12 PM UTC-4, Brian Coca wrote: > > You can use the appropriate service module: > > - service: name=myservice enabled=yes > check_mode: true > register: isit > > - fail: msg=its not enabled > when: isit is changed > > > > > > -- > -- > Brian Coca > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b54af985-206c-4fe3-a5ad-a0286e2f27ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ansible-project] Is there a way to check if a service is already enabled on a linux machine?
I don't see a way to do it with service_facts, do I have to use shell magic? -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b479d58d-d0c4-4c93-b6e2-21fc2bb6c760%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
