[retronet] Random thoughts about databases and config management.

[Grant Taylor]

My brain has disengaged from work and engaged in RetroNet.

I think we need to name interfaces using the “${RNmemberName}-${memberNodeName}” format. That will clearly identify who the interface is for and which of their interfaces it is.

So, I think we need a DB (or comparable) / table that will enforce unique member names as well as one that enforces unique node names for the member. I don’t know how to do the second enforcement. But I’m not a DBA / app designer so I won’t try. (Bad Grant, stop it!)

I think we should NOT support renaming nodes. If you want to rename, turn a new node up in parallel and turn the old node down. Or some such.

I simply want to NOT deal with complications of trying to rename things on multiple systems and ends of links in a transactional like manner. I see no point of it. Thoughts?

This brings us to configuration management.

When we get there, I’m inclined to have things under version control and require a core members approval for anything that changes in RetroNet Core infrastructure. Members are free to change what ever they want on their end any time they want as long as there’s no corresponding change in core.

Data for core will likely come from a DB and dynamically build config files. But I’d like that to feed into a version control system. Or some hybrid of the two that requires approval.

That’s it for now.



-- 
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2338 bytes
Desc: not available
URL: <http://mailman.chivanet.org/pipermail/retronet/attachments/20180911/d9bb3ee4/attachment.bin>