[01:13] <marcoceppi> axw: demo went great, thanks!
[01:13] <axw> marcoceppi: sweet :)
[01:14] <axw> marcoceppi: did you show windows/centos workloads?
[01:14] <marcoceppi> axw: no, just ubuntu stuff, this was mostly a juju benchmarking talk but they asked about it
[01:14] <axw> ah ok
[01:14] <marcoceppi> axw: I plan to have an ubuntu -> centos -> windows + benchmarking example for the follow up conversation
[01:15] <axw> marcoceppi: awesome, I'll be keen to see that in action
[01:35] <axw> wallyworld: could you please take a look over http://reviews.vapour.ws/r/3461/ some time today?
[01:35] <wallyworld> sure
[02:50] <natefinch> ericsnow: are you around?
[03:30] <wallyworld> axw: lgtm, can we hold off landing until current CI run finishes on sm branch. i may be able to merge that to master first
[03:30] <axw> wallyworld: sounds good
[03:30] <axw> thanks
[03:32] <anastasiamac> \o/
[05:33] <mup> Bug #1531718 opened: syslog full of "rsyslogd-2089: netstream session ... will be closed due to error" <juju-core:New> <https://launchpad.net/bugs/1531718>
[05:48] <mup> Bug #1531719 opened: Runaway memory allocation in jujud unit agent <juju-core:New> <https://launchpad.net/bugs/1531719>
[06:17] <wallyworld> axw: may as well land that bootstrap branch. there's one remaining failure in sm branch, which is upgrading from 1.20
[06:24] <axw> wallyworld: okey dokey
[06:26] <wallyworld> axw: seen a409 before? http://pastebin.ubuntu.com/14427956/   get errors adding both centos7 and win2012 machines
[06:27] <axw> wallyworld: urgh. no, take a look in the portal. navigate to the resource group, there will be a bar graph with some red - click on the red and it'll take you to the errors
[06:27] <wallyworld> ok
[06:27] <axw> wallyworld: what location are you using?
[06:28] <wallyworld> West US it seems
[06:28] <axw> wallyworld: ok, should be fine
[06:29] <wallyworld> lol
[06:29] <wallyworld> "Operation results in exceeding quota limits of Core. Maximum allowed: 4, Current in use: 1,
[06:29] <wallyworld> sigh
[06:29] <wallyworld> axw: i'm using a free trial, but 1 < 4 last time i looked
[06:30] <wallyworld> oh wait, there's more message
[06:30] <wallyworld> it says Additonal Requested 4
[06:30] <wallyworld> but i'm only starting 3 machines
[06:31] <wallyworld> bootstrap, plus one each of centos and win
[06:31] <wallyworld> maybe it's cores, not machines
[06:31] <axw> wallyworld: yeah those A3 machines are multi-core I think
[06:32] <wallyworld> yeah had same thought
[06:32] <axw> wallyworld: ask antonio to add you to the enterprise account
[06:32] <wallyworld> will try smaller machines
[06:32] <wallyworld> will have to
[06:32] <axw> wallyworld: my trial account was just converted. I still have my own subscription, it's just not paid by me
[06:32] <wallyworld> ah cool
[06:38] <wallyworld> axw: so far so good with smaller machine, but fark it is soooooooooooooo slooooooooooow
[06:38] <wallyworld> how do eople use it
[06:38] <wallyworld> s/how/why
[06:38] <axw> wallyworld: tis a bit
[06:38] <wallyworld> s/a bit/a lot
[06:39] <axw> wallyworld: I do like the interface and API though
[06:39] <wallyworld> yeah, that is nice
[06:39] <wallyworld> like everything else MS
[06:39] <wallyworld> looks flashy, shit underneath
[06:54] <axw> wallyworld: I've added a separate section to the release notes about the bootstrap changes
[06:55] <wallyworld> awesome, ty. i was going to ask the same thing
[06:55] <wallyworld> people have been wanting that for a while
[06:55] <axw> it's kinda separate from strucutred metadata
[06:55] <wallyworld> yep
[07:18] <axw> wallyworld: you want me to do that cloud yaml bootstrap one next?
[07:19] <axw> wallyworld: needs credentials branch first
[07:19] <wallyworld> axw: yes please, i was hoping to get credentials unmarshalling done before hand, but i might run out of time
[07:19] <wallyworld> credentials marshalling landing now
[07:20] <axw> wallyworld: unmarshallign would be a prereq for bootstrap
[07:20] <wallyworld> yeah
[07:20] <wallyworld> i'll try and get to it tonight
[07:21] <wallyworld> but if not i might have to leave it with you sorry
[07:21] <axw> np
[07:21] <wallyworld> i was optimistic about how much i'd be able to get done ahead of you
[07:21] <wallyworld> axw: i'm aiming to have a bootstrap demo for end of next week
[07:21] <wallyworld> i think that's doable
[09:10] <dimitern> morning o/
[09:15] <TheMue> morning dimitern
[09:19] <dimitern> voidspace, dooferlad, frobware, please have a look at http://reviews.vapour.ws/r/3465/ when you have some time
[09:19] <dimitern> TheMue, hey :)
[09:20] <TheMue> dimitern: always with one eye in juju-land ;)
[09:22] <dimitern> TheMue, cheers!
[09:23] <TheMue> dimitern: that's so nice with open-source
[09:31] <voidspace> dimitern: looking
[09:41] <voidspace> dimitern: do you need to "continue" for *all* those possible errors?
[09:41] <fwereade> late xmas present: http://thecodelesscode.com/case/218
[09:42] <voidspace> dimitern: hmmm... it's only after you've successfully got the interface object and extracted a name that errors cause a skip
[09:42] <voidspace> dimitern: so I guess it's alright
[09:42] <voidspace> dimitern: LGTM
[09:47] <anastasiamac> fwereade: tyvm :D cheers to u too \o/
[09:48] <anastasiamac> fwereade: and right in time for some xmases (russian one is today..)
[09:48] <fwereade> anastasiamac, ah yes, I forgot that -- happy xmas :)
[09:48] <mattyw> does anyone know of a function that will take a unit string and return back the service name? I know it's trivial to do, but I wondered if it had been turned into a function
[09:50] <dimitern> voidspace, tyvm
[09:50] <wallyworld> Mmike: hey, did that mgopurge work?
[09:51] <mattyw> ^^ found it https://godoc.org/github.com/juju/names#UnitService
[09:51] <anastasiamac> tyvm
[09:52] <Mmike> wallyworld: hola! I never received it, I figured menn0 would email it to me, but haven't received anything yet.
[09:53] <wallyworld> Mmike: damn ok, i'll follow up
[09:53] <wallyworld> Mmike: i was going to ask you to update that bug 1528261 with you results
[09:53] <Mmike> wallyworld: np! :) thnx!
[09:53] <mup> Bug #1528261: jujud won't start, log shows a lot of "cannot set addresses of machine XXX: cannot find transaction ObjectIdHex("xxxxxx"); <juju-core:Incomplete> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1528261>
[09:53] <Mmike> wallyworld: I am re-doing what I did before holidays right now, I'll have an update within hour and a half, or os
[09:54] <wallyworld> Mmike: great ok, if you could comment on the bug that would be great
[09:59] <Mmike> yup, willdo
[10:01] <dooferlad> dimitern, frobware: hangout time
[10:01] <frobware> omw
[10:01] <dimitern> omw
[10:44]  * fwereade out for a bit
[11:26] <mattyw> fwereade, are you around?
[11:27] <jam> frobware: can you check something in your MAAS install?
[11:27] <frobware> jam: sure
[11:27] <jam> If you go to one of the VM instances in virt-manager, can you tell me what bus the disk is connected to?
[11:28] <jam> Under Virtual Disk, I have an "Advanced Options" which lists "Disk bus:"
[11:28] <frobware> jam: virtio
[11:28] <jam> yeah, mine as well
[11:28] <jam> can you run "sudo lsblk there" ?
[11:28] <jam> sorry
[11:28] <jam> "sudo lsblk" there
[11:28] <frobware> jam: on the source path? (/var/lib/libvirt/images/maas19-node5.img)?
[11:29] <jam> frobware: from inside the VM
[11:29] <frobware> jam: presumably ... yep
[11:30] <frobware> jam: http://pastebin.ubuntu.com/14429283/
[11:33] <jam> frobware: do you know how you created that disk? I'm just noticing the size on mine is tiny, presumably because qcow can grow, and doesn't have a min size.
[11:33] <jam> sorry, max size
[11:33] <jam> either that or MAAS is just refusing to think about a storage that is only 200KB in size.
[11:33] <frobware> jam: I created the disk through virt-manager's UI
[11:34] <jam> ok
[11:34] <jam> kmaas uses "qemu-img create -f qcow2 $PATH 32G"
[11:34] <jam> which sounds like it can grow to 32GB
[11:34] <jam> but 'lsblk' is reporting something much smaller
[11:34] <jam> frobware: yeah, I think by default virt-manager checks the "preallocate" box
[11:36] <frobware> jam: what does this report?  sudo virt-filesystems -l -a /var/lib/libvirt/images/maas19-node5.img
[11:36] <frobware> jam: on the qemu-img create version?
[11:38] <frobware> jam: I'm pretty sure they are preallocated as my /var looks like: /dev/mapper/crucial--vg-var--volume  493G  326G  142G  70% /var
[11:38] <jam> frobware: virt-manager preallocates by default, qemu create does not
[11:39] <frobware> jam: and I have 30 nodes(??)...
[11:49] <frobware> jam: I tried `qemu-img create -f qcow2 -o preallocation=metadata vm-100-disk-3.qcow2  1G' which seems to generate 1G.
[11:50] <jam> frobware: yeah, I tried that as well, but the disk thing seems to be sparse
[11:50] <frobware> jam: without the preallocate I get 193K
[11:50] <jam> frobware: because the "df -h" doesn't change
[11:58] <jam> frobware: confirmed that this makes MAAS happy
[11:58] <jam> I'm guessing they added code that cared about the size that lsblk returned
[11:58] <jam> and without preallocation it gets a vblk that is is only 200K or so.
[11:59] <jam> and then MAAS says "that's not useable"
[11:59] <frobware> jam: I just created a node based on my previous qemu-imag ... preallocate ... which seems to commission OK && deploy.
[12:00] <jam> frobware: right, I just deleted the disk image (without touching virt-manager) and reran "qemu-img create" with preallocation set
[12:01] <jam> and without changing anything else, maas accepted and found the storage on the machine
[12:01] <jam> so I'm guessing the 1.9rc4 used to notice the disk, but didn't care about the size
[12:01] <jam> and 1.9.0 is saying "that disk is too small, ignore it"
[12:07] <frobware> jam: actually.... my deploy failed. hmm.
[12:08] <jam> frobware: bootstrap is making progress
[12:08] <jam> not sure if everything will be happy, but it didn't stop at the same point
[12:08] <jam> frobware: ugh. timeout (I think). "is started but not deployed"
[12:08] <jam> but I see it downloading stuff in the console
[12:09] <frobware> jam: that's where my deploy failed (cloud-init) looked like it couldn't create stuff on the disk.
[12:09] <jam> frobware: it seems that cloud-init took 4m to download 40MB from the maas host
[12:09] <jam> that seems like a performance problem
[12:10] <jam> my load on this machine is super high
[12:10] <jam> currently 15
[12:12] <jam> (I also had the problem that I had left it running during commisioning, so I had to notice and ask it to reboot, so my timeouts are probably a bit off, but the perf issue is weird)
[12:56] <jam> frobware: dimitern: So it looks like I can almost bootstrap now, but I'm running into the "no IP address for eth1" bug
[12:56] <jam> It doesn't appear that dimitern's patch has made it into the maas-spaces feature branch has it?
[12:56] <dimitern> jam, is that on maas-spaces?
[12:57] <jam> dimitern: I'm getting the failure in maas-spaces
[12:57] <jam> I tried "juju bootstrap --upload-tools" and the last line was: "failed to bootstrap environment: getting addresses: getting node interfaces: no ip_address for link #0 on interface #0 eth1
[12:57] <dimitern> jam, yeah - so that's the same issue thedac was having, and my PR (currently being tested by the merge bot and should land very soon) fixes that
[12:58] <jam> I'm also noticing that apt-http-proxy doesn't seem to affect the initial cloud-init update
[12:58] <jam> at least, it doesn't seem to hit the proxy I just set up
[13:01] <jam> yeah, I see it running now
[13:01] <jam> I hope it lands first try
[13:22] <jam> looks like it landed
[13:38] <perrito666> voidspace: this was just taken a few blocks from here, are you by any chance in argentina? :p https://mmi488.whatsapp.net/d/VPt3jR5VJKCkgy9_4aHti1aOabI/ArCjonYv8CfDvL8KhO5kfWhBAof_QrxONa9F59MKBn2b.jpg
[13:44] <TheMue> perrito666: *rofl*
[14:27] <dimitern> frobware, here's the revert PR: http://reviews.vapour.ws/r/3472/
[14:27] <dimitern> still testing on 1.9
[14:27] <frobware> dimitern, OK. Was going through the process
[14:27] <frobware> dimitern, trying to identify which merge commits we want to revert
[14:27] <dimitern> and I'd appreciate if you also test it on 1.8 as my setup is funny with the IPv6 an all, so the test can't complete because of it
[14:28] <frobware> dimitern, I think I only have 4 - does that sound about right?
[14:28] <dimitern> frobware, yeah, perfect
[14:28] <frobware> dimitern, OK will pull your branch in a bit.
[14:29] <dimitern> frobware, ta!
[14:44] <mup> Bug #1531878 opened: TestBootstrapImage fails on i386 and ppc64el <i386> <ppc64el> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1531878>
[14:52] <frobware> dimitern, I got two merge conflicts. Did you see more than that?
[14:53] <dimitern> frobware, I can't remember the exact number
[14:53] <frobware> dimitern, bridgescript.go and environs.go
[14:54] <dimitern> frobware, the bridgescript one is due to adding head -n1 in one of the follow-up PRs
[14:55] <dimitern> frobware, and the environs.go (dummy provider) is changed in at least 2 of the 3 PRs IIRC
[15:02] <frobware> dimitern, I have a slightly different tree to you: https://github.com/frobware/juju/tree/1.25-redux
[15:12] <dimitern> frobware, I'm comparing now mine and yours against upstream 1.25
[15:17] <mup> Bug #1531886 opened: Status fails during upgrade <upgrade-juju> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1531886>
[15:20] <frobware> dimitern, did you squash your commits for the revert? I was looking at `git log' in your tree and only see the 1 commit.
[15:21] <frobware> dimitern, asking because if we were to revert the revert for 1.25.3 it would be nice to see them applied as individual merge commits again.
[15:25] <dimitern> frobware, both branches mine and yours have the same diff
[15:25] <frobware> dimitern, they're not identical
[15:26] <dimitern> frobware, well, I didn't do it by reverting individual commits, but manually c/p chunks of the PRs
[15:26] <frobware> dimitern, I think it is better to record them as individual reverts
[15:26] <dimitern> frobware, oh, yeah - in 2 places they differ in environ.go (dns[i] -> dns[l] and a comment + in the tests a name)
[15:27] <dimitern> but those are irrelevant
[15:27] <frobware> dimitern, I find the log history makes it clear what happened. http://pastebin.ubuntu.com/14430590/
[15:27] <dimitern> frobware, I have a habit of not trusting git to do the right thing.. so that's why I did it manually
[15:27] <frobware> dimitern, I trust git more than Emacs. :)
[15:27] <dimitern> frobware, hehe
[15:28] <dimitern> frobware, well, I'm fine if you want to do it your way - esp. after I verified both diffs
[15:28] <frobware> dimitern, yes - it's good that we have, more or less, the same result.
[15:29] <frobware> dimitern, the 'more or less' is just cosmetic AFAICS
[15:29] <frobware> dimitern, as a preferences I prefer the discrete steps.
[15:29] <frobware> dimitern, I will test anyway. Trying on 1.8.2 right now.
[15:30] <dimitern> frobware, sounds good, I finished my tests - all fine (well, apart from 2 issues)
[15:30] <frobware> dimitern, new?
[15:31] <dimitern> frobware, the issues are - IPv6 causing issues when used in 1.8-
[15:31] <dimitern> frobware, and it doesn't seem to work well with vlans on top of a single nic
[15:31] <frobware> dimitern, and both those issues went away with devices?
[15:32] <dimitern> frobware, the IPv6 issue I fixed as part of these PRs
[15:32] <dimitern> frobware, like skipping IPv6 subnets when discovering which one to use for address allocation
[15:33] <dimitern> frobware, otherwise it barfs on the first one, which ultimately causes allocation to fail (with A-C on)
[15:33] <dimitern> frobware, now retrying with 1 NIC only, no VLANs on 1.9
[15:34] <frobware> cherylj, mgz: could we take mine or dimiter's change as a feature branch and test the backed out changes like we did for the DNS issue? I want to land/merge this with confidence that we don't endlessly break things.
[15:34] <frobware> dimitern, ^^
[15:34] <dimitern> frobware, the VLAN issues are weird - the bridge script can't seem to handle the "drop eth0.100 and replace it by juju-br0.100, which has vlan-raw-device eth0"
[15:35] <frobware> dimitern, I think that's better on the maas-spaces branch
[15:35] <dimitern> as it complains eth0.100 already exists
[15:35] <dimitern> yeah it is indeed
[15:36] <frobware> dimitern, cut+paste the /e/n/i and try running the bridge-script from the maas-spaces branch
[15:36] <dimitern> frobware, good idea - will try on another node
[15:36] <frobware> dimitern, shamefully I don't think the script reads from stdin.
[15:37]  * frobware blushes.
[15:37] <bogdanteleaga> anyone used the new arm provider?
[15:38] <dimitern> bogdanteleaga, there's an arm provider now?
[15:38] <dimitern> news to me
[15:39] <bogdanteleaga> :)
[15:39] <bogdanteleaga> azure arm provider
[15:39] <bogdanteleaga> to be more exact
[15:41] <katco> jcastro: so for bug 1495978
[15:41] <mup> Bug #1495978: Juju does not deploy CentOS images in LXC <adoption> <centos> <containers> <juju> <lxc> <system> <juju-core:Triaged> <https://launchpad.net/bugs/1495978>
[15:42] <katco> jcastro: for the local case, you can probably use the new lxd provider
[15:42] <dimitern> ah :)
[15:42] <katco> jcastro: it looks for a default image name, and that image could be a centos image
[15:42] <frobware> bogdanteleaga, I'm curious as to why the "arm" part makes a difference. Azure as a provider I can understand but why does the architecture make a diff?
[15:42] <dimitern> no, not yet
[15:42] <jcastro> katco: oh if the new provider makes this bug go away then absolutely!
[15:42] <dimitern> frobware, that's not an arch, it's the MS's acronym for the new az api
[15:42] <bogdanteleaga> frobware: it's just a fancy name that probably everybody will misunderstand at first
[15:42] <bogdanteleaga> it just comes from azure resource manager
[15:42] <jcastro> katco: what's the tldr on when we can start playing with the lxd provider?
[15:43] <katco> jcastro: well it's not a 1:1 match; what i'm describing would only work for the local case
[15:43] <frobware> bogdanteleaga, ah - I see.
[15:43] <katco> jcastro: i.e. matty's comment about lxc/kvm
[15:43] <jcastro> mbruzek: ^^^
[15:44] <frobware> dimitern, you should be able to run the script on your laptop - no need for a deployed node
[15:45] <katco> jcastro: https://blueprints.launchpad.net/juju-core/+spec/charmer-experience-lxd-provider
[15:45] <katco> jcastro: it was going to be in 1.26, it's currently landed in master, but will be released in 2.0 looks like
[15:45] <jcastro> ok so should I tell eco to start banging on it for the alpha then?
[15:46] <dimitern> frobware, yeah, but first need to get the /e/n/i
[15:46] <dimitern> frobware, btw I added both of us to the revert card and linked your redux branch in there
[15:46] <frobware> dimitern, ok - thought you were going to deploy a node from maas-spaces branch to run the script.
[15:46] <katco> jcastro: sure; it's very stable. was slated to be released
[15:46] <frobware> dimitern, ack
[15:46] <katco> jcastro: just got pushed back because of our change in release schedule
[15:47] <jcastro> katco: ok so if we were to do the charmer summit at end of this month with the LXD provider ... would you consider that a good decision?
[15:47] <katco> jcastro: absolutely.
[15:47] <cmars> jcastro, i've been using the lxd provider quite a bit, and find it to be very stable
[15:47] <katco> jcastro: very confident in the stability
[15:47] <frobware> dimitern, heh. when you click on the leankit link the card flashes at you...
[15:47] <jcastro> wow that totally changes my life
[15:47] <katco> jcastro: and it's soooo much better for local stuff
[15:47] <jcastro> omg, I am doing this today then
[15:47] <katco> jcastro: doooo it! lemme know if you have issues
[15:47] <jcastro> what do I need? dev ppa?
[15:48] <dimitern> frobware, yeah - some "improved UX" attempt I guess
[15:48] <katco> jcastro: you need lxd installed and then >= 1.26-alpha2 of juju
[15:49] <jcastro> katco: ok so we should be banging on this already, I'll get the word out
[15:49] <jcastro> I had no idea it was this far along, awesome
[15:50] <katco> jcastro: sorry, how could we have gotten the word out better?
[15:51] <rick_h_> jcastro: yea, the alpha release ppa
[15:51] <frobware> dimitern, do you have objections if we merge my branch? It's easier to look at the individual commits to see what was reverted.
[15:54] <dimitern> frobware, not at all - go for it
[15:55] <frobware> dimitern, I wanted to do some more testing first anyway. then hear from cherylj and mgz as to whether we want to test the change on a feature branch first.
[15:56] <frobware> dimitern, it's great given the two approaches we're reverting the same thing. :-D
[15:56] <cherylj> frobware: I'm on the cross team call, so that's why I'm "ignoring" you.  We're wrapping up :)
[15:56] <dimitern> frobware, +1 :)
[15:58] <dimitern> frobware, I figured out why the 1.25 bridge script was doing it wrong
[16:00] <frobware> dimitern, and that's true on maas-spaces too?
[16:01] <dimitern> frobware, http://paste.ubuntu.com/14430801/
[16:02] <dimitern> frobware, the maas-spaces one does the right thing
[16:02] <frobware> dimitern, just trying to see what's wrong...
[16:03] <dimitern> frobware, well always using $PRIMARY_IFACE in the vlan-raw-device stanza is the cause for the errors I was seeing
[16:03] <dimitern> rather than the correct vlan device, e.g. eth0.100
[16:04] <frobware> dimitern, isn't that what maas-spaces is doing too?
[16:04] <dimitern> frobware, check the paste - it has all details :)
[16:04] <frobware> dimitern, If I grep for vlan-raw-device it is always eth0
[16:05] <dimitern> frobware, what I'm seeing as a result of the maas-spaces script looks correct (although I haven't tried it live)
[16:05] <frobware> dimitern, for 1.25 or maas-spaces
[16:05] <frobware> dimitern, just to be clear though. In your PB I see that the vlan-raw-device is always eth0.
[16:06] <jcastro> katco: I can't seem to find how to configure the lxd provider in the devel docs
[16:06] <katco> jcastro: k sec
[16:07] <dimitern> frobware, sorry - I meant bridge_ports most likely
[16:07] <dimitern> (looking at maas-spaces bridgescript_test as well)
[16:08] <katco> jcastro: https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit#heading=h.w4gb7d5kh9wd
[16:08] <frobware> dimitern, in the 1.25 case we've omitted the iface for the underlying bridge port.
[16:08] <katco> cherylj: any reason the upcoming release notes aren't checked into the devel section of the docs on jujucharms.com?
[16:08] <katco> cherylj: not really sure how that whole process works
[16:09] <dimitern> yeah
[16:09] <frobware> dimitern, :(
[16:10] <dimitern> frobware, sorry, I've just realized I need to go out and will miss the OS call
[16:10] <dimitern> back later
[16:10] <frobware> dimitern, k
[16:11] <cherylj> katco: I'm not sure either.  sinzui? ^^
[16:11] <jcastro> katco: it seems in the devel docs you'd just replace this page: https://jujucharms.com/docs/devel/config-LXC
[16:12] <katco> jcastro: i'm not sure what the plans are for deprecating lxc. maybe for 2.0, but we wanted to give people time to migrate off their current workflows
[16:12] <sinzui> katco: cherylj : there isn't a process to break features in release notes into spearate documetns. Some teams write add wip docs to juju docs, then write/paste the juju-doc into tje release notes
[16:13] <katco> sinzui: well my questions is more specifically what is the process of getting the release notes into the docs. e.g.: https://jujucharms.com/docs/devel/reference-release-notes
[16:13] <katco> sinzui: seems like the 2.0 release notes should be in devel
[16:14] <sinzui> katco: we don't submit release-notes for alpha/betas.
[16:14] <jcastro> hey so I thought documenting in the doc docs was the final sign off for a feature?
[16:15] <cherylj> jcastro: it wouldn't prevent the feature from being merged and available in an alpha
[16:16] <jcastro> cherylj: yeah I just thought there was a step in the process where it was like "check that the feature is documented"
[16:17] <cherylj> jcastro: the goal is to have all of the documentation complete for all 2.0 features before the GA.  The 2.0 schedule has a documentation complete date of Mar-25
[16:18] <jcastro> oh ok so it's not per-feature it's a milestone?
[16:18] <cherylj> jcastro: well,  documentation is tracked per feature, but the date is the same for all features
[16:19] <jcastro> ok, I'll leave some notes in this 2.0 release notes doc
[16:21] <sinzui> katco: the 2.0 doc branch will be made from the master (devel) branch. The docs team would need to remove the alpha/beta information if we had added it to the the release-notes section because those version are not stable. We shouldn't add devel release-notes without the docs team agreeing that they know how to remove non-stable documentation.
[16:41] <jcastro> katco: ok, good news and bad, it bootstrapped and I can go into the unit with lxc but `juju status` and `juju ssh` hang
[16:41] <katco> jcastro: hm. those should work just fine
[16:42] <katco> jcastro: there are instances running?
[16:42] <jcastro> yes
[16:42] <jcastro> the bootstrap instance is running
[16:42] <jcastro> also I am on xenial, so I might be a little more bleeding than normal
[16:43] <katco> jcastro: does the log provide any information when you run status?
[16:43] <katco> jcastro: i don't know if anyone's tested it on xenial, but if it bootstraps it should work i think.
[16:44] <jcastro> it's unclear to me where the logs are
[16:45] <katco> jcastro: juju help debug-log
[16:47] <jcastro> yeah that doesn't work, I suspect for the same reason ssh and status don't work
[16:49]  * jcastro tries a rebootstrap
[16:50] <katco> jcastro: did you freshly set up lxd or had that been installed/working already?
[16:50] <jcastro> freshly installed, launching new images by hand seems to work fine
[16:51] <jcastro> juju did fire up an instance and I can get to it with the lxc tools, seems like it doesn't know about it though
[16:51] <katco> jcastro: what's the os for the image?
[16:52] <jcastro> trusty
[16:54] <katco> jcastro: ah. that's the problem.
[16:55] <katco> jcastro: errr or i think it is? release notes seem to suggest that's ok
[16:55] <katco> jcastro: can you try with wily?
[16:56] <katco> jcastro: trusty doesn't have >= 1.3 so i don't think the tools would work
[16:56] <jcastro> huh so weird, I couldn't destroy env because it was hanging
[16:56] <jcastro> so I killed the instance by hand
[16:56] <jcastro> and rebootstrapped
[16:56] <jcastro> now it's working like a champ
[16:56] <katco> jcastro: did you specify --upload-tools as well?
[16:56] <jcastro> yes
[16:56] <jcastro> holy shit, this is fast katco
[16:56] <katco> jcastro: yeah it is
[16:56] <katco> jcastro: glad it's working. wondering why it hung though.
[16:57] <katco> jcastro: god knows --upload-tools is full of mystery and terror
[16:57] <jcastro> I'll chalk it up to crazy guy with xenial for this one, but I'll see how the other guys get on
[16:57] <katco> jcastro: could be something with thtat
[16:57] <katco> jcastro: awesome ty for testing it out
[16:57] <jcastro> mind if we just dump our notes in this gdoc?
[16:57] <jcastro> I'd like to just tell the list to dump all their lxd provider notes in here, then we can flesh it out for the doc page?
[16:57] <katco> jcastro: that's a question for cherylj since it's intended to be release notes
[16:58] <jcastro> holy smokes, I know I said this before, but this is really fast katco
[16:59] <katco> jcastro: notice machine 0 is just a container so you can do HA and do things like deploy openstack locally
[17:00] <katco> jcastro: as well as theoretically use centos. i don't know if anyone's tried that yet. not sure if we have tools built for it
[17:00] <jcastro> I'll ask bruzer to try it
[17:02]  * perrito666 just deployed an openstack in lxd with lxd provider
[17:02] <voidspace> frobware: dooferlad: http://reviews.vapour.ws/r/3473/
[17:05] <frobware> voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3474/ -- dimiter I reused your commit message.
[17:05] <cherylj> frobware: mgz is going to test your changes to back out the devices patch
[17:05] <jcastro> katco: what's the experience like if someone was all-trusty on say, their laptop?
[17:06] <katco> jcastro: meaning trusty as the host?
[17:06] <frobware> cherylj, mgz: magic. See the review request: http://reviews.vapour.ws/r/3474/
[17:06] <jcastro> katco: yeah
[17:07] <katco> jcastro: officially, that doesn't work right now because trusty only has go1.1 i think
[17:07] <frobware> jcastro, I was curios about this too.
[17:07] <mgz> frobware: that one, not 3472? :)
[17:07] <katco> jcastro: unofficially, if you just use the ppa, it works great
[17:07] <frobware> jcastro, katco: I was contemplating taking my laptop to wily but would prefer not to.
[17:07] <cherylj> frobware, the DNS and default gateway bugs were caused by a commit ontop of the devices fix that didn't make it into master yet, right?
[17:07] <katco> jcastro: wwitzel3 's lightning talk in seattle was to show openstack running on his trusty laptop
[17:07] <cherylj> frobware: I think this one:  bug 1525280
[17:07] <mup> Bug #1525280: 1.25.1 with maas 1.8: devices dns allocation uses non-unique hostname <maas-provider> <network> <regression> <juju-core:Triaged> <juju-core 1.25:Fix Committed by dimitern> <https://launchpad.net/bugs/1525280>
[17:08] <katco> frobware: as a dev, you'd be fine. just use a version of juju you compile yourself or the ppa
[17:08] <frobware> cherylj, correct. and I just discarded the DNS fix/review.
[17:08] <katco> frobware: it's only main that wouldn't work
[17:08] <cherylj> frobware: okay, when bug 1525280 does land in master, we'll need your DNS fix there as well
[17:08] <jcastro> katco: ok so I tell people either wily or xenial as a minimum then?
[17:09] <katco> frobware: it's because of the req. that what's in main be reproducible by building the source, and trusty only has go1.1. but since go is compiled, if you have the binary you're fine
[17:09] <katco> jcastro: yes
[17:09] <frobware> cherylj, yep and the one for the default gw. BTW: did you create a bug for that?
[17:09] <cherylj> frobware: but I think we can get away without the default gateway fix because we're already telling people if you're using 2.0 and MAAS 1.8.3, you're gunna have a bad time.
[17:09] <cherylj> frobware: unless you disagree?
[17:09] <katco> jcastro: although there is movement in getting go1.5 in trusty, so that may happen at some point
[17:09] <frobware> cherylj, and the bad time can include a note to set a default gw?
[17:10] <katco> jcastro: at which point the next release into trusty would work
[17:10] <cherylj> frobware: that was my thought
[17:10] <cherylj> frobware: what do you think?
[17:10] <frobware> cherylj, it's all text. :)
[17:10] <cherylj> heh
[17:10] <cherylj> frobware: I'll bring it up in the release call today
[17:10] <jcastro> cherylj: mind if I get people dropping lxd notes in this doc or want me to split it off?
[17:11] <cherylj> jcastro: if there are things that you find are preventing people from using lxd, then yes, add them do the release notes.
[17:11] <frobware> mgz, 3472 vs 3474. Dimiter and I went about doing the backout in different ways and (thankfully) ended up with the same results. the git commit history in 3474 is a bit more discrete in what was done.
[17:11] <cherylj> jcastro: if there are other issues that should just be included in the documentation, maybe they should be in a different doc.
[17:12] <cherylj> katco: is there a separate doc you guys are working on for documenting lxd in jujucharms.com?
[17:12] <katco> cherylj: no
[17:12] <mgz> frobware: gotcha
[17:12] <frobware> cherylj, inferring the default gw is a lower barrier to entry for the end user. I would want that.
[17:13] <cherylj> frobware: if it's an easy code change, then yeah, I would agree
[17:13] <cherylj> frobware: I can open the bug for you
[17:13] <frobware> cherylj, please. thx.
[17:23] <jcastro> cherylj: is there a reason we should keep the release notes gdoc not public?
[17:24] <cherylj> jcastro: they are released publicly with the alpha / beta builds.
[17:24] <frobware> cherylj, card for 1528217 forward port to master - https://canonical.leankit.com/Boards/View/101652562/119358672
[17:24] <jcastro> ok so what if we want public feedback? Perhaps we should split this off?
[17:39] <dooferlad> frobware, voidspace: http://reviews.vapour.ws/r/3475/
[17:39] <dooferlad> will get to your reviews now.
[17:59] <mup> Bug #1531932 opened: Unit agents unable to connect with MAAS 1.8 due to lack of default gateway in MAAS <juju-core:Triaged by frobware> <https://launchpad.net/bugs/1531932>
[18:16] <frobware> cherylj, thanks for opening the bug
[18:17] <cherylj> frobware: np :)
[18:19]  * frobware EOD
[18:25] <cherylj> mgz: were you able to get frobware's changes to revert 1483879 in a feature branch to test?
[18:35] <mgz> cherylj: it's build-revision 3487
[18:35] <mgz> various maas tests still pending
[18:37] <cherylj> mgz: awesome, thanks!
[18:50] <mup> Bug #1531954 opened: Trying to use Juju without a bootstrap node has a confusing error <juju-core:New> <https://launchpad.net/bugs/1531954>
[18:57] <dooferlad> frobware: you have a +1 for http://reviews.vapour.ws/r/3474/
[18:57] <dooferlad> frobware: I would say LGTM, but some of those reverts make me sad.
[21:11] <wallyworld> katco: hey, did you want a chat?
[21:11] <katco> wallyworld: hey, yep. 1:1?
[21:11] <wallyworld> ok
[21:30] <mup> Bug #1531995 opened: 2.0 upgrade-juju command should give exact command to run to upgrade a 1.x environment <juju-core:Triaged> <https://launchpad.net/bugs/1531995>
[21:33] <natefinch> ericsnow: after the demo, we're going to have to devise a way to extract the set resource ops so we can do it in the same transaction as the rest of deploy.  But for now I'll just run setresource after deploy
[21:34] <ericsnow> natefinch: we're going to do that stuff in a worker, if I remember right
[21:34] <ericsnow> natefinch: so the transaction won't factor in
[21:35] <natefinch> ericsnow: don't we have the resource metadata information (if not the bytes) available at deploy time? Might as well add it to the DB at that time
[21:35] <ericsnow> natefinch: I'm pretty sure we don't have all the info we need, but I may be wrong
[21:44] <cherylj> hey jog, I'm looking at the test run for the revert-maas-devices branch and I see that there's an OS deployer timeout
[21:44]  * jog looks
[21:44] <cherylj> jog: It looks like the services are still coming up.  Maybe things were slow?  I see nova-compute/0 is still installing things
[21:51] <jog> cherylj, there are other lxc's still in pending, nova-compute/0's workload status is 'blocked' maybe waiting for relations to complete...
[21:52] <jog> specifically LXCs on machines 5 and 6.
[21:53] <jog> I'm looking to see if there is log information about what's going on there.
[21:53] <cherylj> jog: If all the  clocks are synced, I see that we timed out here: 2016-01-07 21:19:34 ERROR Workloads not ready in maas-1_9-OS-deployer.
[21:53] <cherylj> jog: and in the unit log for nova-compute/0:  2016-01-07 21:19:51 DEBUG juju.worker.uniter.context context.go:326 [WORKLOAD-STATUS] active: Unit is ready
[21:54] <cherylj> jog: I can also look at the lxcs for machine 5 and 6
[21:55] <cherylj> I see that they're "started"?
[21:58] <jog> cherylj, sorry I think I was looking at the wrong one.
[21:58] <cherylj> ah, phew
[22:06] <jog> cherylj, the failure is due to the workload-status for all charms not setting down to 'active' or 'unknown'
[22:09] <cherylj> jog: yeah, I was wondering that.  I think, however, that it might've been premature?
[22:09] <jog> possibly... mgz recently added the workload verification code
[22:09] <cherylj> I see that at least the nova-compute/0 unit was still chugging along after the test timed out.
[22:10] <cherylj> jog: Can we queue that branch up for a retest, at least for the 1.9 os deployer test?
[22:10] <jog> yeah and rabbitmq-server/0 is still running a hook
[22:11] <jog> cherylj, a second run is going on now
[22:12] <cherylj> jog: ah, perfect!
[22:14] <jog> cherylj, hmm... we are only waiting 3 minutes
[22:14] <cherylj> jog: wow, that seems short
[22:14] <jog> that's after all unit agents become ready
[22:15] <cherylj> oh
[22:15] <cherylj> well, still seems a bit short given the size of the deployment
[22:15] <jog> I'll hot fix in a longer timeout
[22:15] <cherylj> thanks!
[22:15] <jog> we'll need another run after this current test
[22:16] <cherylj> if it fails again
[22:16] <cherylj> (in the same way)
[22:16] <jog> right
[22:16] <jog> other Openstack tests have passed today, on master and structured-metadata
[22:17] <cherylj> it really may be just a bit too short.  Like I said earlier, there were just a few seconds between the test timing out and that one unit being ready
[22:19] <jog> I agree, other revisions also failed today with the same timeout waiting for workloads, then passed on a second attempt... either way is seems like a longer default timeout should be applied
[22:24] <wallyworld> menn0: hey, you were going to email mario that mgopurge binary? i asked him last night and he hadn't received it yet
[22:32] <menn0> I emailed it to him soon after we talked
[22:32] <menn0> wallyworld:
[22:33] <wallyworld> menn0: ok, i'll need to follow up with him and see why he didn't have it
[22:33] <menn0> wallyworld: he sent me his email privately via IRC
[22:33] <menn0> wallyworld: I just checked my sent mail and it's there
[22:34] <wallyworld> menn0: ok, ty. no idea why he said he didn't get it
[22:34] <menn0> wallyworld: virus scanner or spam filter?
[22:34] <wallyworld> yeah, could be
[22:34] <menn0> wallyworld: I'll sent it to you now as well
[22:34] <wallyworld> ok, ty
[22:35] <menn0> wallyworld: you should have the email now as well
[22:35] <wallyworld> menn0: yep, just got it, tyvm
[22:35] <menn0> cool
[23:06] <mwhudson> Broadcast message from systemd-journald@DEVAC01 (Fri 2016-01-08 01:05:48 EET):
[23:06] <mwhudson> [33800]: 2016-01-07 23:05:48 INFO juju.testing mgo.go:515 reset successfully reset admin password
[23:06] <mwhudson> is there something i can do to shut this spam up?
[23:08] <perrito666> mwhudson: soon, that is sadly something you cannot turn off in the current version of mongo, we aim to upgrade it soon
[23:08] <mwhudson> ah ok