On 06/02/2014 11:57 AM, Martin Packman wrote:
> On 02/06/2014, roger peppe wrote:
>>
>> What is the policy around rebasing before commenting with $$merge$$ ?
>> Does this need to be done? If not, how does the merge procedure
>> decide what commit message gets attached to the final merge?
>> (Or ar
On 06/05/2014 10:22 AM, Nate Finch wrote:
> This mashes all your pre-PR commits into one, so hides some commit spam
> that way, but then keeps the post-PR commits, to preserve comments. It
> sounds like we can still get a list of just the merges from git, to exclude
> all the commits during code r
+1 for feature flags in general and +1 for using environment variables
in upstart to get them to the servers & agents.
I think it'd be nice to have an environment variable per flag, with a
common prefix JUJU_FEATURE_. That way, if you need to check one in a
package init(), you don't have to parse
Juju developers,
I would like to announce Domas Monkus is a fully graduated Juju core
reviewer. This announcement is really long overdue.. Domas is careful
and thoughtful in his reviews, his feedback is useful, actionable and
relevant, and he's landed several significant improvements that
demonstra
Just a friendly heads-up.. a fix for this longstanding bug will be
landing into master shortly:
LP: #1174610, unit ids should be unique
What this fix essentially does is assign each deployed workload a
distinct unit ID (incrementing sequentially) within the scope of an
environment. Example:
1. j
All,
I'm pleased to announce Aleš Stimec is now a graduated Juju core reviewer.
His recent contributions and improvements to the Juju unit agent,
command-line infrastructure and API login clearly demonstrate a depth and
breadth of Juju core knowledge befitting this role.
Welcome Aleš, and well don
How about github.com/camlistore/lock ?
On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey
wrote:
> Hi folks,
>
> The fslock was a mistake that I added to the codebase some time back. It
> provided an overly simplistic solution to a more complex problem.
>
> Really the filesystem shouldn't be used as a
On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer <
alexis.bruem...@canonical.com> wrote:
>
> Hi All,
>
> As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the
> latest LXD will not work with Juju 2.0-beta3. This is a result of LXD
> moving to use a default bridge of lxdbr0 and
An excellent demonstration of writing tests that fail first that I've seen
recently: https://www.youtube.com/watch?v=PEbnzuMZceA
On Wed, May 4, 2016 at 9:24 PM, Andrew Wilkins wrote:
> See: https://bugs.launchpad.net/juju-core/+bug/1578456
>
> Cheers,
> Andrew
>
> --
> Juju-dev mailing list
> Ju
I seem to be unable to connect to the Juju 2.0 controller database lately.
I'm thinking this might be related to the move to mongodb 3.2.
Can someone in the know please share how to do this? While most users
should never, ever connect directly to the controller's database, I have
two good use case
se case #1, yes, use the shell.
For use case #2, I'd be using github.com/dcu/mongodb_exporter, which uses
mgo.v2 and just needs a mongodb URI
<https://github.com/dcu/mongodb_exporter/blob/master/mongodb_exporter.go#L26>
.
> On Friday, 13 May 2016, Casey Marshall
> wrote:
>
On Wed, May 18, 2016 at 11:02 PM, David Cheney
wrote:
> Hello,
>
> github.com/juju/juju/cmd/juju/commands:
> github.com/juju/romulus/cmd/commands:
> github.com/juju/romulus/cmd/setplan: <
> github.com/juju/juju/api/service:
> github.com/juju/juju/cmd/modelcmd
Matty, this sounds like a great idea.
Dave, I understand and thanks for clarifying. Please give us some time to
coordinate the package relocation in our next iteration (begins next week).
Thanks,
Casey
On Thu, May 19, 2016 at 2:57 AM, David Cheney
wrote:
> Thanks Matty!
>
> On Thu, May 19, 20
What is the intended behavior for automatic hook retries in Juju 2.0?
Specifically, I'd like to know, as a Juju user:
Are errors in hooks all retried with the same policy, or are some retried
with a different policy / strategy than others (install, for example)?
Is there a limit to the number of
On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:
> This is a simple story of a man and a simple mission. Eliminate the final
> 2 dependencies that are in bazaar and launchpad. It makes juju and it's
> dependencies live completely in git. A notable goal, and
Menno,
This is great and thanks for sharing!
In case anyone else runs into this.. charms that install from PPAs will
fail with this squid-deb-proxy setup. You'll need to allow archive mirrors
for this to work. See
https://1337.tips/ubuntu-cache-packages-using-squid-deb-proxy/ for an
example.
On M
I decided it'd be easier & safer to host squid-deb-proxy in a LXD container
rather than the host. My host doesn't route inbound to LXD from other
networks, and all the Juju machines can see it.
On Tue, Aug 16, 2016 at 12:30 AM, John Meinel
wrote:
> ...
>>
>
>
>> +### tuple ### allow any 8000 0.0
My main use case for killing controllers is development & testing. For
this, I have a script that force deletes all the juju-* LXC containers, and
then unregisters all controllers with cloud: lxd. It's *much* faster than
waiting for each juju controller to tear itself down. It's also nothing I'd
pr
I discovered another trick that works: set the streams and urls to invalid
values in your bootstrap config. This will force Juju to use an already
compiled jujud in your $PATH. For example, bootstrap --config with:
image-metadata-url: http://localhost
image-stream: nope
agent-metadata-url: http://
I'm halfway through my first Github review (different project though) on
the new system, and so far I'm loving it. Also consider the issues we've
had with rbt being unable to handle diffs with files
added/removed/relocated. +1 from me!
-Casey
On Wed, Sep 14, 2016 at 3:23 PM, Reed O'Brien
wrote:
I had pretty high hopes for Github Reviews but Reviews are starting to show
some rough edges.
Comments on prior commits in the PR stick around. They never go away.
Before Juju Reviews, pushing a change would hide old lines, which was bad,
because it was easy to lose track of requests and comments.
+1, as I work on many other Github projects besides Juju and it's familiar.
It's not perfect by any means but I can work with it.
I thought the ReviewBoard we had was pretty ugly and buggy, but it was
reasonably easy to use. Gerrit is cleaner and clearer to me -- though I
feel like Gerrit is also
On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi
wrote:
> On Thu, Dec 1, 2016 at 5:00 AM Adam Collard
> wrote:
>
>> On Thu, 1 Dec 2016 at 04:02 Nate Finch wrote:
>>
>> On IRC, someone was lamenting the fact that the Ubuntu charm takes longer
>> to deploy now, because it has been updated to exercise
On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard
wrote:
> Hi,
>
> The automatic hook retries[0] that landed as part of 2.0 (are documented
> as) run indefinitely[1] - this causes problems as an API user:
>
> Imagine you are driving Juju using the API, and when you perform an
> operation (e.g. set the
^^ s/immutability/idempotency
On Thu, Jan 5, 2017 at 12:39 PM, Casey Marshall <
casey.marsh...@canonical.com> wrote:
> On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard
> wrote:
>
>> Hi,
>>
>> The automatic hook retries[0] that landed as part of 2.0 (are documented
On Fri, Jun 9, 2017 at 12:29 PM, Uros Jovanovic <
uros.jovano...@canonical.com> wrote:
> Quick instructions on how the new azure credentials flow works in Juju
> 2.2-RC2:
>
> # install az client using a snap
> $ sudo snap install azure-cli --classic --edge
>
I've pushed the snap to stable, so you
26 matches
Mail list logo