Hi all,
Just thought I would put this out there… is there a place where we can share extension scripts etc?
I do firmware updates using a provision. I wanted to be able to set a limit on how many I do per day. I.e I don’t want to have to go through and set a tag on every device I want to update. The provision should run x times. Previously I have run on a schedule starting at 2:00am - but this doesn’t limit how many devices can be upgraded. (could make a smaller time window but still ugly)
I couldn’t find a way to do this in Genieacs so I made an extension script to do it, it’s also idempotent - being that the provision is just a function I leverage the fact that the timestamp remains constant to check if it’s been run before.
Check it out. I had to write it to run on node 6 / ECMA5 as I haven’t update yet (soon)
I’ve been using gist’s to share the code to the forum.
The one problem I can foresee with your ext script is it relies on redis. I’m not a redis expert, but as I understand it redis is designed to be used as a high-speed key/value store cache. So if redis gets restarted for any reason, your counter will be reset. That may be fine in your environment, just thought I would point it out.
Out of curiosity, why do you want to limit the number of f/w upgrades per day? To limit the possibility of taking down your entire customer base in one fell swoop by a bad upgrade/config? If that is your goal, another method that might work and be easier would be to only do f/w upgrades on reboot. I do this with some CPEs when we want to trickle out upgrades, or if I know this CPE is rather finicky and has to be manually rebooted sometimes because it gets in some sort of wedged state.
Good point about the Redis counter reset. I thought about doing it with a flat file but didn’t want to go down the road of I/O race conditions and locking mechanisms. In my environment the counter being reset isn’t critical. I find firmware updates quite tricky to work with - mainly the TR069 implementation on the CPE I work with is a bit unpredictable.
I’ve thought about upgrading on BOOT but I’ve always been a bit hesistant to perform upgrades while the end user is nearby; as if they power cycle mid update - they will brick the device. Maybe this is a misconception of mine and I should revisit it.
Where are you based out of interest? If you don’t mind me asking? (I’m from New Zealand)
Hi David!
What brand CPE are you using? We’ve been using the SmartRG’s (now owned by Adtran) with good results. I’ve only had a handful go sideways on firmware upgrade.
I thought about the flat file too, and the race conditions and locking etc etc which is precisely why I didn’t propose it :).
I’m on the opposite side of the world from you up here in Alaska, USA :).
I think it’s not often that you can find an existing script that you can reuse as is or with minor adjustments to do what you need. A script for firmware upgrade roll out is the only exception that I can think of.
Here’s how I approach this. Ditch your counters and embrace probability Figure out how many devices in total need to be upgraded, and based on that calculate the probability any given device is to be upgraded during a given night. Here you can exploit the fact that in provision scripts the function Math.random() always returns the same value for a given device (random function is seeded with Device ID by default), so when and how often the device informs during the upgrade time window doesn’t matter. Compare values extrapolated from Date.now() and Math.random() to get your desired probability.
Hope that makes sense. I have the script somewhere. I’ll try to clean it and share it soon.
Using probability to determine what devices get updated. However you can enter total device pool, how many you want to start with and what the max updates per night are.
It will ramp up upgrades per night (double) until max updates is reached. It adjusts the probablity of updating to account for there being less devices after each night’s upgrades to keep the amount of devices that update consistent.
This is for a start number of 200, max of 1000 and total of 10000.
So day 2, double day 1’s 2% is 4% but it increases this to 4.069% to account for the devices that have already been done.
Obviously this doesn’t account for new devices being added or attrition. However for my application they don’t skew the numbers very much. Would be easy enough to add in a variable to account for this.
This is the schedule that I run in Genieacs: 7200 0 2 * * 2-5 (Run for 2 hours between 2am and 4am Tuesday to Friday)
Figure out how many devices in total need to be upgraded, and based on that calculate the probability any given device is to be upgraded during a given night. Here you can exploit the fact that in provision scripts the function Math.random() always returns the same value for a given device (random function is seeded with Device ID by default), so when and how often the device informs during the upgrade time window doesn’t matter. Compare values extrapolated from Date.now() and Math.random() to get your desired probability.