auto-upgrading models

[Eric Snow]

In a recent bug I was working on the issue of auto-upgrading models
came up.  I also ran into this personally not too long ago.
Currently, running "juju upgrade-juju -m admin --upload-tools"[1]
upgrades the admin model to a new version.  To set the version of any
other model to the uploaded one, you must do so separately afterward,
e.g. "juju upgrade-juju -m default 2.0-rc1.3". [2]

The fact that you must upgrade the non-admin model separately is
something new with multi-model support.  Perhaps it is only something
that will throw off folks that have relied on --upload-tools
previously and perhaps it is something that we'll just adjust to.
However, I wanted to bring the matter up here and identify potential
courses of action (not all mutually exclusive):

1. do nothing (rely on users to know to always upgrade juju per-model)
2. clearly point this out in the documentation
3. add a note in the output of "juju upgrade-juju --upload-tools"
reminding admins to manually upgrade each model
4. make the "juju is out-of-date" warnings also show up for models
relative to the controller
5. auto-upgrade models when the controller is upgraded
6. auto-upgrade but have a flag to not auto-upgrade
7. have a flag to auto-upgrade

FWIW, I don't consider #1 or #5 to be acceptable options.  I'm on the
fence about #6; it aligns with what I expect would be a better default
experience but hesitate to make unrequested changes of that sort by
default.  So #7 might be more appropriate if the consequences of #6
would be too risky.  Regardless, I do think the user experience of
upgrade-juju could be improved.

Thoughts?

-eric


[1] You can no longer upload tools to any other model than admin.
[2] Thankfully, due to some recent work by axw the new version is
*available* to all models.

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

two new helpers in github.com/juju/testing

[Nate Finch]

I added a couple new helpers to the testing repo that I think will help us
avoid some of the contortions we have had to do in the past when testing
executables and output on stderr/stdout.

The first is a fairly simple function, CaptureOutput
, which takes in a
func() and returns anything written to stderr or stdout while running that
function.  It temporarily replaces os.Stderr and os.Stdout with files on
disk while running the function (necessary because those two values are
*os.File values, so, rather hard to mock out with anything in-memory).

The second is slightly more complicated - PatchExecHelper


We had PatchExecutable, which creates gnarly bash/batch scripts on disk to
replace expected executables, but it has a few weaknesses - it doesn't
allow you to test the arguments passed to it *and* test stderr/stdout at
the same time, it assumed the thing you were patching out was on the PATH,
and I'm pretty sure it wouldn't work to patch out .exe files on Windows.

PatchExecHelper fixes all of those problems by approaching the problem in a
different way, it creates a function that is intended to mock out a call to
exec.Command.  It's very easy to use, just embed PatchExecHelper in your
test suite, and then use its GetExecCommand() method to get a function that
can be used to mock out exec.Command.

The exact method of how it works is detailed in the godoc, and it's an
example implementation of something I blogged about a while back:
https://npf.io/2015/06/testing-exec-command/

Here's an example of how it can be used:

// production code
var execCommand = exec.Command
func Run(command string, args ...string) ([]byte, error) {
return execCommand(command, args...).CombinedOutput()
}

// test code
type RunSuite struct {
testing.CleanupSuite

// you *must* embed PatchExecHelper in your test suite.
testing.PatchExecHelper
}

func (s RunSuite) TestRun(c *gc.C) {
outArgs := make(chan []string, 1)
f := s.GetExecCommand(testing.PatchExecConfig{
Stderr: "this is stderr!",
Stdout: "this is stdout!",
ExitCode: 5,
Args: outArgs,
})
s.PatchValue(&execCommand, f)

output, err := Run("echo", "hello world!")
args := <-outArgs
// test output, args, etc.
}

Let me know if you have any questions or comments.
-Nate
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

a few notes on common windows breaking mistakes.

[Horacio Duran]

Hello all, this past week I have spent some time fixing Wintows tests for
go 1.6, many errors where caused by http being more strict on what it will
take on a Get and therefore many innocent mistakes often made in tests
where suddenly not so innocent, so just as a friendly reminder.

* Always join paths with filepath.Join,
* if you want to represent a fake absolute path, don't just append "/"
either try to obtain current root/drive letter or make them into a
conditional variable that uses ":" for windows and "/" for
the rest
* don't craft File URLs (file://) by hand, for this there is
utils.MakeFileURL that has a different implementation for windows and linux
paths. many errors where caused by stuff like: "file://" + aRandomPath +
"/tools" which is a combination of this point and the previous one.

Hope this reminder helps.
Cheers
--
Horacio
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev