backward compatibility

[Anastasia Macmood]

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 determine that if your client version differs from
your controller version by:

  * 2 minor versions, you are running a deprecated back-end;
  * 3 minor versions, you are running an obsolete back-end;
  * 4+ minor versions, you are running an unsupported backend.

In this world, it means that when you are running a 2.4 client, you will
be told that the controller on:

  * 2.2 is deprecated;
  * 2.1 is obsolete;
  * 2.0 is unsupported.

This will be surfaced as a warning on 'juju status'.

This approach will allow us to not just retire certain API versions, but
also help triage bugs and set clear user expectations. Additional
benefits for maintenance and support - we will not be carrying around
huge amount of backward compatible code and craft... For example, does
it really makes sense for us to carry around and cater for backward
compatibility with Juju 2.0 when we are developing 2.6?

Thoughts?

Sincerely Yours,

Anastasia


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: developer commands

[Anastasia Macmood]

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 infrastructure, they
> gained access to some useful methods. Thus, eliminating code duplication
> and inconsistencies.
>
> The versions of command, acting as "controller" type commands, that take
> no arguments, indeed exist. Both commands can be used without model
> name, i.e. 'juju dump-model' and 'juju dump-db' are fully formed. These
> versions still work as expected, have not changed and are, in fact,
> verified by existing feature tests.
>
> The change that I have brought up is only applicable to the versions of
> 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 Macmood wrote:
>>> 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 instead of
>>> as a positional argument.
>>>
>>> i.e.
>>> 'juju dump-model -m modelName' NOT 'juju dump-model modelName'
>>> 'juju dump-db -m modelName' NOT 'juju dump-db modelName'
>>>
>>> Happy juju-ing!
>>>
>>> Sincerely Yours,
>>> Anastasia
>>>
>>> [1]
>>> https://github.com/juju/juju/pull/7797
>>>
>>>
>


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: developer commands

[Anastasia Macmood]

Tim,

Completely agree :)

By changing where these commands fit within command infrastructure, they
gained access to some useful methods. Thus, eliminating code duplication
and inconsistencies.

The versions of command, acting as "controller" type commands, that take
no arguments, indeed exist. Both commands can be used without model
name, i.e. 'juju dump-model' and 'juju dump-db' are fully formed. These
versions still work as expected, have not changed and are, in fact,
verified by existing feature tests.

The change that I have brought up is only applicable to the versions of
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 Macmood wrote:
>> 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 instead of
>> as a positional argument.
>>
>> i.e.
>> 'juju dump-model -m modelName' NOT 'juju dump-model modelName'
>> 'juju dump-db -m modelName' NOT 'juju dump-db modelName'
>>
>> Happy juju-ing!
>>
>> Sincerely Yours,
>> Anastasia
>>
>> [1]
>> https://github.com/juju/juju/pull/7797
>>
>>



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Fwd: developer commands

[Anastasia Macmood]

-- 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 will now accept model name as an option instead of
as a positional argument.

i.e.
'juju dump-model -m modelName' NOT 'juju dump-model modelName'
'juju dump-db -m modelName' NOT 'juju dump-db modelName'

Happy juju-ing!

Sincerely Yours,
Anastasia

[1]
https://github.com/juju/juju/pull/7797


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

developer commands

[Anastasia Macmood]

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 instead of
as a positional argument.

i.e.
'juju dump-model -m modelName' NOT 'juju dump-model modelName'
'juju dump-db -m modelName' NOT 'juju dump-db modelName'

Happy juju-ing!

Sincerely Yours,
Anastasia

[1]
https://github.com/juju/juju/pull/7797


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Weekly Development Summary

[Anastasia Macmood]

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 [1] as well non-destructive
storage removal [2] aspects. This effort also led to identifying
improvements in model destruction that are now under way.

We have made considerable progress in improving actions' footprint with
work that prunes action results periodically [3].

As usual, with a week that follows a new release of Juju, we have
provided support to our existing users upgrading to a newer release.

In addition, to excite and expedite developer experience, the team has
put in place an improved merge job! Now developers can with greater ease
track running tests when merging code.

This week, the team has also worked on increasing functional coverage
for persistent storage, relations as well as model migration.

Last but not least, in a "call for arms", we are working on enabling
users to specify primary network on VSphere overwriting the default VM
network specified in OVF files shipped with Ubuntu images [4]. The
nature of VSphere deployments, and the variety of networking
combinations that are useful in the production environments, means that
we need a hand from Juju community to verify our current approach. If
you are interested in the ability to specify network in your VSphere,
try the patch [5] linked in the bug and reach out to us with your feedback!

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

