I wanted to throw some insight from a field perspective on juju upgrades and or updates ~ which I hope is helpful, and in the spirit and in line with this discussion. Here are my notes :
1) Stable juju versions : Once a customer ends up finding a juju-core, juju-gui version that works with whatever specific endpoint (be it MAAS, AWS, LXC), they are extremely hesitant to move off of working versions. Updates have lead to potential bugs and instability in environments where stability is key. In these specific cases, we need to lock down the versions of known/good versions almost in an LTS state (where stability over features is more important). This of course is potentially a highly debatable philosophical and technical discussion regarding "release early and often" versus a different methodology. The question by many customers is - how will they be are aware of knowing, and can differentiate juju version upgrades that are performance/bug fix related in comparison to 'stable' versions ready for full production use, and lock them down for a period of time to ensure stability. 2) Enabling of Complex reference architecture charms: Many of our charms are beautiful in that they allow customers of all sorts to now capture incredible reference architectures. Also a rich dynamic set of conversations is taking place around enabling of hardware via MAAS ~ "An optimized experience". However in these discussions, the extension of the charms to include HA versus on HA versions of the charms needs to exist. There are some partners that are looking for a quick go-to-market strategic charm bundle to integrate their components love our "quick and easy" charm bundles. Then there are other customers/partners that want to "bridge" development or POC environments with those that are far more complex in production and are held by certain SLA's that require everything from deep security to multiple components being HA to provide both scale AND redundancy (in terms of overall infrastructure stability). The question here is : In the ability to "upgrade" - is there a way to create an easy upgrade path that has an option for HA for certain charms and/or differentiate them with severe re-writes of the charms themselves? Thanks, Akash Chandrashekar On Thu, Oct 2, 2014 at 10:19 AM, José Antonio Rey <j...@ubuntu.com> wrote: > In terms of 'upgrading later', Juju is built for not going into the > machines after they are launched. Bare that in mind. > > -- > José Antonio Rey > On Oct 2, 2014 8:19 AM, "David Cheney" <david.che...@canonical.com> wrote: > >> >> >> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae <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> 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> >>>> 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> >>>>> 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> wrote: >>>>>> >>>>>>> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu >>>>>>> <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 >>>>>>> Modify settings or unsubscribe at: >>>>>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>>>>> >>>>>> >>>>>> -- >>>>>> Juju mailing list >>>>>> Juju@lists.ubuntu.com >>>>>> Modify settings or unsubscribe at: >>>>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Juju mailing list >>>>> 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> / Canonical <http://canonical.com> UK LTD >>>> samuel.cozan...@canonical.com >>>> +33 616 702 389 >>>> >>>> >>>> -- >>>> Juju mailing list >>>> Juju@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>> >>>> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
