Halfwittering.

[hirez]

And now, a short section from here:

The official SAAB service schedule states that at every service the key fob batteries must be checked or changed as required. When cars fall out of the dealer network as they get older, this simple procedure tends to get overlooked. Usually -when 9-3 or 9-5 owners least expect or need it- a message appears on the SID "Change key fob battery".

Owners of NG900s or 9000s with the optional SAAB alarm/immobiliser were less fortunate: if the fob didn't unlock the doors, it was time to change the batteries!


... Which is entirely and tiresomely correct. I have some spare CR2016 cells now, however at mumble-PM on a busy-for-the-AA Saturday night, I wasn't quite so much of an adult...

So yesterday was a bit surplus because of $reasons and today not much better. I really do have the brains of someone dim and gormless, while the relevant dim & gormless person is probably joyriding my brain about town, bashing into cardboard boxes stored in alleyways and generally ignoring the rev-limiter on my superego. The bastard.

For instance:

We have a pile of Puppet manifests that describe some moderately complex multi-VM systems. Because Puppet's a bit poor on cross-machine config, a lot of the complicated bits are tied down to IP address and/or hostname.

Were one wanting to bring up a number of these systems in an isolated environment for the purposes of testing, one would likely have to go through the faff of generating a set of hostnames, bagging some IP space, C&Ping the relevant bits of config over to the new set of addresses.. And only then could you bring up some new VMs for the purposes of doing some work. It's amazingly much more better than it used to be, but it's still a complete faff and really not repeatable. Unless you're going to do something like carve out wedges of pre-allocated IP space and label each bit as not to be fiddled with, by order, The Mgt.

A much more scalable, sensible and automatable approach would be to use some kind of config DB that the machines would connect to on start up so that they could announce their presence and function, should other kit be interested. The mildly complex part of that approach would be getting the ordering right or building it all such that the component parts have the brains to poll the DB on and off 'til they get a sensible answer. If you make that work, then your rig no longer cares about hostnames or IP addresses, which is just a Good Thing in this modern world of toys-on-demand.

... And I'm totally failing to get to grips with any of this.

On the other hand, I have Hunter/Land-Rover green nail varnish.

I also have a clean keyboard for the first time in a while. Were this five or seven years ago when people who read LJ also had the patience to deal with the largely missing photo-handling capability, I'd be asking for pictures of yr keyboards. However, passive-aggressive paragraphs (or entire posts) about 'no-one being on LJ' aren't any fun and I suspect El Reg has the premier collection of jallop-and-breakfast-encrusted keyboards.

I would like to point out that my keyboard was not encrusted with breakfast or jallop.

Comments

[nemesis-to-go.livejournal.com]

I have photo handling capability. (I also have logged back in to LJ, after it mysteriously kicked me off. Sorry about that anonymous comment.)

Anyway - here's a picture of my keyboard:



Note missing letters…which cause no end of problems when I can't find the E or the S.

[hirez.livejournal.com]

Were it not for the Euro symbol, I'd take that for a Superbrain k/b. And then I'd be all like 'IP for CP/M? Crikey!'

[maluse.livejournal.com]

http://www.retrotechnology.com/dri/cpm_tcpip.html

CP/M, an elegant OS, for a more civilised age.

[quercus.livejournal.com]

Tape a stash of shrink-wrapped CR2016s (real ones, not pondshop) inside the bumper.

[hirez.livejournal.com]

They can go in the ashtray - the immobiliser's a parts-bin special and doesn't stop the key working. Although Hijinks can Ensue when locks and alarm get out of sync...

[mr-tom.livejournal.com]

I trust that Sir is already using heira for the configs?

We're in the process of moving a lot of config stuff into DNS for $CLIENT. Use shortnames for everything you're touching, and then give yourself a new domain for each environment of machines that have to talk to each other. Then you need a little bit of scripting to make yourself a pile of DNS entries when you spin up a VM or two and job's a good'un.

[hirez.livejournal.com]

Sir is indeed using Heira - on the 2.6 tree and the 3.x one.

I am considering etcd and the hiera bolt-on for same.

I have this daft theory in my head (largely because Anarchy, bottom-up rather than top-down, workers self-management, etc) that the kit should be able to annonce its role itself and then enter into mutually-beneficial contracts with the other equipment. Iron-forged weapon in the hands of progressive people, rise up against the management layers and their human lackeys, etc.

[jarkman.livejournal.com]

What does each machine know about its place in the world ? A role identifier and an environment identifier ?

[hirez.livejournal.com]

I'd like the notion of 'environment' to go away. In that the code shouldn't be making determinations about where its running - the config-management gubbins works out where the DB is or what clients the load-balancer should have, so all the app has to do is ask how it connects to the DB.

That answer would change depending on who (or from where) is asking.

For instance ,you fire up a new instance of a web-server for, er, www.fred.com. The minimal things it needs to know to be able to do some work (helo i am a new webserver can i do some work today? i have the greatest enthusiasm for this project, etc.) is where its traffic comes from and where its database is. (assuming a DB-driven site. It could equally well be the location of some large amount of static data.)

The first thing it ought to do is grovel in the config-db for something like /conf/www.fred.com/database-server, ../database-name and ../database-auth - which should return a JSON packet with enough info for the thing to establish a connection.

At that point, a well-written server could try some example queries or other useful self-testery before...

The next/last thing that should happen is that it registers itself as an available www.fred.com server by (say) writing its IP address into the /conf/www.fred.com/webservers area.

A moderately wonky load-balancer config would subscribe to that key and reconfigure itself to add the new server to the pool, a less wonky one would wait 'til the next Puppet run noticed the config change ditto.

So I guess it just wants some fiddling about with resources and ordering. Probably.

[jarkman.livejournal.com]

Right, but if there is to be a www.fred.com for testing the flanges feature and a different www.fred.com for testing the intercept trajectories, the two webservers presumably need to identify themselves as 'flanges' or 'intercepts' as well as 'fred.com' when they go to the config DB.

[hirez.livejournal.com]

Hm. Point. There is the case where v1.0.4-intercepts requires an extra column in the DB.

At the moment, the code would just catch fire.

In a less worse world, the self-test code should do something like 'if exists(intercepts-column) then intercepts-enable = 1 else intercepts-enable = 0.

... Which is just feature-flagging.

Hm. So I guess there's a /conf/www.fred.com/webservers/features path.

[jarkman.livejournal.com]

What do you do when you want to run up one of these configs multiple times on multiple sets of hardware - say, a live and a staging and a load-testing ?

[hirez.livejournal.com]

Currently I envisage a different config DB per subdomain, which is how we've managed some other systems that act differently depending on where you ask from. Such that config.stage.fred.com is a different server to config.dev.fred.com is different to config.test.fred.com

[maluse.livejournal.com]

The "Autonomic Networked Systems" project that I used to work on at Imperial did this sort of thing, although for wireless sensor devices rather than servers. Devices would broadcast a request for particular capabilities and anything that could provide them would reply, with some form of metric saying how well they can provide it (e.g. a heavily loaded server can't offer as good a service as an unloaded one. Simple maths was used to select the "best" (or "least worst") provider. Regular rebroadcasting plus rebroadcasting on failure meant that the system tended towards optimal over time.

There's a paper online (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.130.5744&rep=rep1&type=pdf) that goes into the details, though be aware that as with all scientific papers there's about one paragraph of new information and ten pages of padding.

[hirez.livejournal.com]

Coo. Ta!

[sallypointzero.livejournal.com]

*wheech*
(stuff going over head)