I have a large complex Ansible provisioning setup, > 100 roles, > 30 inventory groups, etc... This is organised in the recommended way: top level playbooks, with a /roles folder, a /group_vars folder, etc...
Sometimes this fails part-way through, and I want to restart it from where it failed, using the --start-at-task command line switch.
However, I have several tasks that always need to run. These dynamically add hosts to the inventory, set variables that are needed later, etc...
Is there a way to force a task to always be run - or a role to always be applied, even when using --start-at-task?
I know about the always tag, but I think this only makes it run when filtering tasks by using --tag, not --start-at-task - unless someone knows differently?
Alternatively, is there some other way to structure things that would avoid this problem with --start-at-task?
Unfortunately, it is not possible.
Currently you either have to use tags or bite the bullet, rely on idempotency and let all tasks re-run.
There were PRs and discussions to add such a functionality, but they never made it to the official Ansible release.
There is also an open issue asking for this feature, with a suggestiion, that always_run should enable running the task when using in conjunction with --start-at-task, but the discussion also withered away more than a year ago.
The conclusion of the issue mentioned by techraf is that the good way to do it is by implementing a custom strategy: https://github.com/ansible/ansible/issues/12565#issuecomment-834517997
One has been implemented there (but I haven't been able to make it work with ansible-test)
Anyway it's a good start to implement a working solution and the only way possible as Ansible devs will not patch --start-at-task
Related
I'm using the Ansible debugger, using commands:
p(print variables)
r(edo)
c(ontinue)
q(uit)
Once the playbook gets to the step it fails on, I often wish I could go back and re-do previous tasks, before the task that failed. Is this possible?
In respect to your question
... go back and re-do previous tasks ...
this seems to be not possible according the documentation playbooks_debugger since
You have access to all of the features of the debugger in the context of the task
only.
I was watching this video about Jenkins:
https://www.youtube.com/watch?v=6BIry0cepz4
He mentions that shell scripts have many advantages over using Groovy, to do custom work, in a Jenkins build process.
Apparently the sandbox that Jenkins uses to run the Groovy has some sharp limits?
Where can I find more information about this? When do I give up on Groovy and switch to a shell script?
As the comment from Szymon says this a broad question to answer. And there is no one stop shop that list all the pros and cons of each. It will rather build up based on the use case and the experience that you encounter.
Apparently the sandbox that Jenkins uses to run the Groovy has some
sharp limits?
This is due to the fact that Jenkins enforces certain security measure,so as to not call any method that can perform malicious or unhealthy stuff inside your infrastructure. If you really need to use certain listed libraries, you/jenkins admin need to white-list the class by approving it. Check out the link below:
https://jenkins.io/doc/book/managing/script-approval/
Now, shell script does comes very handy but its not always hunky-dory, on everything.
When do I give up on Groovy and switch to a shell script?
To me, it depends on what i am trying to achieve. Select it based on the which one makes it more easier.
I have tried googling, but had no luck. Maybe I just don't know the terms to search for...
Recently we made some changes to the environment, and now tests that used to run without issue kill the service. We are working to find out why that is happening... but in the meantime, is there a way I could pass a CLI command or something to slow down the tests on demand? (or vice versa, run at full speed on demand) Or maybe build something into a rake task?
I know I could easily add an after hook to sleep between scenarios, but I want to be able to run the tests full blast as well while we are trying to sort out the issue. Adding an after hook would require editing several files every time we wanted to turn the throttling on or off.
UPDATE:
decided to try adding this to env.rb and I think it might work, although it feels crude. If you have other suggestions I would love to hear them. This is just a temporary fix though, once we figure out what is up with the environment we do need to go back and add a more elegant way of slowing tests down when needed, perhaps through the http client.
After do
if ENV['SLOW'].eql? 'yes'
sleep(3)
#logger.info '******* Waiting 3 seconds before running next scenario *******'
end
end
I want to know if a extension (for example: joomfish) is really used or not used at all before i disable it / uninstall it.
Is there a way to check ?
First, in Joomla plugin has a specific meaning, so what you want to know is whether a component, module or plugin is used.
This is a common problem when you inherit sites. A lot of times users install tons of extensions and never use or uninstall them.
The simplest first step with modules and plugins is to see if they are published or not. Also you can look at modules and see if they are assigned to any positions or menu items.
In terms of extensions, if they are a kind of extension that would be used to create content and you look at the manager you can see if any content was ever created. If not it is probably safe to uninstall. IF there is content then you will want to figure out whether you need o preserve it.
The problem with Mike's answer is .. how do you know if you have tried every possible combination of things or possible events with enough certainty to say for sure that something is not running ever. For example you may have a component that you never use as a menu item but then some module is running a query against its data.
Well you cannot know that. To be absolutely shure you could write a system plugin which gets triggered on plugin calls and logs the triggering plugin names.
I'm creating a module that requires a few things to be done (once only) when the module is installed. There may be a number of things that need to be done, but the most basic thing that I need to do is make an API call to a server to let the external server know that the module was installed, and to get a few updated configuration items.
I read this this question on stackoverflow however in my situation I truly am interested in executing code that has nothing to do with the database, fixtures, updating tables, etc. Also, just to be clear this module has no affect (effect?) on the front end. FYI, I've also read this spectacular article by Alan Storm, but this really only drives home the point in my mind that the install/upgrade scripts are not for executing random PHP.
In my mind, I have several possible ways to accomplish this:
I do what I fear is not a best practice and add some PHP to my setup/install script to execute this php
I create some sort of cronjob that will execute the task I need once only (not sure how this would work, but it seems like it might be a "creative" solution - of course if cron is not setup properly then this will fail, which is not good
I create a core_config_data flag ('mynamespace/mymodule/initialized') that I set once my script has run, and I check on every area of the adminhtml that my module touches (CMS/Pages and my own custom adminhtml controller). This seems like a good solution except for all of the extra overhead every time CMS/Pages is hit or my controller is hit, checking this core_config_data setting. The GOOD thing about this solution would be that if something were to fail with my API call, I can set this flag to false and it will run again, display the appropriate message, and continue to run until it succeeds (or have additional logic that will stop the initialization code after XX number of attempts)
Are any of these options the "best" way, and is there any sort of precedent for this somewhere, such as a respected extension or from Magento themselves?
Thanks in advance for your time!
You raise an interesting question.
At the moment, I am not aware of a means to go about executing any arbitrary PHP on module installation, the obvious method (rightly/wrongly) would be to use the installer setup/upgrade script as per 1 of your Q.
2 and 3 seem like a more resource intensive approach, ie. needlessly checking on every page load (cache or not).
There is also the approach of using ./pear to install your module (assuming you packaged it using Magento). I had a very quick look through ./downloader/pearlib/php/pearmage.php but didn't see any lines which execute (vs copying files). I would have imagined this is the best place to execute something on install (other than 1 mentioned above).
But, I've never looked into this, so I'm fairly interested in other possible answers.