Hi
Now that we are settled on Juju 2, going forward we need to have a way
to retire older minor versions in a user-friendly manner.
We propose to use client/server version comparison to flag retiring
versions in 3 distinct steps - deprecated, obsolete and unsupported.
For example, we can
Furthermore, if you are seeing any problems with these commands or if
you *think* that they no longer behave as per your expectations, let me
know :D
On 28/08/17 21:18, Anastasia Macmood wrote:
> Tim,
>
> Completely agree :)
>
> By changing where these commands fit within command
f
commands that were passing in a model name.
Anastasia
On 28/08/17 19:16, Tim Penhey wrote:
> FYI, the developer commands were originally designed like the controller
> commands.
>
> You don't say "juju destroy-model -m foo".
>
> Tim
>
> On 28/08/17 19:48, Anastasia
-- Here is un-encrypted version \o/ --
Hi
Just a quick note for developers that use developer commands.
'juju dump-model' and 'juju dump-db' are changing on develop tip [1],
from 2.3.x.
These commands are now fully-fledged model commands as they were
originally designed.
This means that they
Hi
Just a quick note for developers that use developer commands.
'juju dump-model' and 'juju dump-db' are changing on develop tip [1],
from 2.3.x.
These commands are now fully-fledged model commands as they were
originally designed.
This means that they will now accept model name as an option
Hi
A quick update on what keeps us, Juju team, busy...
This week the team has been busy with an important task of improving
developer experience in addition to improving the product.
Of course, we have continued highly desired work on persistent storage
with this week's focus on storage import
On 02/06/17 15:11, Tim Penhey wrote:
> Hi all,
>
> Sorry for the weird encrypted one.
>
> The date for the release candidate is Tuesday the 6th of June. We really
> wanted to get it out this week, but we hit two issues that we just had
> to get done before the release candidate. We decided that
On 29/11/16 11:26, James Beedy wrote:
> Just wanted to let everyone know (thanks to lots of help) that I've
> rendered a successful manual provider deploy :-)
\o/
> This will be my first production deploy for CreativeDrive, you can
> take a peek at the success here ->
On 29/11/16 11:26, James Beedy wrote:
> Just wanted to let everyone know (thanks to lots of help) that I've
> rendered a successful manual provider deploy :-)
\o/
> This will be my first production deploy for CreativeDrive, you can
> take a peek at the success here ->
Hi
There is a nice, yummy bug [1] with respect to change in Juju behavior,
possibly related to changes when systemd support was added, where we
started symlinking to /var/lib/juju/init & /etc.
Simple solution seems to be stop symlinking \o/ Thoughts?
Sincerely Yours,
Anastasia
[1]
On 16/09/16 08:02, Ian Booth wrote:
> Another data point - in the past, when we have had PRs which touch a lot of
> files (eg change the import path for a dependency), review board paginates the
> diff so it's much easier to manage, whereas I've seen github actually truncate
> what it displays
+1 on moving away from RB \o/
Currently contributors need to allow RB to run against their github
fork, if they don't then we do not see their contributions on RB and PRs
go un-reviewed and seem ignored.
Communication between github and RB is not optimal: we had plenty of
instances where RB
We have started putting useful information and similar handy scripts on
juju/wiki [1].
It'd be nice to grow this knowledge base and have this information in
one central area - easier to maintain/keep current.
Mailing lists are a nice way of communicating new and interesting
information but can
Tim
If you are adding the ability to specify commands as "hidden", we may
greatly benefit from specifying commands as "blockable" too
Sincerely Yours,
Anastasia
On 24/05/16 14:19, Tim Penhey wrote:
> Hi folks,
>
> More from the "let's fix the output" school of thought.
>
> One thing that
nt dilemma. I
second Andrew's suggestion as well \o/
Developing short/long test distinctions and special processing for the
tests that we maintain seems like a waste of our effort.
>
> On Thu, Apr 28, 2016 at 5:24 PM Anastasia Macmood
> <anastasia.macm...@canonical.com
> <m
For what it's worth, to distinguish between tests based on the times
they take to run is borderline naive. Meaningful distinction is what the
test tests :D
Unit test checks that unit of work under testing is doing what is expected;
integration tests tests that we play well together;
functional
I am guessing that we have already covered the other side of destroying
controllers
1. If I am using someone else's controller and the admin of this
controller destroys it, I get notified and I know I need to "purge" it
2. If I am an admin of the controller that other users are using,
John
Thank you for discovering and working on this!
This sounds like an awful can of worms and should be addressed in a
dedicated manner.
I'll add it to the tech debt board and bug squad board with a reference
to your branch.
I am not sure that anyone on core has a capacity to tackle it right
Hi
In our last team meeting, we have decided that we will be removing all
untouched PRs in RB that are older than a month.
Please ensure that all PRs that are important to you are either
hand-held to completion or receive regular progress comments.
For example, there are some PRs in the queue
Menno
Ian is traveling, so the renaming discussion will take place when he is
back online full-time - most likely Wednesday for us...
Renames scheduled for this iteration are:
* CLI;
* user facing text;
* api facades [methods and parameter names].
This is scheduled for this Iteration but we
Hi
Please review list of your proposals on RB :D
While doing reviews today, I have noticed that we have several reviewed
proposals that are older than 2 weeks.
Some of these may have a legitimate reason to be this weathered - they
are against feature branches or do not have ShipIt...
Others
Hi Dave
Blocks protect environment from accidental corruption by blocking some
operations.
Here is the spec
https://docs.google.com/a/canonical.com/document/d/1XFYlNGmQH7-X68IXhdxsANwHN6DgAL_RMn7IDK7ZbJc/edit#heading=h.ap4vrey3xxh6
Let me know if I could be of further assistance :D
Sincerely
a resolution for the behaviour
you are observing in your environment :)
Sincerely Yours,
Anastasia
On 24/01/15 22:00, juju-dev-requ...@lists.ubuntu.com wrote:
Date: Fri, 23 Jan 2015 10:32:40 -0500
From: Kapil Thangavelu kapil.thangav...@canonical.com
To: Anastasia Macmood anastasia.macm
),
($key2, $value2)...]
Thanks,
Adam
On 12 January 2015 at 00:41, Anastasia Macmood
anastasia.macm...@canonical.com wrote:
A new annotations client is available from 1.22 effectively deprecating
annotations in old client.
New annotations client provides functionality to annotate charms
24 matches
Mail list logo