Sincerely Yours,

Anastasia

[1] https://github.com/juju/juju/pull/7653

[2] https://github.com/juju/juju/pull/7648 and
https://github.com/juju/juju/pull/7649

[3] https://github.com/juju/juju/pull/7645

[4] https://bugs.launchpad.net/juju/+bug/1619812

[5] https://github.com/juju/juju/pull/7660



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Weekly Development Summary - and Juju 2.2-rc1 date

[Anastasia Macmood]

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 a few extra
> days for a better quality release was worth it.
>
> On Tuesday we will be branching develop into a 2.2 branch. Also, we are
> enacting a slightly different policy around landing changes into the 2.2
> branch during the RC period. No extra bug fixes will be landed in 2.2
> once the release candidate has been cut unless it is a critical
> regression, in which case another candidate will be released. The
> intention here is that the release candidate will be a true candidate,
> and not just be another week to get fixes in before the final release.
> Once we have confirmation from Solutions QA and JAAS that they are happy
> with the release candidate, we will release is as 2.0.0
2.2.0 maybe?
>  final. Once this
> happens the landing restrictions will be lifted on the 2.2 branch.
>
> We already have a number of bugs that we want to get fixed for 2.2.1.
> Bugs that we have decided need to be fixed and put into the user's hands
> before the 2.3 release, which won't be for a number of months.
>
> The notable fixes of the last week:
>  * a number of race test fixes, Go 1.8 found more than 1.6
>  * long awaited log compression during log rotation
>  * additional configuration around max txn log size so large controllers
> can better handle large workloads happening very quickly
>  * issues with migrating models that use local charms
>
> There are just a couple more changes that we hope to land over the next
> day, that will improve performance on larger models.
>
> Also, the 2.2-rc1 milestone on Launchpad got significantly cleaned up.
> There were bugs that were marked as high priority that had been bounced
> from milestone to milestone with no one addressing them. These have been
> removed from milestones as they just weren't getting addressed that way.
>
> A lot of work has gone into the CI infrastructure this week to make it
> more robust and to produce less noise on the test runs. We are looking
> much better across all the CI tests. There are a few intermittent tests
> still bugging us, and a few CI tests that needed updating due to changes
> that landed over the week. On the whole though, we are very happy with
> the stability and robustness of this upcoming release.
>
> Cheers,
> Tim
>


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Deployment Oversight

[Anastasia Macmood]

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 -> http://paste.ubuntu.com/23551183/
>
> I've created a temporary repo for my prm-web and prm-worker charms
> here -> https://github.com/jamesbeedy/prm-temp (about 6 months of
> curation has gone into these). I'll leave the repo up for the next few
> days, but will have to take it down eventually as these charms are
> CreativeDrive's ip.
>
> Thank you everyone!
>
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deployment Oversight

[Anastasia Macmood]

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 -> http://paste.ubuntu.com/23551183/
>
> I've created a temporary repo for my prm-web and prm-worker charms
> here -> https://github.com/jamesbeedy/prm-temp (about 6 months of
> curation has gone into these). I'll leave the repo up for the next few
> days, but will have to take it down eventually as these charms are
> CreativeDrive's ip.
>
> Thank you everyone!
>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

to symlink or not to symlink?

[Anastasia Macmood]

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]

https://bugs.launchpad.net/bugs/1634390



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reviews on Github

[Anastasia Macmood]

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 because the diff is "too large". Hopefully this will no 
> longer
> be an issue, or else we won't be able to review such changes in the future.
This is perfect to reduce the size of our proposals to manageable :)
>
> On 16/09/16 07:53, Menno Smits wrote:
>> Although I share some of Ian's concerns, I think the reduced moving parts,
>> improved reliability, reduced maintenance, easier experience for outside
>> contributors and better handling of file moves are pretty big wins. The
>> rendering of diffs on Github is a whole lot nicer as well.
>>
>> I'm +1 for trialling the new review system on Github for a couple of weeks
>> as per Andrew's suggestion.
>>
>> On 16 September 2016 at 05:50, Nate Finch  wrote:
>>
>>> Reviewboard goes down a couple times a month, usually from lack of disk
>>> space or some other BS.  According to a source knowledgeable with these
>>> matters, the charm was rushed out, and the agent for that machine is down
>>> anyway, so we're kinda just waiting for the other shoe to drop.
>>>
>>> As for the process things that Ian mentioned, most of those can be
>>> addressed with a sprinkling of convention.  Marking things as issues could
>>> just be adding :x: to the first line (github even pops up suggestions and
>>> auto-completes), thusly:
>>>
>>> [image: :x:]This will cause a race condition
>>>
>>> And if you want to indicate you're dropping a suggestion, you can use :-1:
>>>  which gives you a thumbs down:
>>>
>>> [image: :-1:] I ran the race detector and it's fine.
>>>
>>> It won't give you the cumulative "what's left to fix" at the top of the
>>> page, like reviewboard... but for me, I never directly read that, anyway,
>>> just used it to see if there were zero or non-zero comments left.
>>>
>>> As for the inline comments in the code - there's a checkbox to hide them
>>> all.  It's not quite as convenient as the gutter indicators per-comment,
>>> but it's sufficient, I think.
>>>
>>> On Wed, Sep 14, 2016 at 6:43 PM Ian Booth  wrote:
>>>

 On 15/09/16 08:22, Rick Harding wrote:
