From owner-freebsd-pkg@freebsd.org Wed Jun 7 13:40:28 2017 Return-Path: Delivered-To: freebsd-pkg@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6FEBC31F80 for ; Wed, 7 Jun 2017 13:40:28 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EDC574AED for ; Wed, 7 Jun 2017 13:40:28 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: by mail-ot0-x22e.google.com with SMTP id a2so7074274oth.2 for ; Wed, 07 Jun 2017 06:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VLoTvy/Y62lfFYhq/WTVvrlEvhwNfPq7K2fIUbMvVHA=; b=QYxBzDL8sSz4TKCHeOrdoHl+Mk5iJgRyOzGg3MbR+i8S8/FCm0K317aZKBFUBpVI+T 3lnxg+5qN03MF4EOpoPvKPp1guFJ5d4Kcp3SzQdX8sUHAAJ2//BiQBki01eJhhKqDi/4 Hy9UVwCyU8c5nXZvfiX+lmDSOsANpr0IPf1Wbs3MioT7fcd1f7DQz1pJXoxxeimFEdLg XoqjYb4yCPgZRZ93UAC0cZvvxArpcOV+kJuQNJpgrkEBpHNuBcSeJbZAp8YHCqi5NrKT QmCLaRnDybLoMbbxlK4AR92rxyrU8SI9bqD3k9x51YANdkvbJzOrDNPVtPrentIgaUtf VOXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VLoTvy/Y62lfFYhq/WTVvrlEvhwNfPq7K2fIUbMvVHA=; b=OAJNA4F81fBGr2nJK0tcy1c3mgDPnjAH2jXMjNOvmggVne4GwdwD8wY0EeNAWFBFdF F2wAWhgxnlxojoYGgFbIWb3Iku/BWNt4FOdWdOI5FB/giAVZFK+O/uoGA9ULQsmGyUl1 IhBYfXMGkFanCUuPWXt4X53cs6/KvuYdipdEJ/4OINA1WS/bEhb66ouuQSfakZcQ03SW xev5f4W2knYnG4Pb0jPlnhm886m/ukOdYDFKo3XDpyQkQ9b9IzIoMsrpqduAe7TRZ2/a KRXpy4K/iEXp9jfaQyAcc4KNg6GZK8XlwZzbe9vOf839JLo0A/pahmG3BCIzrrwNiHep MPLQ== X-Gm-Message-State: AKS2vOxeyUglFzMBXGCz09zUp3AdoqMRBOedQJsuFS/QW0Md5/To1i1m 88nl6o9Jcp54Ub0YjkEKjafWiNZ/sMD8NaY= X-Received: by 10.157.84.22 with SMTP id j22mr18376646oth.252.1496842827474; Wed, 07 Jun 2017 06:40:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.47.103 with HTTP; Wed, 7 Jun 2017 06:40:07 -0700 (PDT) From: Luca Pizzamiglio Date: Wed, 7 Jun 2017 15:40:07 +0200 Message-ID: Subject: pkg rollback To: freebsd-pkg@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 13:40:28 -0000 Hi all, I'm trying to figure out how an automatic process to upgrade packages on production machines can look like. A kind of: # pkg upgrade # restart services # if everything not OK # rollback # restart services I'm considering a package repository that is not guaranteeing 100% stability, like `latest`. Even intercepting events needing manual intervention (i.e. reported by UPDATING), a blind pkg upgrade can break the web application running on top. So, I was thinking if it's possible to perform some kind of rollback. to proof if it's possible, I wrote a shell scripts with two features (it helped me a lot to understand how pkg works): # backup ## backup the repo sqlite database ## run `pkg update` and determine all actions would be performed by `pkg upgrade` (a kind of `pkg upgrade` simulation) ## backup all packages from the cache that would be replaced by `pkg upgrade` ## download all new packages to determine potentially conflicts ## backup all packages from the cache that would be replaced by `pkg upgrade` (after determined conflicts) ## restore the repo sqlite database # rollback ## restore the repo sqlite database ## install all previously backup'ed packages Another approach, less complex, but I guess even valid, could be: # backup (or snapshot) ## backup of the repo sqlite database ## take a snapshot of all installed packages # rollback (a previously stored snapshot) ## restore the repo sqlite database ## reinstall all previously backup'ed packages Adding two features [snapshot and rollback] to pkg(8), the automated upgrade process would become: # pkg snapshot # pkg upgrade # restart services # if everything not OK # rollback # restart services What do you think? What am I missing? Ideas, suggestions and feedback are welcome, so, please, feel free to reply. Best regards, Luca PS: I'd use `pkg snapshot`, because `pkg backup` already exist and it has another meaning. PS2: In some case, `zfs snapshot` could work as well, but it's not always possible PS3: if feebacks are positive, I'd like to implement those features