Hi All,
I am still a little confused as to when Juju decides to run hooks.
Obviously hooks run when something changes.
However, I see juju rujnning config-changed hooks at times when the
configuration has not changed recently.
So, I'd like to know how Juju decides to run the hooks and when?
Any
On Wed, Sep 3, 2014 at 9:57 PM, Darryl Weaver
darryl.wea...@canonical.com wrote:
Hi All,
I am still a little confused as to when Juju decides to run hooks.
Obviously hooks run when something changes.
However, I see juju rujnning config-changed hooks at times when the
configuration has not
On 3 September 2014 13:12, Michael Nelson michael.nel...@canonical.com wrote:
On Wed, Sep 3, 2014 at 9:57 PM, Darryl Weaver
darryl.wea...@canonical.com wrote:
Hi All,
I am still a little confused as to when Juju decides to run hooks.
Obviously hooks run when something changes.
However, I
Even if the config-changed hook was run when it was not supposed to, it
shouldn't have caused any changed if values were not moved to anything
different. If it did, then I believe we're having an idempotency problem
there.
Still, hooks running when they shouldn't is not what expected.
On
Given CAP theorem any message can really only be at most once or at
least once. You can never guarantee exactly only once.
I'm sure juju is biased to the at least once for hooks (hence why it runs
at agent restart because it hasn't been around to know for sure that
nothing changed in the interim).
I wanted to update everyone to let them know the first iteration of this
review queue is out. While it's a very bare MVP it's the direction I'm
taking the review queue in. I've written a blog post,
http://marcoceppi.com/2014/09/a-new-charm-review-queue/ which outlines the
features and the short
I'm working on moving all tools downloads to download from the API server.
There will are a few APIs that return tools:
- Upgrader.Tools
- Client.FindTools
- Provisioner.FindTools
These APIs will need to return URLs pointing at the API server. I'm
intending to change the facade constructors
It feels like this should be something that the API server is looking up in
the database/some sort of query, not just munging a URL. I'm fine with
having a Params struct, though I worry that it isn't really appropriate to
be passing all possible Params to all facades. They already have a State
Hey,
It seems that gocheck is still updated from https://launchpad.net/gocheck.
However, as you can see if you check the page the project has moved to
github(https://github.com/go-check/check) and this results in us not having the
latest updates.
So far I've tried doing a global sed in a
On Wed, Sep 3, 2014 at 4:49 PM, John Meinel j...@arbash-meinel.com wrote:
It feels like this should be something that the API server is looking up in
the database/some sort of query, not just munging a URL. I'm fine with
having a Params struct, though I worry that it isn't really appropriate to
Hi Tim,
Great question, sorry it took me so long to get back to you. I have an
assumption that all hooks run serially on a single unit regardless of
service group, etc. However, I want to say I've seen some kind
serialization between peers. I've cc'd the Juju core mailing list and the
regular
I am working on writing a Juju charm to deploy the Discourse discussion
forum software using their new docker image install process. This was my
first charm, and I'm writing it in Go, because I like Go. This means I
can't use the python charm helpers, but since I don't actually know what
they
Hi folks
The question recently came up in reviews as to whether we should be updating the
date in the copyright statement in the file header when we make a change to the
code in that file. I sought clarification from Robie Basak, who previously had
provided input on licensing issues and
I think this is needless busy work, I vote that as long as there is a
copyright header with _a_ year, that is sufficient.
On Thu, Sep 4, 2014 at 7:50 AM, Ian Booth ian.bo...@canonical.com wrote:
Hi folks
The question recently came up in reviews as to whether we should be updating
the
date
I've been asking for updates in my reviews. I'm happy to stop if the
consensus is we don't need to. Once we get an agreement on policy, let's
put it in the style guide.
On 04/09/14 09:55, Gustavo Niemeyer wrote:
I suggest not updating it. Updates on the same line will conflict, and
cause
On Wed, Sep 3, 2014 at 11:37 PM, William Reade william.re...@canonical.com
wrote:
On Wed, Sep 3, 2014 at 4:49 PM, John Meinel j...@arbash-meinel.com
wrote:
It feels like this should be something that the API server is looking up
in
the database/some sort of query, not just munging a URL.
On Thu, Sep 4, 2014 at 5:50 AM, Ian Booth ian.bo...@canonical.com wrote:
Hi folks
The question recently came up in reviews as to whether we should be
updating the
date in the copyright statement in the file header when we make a change
to the
code in that file. I sought clarification from
My understanding is that the proposed Leader spec is likely to help with
this, as a leader unit could coordinate between its peers which one should
work next. Otherwise, it is just up to the charm peer relation to
coordinate anything like this. So in peer-relation-changed you could say
that you
On Thu, Sep 4, 2014 at 3:46 AM, Eric Snow eric.s...@canonical.com wrote:
Hi all,
Here's a write-up on my experience writing a charm for the first time.
In summary, it wasn't nearly as bad as I expected it to be. The docs
were super useful (both the getting-started side of things and later
19 matches
Mail list logo
