[Bug 1329302] Re: Meta bug for tracking juju-core 1.18.4 landing in Trusty

2014-06-27 Thread Robie Basak
** Also affects: juju-core (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Summary changed:

- Meta bug for tracking juju-core 1.18.4 landing in Trusty
+ juju-core 1.18.4 MRE tracker

** Changed in: juju-core (Ubuntu)
   Status: Triaged = Fix Released

** Changed in: juju-core (Ubuntu Trusty)
   Status: New = Triaged

** Changed in: juju-core (Ubuntu Trusty)
   Importance: Undecided = High

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1329302

Title:
  juju-core 1.18.4 MRE tracker

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1329302/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1329302] Re: Meta bug for tracking juju-core 1.18.4 landing in Trusty

2014-06-18 Thread Robie Basak
** Description changed:

  1.18.4 contains essential fixes that need to land in Trusty.
+ 
+ Changes extracted from bzr for 1.18.1 Trusty (currently in Trusty) to
+ 1.18.4:
+ 
+ 
+ revno: 2272 [merge]
+ author: John Arbash Meinel j...@arbash-meinel.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Sat 2014-04-12 06:15:19 +
+ message:
+   [r=jameinel] testing/filetesting: preserve bzr file-ids
+   
+   filetesting was backported from trunk to 1.18 using diff+patch rather than 
a bzr merge that would preserve its file identifiers. That means that when 
merging from 1.18 = trunk all those files look like duplicated files. This 
patch just fixes up the Bazaar indentifiers so that they match, which should 
allow easier merging between 1.18 and trunk in the future.
+   
+   As this is a metadata only change (no code changes), I'm going to self 
approve this.
+ 
+ revno: 2273 [merge]
+ author: Curtis Hovey cur...@canonical.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Sat 2014-04-12 09:54:13 +
+ message:
+   [r=jameinel] Increment juju stable to 1.18.2
+   
+   Increment juju stable version and win installer to 1.18.2.
+   
+   https://codereview.appspot.com/87120043/
+ 
+ revno: 2274 [merge]
+ author: John Arbash Meinel j...@arbash-meinel.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Thu 2014-04-24 14:14:20 +
+ message:
+   [r=jameinel],[bug=1311676] worker/provisioner: no tools is an error
+   
+   We were treating no tools found as an error of the Provisioner, rather
+   than an error with the machine we were trying to provision (bug
+   #1311676). This now sets the status of the machine to an error state,
+   which lets us continue with our lives.
+   
+   In the original bug about not having tools, it was shown that in the
+   local provider, doing
+   
+ juju bootstrap -e local
+ juju deploy -e local precise/ubuntu
+ juju deploy -e local trusty/ubuntu ubuntu-t
+   
+   Would end up with both machines stuck in Pending. Now it says:
+   $ juju status -e local
+   environment: local
+   machines:
+ 0:
+   agent-state: started
+   agent-version: 1.18.2.1
+   dns-name: localhost
+   instance-id: localhost
+   series: trusty
+ 1:
+   agent-state-info: '(error: no matching tools available)'
+   instance-id: pending
+   series: precise
+ 2:
+   agent-state: started
+   agent-version: 1.18.2.1
+   dns-name: 10.0.3.194
+   instance-id: jameinel-local-machine-2
+   series: trusty
+   hardware: arch=amd64
+   
+   And you can see that it succeeded in deploying trusty because it put
+   precise into an error state.
+   
+   https://codereview.appspot.com/93720044/
+ 
+ revno: 2275 [merge]
+ author: Nate Finch nate.fi...@canonical.com, John Arbash Meinel 
j...@arbash-meinel.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Thu 2014-04-24 20:35:41 +
+ message:
+   [r=natefinch] juju/api.go: actually handle error (bug #1312136)
+   
+   (refactored from a change John made)
+   
+   If there is a problem reading the .jenv file, it can return an error,
+   but we weren't paying attention to it. Instead we would end up getting a
+   panic() a few lines down when we go to use a *Config that is actually
+   nil.
+   
+   addition by Nate:
+   
+   Refactored the code to extract the logic for getting the config into a 
separate function, which cleans up the error handling significantly.
+ 
+ revno: 2276 [merge]
+ author: Curtis Hovey cur...@canonical.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Thu 2014-04-24 21:26:22 +
+ message:
+   [r=sinzui] Fix loggo import.
+   
+   github.com/loggo/loggo moved to github.com/juju/loggo.
+   
+   https://codereview.appspot.com/96780043/
+ 
+ revno: 2277 [merge]
+ author: John Arbash Meinel j...@arbash-meinel.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Fri 2014-04-25 11:18:42 +
+ message:
+   [r=jameinel],[bug=1312537] Rename authorised-keys to authorized-keys, but 
keep the other as an alias.
+   
+   This makes us a bit more consistent with the value in environments.yaml.
+   (Addresses bug #1312537)
+   https://codereview.appspot.com/93800043/
+ 
+ revno: 2278 [merge]
+ author: Ian Booth ian.bo...@canonical.com
+ committer: Tarmac
+ branch nick: 1.18
+ timestamp: Tue 2014-04-29 18:04:13 +
+ message:
+   [r=wallyworld],[bug=1302205] Cherry pick trunk 2588,2589 to backport fix 
for bug 1302205 
+   manual provisioned systems stuck in pending on arm64
+