On 17/11/14 06:35, Sameer Zeidat wrote:
Reporting back. The latest release from the archive fixed it. Thank you.
Great to hear. We'll SRU 1.20.latest to Trusty and Utopic shortly.
Mark
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
Let me know about the shims!
Well, I've just tested and it looks like it was fixed in Ansible 1.7 at
least for host_vars/...
So much cleaner code to come!
Also, let met know what your thinking about the changes I propose on how
relations
are handle in charm-ansible-roles.
Patrick
2014-11-07
I have a few charms that expect /mnt to be the ephemeral disk, while it
wouldn't be a huge headache and I certainly wouldn't want to stand in the
way of progress. It won't be trivial and I'll start to devise a way to test
all the charms so we can get a count of charms that expect /mnt to exist.
On Tue, Nov 18, 2014 at 10:25 AM, Marco Ceppi ma...@ondina.co wrote:
I have a few charms that expect /mnt to be the ephemeral disk, while it
wouldn't be a huge headache and I certainly wouldn't want to stand in the
way of progress. It won't be trivial and I'll start to devise a way to test
+smoser
On Mon, Nov 17, 2014 at 8:13 PM, Andrew Wilkins
andrew.wilk...@canonical.com wrote:
Hi all,
I am working on introducing storage as a first-class primitive in Juju.
Charms will be able to indicate that they require storage (block devices,
filesystems...), and when you deploy that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15.11.2014 07:07, Eric Snow wrote:
FYI, I was able to solve 3 reviewboard-github integration issues
today:
1. pull requests for branches other than master now work (e.g. 1.21
backports) 2. no more hitting rate limits (5000 requests/hour limit
On Mon, Nov 17, 2014 at 5:10 AM, Dimiter Naydenov
dimiter.nayde...@canonical.com wrote:
I can confirm RB diffs for backports to 1.21 get generated correctly
now, and the PR description is updated to include a link to the RB diff.
Thanks for reporting on this.
There's one issue however -- the
FWIW, I'd rather we used HTTPS and just fixed whatever issues we had with
Ship It, etc. But I'm certainly happiest just to see it working.
John
=:-
On Mon, Nov 17, 2014 at 6:55 PM, Eric Snow eric.s...@canonical.com wrote:
On Mon, Nov 17, 2014 at 5:10 AM, Dimiter Naydenov
I've had this around to think about for a bit. I think it is ok, though
sniffing an input parameter to change behavior seems brittle. Mostly
because the object isn't really design to work that way. Could we wrap the
objects so that we just have Find/FindId do the right thing to start?
I suppose
Wrapping the collection objects that are returned from the
`getCollection` method shouldn't be too hard and it could wrap the Find
and FindId calls. It would have fixed this missed call below:
// aliveUnitsCount returns the number a alive units for the service.
func aliveUnitsCount(service
'ello 'ackers,
This is something that I have been meaning to add for quite some time.
We have been recording stack traces with the juju/errors library, but
until now, they have been of limited use.
One of the key places I have wanted to see the stack trace for a while
is when running tests, and
This sounds great, and sounds like a sed replacement of:
s/Assert(err, gc.IsNil)/Assert(err, jc.IsNil)/
would be quite useful.
On Tue, Nov 18, 2014 at 8:22 AM, Tim Penhey tim.pen...@canonical.com
wrote:
'ello 'ackers,
This is something that I have been meaning to add for quite some time.
On 17/11/14 15:47, Stuart Bishop wrote:
On 17 November 2014 07:13, Ian Booth ian.bo...@canonical.com wrote:
The new Juju Status work planned for this cycle will hopefully address the
main
concern about knowing when a deployed charm is fully ready to do the work for
which it was
On Mon, Nov 17, 2014 at 11:23 PM, Ian Booth ian.bo...@canonical.com wrote:
On 17/11/14 15:47, Stuart Bishop wrote:
On 17 November 2014 07:13, Ian Booth ian.bo...@canonical.com wrote:
The new Juju Status work planned for this cycle will hopefully address
the main
concern about knowing
14 matches
Mail list logo