> I think that the issue is that someone has to maintain the RB and the
> cost/time spent on that does not seem commensurate with the bonus
 features
> in my experience.
>
 The maintenance is not that great. We have SSO using github credentials so
 there's really no day to day works IIANM. As a team, we do many, many
 reviews
 per day, and the features I outlined are significant and things I (and I
 assume
 others) rely on. Don't under estimate the value in knowing why a comment
 was
 rejected and being able to properly track that. Or having review comments
 collapsed as a gutter indicated so you can browse the code and still know
 that
 there's a comment there. With github, you can hide the comments but
 there's no
 gutter indicator. All these things add up to a lot.


> On Wed, Sep 14, 2016 at 6:13 PM Ian Booth 
 wrote:
>> One thing review board does better is use gutter indicators so as not
 to
>> interrupt the flow of reading the code with huge comment blocks. It
 also
>> seems
>> much better at allowing previous commits with comments to be viewed in
>> their
>> entirety. And it allows the reviewer to differentiate between issues
 and
>> comments (ie fix this vs take note of this), plus it allows the notion
 of
>> marking stuff as fixed vs dropped, with a reason for dropping if
 needed.
>> So the
>> github improvements are nice but there's still a large and significant
 gap
>> that
>> is yet to be filled. I for one would miss all the features reviewboard
>> offers.
>> Unless there's a way of doing the same thing in github that I'm not
 aware
>> of.
>>
>> On 15/09/16 07:22, Tim Penhey wrote:
>>> I'm +1 if we can remove the extra tools and we don't get email per
>> comment.
>>> On 15/09/16 08:03, Nate Finch wrote:
 In case you missed it, Github rolled out a new review process.  It
 basically works just like reviewboard does, where you start a review,
 batch up comments, then post the review as a whole, so you don't just
 write a bunch of disconnected comments (and get one email per review,
 not per comment).  The only features reviewboard has is the edge case
 stuff that we rarely use:  like using rbt to post a review from a
 random
 diff that is not connected directly to a github PR. I think that is
 easy
 enough to give up in order to get the benefit of not needing an
 

Re: Reviews on Github

[Anastasia Macmood]

+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 would close a review but github PR is still active;
as well as the other way around.

RB is also not configured on some of our "external" libraries under
github/juju. So we are not reviewing these proposals either...

Not to mention that we still need to fall back to github to confirm that
there are no conflicts on PRs as RB does not report that.


On 15/09/16 08:22, Rick Harding wrote:
> I think that the issue is that someone has to maintain the RB and the
> cost/time spent on that does not seem commensurate with the bonus
> features in my experience. 
>
> On Wed, Sep 14, 2016 at 6:13 PM Ian Booth  > wrote:
>
> One thing review board does better is use gutter indicators so as
> not to
> interrupt the flow of reading the code with huge comment blocks.
> It also seems
> much better at allowing previous commits with comments to be
> viewed in their
> entirety. And it allows the reviewer to differentiate between
> issues and
> comments (ie fix this vs take note of this), plus it allows the
> notion of
> marking stuff as fixed vs dropped, with a reason for dropping if
> needed. So the
> github improvements are nice but there's still a large and
> significant gap that
> is yet to be filled. I for one would miss all the features
> reviewboard offers.
> Unless there's a way of doing the same thing in github that I'm
> not aware of.
>
> On 15/09/16 07:22, Tim Penhey wrote:
> > I'm +1 if we can remove the extra tools and we don't get email
> per comment.
> >
> > On 15/09/16 08:03, Nate Finch wrote:
> >> In case you missed it, Github rolled out a new review process.  It
> >> basically works just like reviewboard does, where you start a
> review,
> >> batch up comments, then post the review as a whole, so you
> don't just
> >> write a bunch of disconnected comments (and get one email per
> review,
> >> not per comment).  The only features reviewboard has is the
> edge case
> >> stuff that we rarely use:  like using rbt to post a review from
> a random
> >> diff that is not connected directly to a github PR. I think
> that is easy
> >> enough to give up in order to get the benefit of not needing an
> entirely
> >> separate system to handle reviews.
> >>
> >> I made a little test review on one PR here, and the UX was almost
> >> exactly like working in reviewboard:
> https://github.com/juju/juju/pull/6234
> >>
> >> There may be important edge cases I'm missing, but I think it's
> worth
> >> looking into.
> >>
> >> -Nate
> >>
> >>
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Small script to connect to Juju's mongo in LXD

