[01:31] <redir> thumper: yt?
[01:32] <thumper> yep
[01:44] <redir> that test bit is a fake, it doesn't really matter what it returns. The actuall code that does that work is in container/kvm
[01:45] <thumper> redir: I trust you to make a good call
[01:45] <thumper> do what you think is right
[01:45] <redir> I'll update the code to use nonsense names and not depend on runtime since it is a fake to let the Initialiser complete so the rest of the suite will passa
[01:45] <thumper> ok
[01:52] <redir> crap maybe I'm wrong
[01:52] <redir> me looks harder
[02:05] <redir> brb
[03:53] <redir> back for a few
[09:52] <hoenir> Hi guys, other than "--debug" option there is anything that triggers the output to be more "verbose" ?
[09:53] <hoenir> ?
[09:54] <hoenir> anyone?
[09:54] <hoenir> can provide some insight?
[09:58] <macgreagoir> hoenir: Not that I know of. You can up the logging levels on the machines/units though. Take a look at `model config`.
[10:00] <babbageclunk> hoenir: You can also get a lot more logging out during the bootstrap process by setting JUJU_LOGGING_CONFIG, eg:
[10:01] <hoenir> Thanks, I'm already aware of that option. I thought that there is more than this, some special flag hidden in the cmd that I'm not aware already.
[10:01] <hoenir> the JUJU_LOGING_CONFIG tirggers the ctx.Verbose flag to be true?
[10:02] <babbageclunk> hoenir: I don't think so -  the --verbose flag does that.
[10:03] <babbageclunk> hoenir: hang on, what I was saying was: `JUJU_LOGGING_CONFIG="<root>=TRACE" juju bootstrap ...`
[10:03] <hoenir> babbageclunk, I will try now this.
[10:04] <babbageclunk> so setting the env var before bootstrapping (or other command) will show more logging from the client
[10:04] <babbageclunk> which might be useful if you're interested in --verbose
[10:05] <hoenir> simple just like this ? JUJU_LOGGING_CONFIG="<root>=TRACE"
[10:05] <babbageclunk> hoenir: yes, and then the command.
[10:05] <babbageclunk> hoenir: oh, are you on linux or windows?
[10:06] <hoenir> linux amd64-arch linux.
[10:06] <babbageclunk> hoenir: actually I
[10:06] <babbageclunk> oops
[10:06] <hoenir> Actually what?
[10:06] <hoenir> :))
[10:06] <babbageclunk> hoenir: no, it was a half-thought and I meant to delete it.
[10:07] <babbageclunk> dumb laptop keyboard ;)
[10:07] <hoenir> I forgive your keyboard.
[10:08] <hoenir> Tell him/her to not worry.
[10:08] <hoenir> ^_^
[10:08] <hoenir> and thanks for the advice.
[10:08] <babbageclunk> so setting that env var using export and then running the command should do it, or prefixing the command with the assignment.
[10:08] <babbageclunk> my pleasure - hope it helps!
[10:10] <babbageclunk> oops - bedtime!
[10:10]  * babbageclunk bedtimes
[10:41] <perrito666> morning jujuers
[11:06] <junaidali> Hi guys, I'm trying to restore a failed juju controller. I have created a new controller and running the command 'juju restore-backup -b --file=juju-backup-20170110-092916.tar.gz'
[11:06] <junaidali> but it is erroring out with the message 'ERROR old bootstrap instance ["bootstrap:6tdgfk"] still seems to exist; will not
[11:07] <junaidali> replace'
[11:07] <junaidali> I'm following this doc->https://jujucharms.com/docs/2.0/controllers-backup. Am I missing anything here?
[11:08] <junaidali> On deleting all existing controllers, commands outputs: empty controller name not valid
[11:08] <junaidali> command*
[11:22] <perrito666> junaidali: restore -b needs the controller to be gone, you can do that by killing it in your cloud controller
[11:23] <perrito666> junaidali: it is intended to be used when the controller is fully gone (usually died on its own)
[11:23] <perrito666> I advice you to do this
[11:25] <junaidali> perrito666: I have killed all the controllers but now the error is 'empty controller name not valid'
[11:28] <perrito666> junaidali: how exactly did you kill the controllers if I may ask?
[11:33] <junaidali> juju kill-controller <controller-name>
[11:34] <perrito666> ah there lies the problem
[11:34] <perrito666> junaidali: backup is intended to restore a fallen controller, so for instance, lets say you have an lxd juju
[11:34] <perrito666> if you go and lxc delete --force controller
[11:34] <perrito666> you end up with a headless juju
[11:35] <perrito666>  in that case a backup would give you back a controller
[11:35] <perrito666> if you kill controller, you kill the environment
[11:35] <junaidali> oh :(
[11:35] <perrito666> sorry :(
[11:36] <junaidali> no issues, it was a test setup. Thanks, I will be careful next time :)
[11:36] <perrito666> junaidali: yay, better this happening on test setups
[11:37] <perrito666> junaidali: in any case you can also restore a backup into the working controller but that is not the preferred way
[11:37] <perrito666> ask around if you have more doubts, ill be here all day
[11:37] <junaidali> perrito666: thanks, much appreciated.
[12:46] <perrito666> anyone knows in depth how upgradeStepsGate
[14:31] <natefinch> voidspace: so, I seem to have that change working with lxd.... but I'm not entirely sure how to test that the constraints are actually applied
[15:10] <natefinch> tych0: how can I test that my lxd limits are applied correctly?  i.e. 2GB RAM
[15:10] <perrito666> natefinch: compile juju inside lxc
[15:11] <natefinch> lolol
[15:14] <SimonKLB> whats the current status on how the primary ip is "chosen" for a machine in juju? last i checked it was kind of arbitrary when you have multiple interfaces on the machine
[15:15] <SimonKLB> has there been any recent discussions on that topic?
[15:15] <perrito666> SimonKLB: afaik it chooses one of the public ones but sort of randomly (ie, there is no predefined order)
[15:15] <perrito666> SimonKLB: perhaps voidspace can answer better
[15:17] <SimonKLB> yea, it would be nice to have a way to force it to choose one of them, for example, i have a maas setup where each machine have 2 nics, and i'd like one of them to be an internal network while the other the public one
[15:17] <SimonKLB> right now there doesnt seem to be a way to guarantee that the nic i use as the public one becomes the primary in juju
[15:17] <perrito666> SimonKLB: I see, I presume the ips are both "public" or both "private" ?
[15:17] <SimonKLB> one public and one private
[15:18] <perrito666> SimonKLB: I believe spaces should provide you with a solution for that I am not sure what is the working status of that for maas to be honest
[15:18] <perrito666> natefinch do you?
[15:19] <natefinch> spaces are supposed to do that, I think
[15:21] <SimonKLB> are maas spaces and juju spaces one and the same?
[15:21] <natefinch> for maas, yes, I believe so
[15:21] <perrito666> brb, lunch while bootstraping
[15:21] <perrito666> natefinch: SimonKLB I would not be so sure
[15:22] <perrito666> there is some overlapping in the definition but something tells me that juju spaces might be a bit more encompassing
[15:22] <perrito666> frobware: ?
[15:22] <natefinch> hmm, possibly
[15:23] <frobware> SimonKLB: your desire for "internal and public" would be met by spaces
[15:24] <SimonKLB> frobware: and would that be defined in maas or in juju, or both?
[15:24] <SimonKLB> because i see that both maas and juju have spaces
[15:25] <SimonKLB> not sure if they are directly translated from the provider to juju or if it's something that you define separately
[15:26] <frobware> SimonKLB: define your spaces in MAAS. That's your definitive network setup/topology. Juju will learn of the spaces on bootstrap. From there you can use do: https://jujucharms.com/docs/2.0/charms-deploying#deploying-with-binding
[15:26] <SimonKLB> frobware: thanks!
[15:27] <SimonKLB> oh and btw, what decides what is going to be the primary ip and not?
[15:27] <frobware> SimonKLB: You can also use spaces (i.e., their names) in provisioning machines.
[15:28] <SimonKLB> so now i have machines with two nics, one on the public subnet and one private, the public subnet is in spaces-0 and private in internal-0
[15:29] <SimonKLB> since spaces-X are special spaces names, do they simply have priority? or how can i force the public subnet to become the primary nic/ip in juju?
[15:34] <SimonKLB> this looks kind of related https://bugs.launchpad.net/juju/+bug/1473069
[15:34] <mup> Bug #1473069: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <2.0> <addressability> <bug-squad> <cdo-qa-blocker>
 <lxc> <maas-provider> <networking> <uosci> <juju:Triaged by rharding> <Landscape Server:New> <https://launchpad.net/bugs/1473069>
[15:37] <SimonKLB> also this: https://bugs.launchpad.net/juju/+bug/1616098
[15:37] <mup> Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> <cpec> <juju:Fix Released by dimitern> <https://launchpad.net/bugs/1616098>
[15:38] <frobware> SimonKLB: the software that you want to run an be public should be deployed and bound to your public space
[15:39] <frobware> SimonKLB: you guide the exposure using spaces
[15:39] <SimonKLB> frobware: my issue is that i can guarantee that juju chooses the "correct" public ip
[15:39] <SimonKLB> frobware: so i could end up with the private ip being the one exposed in juju
[15:40] <SimonKLB> frobware: i dont see anywhere an option in maas to define a spaces as "public" or "private"
[15:40] <frobware> SimonKLB: put discrete subnets you put in your "public" space
[15:40] <frobware> in your...
[15:40] <frobware> SimonKLB: bbiab; meeting
[15:40] <SimonKLB> okok!
[17:42] <redir> brb reboot
[17:42] <redir> new kernel
[19:53] <perrito666> this bug is starting to feel like a fractal ffs
[19:59] <redir> :(
[20:29] <perrito666> k , EODing until standup, ill reply if privmsgs are sent tho
[20:57]  * redir lunches
[23:07]  * perrito666 is back