Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
raphaelsalomao3
@raphaelsalomao3
Taking a look at actioning.py, there's a condition that checks if trigger is less than the threshold, maybe I could add an extra condition that compares trigger to a predefined number and set the run to false, do you think that would work? I'm not sure if I have to reset the queue after
Here's the code I'm talking about btw:
# see if we are beyond or equal to trigger threshold
        for status in call_on:
            if trigger <= target['runbooks'][item['runbook']]['status'][status]:
                logger.debug("Action {0} has trigger of {1} and status has {2}".format(
                    action, trigger,
                    target['runbooks'][item['runbook']]['status'][status]))
                run_me = True # turn True
Benjamin Cane
@madflojo
I was contemplating a run one type of book in the run book and if it’s there than skip the trigger values
One problem though is when to reset? I mean a runbook that only runs once ever is kinda rare
More often than not it’s run once per occurrence
Bah autocorrect fail
run once boolean in the runbook*
raphaelsalomao3
@raphaelsalomao3
Once per occurrence should be enough. I understand that my case is a bit specific, I'm running automatron to open incident tickets on service-now
Benjamin Cane
@madflojo
It’s been a while since I thought about it but the main thing to work out was when to reset the run once. Ideally you want to account for flapping failure and only run once within a timeframe
Ah that’s a cool use case, would totally fork that plugin if you wanted to share it in the plugins org
I’m on my phone right now but I can check the code you pinged later
raphaelsalomao3
@raphaelsalomao3
The problem is that if my healing script fails, i'll have multiple tickets opened for the same problem
Cool
I'm willing to share the code np hehe
Benjamin Cane
@madflojo
Is maybe an ignore failures flag better?
So even if it fails count it as an execution
Benjamin Cane
@madflojo
Have you been using Automatron long or just started?
raphaelsalomao3
@raphaelsalomao3
Just started :D
Benjamin Cane
@madflojo
Ok cool
Let me know how it goes
raphaelsalomao3
@raphaelsalomao3
Is maybe an ignore failures flag better?
Hm, not sure. Say I have a check with 2 actions: ticket creation and healing script.
If healing fails, I still want it to be executed but not the ticket creation
A run once flag would be better for this particular case
Benjamin Cane
@madflojo
Always good to hear from more users
raphaelsalomao3
@raphaelsalomao3
Nice work there, bro :)
Benjamin Cane
@madflojo
Thanks
raphaelsalomao3
@raphaelsalomao3

Taking a look at actioning.py, there's a condition that checks if trigger is less than the threshold, maybe I could add an extra condition that compares trigger to a predefined number and set the run to false, do you think that would work? I'm not sure if I have to reset the queue after

Just let me know if you think this is a good start when you can please, I'll try to start working on this tomorrow!

Benjamin Cane
@madflojo
Yeah, though I’d say a run once flag and a rest time might be better but feel free to take a crack at it and open a PR or WIP PR when ready
Reset time*
raphaelsalomao3
@raphaelsalomao3
Hey, just to let you know the website is down https://automatron.io
Benjamin Cane
@madflojo
Fixed, must have been something up with the domain expiration
HTTP was working but not HTTPS, was a Cloudflare config
raphaelsalomao3
@raphaelsalomao3
Do you know any easy way to refresh configs? Seems like I have to recreate both containers whenever I change something
docker-compose restart is not enough for some reason
Benjamin Cane
@madflojo
You can do a volume mount to the config directory
And then a restart will work
When you run build it puts the config into the container
But if you use a volume it would reflect what you have on the host
raphaelsalomao3
@raphaelsalomao3
Hi, Ben. Today I started to work on what we discussed here and I think I have it working. I have my fork updated. Since you're much more experienced than I am, you might want to take a look first and I'll PR if you want
I had to update a few installation files as well to have it running (e.g. fabric newest version breaks your import)
Basically what I'm doing is checking if theres a flag called "run_once" in the runbook actions. If it's set to True, automatron will run that action only once and then will ignore that action
Benjamin Cane
@madflojo
Cool I’ll take a look
Benjamin Cane
@madflojo
@raphaelsalomao3 code changes look good to me. Looks like you changed the Timezone and had a couple of configs specific to your implementation that you might want to remove before opening a PR but the code itself looks good.
raphaelsalomao3
@raphaelsalomao3
Nice! Will pr without specific config changes, although you might want to take a look at the fabric version one, because that prevents new installations from working
Benjamin Cane
@madflojo
Oh I thought you already fixed it in your fork
Benjamin Watson
@watsonb
running into "ImportError: No module named api" trying to start Automatron. First time installer/user here, any ideas? Shall I try a different branch/tag?
Benjamin Watson
@watsonb
nvm, saw the previous comment about the fork and am ensuring fabric<2 is installed via pip
raphaelsalomao3
@raphaelsalomao3
Hey, benjamin, I'm happy to see you merged the PR! Please let me know if I can help with anything you wish to see implemented in the future
I'm currently working in a better way to debug fabric.api calls, some of my plugins are failing without an apparent reason (which also breaks the run_once flag, cause it doesn't count as an execution)
Benjamin Cane
@madflojo
Awesome, it’s true that the errors are pretty generic