Versions, versions, everywhere :) To clarify this conversation, let's be more precise about the things that are being upgraded:
Juju itself has three parts: * the juju client (usually installed on your workstation from a package) * the juju server (installed by the bootstrap process) * the juju agents in all the machines in the environment (generally aligned to server version) We call the latter two pieces "tools" but we should really call them the server and the agents. What this thread is about, however, is the policy of how up-to-date the OTHER packages should be on new machines spun up by Juju. When you deploy a service or add a unit, and a new machine or container is created for that, we start with a base image (AMI or the like) and then we have the option to apt-get dist-upgrade. Currently, we spin up the machine then do a full package update. This slows down the experience, and it doesn't address the real issue for the administrator that they will need a process by which they KEEP packages updated. Juju won't do that, most people do it manually, or with scripts or management tools like Landscape. On 02/10/14 19:15, Akash Chandrashekar wrote: > 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). Katherine points out that work in the current development tree (targeting 1.21) gives people complete control of this. They can: * pin to a specific version of Juju * track a "stream" which might be development releases or stable releases only We need to ensure that agents can be handled separately from the server itself, and of course, the user has complete control of the client that's installed on their workstation. > 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. The new configuration options will let the user control this, precisely. > 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? I think you'll find there are "production HA bundles" and "dev/test" bundles that use the same *charms* but combine them in different ways. So the same versions of the software are used, but the spreading out fo that software over machines is different. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
