ld be on the destination controller, isn't it?
<menn0> the auth details will in fact be the same for the migration case
<babbageclunk> menn0: ah, ok
<menn0> actually... they probably will be
<menn0> not guaranteed
 * menn0 ponders
<babbageclunk> so how can I find what macaroons should be attached to the login request? At the moment nothing gets passed.
<menn0> babbageclunk: macroons will already get attached if there are some
<menn0> babbageclunk: but the admin user won't have any, it'll be using username/password
<babbageclunk> menn0: How would I have gotten macaroons? If it'd been registered instead of being admin? I can check that.
<menn0> babbageclunk: yes, when juju register is used you get a macaroon
<babbageclunk> ok, I'll try that.
<menn0> babbageclunk: there's also a way to switch the admin user to macaroons, via "juju login" I think
<babbageclunk> I mean, I guess we need to solve the other problem too, but it'd be good to see it working with macaroons
<menn0> babbageclunk: yeah and i'm not sure what the right answer is for the user/password case
<menn0> babbageclunk: we don't necessarily want to sending off passwords to arbitrary controllers
<menn0> maybe it's ok...
<axw> babbageclunk: also if you use "juju change-user-password", your initial password is cleared and you get a macaroon
<menn0> axw: thanks. I was trying to remember the trick you've mentioned before
<axw> anastasiamac: teeny weeny review please: https://github.com/juju/juju/pull/6535
<axw> fixes 3 openstack bugs
<menn0> babbageclunk: the more I think about it, the more I think using the username and password, if they were provided originally is probably ok
<babbageclunk> axw: thanks - annoyingly the sequence of things I tried seems to have left me in an unrecoverable state, other than blowing away the lxcs for my dest controller.
<menn0> babbageclunk: not ideal but ok
<menn0> babbageclunk: I just saw this: // TODO(rog) update cached model addresses.
<menn0> babbageclunk: that'll need to be taken care of now
<babbageclunk> menn0: yes - was 