-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Why not change the image-stream to 'daily' from 'release' rather than altering whether or not we update packages on an instance?
The default environment configuration specifies that the image stream is 'releases' rather than 'daily'. This means that the delta for updates will be large and updating the instance takes more time. I'd suggest changing that default and leave the automatic update. If you keep the 'release' stream as the default and then make the change to not perform updates then there are so many more packages that are old and crufty (and possibly insecure). The issue that you could break users means that package testing of - -proposed during an SRU has missed a problem. It's not just charms that will break, it's any installation using that package, so this really isn't a unique failure for charms. Anyhow, if the package is installed in the charm install hook then the instance will get the latest version, so this argument boils down to, what happens if a core package in the OS image breaks on update, right? Samuel Cozannet's spreadsheet suggests testing with updates disabled but running with updates enabled; this seems like a problem. I say, test with the daily image and keep updates on. You would not be testing what is being deployed. At a minimum the automated testing should always perform updates and should be run as packages are updated in the archives. If the charms had metadata on which packages they installed, that knowledge could be used to automatically run charm tests when those packages show up in -proposed. Saying that we don't need to update because the user should be following best practices by keeping their instances up-to-date is saying that we don't need to demonstrate best practices.</soapbox> - --Rob Jennings On 10/02/2014 09:14 AM, Matt Rae wrote: > Thanks Dave! > > A downside to disabling upgrades is that users may have a bad > experience if broken packages get installed and their services > don't work. Not sure how often this would happen. > > On Thu, Oct 2, 2014 at 6:19 AM, David Cheney > <david.che...@canonical.com <mailto:david.che...@canonical.com>> > wrote: > > > > On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae <matt....@canonical.com > <mailto:matt....@canonical.com>> wrote: > > I don't think the upgrade matters as much as speed. I feel like > most users know to manage updates already, with their own policies, > and that the fast user experience is important. > > Even if juju upgrades initially, users will still need to manage > updates after, so I'm not sure how much the initial upgrade gains. > > "Juju is blazing fast!" is more exciting than "Juju makes sure I'm > updated initially!" > > There is something to be said for having the exact same packages on > every unit of a service rather than a few units having some > versions, then units added later getting different versions. > > > That happens anyway. Units added later may be built from later > releases of the cloud image. > > > > > Matt > > On Thu, Oct 2, 2014 at 12:27 AM, Samuel Cozannet > <samuel.cozan...@canonical.com > <mailto:samuel.cozan...@canonical.com>> wrote: > > Why not put our perception to the test? > > Here > <https://docs.google.com/a/canonical.com/spreadsheets/d/1T-8rf_XxXbvCCRRHT69KtRM5k4oJiHyTEuzbENBU0Js/edit#gid=0> > > is a spreadsheet where you can compile your variables. The > top line summarizes the sum of values. The column that gets green > is the one we should go for [assuming we are representative] > > Sam > > On Thu, Oct 2, 2014 at 7:45 AM, John Meinel <j...@arbash-meinel.com > <mailto:j...@arbash-meinel.com>> wrote: > > So there is the question of what is the "user experience", and > people trying out Juju and it seems slow. Though if it is slow, > doesn't that mean that images are out of date? > > I just bootstrapped a fresh Ubuntu from Amazon's web interface > today, and I noticed that apt-get upgrade on there installed a new > bash to fix the newest major security hole. It seems like it is > good to at least apply security updates, and I'm not sure if it is > easy to only install those. > > John =:-> > > On Thu, Oct 2, 2014 at 7:51 AM, José Antonio Rey <j...@ubuntu.com > <mailto:j...@ubuntu.com>> wrote: > > I believe that, as Jorge mentioned, most users do value having > everything up to date by default, specially when they may go > directly to production environments. Devs may also want to use this > switch, as it will save time during the deployment for testing the > charms they have developed. > > I believe that turning on upgrades as a default would be more > valued by end-users, but that's just a personal opinion. > > -- José Antonio Rey > > On Oct 1, 2014 2:34 PM, "Jorge O. Castro" <jo...@ubuntu.com > <mailto:jo...@ubuntu.com>> wrote: > > On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu > <kapil.thangav...@canonical.com > <mailto:kapil.thangav...@canonical.com>> wrote: >> juju can save minutes per machine (especially > against release images) if we >> turn off upgrades by default. > > There are some updates coming to how we build cloud images that > might be relevant to this discussion: > http://blog.utlemming.org/2014/08/archive-triggered-cloud-image-builds.html > > IMO safer and slower makes sense for most people, those of us who > need speed for demos/conferences will know about this switch. > > -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate > your Cloud Infrastructure > > -- Juju mailing list Juju@lists.ubuntu.com > <mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > -- Juju mailing list Juju@lists.ubuntu.com > <mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > > -- Juju mailing list Juju@lists.ubuntu.com > <mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > -- Samuel Cozannet Cloud, Big Data and IoT Strategy Team Strategic > Program Manager Changing the Future of Cloud Ubuntu > <http://ubuntu.com <http://ubuntu.com/>> / Canonical > <http://canonical.com <http://canonical.com/>> UK LTD > samuel.cozan...@canonical.com > <mailto:samuel.cozan...@canonical.com> +33 616 702 389 > > > -- Juju mailing list Juju@lists.ubuntu.com > <mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > > -- Juju mailing list Juju@lists.ubuntu.com > <mailto:Juju@lists.ubuntu.com> Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJULWUsAAoJEHQMPZ7t8u1z4oIP/i98DFVNK7X8S0fZZTmThnla XL6OklGcL++T47XQteAzZu96HRkP0xZHn1m1Mt0Z3fBR5gRD3cocL15f0HrQ4nil nxycAxd2fELBWshQdziChdR+ccHtFqBjuZRji5K2nG2C5Gi2mhoRp2mhgJrIm9BQ YRDGbsXzqpFrEXeiLoPAzPm+/GybrmJoft31CT/ndxvLYfb8BVjL4ubxqY7TbCtO 2mXuWUpQO42oyxFiUeiPnTQ9e/bx9P4qVdDaOxpnK7K3MvYQgTQ/KPRJgfscmaP2 8mz8uBUZI7N/2ul0w9en0mVhAc/NgkMesgn342XuK1p2yA3jeMbgJjT/+EuIgn0s DHiWalWZlxb4C6TCNTJ7f6mJSVAhS3/NC7VC4BhLc8NfQM7fb3H6nfc8NgJUZjXI aVqhcmXhY4ZkKjCEzl96aGTDDykzlqdyU2wNbXsOKxlx5c2hl0qLLJXOx6Wrn82x 3HPhEo35ETpyw3cNKLwKCXIDjwRRHmCTVJWnT6278hLstqq/3NzdC3p/+QZJmZL/ oOyBtodliuiOAKRQ8Ij7lZB8iJGF4Dpz4AQz+mlVub2BytpqArWYk+gOUBegg2ZT q41RAYSMnTcq8i9/vWo5oFRV8rY7I41RRQwj9kc6chMbatbqHawabjIS0yxjcV8N n9ygUmyGiJic4megOyyx =Vd+9 -----END PGP SIGNATURE----- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