[Anastasia Macmood]

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 be tedious to search through when something is needed.

[1]

https://github.com/juju/juju/wiki/Debugging-Juju


On 28/07/16 12:46, Andrew Wilkins wrote:
> On Thu, Jul 28, 2016 at 12:32 AM John Meinel  > wrote:
>
> Did you intend to attach the script to the email? It does sound
> like something useful. I know when we were investigating at some
> client sites we had a small snippet of a bash function to dig the
> content out of agent.conf and launch mongo with the right options.
> It would be nice to have that in a more official place so it
> doesn't get forgotten.
>
>
> Kapil wrote a plugin for inspecting
> Mongo: https://github.com/kapilt/juju-dbinspect. It's almost certainly
> broken in Juju 2.0. I've found it handy in the past, it'd be good to
> have that brought up to date.
>
> Cheers,
> Andrew
>  
>
> John
> =:->
>
>
> On Wed, Jul 27, 2016 at 6:19 PM, Katherine Cox-Buday
>  > wrote:
>
> I frequently need to connect to Juju's Mongo instance to poke
> around and see if something I've done is having the desired
> effect. Back when we were using LXC, I had a script that would
> pull the password from agent.conf and open a shell. When we
> switched to LXD my script broke, and I never updated it. I
> finally got frustrated enough to modify[1] it, and thought
> others might find this useful for poking around Mongo.
>
> Let me know if you have any suggestions.
>
> --
> Katherine
>
> [1] - http://pastebin.ubuntu.com/21155985/
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Fixing "juju help commands"

[Anastasia Macmood]

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 has bugged me about 'juju help commands' was the
> repeated mentions of "alias for ".
>
> I propose that we don't show aliases by default, and allow the user to
> task for them.
>
> Also, the supercommand describe commands method was written before I
> knew about the tabular output, so some code could be cleaned up there.
>
> Proposal:
>
> juju help commands
>   - shows the commands that are neither aliases, nor hidden
> juju help commands --alias
>   - shows either just the aliases, or everything including aliases
> juju help commands --all
>   - shows basic commands, aliases and hidden commands.
>
> I'd like to add the ability to say a command is hidden so it doesn't
> show up in the commands list. The purpose for these could be debugging
> assisting type functions, like "dump-model" or "debug-controller" (two
> commands that don't yet exist).
>
> Thoughts?
>
> Tim
>


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: adding unit tests that take a long time

[Anastasia Macmood]

Well, now that you ask :D

On 29/04/16 12:10, Nate Finch wrote:
> I don't really understand what you mean by stages of development. 
I mean -  developing a unit of work as opposed to developing a component
as opposing to developing wiring of several components, etc. On top of
that, besides the usual development activities, you'd also need to
include bugs and regression fixes which entail slightly different
mindset and considerations than when you are writing code from scratch.
Let's say "different development activities", if it helps to clear the
mud \o/

So, you'd start developing code by yourself, then your code is
amalgamated with your team, then between teams, etc...
> At the end of the day, they all test the exact same thing - is our
> code correct?  The form of the test seems like it should be unrelated
> to when they are run.
This statement is worthy of a discussion over a drinks :)
Let's start by making a clear distinction - all tests are important to
deliver a quality product \o/ However, there are different types of testing:

unit testing;
component testing;
integration testing (including top-down, bottom-up, Big Bang,
incremental, component integration, system integration, etc);
system testing;
acceptance testing (and just for fun, let's bundle in here alpha and
beta testing);
functional testing;
non functional testing;
functionality testing;
reliability testing;
usability testing;
efficiency testing;
maintainability testing;
portability testing;
baseline testing;
compliance testing;
documentation testing;
endurance testing;
load testing (large amount of users, etc);
performance testing;
compatibility testing;
security testing;
scalability testing;
volume testing (large amounts of data);
stress testing (too many users, too much data, too little time and too
little room);
recovery testing;
regression testing

