juju 1.20.10.is proposed for release

2014-10-02 Thread Curtis Hovey-Canonical 
juju-core 1.20.10

A new proposed stable release of Juju, juju-core 1.20.10, is now available.
This release may replace stable 1.20.9 after a period of evaluation. If
no issues are raised about this version, it will released on or after
October 7, 2014.


Getting Juju

juju-core 1.20.10 is available for utopic and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

The proposed packages in this archive use the proposed simple-streams.
You must configure the 'tools-metadata-url' option in your
environments.yaml to use the matching juju tools.

tools-metadata-url: https://streams.canonical.com/juju/proposed/tools

This ensures a clean separation between the stable tools and the proposed
tools. Production environments based on stable juju cannot accidentally
upgrade to a proposed release. The 'tools-metadata-url' option must be set
to clearly state the environment is for evaluating proposed versions.


Notable Changes

This releases addresses packaging and documentation issues.


Resolved issues

* make-release-tarball could check the packages with dependencies.tsv
  Lp 1368417


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Kapil Thangavelu 
On Thu, Oct 2, 2014 at 10:46 AM, Robert Jennings <
robert.jenni...@canonical.com> wrote:

> -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 primary issue with the daily stream, is unlike the release images it
doesn't undergo qa, so it can be broken and its not a sane default imo. the
release images are roughly on a 3 week schedule afaicr. but even then cloud
io perf is painful and causes the additional time usage issues (even with
fast cloud local archives).

-k
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Akash Chandrashekar 
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  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"  wrote:
>
>>
>>
>> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  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
 
 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 
 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 
> 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, b

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Mark Shuttleworth 
On 02/10/14 15:46, Robert Jennings wrote:
> 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 'release' image stream is iirc rebuilt at least fortnightly to
include latest updates, to avoid the ever-increasing-delta that you
describe. It's also iirc rebuilt any time there's a big security issue.
Jorge pointed to
http://blog.utlemming.org/2014/08/archive-triggered-cloud-image-builds.html
for daily builds but I believe a similar process is in place for release
images.

Mark



signature.asc
Description: OpenPGP digital signature
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: disabling upgrades on new machines by default?

2014-10-02 Thread José Antonio Rey 
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"  wrote:

>
>
> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  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
>>> 
>>> 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 
>>> 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 
 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"  wrote:
>
>> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
>>  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  / Canonical  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 stable 1.20.9 is released

2014-10-02 Thread Curtis Hovey-Canonical 
juju-core 1.20.9

A new stable release of Juju, juju-core 1.20.9, is now available.
This release replaces stable 1.20.8.


Getting Juju

juju-core 1.20.9 is available for utopic and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/stable


Notable Changes

This releases addresses stability and performance issues.


Resolved issues

* Not okforstorage error when deploying local charm
  Lp 1308146

* Cloud-archive on precise not pinned when juju calls apt-get upgrade
  Lp 1370781


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] rabbitmq-server

2014-10-02 Thread Adam Israel 
Yesterday during my review queue time, I revisited a MP[1] I had worked on the 
previous week. With the information provided by gnuoy, I was able to fully test 
the rabbitmq-server against bug #1355848[2] and I am happy to report that the 
bug is fixed by this MP and have approved it.


[1]https://code.launchpad.net/~gnuoy/charms/trusty/rabbitmq-server/lp-1355848/+merge/231528
[2]https://bugs.launchpad.net/charms/+source/rabbitmq-server/+bug/1355848


-- 
Adam Israel-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Robert Jennings 
-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.

- --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
> mailto:david.che...@canonical.com>>
> wrote:
> 
> 
> 
> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  > 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 
>  > wrote:
> 
> Why not put our perception to the test?
> 
> Here 
> 
>
> 
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  > 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  > 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"  > wrote:
> 
> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu 
>  > 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

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Mark Ramm-Christensen (Canonical.com) 
In practice, it almost never happens.

I don't remember seeing anything actually from the archive break a charm on
update -- though the cloud tools pocket did have a breakage about 8 months
ago which did bad things.

--Mark Ramm

On Thu, Oct 2, 2014 at 10: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 
> wrote:
>
>>
>>
>> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  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
 
 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 
 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 
> 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"  wrote:
>>
>>> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
>>>  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  / Canonical  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
>>>
>>>

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Matt Rae 
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 
wrote:

>
>
> On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  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
>>> 
>>> 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 
>>> 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 
 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"  wrote:
>
>> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
>>  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  / Canonical  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

Re: disabling upgrades on new machines by default?

2014-10-02 Thread David Cheney 
On Thu, Oct 2, 2014 at 10:55 PM, Matt Rae  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
>> 
>> 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 
>> 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 
>>> 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"  wrote:

> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
>  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  / Canonical  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

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Matt Rae 
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.

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
> 
> 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 
> 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  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"  wrote:
>>>
 On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
  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  / Canonical  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

Re: disabling upgrades on new machines by default?

2014-10-02 Thread Samuel Cozannet 
Why not put our perception to the test?

Here

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  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  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"  wrote:
>>
>>> On Wed, Oct 1, 2014 at 3:26 PM, Kapil Thangavelu
>>>  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  / Canonical  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