> On Jun 13, 2014, at 6:22, "Khushil dep via smartos-discuss" > <[email protected]> wrote: > > My two cents below... > > Sent from my iPad > >> On 13 Jun 2014, at 06:32, "Tim Boudreau via smartos-discuss" >> <[email protected]> wrote: >> >> Thanks, Jonathan, for the clear upgrade instructions! >> >> It seems like the upgrade situation, for those who would like to do it, >> could be helped by the community with a smidgin of coding and a bit of >> crowd-sourcing. Assuming the following assertions are true: >> >> - The set of packages may NOT upgrade cleanly from QN to QN+1 is a >> relatively small percentage, and finite and knowable list > > No. Not at all. This mythical list may also change from one QN to another. > >> - If a package may not upgrade cleanly from QN to QN+1 it is assumed that >> is also true of QN to QN+2 and so forth > > This will bite you. This will not hold true for the same package installed on > varying systems with different package installation combinations. > > >> - Therefore, if that list is known, it is possible to determine if a >> system definitely can NOT be upgraded cleanly and which packages are at fault > > This is list is nonsensical depending packages installed in varying > combinations. It makes a great many assumptions about machine, state and > intent. Bad idea. > >> then some sort of reporting tool which allows users who do this sort of >> upgrade and find it does not go smoothly for a package can contribute that >> information to some sort of online repository for it, which pkgin (or a >> wrapper around it) can query as part of an upgrade would allow most (not >> all, but most) people to upgrade systems with reduced risk. > > This is a non trivial and a dangerous tool to write. You assume a fully > knowable stable state, not so. People will try and depend on the reassuring > lies this tool tells and There Will Be Blood. Or at least data loss and lost > weekends. We really must stop assuming so much about the machine like this. > >> It's the sort of thing that would be pretty trivial to write - probably take >> a similar approach to the one the NodeJS folks did with npm (one of the few >> uses of CouchDB I've seen where it was a really perfect fit - customers >> could optionally run a local mirror that accepts writes about packages if >> they're paranoid or maintain their own package repo, etc.). I'd imagine the >> integration with pkgin would actually be the hard part. > > Oh (insert deity here) please no. This is really not what CouchDB is for and > npm know it. Theres no way you want a CouchDB installation on each machine > your run nor do you want the SPOF of a 'master' knowledge hub. there's > actually a pkgsrc conference coming up in the UK if your interested in > attending to discuss topics like the further. > > The truth that we should face is that system upgrades are a dangerous, > legacy, foolish and fearful way of managing systems. You don't need to > upgrade unless for the trivial cases. You can rebuild quickly and easily. > Most of my platform can be rebuilt in 10 minutes, and I run a non trivial > platform on the JPC. Databases are "fun"'to rebuild and I'll post my > experiences to my blood over the next few weeks. Seriously though, please > don't get distracted like this. There are amazing challenges to solve in > SmartOS. This really isn't one of them IMHO. > >> -Tim
I totally agree. Redeploy, don't upgrade. It's not trivial, but it is safe and you need it for DR anyway. Time spent on making pkgsrc upgrades work is time better spent on Ansible, CFEngine, Chef, Puppet, etc. making your platform deployable from code. Think about APTs (Advanced Persistent Threats). If you have deployment from code you can replace machines prophylactically to limit the maximum persistence of such threats. Think about scaling up or down. If you need to upgrade in place it's also likely that you can't scale dynamically which means you are overpaying for idle compute, memory, and storage. ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