> Can you explain why you think running tests of different sorts at the
> same time would be a bad thing?
All different types of testing that I have attempted to enumerate are
written at different times and when they are run makes a difference to
efficiency of development processes. They may live in different phase of
SDLC. Focusing on all of these types will improve product quality at the
expense of team(s) momentum as well as will affect individual
developer's habits (and other factors).

When you as a developer work on a task, the most relevant to you would be:
a. unit tests (does this little unit of work do what i want?),
b. integration (does my change work with the rest of the system?),
c. functional (does my work address requirements?).

Depending on your personal development habits, you may only want to run
either unit tests and/or integration and/or functional tests while you
work on your task. Before you add your code to common codebase, you
should make sure that your code is consistent with:
* coding guidelines (gofmt, in our case),
* agreed and recommended coding practices (like the check that you are
adding).
These checks test code for conformity ensuring that our code looks the
same and is written to the highest agreed standard.
 
>
> Note that I only want to "divide up tests" temporally... not
> necessarily spatially.  If we want to put all our static analysis
> tests in one directory, our integration tests in another directory,
> unit tests in the directory of the unit... that's totally fine.  I
> just want an easy way to run all the fast tests (regardless of what or
> how they test) to get a general idea of how badly I've broken juju
> during development.
I understand your desire for a quick turn around.
But I question the value that you would get from running "fast" (short)
tests - would this set include some fast running unit tests, integration
tests and functional tests? Simply because they have been identified as
running quickly on some machines? How would you know if that "fast" run
is comprehensive enough? It sounds to me like you might as well say 
"let's run couple of tests randomly" and rely on these result until you
commit...

I do not know what you will end up doing with your current 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
> <mailto:anastasia.macm...@canonical.com>> wrote:
>
> 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 tests tests behaviour;
> static analysis analyses codebase to ensure conformit

Re: adding unit tests that take a long time

[Anastasia Macmood]

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 tests tests behaviour;
static analysis analyses codebase to ensure conformity to agreed policies.

They all have meaning at different stages of development and to bundle
them based on the running time is to compromise these stages in long-term.

