[ixpmanager] Order of customers' config in the RS configuration of the IXP manager

[Rowan Thorpe]

On 2014/12/15-14:43, Barry O'Donovan wrote:
> ..[snip]..
> See: http://git.io/dsFP9w (documented in the wiki at: http://git.io/bv_i0g
> 
> This is the script we use to download a new route server configuration 
> and it:
> 
>   - ensures wget terminated successfully
>   - ensures the new file exists and has content
>   - ensures we have a minimum number of neighbors
>   - runs Bird parser against the new file

I agree using the API approach will be simpler when we can - I referred to
those example scripts when we started investigating RS-options but the reason
for our more complex local-scripts-and-diff workflow at the moment is to fit
the "human review then copy" requirement for staging phase.

> > For that reason we are writing a script that:
> > a) updates the IXP manager ASN and prefixes database
> > ..[snip]..
> We've discussed this script with Rowan also. For (a) above, please note 
> that we have documentation at http://git.io/7jnKcQ

We use those commands in our script, based on that documentation :)

> We have put a lot of effort into decoupling (a) from the RS build. 
> Chaining the update of the as/prefix table to the rs build can lead to 
> ~1hour of processing time (ymmv depending on members, AS-SET unwrapping, 
> etc). What we have now is a transaction safe process where they can be 
> run independently and on separate servers.

I'll add that although decoupling the two makes obvious general sense, one good
use-case for wrapping them in the script with option-flags (for either calling
independently _or_ recoupling-in-strict-order as desired) is that they can
easily be sequenced for debug-runs/manual-use (with flags for debug output,
etc) especially when troubleshooting, which has already been useful during our
setup/testing. Another case might be a cron running every X hours calling it to
update configs, and another cron running maybe once or twice a day calling it
to update AS/prefixes and _then_ update configs (this doesn't achieve anything
which fully independent scripts couldn't, but just simplifies the process for
common usage when running on the same server, and reduces the number of scripts
to track/maintain). When we finish babysitting the configs on our ixp-m server,
using remote API calls will obviously be simpler than local generation if
possible though, to avoid messing around with things like stunnel,
ssh-between-servers, sftp, etc for safely copying files - then the as/prefix
updates would have to be run by a separately (local) script anyway.

> Rowan's script also had Git functionality. I'm not sure this is 
> necessary as:
> 
>   - for a known database and version of IXP Manager, the configuration 
> is always reproducible.
>   - standard server backups should maintain all three of the above 
> without the additional need for Git.
>   - in 7 years, we have never needed to revisit an older configuration.

As the present workflow is just a pre-API testing-workflow, I used git purely
as a way to get catchall-diffing in quick one-liners rather than
copy-find-diff(new-against-/dev/null)-delete-move codeblocks. git-diff also has
colour-highlighted word-diffing with stat-headers, etc thrown in for free. The
actual "archived history" is a meaningless side-effect for us, but having said
that I did find a quick "git log -p" has been useful once or twice while
troubleshooting, and quicker than digging into backups and manually grokking
changes.

> I've just tested and pushed the following diff:
> 
> --- a/application/Repositories/VlanInterface.php
> +++ b/application/Repositories/VlanInterface.php
> 
> ..[snip]..
>
> I've also pushed changes to the select queries for routes / asn acls to 
> ensure a deterministic ordering of those.

Thanks! :)

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD