Re: full functional tests for API methods
https://docs.google.com/a/canonical.com/document/d/1hXAOBVpM8o--9L7GOb4r6NUaloZQ8BsWj8W-Bqpznpw/edit?usp=sharing is about how CI is set up today, and how to add more tests there. John =:-> On Tue, Jul 22, 2014 at 7:10 PM, Eric Snow wrote: > On Tue, Jul 22, 2014 at 8:17 AM, Eric Snow > wrote: > > Yep. For my case (backup/restore) we have a "good enough" solution > already. > > Incidentally, do we have documentation somewhere on CI tests (e.g. > backup/restore)? Specifically, where are they, how do they work, and > how do you install them? > > -eric > > -- > 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: Specific configuration on network-bridge interface
On Wed, Jul 23, 2014 at 7:29 AM, Jorge Niedbalski <
jorge.niedbal...@canonical.com> wrote:
> Hello,
>
> I need some pointers regarding to provide a Fix for bug LP:
> https://bugs.launchpad.net/juju-core/+bug/1341524 , as you can see a
> user is experiencing problems to boot up a new environment cleanly
> when some specific network configuration is used, on this case a
> bonding setup configured using a preseed file on the same interface
> declared for the network-bridge option.
>
> Some clues points to the ('ifdown %s', network-bridge) command
> performed on the cloud-init stage. So, i am wondering why this was
> introduced in favor of the previous 'service networking restart' as
> you can see performing a git diff -r 411dbff4^!
>
Because https://bugs.launchpad.net/maas/+bug/1248283
("service networking restart" kills dbus)
> If somebody has a clue, would be very helpful.
>
> --
> Jorge Niedbalski R.
> Software Sustaining Engineer @ Canonical
> Canonical Technical Services Engineering Team
> # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544)
> # Phone: +56976670504
> # Launchpad: ~niedbalski | IRC: niedbalski | gtalk: niedbalski
>
> --
> 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
Specific configuration on network-bridge interface
Hello,
I need some pointers regarding to provide a Fix for bug LP:
https://bugs.launchpad.net/juju-core/+bug/1341524 , as you can see a
user is experiencing problems to boot up a new environment cleanly
when some specific network configuration is used, on this case a
bonding setup configured using a preseed file on the same interface
declared for the network-bridge option.
Some clues points to the ('ifdown %s', network-bridge) command
performed on the cloud-init stage. So, i am wondering why this was
introduced in favor of the previous 'service networking restart' as
you can see performing a git diff -r 411dbff4^!
If somebody has a clue, would be very helpful.
--
Jorge Niedbalski R.
Software Sustaining Engineer @ Canonical
Canonical Technical Services Engineering Team
# Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544)
# Phone: +56976670504
# Launchpad: ~niedbalski | IRC: niedbalski | gtalk: niedbalski
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: full functional tests for API methods
On Tue, Jul 22, 2014 at 8:17 AM, Eric Snow wrote: > Yep. For my case (backup/restore) we have a "good enough" solution already. Incidentally, do we have documentation somewhere on CI tests (e.g. backup/restore)? Specifically, where are they, how do they work, and how do you install them? -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: full functional tests for API methods
On Mon, Jul 21, 2014 at 3:08 PM, Eric Snow wrote: > Ideally the > test would create an LXC into which it would bootstrap. Then the test > would set up the environment however it needed before running the API > client method against that environment. I imagine that this could be > addressed with something similar to a local provider but where the > master is also in an LXC (and the kinks with that are worked out). > From what I understand there has been some discussion on this already. > How hard would it be to do this? While I doubt we could justify near-term work on it, what are your thoughts on this part of my original post? -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: full functional tests for API methods
On Mon, Jul 21, 2014 at 5:56 PM, Mark Ramm-Christensen (Canonical.com) wrote: > I would like to propose that we *tag* tests as small, medium, or large. > > Small tests are measured in millisecionds, medium are measured in seconds up > to a minute, and large are measured in minutes or hours > +1 > We should run small tests locally, all the time. Medium tests should gate > commits. Large tests should be run on a periodic basis, hourly, daily our > whatever is required to catch errors on a regular basis. > > I think we have mechanisms to run all three sets of tests. The CI folks > have stuff to create environments and /do things/, we have local test > running, and we have both commit level testing, and periodic CI tests. Good point. I'd still like to be able to run all the tests at my desk if I need to, but certainly concede that the utility of that probably doesn't outweigh the cost given our current priorities and resources. :P > > What we don't yet have is clear definition on where various tests belong, > and how to add them. Nor do we have a clear way to mark tests in the unit > test suite as "medium" so that developers can have a very fast set of tests > to run, Yeah, though I do like Nate's suggestion. We'd just have to be consistent. > and we don't have so much backpressure on adding "more expensive" > tests. Yep. For my case (backup/restore) we have a "good enough" solution already. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: full functional tests for API methods
FYI, it's trivial to add build tags to test files and put slower tests in separate files that only build when requested. At the top of files with large tests add // +build large At the top of files with medium tests, add // +build medium large All the rest of the tests need no changes. Then, if you do go test it'll run just the small tests. If you do go test -tags medium It'll run the medium and small tests. and if you do go test -tags large It'll run all the tests. On Mon, Jul 21, 2014 at 7:56 PM, Mark Ramm-Christensen (Canonical.com) < mark.ramm-christen...@canonical.com> wrote: > I would like to propose that we *tag* tests as small, medium, or large. > > Small tests are measured in millisecionds, medium are measured in seconds > up to a minute, and large are measured in minutes or hours > > We should run small tests locally, all the time. Medium tests should > gate commits. Large tests should be run on a periodic basis, hourly, > daily our whatever is required to catch errors on a regular basis. > > I think we have mechanisms to run all three sets of tests. The CI folks > have stuff to create environments and /do things/, we have local test > running, and we have both commit level testing, and periodic CI tests. > > What we don't yet have is clear definition on where various tests belong, > and how to add them. Nor do we have a clear way to mark tests in the unit > test suite as "medium" so that developers can have a very fast set of tests > to run, and we don't have so much backpressure on adding "more expensive" > tests. > We've been working on adding a backup method to the API client. One > test I wanted to add was a functional test that did no patching > anywhere. Such an end-to-end test would give us more confidence in > the API method. We currently have something like that for > backup/restore, but only as a CI test running on jenkins. > > As I understand it, there are two roadblocks to getting such a > functional test in our test suite: > > 1. such a test would drastically slow down our other tests; > 2. we don't have an easy way to set up a clean full environment > against which to run the test, > > Solving the first should be as simple as only running the test when > some env variable is set (e.g. JUJU_TESTING_INCLUDE_SLOW). > > However, solving the second roadblock isn't so trivial. Ideally the > test would create an LXC into which it would bootstrap. Then the test > would set up the environment however it needed before running the API > client method against that environment. I imagine that this could be > addressed with something similar to a local provider but where the > master is also in an LXC (and the kinks with that are worked out). > From what I understand there has been some discussion on this already. > How hard would it be to do this? > > While my interest is specifically for backup/restore, I imagine that > other API client methods (and perhaps other parts of juju) would > benefit from the above functionality. > > Thoughts? > > -eric > > -- > 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