On 29/04/16 05:03, Nate Finch wrote:
> Our full set of tests in github.com/juju/juu
>  takes 10-15 minutes to run, depending on
> the speed of your computer.  It's no coincidence that our test pyramid
> looks more like this ▽ than this △.   Also, we have a lot of tests:
>
> /home/nate/src/github.com/juju/juju/$ 
> grep -r ") Test" . --include="*_test.go" | wc -l
> 9464
>
> About small, medium, and large tests... I think that's a good
> designation.  Certainly 17 seconds is not a small test.  But I /think/
> it qualifies as medium (hopefully most would be faster).   Here's my
> suggestion, tying this back into what I was talking about originally:
>
> Small tests would be those that run with go test -short.  That gives
> you something you can run frequently during development to give you an
> idea of whether or not you really screwed up.  Ideally each one should
> be less than 100ms to run.  (Note that even if all our tests ran this
> fast, it would still take 15 minutes to run them, not including
> compilation time).
>
> Medium tests would also be run if you don't use -short.  Medium tests
> would still be something that an average developer could run locally,
> and while she may want to get up to grab a drink while they're
> running, she probably wouldn't have time to run to the coffee shop to
> get said drink.  Medium tests would be anything more than 100ms, but
> probably less than 15-20 seconds (and hopefully not many of the
> latter).  Medium tests would be run before making a PR, and as a
> gating job.
>
> Long tests should be relegated to CI, such as bringing up instances in
> real clouds.
>
> I don't think it's terribly useful to divide tests up by type of test.
> Who cares if it's a bug found with static analysis or by executing the
> code? Either way, it's a bug.  The only thing that really matters is
> how long the tests take, so we can avoid running slow tests over and
> over.  I run go vet, go lint, and go fmt on save in my editor.  That's
> static analysis, but they run far more often than I actually run
> tests and that's because they're always super fast.
>
> I think we all agree that all of these tests (except for CI tests)
> should be used to gate landings.  The question then is, how do you run
> the tests, and how do you divide up the tests?  To me, the only useful
> metric for dividing them up is how long they take to run.  I'll run
> any kind of test you give me so long as it's fast enough.
>
> On Thu, Apr 28, 2016 at 12:39 PM Nicholas Skaggs
> >
> wrote:
>
> On 04/28/2016 10:12 AM, Katherine Cox-Buday wrote:
> > On 04/27/2016 09:51 PM, Nate Finch wrote:
> >> So, this is exactly why I didn't want to mention the nature of the
> >> test, because we'd get sidetracked. I'll make another thread to
> talk
> >> about that specific test.
> Sorry I forced you into it, but it was important to this discussion. I
> was wanting to understand your feelings towards a test you should be
> running regularly as you develop, aka a unit test, that took more
> than a
> trivial amount of time to actually execute.
> >>
> >> I do still want to talk about what we can do for unit tests
> that take
> >> a long time.  I think giving developers the option to skip long
> tests
> >> is handy - getting a reasonable amount of coverage when you're
> in the
> >> middle of the develop/test/fix cycle.  It would be really
> useful for
> >> when you're making changes that affect a lot of packages and so you
> >> end up having to run full tests over and over.  Of course, running
> >> just the short tests would not give you 100% confidence, but once
> >> you've fixed everything so the short tests pass, *then* you
> could do
> >> a long run for thorough coverage.
> >
> > I believe Cheryl has something like this in the works and will be
> > sending a note out on it soon.
> >
> Yes. It is imperative that developers can quickly (and I mean
> quickly or
> it won't happen!) run unit tests. We absolutely want testruns to be a
> part of the code, build, run iteration loop.
> >> This is a very low friction way to increase developer productivity,
> >> and something we can implement incrementally.  It can also lead to
> >> better 

Re: Unable to kill-controller

[Anastasia Macmood]

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, when I
destroy it, I get notified that "other users are using this
controller... are you sure you want to destroy it?"...

On 07/04/16 07:54, Alexis Bruemmer wrote:
> Any reason why destroy-controller and kill-controller would not also
> remove the local reference (purge-controller)?
>
> On Wed, Apr 6, 2016 at 1:54 PM, Tim Penhey  > wrote:
>
> On 06/04/16 23:13, Nick Veitch wrote:
> > Sure, I am just concerned about a proliferation of commands to
> do the
> > same (ultimately) task
> >
> > destroy-controller
>
> The most correct way to take down a controller.
>
> > kill-controller
>
> The OMG it is broken, please do as much as you can and I know I'm
> going
> to have to manually check any resources left around that it couldn't
> clean up.
>
> > forget/purge-controller
>
> Remove local references to the controller.
>
>
> Not really the same things at all.
>
> Tim
>
>
> >
> >
> >
> > On 6 April 2016 at 11:59, Horacio Duran
> 
> >  >>
> wrote:
> >
> > The issue I see with that approach is that in that case
> > kill-controller might be doing less than you expect instead
> of more,
> > suppose the controller is having transient issues and kill
> > controller cannot reach the cloud for deletion, this would
> forget
> > the controller and leave it in the cloud, forget-controller
> instead
> > tells us very clearly what is going to happen, the change is
> going
> > to be local and not affect the controller.
> > My 2c
> >
> >
> > On Wednesday, 6 April 2016, Nick Veitch
> 
> >  >> wrote:
> >
> > just my tuppence
> >
> > instead of having another command, can't we just add
> this as an
> > option to kill-controller?
> >
> > juju kill-controller --cleanup 
> >
> >
> >
> > On 6 April 2016 at 11:05, Horacio Duran
> >  > wrote:
> >
> >
> > I might be biased by years of apt-get but purge makes me
> > think that you are going to do what kill is supposed
> to do,
> > forget sound more aligned whit what you are really
> aiming to.
> >
> > On Wednesday, 6 April 2016, Andrew Wilkins
> >  > wrote:
> >
> > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
> >  > wrote:
> >
> > Relevant bug:
> > 
> https://bugs.launchpad.net/juju-core/+bug/1553059
> >
> > We should provide a way to clean up controllers
> > without making the user manually edit juju's
> files.
> >
> >
> > Unless anyone objects, or has a better spelling,
> I will
> > be adding a command to do this:
> >
> > juju purge-controller 
> >
> > The command will require a "-y" or prompt for
> > confirmation, like kill-controller. It will not
> attempt
> > to destroy the controller, it will just remove the
> > details of it from the client.
> >
> > (Alternative suggestion for spelling: "juju
> > forget-controller". Purge-controller may suggest
> that
> > we're purging a controller of its contents,
> rather than
> > purging the controller from the client?)
> >
> > Cheers,
> > Andrew
> >
> > On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch
> >  > wrote:
> >
> > This just happened to me, too. 
> Kill-controller
> > needs to work if at all possible. 
> That's the
> > whole point.  And yes, users may not 

Re: Warning: test suite not actually isolated

[Anastasia Macmood]

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 this
second but I am hoping that the bug squad can take it head-on soon \o/

Sincerely Yours,

Anastasia

On 17/03/16 19:43, John Meinel wrote:
> tl; dr: I need some help fixing our tests that are incorrectly not
> isolated from the real world.
>
> So...
>
> In investigating the bug with PatchValue and non pointer receivers, we
> realized that PatchValue calls AddCleanup. Which means that If you are
> doing:
> func ... SetUpSuite() {
>s.PatchValue(, safeFoo)
> }
>
> That PatchValue gets cleaned up in the first TearDownTest().Which
> means that the isolation you thought you were adding to the *Suite* is
> actually isolated only to the first test that gets run.
>
> I have a branch of "juju/testing" that fixes it so AddCleanup can be
> called at any time. If it is called before SetUpTest(), then it adds a
> cleanup to the Suite stack, otherwise it adds it to the current Test
> stack.
>
> But that breaks about 100 tests that weren't as isolated as they
> thought they were.
>
> It also breaks a few tests that were Patching values before calling
> IsolationSuite.SetUpTest/Suite(), eg:
> SetUpTest() {
>   PatchValue()
>   Base.SetUpTest()
> }
>
> My branch that starts working on this is at:
>  g...@github.com:jameinel/juju unsafe-cleanups
>
> One of the big examples of bad tests is "provider/ec2". 52 tests fail
> because they either try to read from cloud-images.ubunt.com
>  directly, or because they try to read
> from test:/streams/v1/index.sjson but don't accept the signature on
> those files.
>
>
> Is anyone able to help me tackle cleaning up our test suite?
>
> Thanks,
> John
> =:->
>
>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

old, untouched PRs

[Anastasia Macmood]

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 that are waiting for Go
1.6. A simple monthly/weekly comment that you are still waiting, will
ensure your PR will be left alive \o/

Our RB list will stay healthy and current if we review it during team calls.

Sincerely yours,

Anastasia

 


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: "environment" vs "model" in the code

[Anastasia Macmood]

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 all know that this is
ahopeful list and there are complexities. So, whether all these renames
will land in this Iteration or not can only be determined once we start
rolling \o/

To minimise conflicts, I'd second suggestion to have all new work to
have "model" and not to touch existing functionality... Yes, there will
be "inconsistencies" \o/ BUT, if all goes well, the inconsistencies will
be short-lived (/me crosses fingers)

Sincerely Yours,

Anastasia

PS. Please notice the big BUT :D

On 18/01/16 10:35, Menno Smits wrote:
> +1 to what Roger said. New features always require changes to existing
> code so inconsistency is unavoidable if we take a piecemeal approach.
>
> Given that a big rename is planned at some point, and that renaming
> can be largely automated, continuing to use "environment" internally
> until the big rename happens may make more sense in terms of
> maintainability.
>
> Thoughts?
>
>
>  
> On 15 January 2016 at 21:05, roger peppe  > wrote:
>
> On 15 January 2016 at 06:03, Ian Booth  > wrote:
> >
> >
> > On 15/01/16 10:16, Menno Smits wrote:
> >> Hi all,
> >>
> >> We've committed to renaming "environment" to "model" in Juju's
> CLI and API
> >> but what do we want to do in Juju's internals? I'm currently adding
> >> significant new model/environment related functionality to the
> state
> >> package which includes adding new database collections, structs and
> >> functions which could include either "env/environment" or
> "model" in their
> >> names.
> >>
> >> One approach could be that we only use the word "model" at the
> edges - the
> >> CLI, API and GUI - and continue to use "environment"
> internally. That way
> >> the naming of environment related things in most of Juju's code and
> >> database stays consistent.
> >>
> >> Another approach is to use "model" for new work[1] with a hope
> that it'll
> >> eventually become the dominant name for the concept. This will
> however
> >> result in a long period of widespread inconsistency, and it's
> unlikely that
> >> things we'll ever completely get rid of all uses of "environment".
> >>
> >> I think we need arrive at some sort of consensus on the way to
> tackle this.
> >> FWIW, I prefer the former approach. Having good, consistent
> names for
> >> things is important[2].
> >>
> >
> > Using "model" for new work is the correct approach - new chunks
> of work will be
> > internally consistent with the use of their terminology. And we
> will be looking
> > to migrate existing internal code once we tackle the external
> facing stuff for
> > 2.0. We don't want to add to our tech debt and make our future
> selves sad by
> > introducing obsoleted terminology for new work.
>
> The other side of this coin is that, as Menno says, now the code base
> will be harder to read because it will be inconsistent throughout (and
> not consistently inconsistent either, because the new work is bound to
> cross domain boundaries).
>
> Given that it's not hard to make automated source code changes in Go
> (given gofmt, gorename, gofix etc), I wonder if doing it this way
> might
> just be making things harder for people maintaining the code without
> actually making things significantly easier in the long run.
>
>   cheers,
> rog.
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Reviewed proposals against juju/juju

[Anastasia Macmood]

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 should have been merged or updated or abandoned and closed. As
authors, could you please clean up your proposals?

Let's keep our review list current and relevant :D

Sincerely Yours,

Anastasia


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: What are blocks ?

[Anastasia Macmood]

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 Yours,

Anastasia

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New charms client

[Anastasia Macmood]

Hi Kapil

It is great to hear that you are exercising new Charms and Annotations
clients!

Both are definitely enabled and have never been behind a feature flag.

As per bug https://pad.lv/1414027 - thank you logging it! - full stack
tests for Charms client and other features, are located in
github.com/juju/juju/featuretests. These tests are run as part of our
landing process, so we know that these clients work.

Latest changes in the trunk, however, include changes to how client
facades are called and these could be affecting your calls. Tim and his
team may shed more light on this and have 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...@canonical.com
 Cc: juju-dev@lists.ubuntu.com juju-dev@lists.ubuntu.com
 Subject: Re: New charms client
 Message-ID:
   caccj7wvx1ryeg_z1zxj8o+yyeas0y182265gykcv3ij+hdr...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 I'm having some problems actually using this api, is it enabled? or does it
 need a feature flag?

 return self.rpc._rpc({
 Type: Charms,
 Request: List,
 Params: {Names: names}})

 gets

 jujuclient.EnvError: Env Error - Details:
  {   u'Error': u'unknown object type Charms',
 u'ErrorCode': u'not implemented',
 u'RequestId': 1,
 u'Response': {   }}

 same code works for every other facade, using a trunk checkout. I do see
 the Charms facade in the login data, ie.


 {u'EnvironTag': u'environment-fb933e3d-5293-486a-8ff9-7ac565271c35',
  u'Facades': [{u'Name': u'Action', u'Versions': [0]},
   {u'Name': u'Agent', u'Versions': [0, 1]},
   {u'Name': u'AllWatcher', u'Versions': [0]},
   {u'Name': u'Annotations', u'Versions': [1]},
   {u'Name': u'Backups', u'Versions': [0]},
   {u'Name': u'CharmRevisionUpdater', u'Versions': [0]},
   {u'Name': u'Charms', u'Versions': [1]},


 On Mon, Jan 19, 2015 at 1:59 AM, Anastasia Macmood 
 anastasia.macm...@canonical.com wrote:

 Hi

 I have just landed a new charms client.

 This client can list charms.

 The intention is to have a dedicate charms client for 1.23, deprecating
 old client. However, at the moment the only ported method from old
 client is CharmInfo.

 Sincerely Yours,

 Anastasia

 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev

 -- next part --
 An HTML attachment was scrubbed...
 URL: 
 https://lists.ubuntu.com/archives/juju-dev/attachments/20150123/a4ba4f35/attachment-0001.html

 --




-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New annotation client

[Anastasia Macmood]

Hi Adam

Thank you for your question!
Your call for the new client will look like this :

Annotations Set Annotations=[

(EntityTag=$entityType-$entityId), Annotations=[($key1, $value1), ($key2, 
$value2)...]),

(EntityTag=$entityType-$entityId), Annotations=[($key3, $value3), ($key4, 
$value4)...])

...

]

Sincerely Yours,

Anastasia

On 12/01/15 19:31, Adam Collard wrote:
 Hi Anastasia,

 Could you give some clues as to what API changes (if any) will come with
 this change?

 Our current usage looks something like:

 Client SetAnnotations Tag=$entityType-$entityId Pairs=[($key1, $value1),
 ($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 as well
 as environment, machine, service and unit previously done through our old
 client.
 New annotations client also supports bulk calls.

 For the SET annotations call that looks similar to this:

 ..{
 Type: Annotations,
 Request: Set,
 Params: {
  Annotations: {{
 Entity: a, Annotations: pairs1
   },{
 Entity: b, Annotations: pairs2
   }}
 }}..

 corresponding GET annotations call may look like:

 ..{
 Type: Annotations,
 Request: Get,
 Params: {
  Entities: {{
 Tag: a},{
 Tag: b}}
 }}..

 Returning

 {
 Results: {
   {Entity: a, Annotations: pairs1, Error: nil},
   {Entity: b, Annotations: pairs2, Error: nil},

 }

 }

 Note that where SET call returns an error, Error in GET call return is
 params.ErrorResult.





 --
 Juju-dev mailing list
 Juju-dev@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev