/srv/irclogs.ubuntu.com/2016/01/07/#juju-dev.txt

marcoceppiaxw: demo went great, thanks!01:13
axwmarcoceppi: sweet :)01:13
axwmarcoceppi: did you show windows/centos workloads?01:14
marcoceppiaxw: no, just ubuntu stuff, this was mostly a juju benchmarking talk but they asked about it01:14
axwah ok01:14
marcoceppiaxw: I plan to have an ubuntu -> centos -> windows + benchmarking example for the follow up conversation01:14
axwmarcoceppi: awesome, I'll be keen to see that in action01:15
axwwallyworld: could you please take a look over http://reviews.vapour.ws/r/3461/ some time today?01:35
wallyworldsure01:35
natefinchericsnow: are you around?02:50
wallyworldaxw: lgtm, can we hold off landing until current CI run finishes on sm branch. i may be able to merge that to master first03:30
axwwallyworld: sounds good03:30
axwthanks03:30
anastasiamac\o/03:32
mupBug #1531718 opened: syslog full of "rsyslogd-2089: netstream session ... will be closed due to error" <juju-core:New> <https://launchpad.net/bugs/1531718>05:33
mupBug #1531719 opened: Runaway memory allocation in jujud unit agent <juju-core:New> <https://launchpad.net/bugs/1531719>05:48
wallyworldaxw: may as well land that bootstrap branch. there's one remaining failure in sm branch, which is upgrading from 1.2006:17
axwwallyworld: okey dokey06:24
wallyworldaxw: seen a409 before? http://pastebin.ubuntu.com/14427956/   get errors adding both centos7 and win2012 machines06:26
axwwallyworld: 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 errors06:27
wallyworldok06:27
axwwallyworld: what location are you using?06:27
wallyworldWest US it seems06:28
axwwallyworld: ok, should be fine06:28
wallyworldlol06:29
wallyworld"Operation results in exceeding quota limits of Core. Maximum allowed: 4, Current in use: 1,06:29
wallyworldsigh06:29
wallyworldaxw: i'm using a free trial, but 1 < 4 last time i looked06:29
wallyworldoh wait, there's more message06:30
wallyworldit says Additonal Requested 406:30
wallyworldbut i'm only starting 3 machines06:30
wallyworldbootstrap, plus one each of centos and win06:31
wallyworldmaybe it's cores, not machines06:31
axwwallyworld: yeah those A3 machines are multi-core I think06:31
wallyworldyeah had same thought06:32
axwwallyworld: ask antonio to add you to the enterprise account06:32
wallyworldwill try smaller machines06:32
wallyworldwill have to06:32
axwwallyworld: my trial account was just converted. I still have my own subscription, it's just not paid by me06:32
wallyworldah cool06:32
wallyworldaxw: so far so good with smaller machine, but fark it is soooooooooooooo slooooooooooow06:38
wallyworldhow do eople use it06:38
wallyworlds/how/why06:38
axwwallyworld: tis a bit06:38
wallyworlds/a bit/a lot06:38
axwwallyworld: I do like the interface and API though06:39
wallyworldyeah, that is nice06:39
wallyworldlike everything else MS06:39
wallyworldlooks flashy, shit underneath06:39
axwwallyworld: I've added a separate section to the release notes about the bootstrap changes06:54
wallyworldawesome, ty. i was going to ask the same thing06:55
wallyworldpeople have been wanting that for a while06:55
axwit's kinda separate from strucutred metadata06:55
wallyworldyep06:55
axwwallyworld: you want me to do that cloud yaml bootstrap one next?07:18
axwwallyworld: needs credentials branch first07:19
wallyworldaxw: yes please, i was hoping to get credentials unmarshalling done before hand, but i might run out of time07:19
wallyworldcredentials marshalling landing now07:19
axwwallyworld: unmarshallign would be a prereq for bootstrap07:20
wallyworldyeah07:20
wallyworldi'll try and get to it tonight07:20
wallyworldbut if not i might have to leave it with you sorry07:21
axwnp07:21
wallyworldi was optimistic about how much i'd be able to get done ahead of you07:21
wallyworldaxw: i'm aiming to have a bootstrap demo for end of next week07:21
wallyworldi think that's doable07:21
dimiternmorning o/09:10
TheMuemorning dimitern09:15
dimiternvoidspace, dooferlad, frobware, please have a look at http://reviews.vapour.ws/r/3465/ when you have some time09:19
dimiternTheMue, hey :)09:19
TheMuedimitern: always with one eye in juju-land ;)09:20
dimiternTheMue, cheers!09:22
TheMuedimitern: that's so nice with open-source09:23
voidspacedimitern: looking09:31
voidspacedimitern: do you need to "continue" for *all* those possible errors?09:41
fwereadelate xmas present: http://thecodelesscode.com/case/21809:41
voidspacedimitern: hmmm... it's only after you've successfully got the interface object and extracted a name that errors cause a skip09:42
voidspacedimitern: so I guess it's alright09:42
voidspacedimitern: LGTM09:42
anastasiamacfwereade: tyvm :D cheers to u too \o/09:47
anastasiamacfwereade: and right in time for some xmases (russian one is today..)09:48
fwereadeanastasiamac, ah yes, I forgot that -- happy xmas :)09:48
mattywdoes 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 function09:48
dimiternvoidspace, tyvm09:50
wallyworldMmike: hey, did that mgopurge work?09:50
mattyw^^ found it https://godoc.org/github.com/juju/names#UnitService09:51
anastasiamactyvm09:51
Mmikewallyworld: hola! I never received it, I figured menn0 would email it to me, but haven't received anything yet.09:52
wallyworldMmike: damn ok, i'll follow up09:53
wallyworldMmike: i was going to ask you to update that bug 1528261 with you results09:53
Mmikewallyworld: np! :) thnx!09:53
mupBug #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
Mmikewallyworld: I am re-doing what I did before holidays right now, I'll have an update within hour and a half, or os09:53
wallyworldMmike: great ok, if you could comment on the bug that would be great09:54
Mmikeyup, willdo09:59
dooferladdimitern, frobware: hangout time10:01
frobwareomw10:01
dimiternomw10:01
* fwereade out for a bit10:44
mattywfwereade, are you around?11:26
jamfrobware: can you check something in your MAAS install?11:27
frobwarejam: sure11:27
jamIf you go to one of the VM instances in virt-manager, can you tell me what bus the disk is connected to?11:27
jamUnder Virtual Disk, I have an "Advanced Options" which lists "Disk bus:"11:28
frobwarejam: virtio11:28
jamyeah, mine as well11:28
jamcan you run "sudo lsblk there" ?11:28
jamsorry11:28
jam"sudo lsblk" there11:28
frobwarejam: on the source path? (/var/lib/libvirt/images/maas19-node5.img)?11:28
jamfrobware: from inside the VM11:29
frobwarejam: presumably ... yep11:29
frobwarejam: http://pastebin.ubuntu.com/14429283/11:30
jamfrobware: 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
jamsorry, max size11:33
jameither that or MAAS is just refusing to think about a storage that is only 200KB in size.11:33
frobwarejam: I created the disk through virt-manager's UI11:33
jamok11:34
jamkmaas uses "qemu-img create -f qcow2 $PATH 32G"11:34
jamwhich sounds like it can grow to 32GB11:34
jambut 'lsblk' is reporting something much smaller11:34
jamfrobware: yeah, I think by default virt-manager checks the "preallocate" box11:34
frobwarejam: what does this report?  sudo virt-filesystems -l -a /var/lib/libvirt/images/maas19-node5.img11:36
frobwarejam: on the qemu-img create version?11:36
frobwarejam: I'm pretty sure they are preallocated as my /var looks like: /dev/mapper/crucial--vg-var--volume  493G  326G  142G  70% /var11:38
jamfrobware: virt-manager preallocates by default, qemu create does not11:38
frobwarejam: and I have 30 nodes(??)...11:39
frobwarejam: I tried `qemu-img create -f qcow2 -o preallocation=metadata vm-100-disk-3.qcow2  1G' which seems to generate 1G.11:49
jamfrobware: yeah, I tried that as well, but the disk thing seems to be sparse11:50
frobwarejam: without the preallocate I get 193K11:50
jamfrobware: because the "df -h" doesn't change11:50
jamfrobware: confirmed that this makes MAAS happy11:58
jamI'm guessing they added code that cared about the size that lsblk returned11:58
jamand without preallocation it gets a vblk that is is only 200K or so.11:58
jamand then MAAS says "that's not useable"11:59
frobwarejam: I just created a node based on my previous qemu-imag ... preallocate ... which seems to commission OK && deploy.11:59
jamfrobware: right, I just deleted the disk image (without touching virt-manager) and reran "qemu-img create" with preallocation set12:00
jamand without changing anything else, maas accepted and found the storage on the machine12:01
jamso I'm guessing the 1.9rc4 used to notice the disk, but didn't care about the size12:01
jamand 1.9.0 is saying "that disk is too small, ignore it"12:01
frobwarejam: actually.... my deploy failed. hmm.12:07
jamfrobware: bootstrap is making progress12:08
jamnot sure if everything will be happy, but it didn't stop at the same point12:08
jamfrobware: ugh. timeout (I think). "is started but not deployed"12:08
jambut I see it downloading stuff in the console12:08
frobwarejam: that's where my deploy failed (cloud-init) looked like it couldn't create stuff on the disk.12:09
jamfrobware: it seems that cloud-init took 4m to download 40MB from the maas host12:09
jamthat seems like a performance problem12:09
jammy load on this machine is super high12:10
jamcurrently 1512:10
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:12
jamfrobware: dimitern: So it looks like I can almost bootstrap now, but I'm running into the "no IP address for eth1" bug12:56
jamIt doesn't appear that dimitern's patch has made it into the maas-spaces feature branch has it?12:56
dimiternjam, is that on maas-spaces?12:56
jamdimitern: I'm getting the failure in maas-spaces12:57
jamI 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 eth112:57
dimiternjam, 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 that12:57
jamI'm also noticing that apt-http-proxy doesn't seem to affect the initial cloud-init update12:58
jamat least, it doesn't seem to hit the proxy I just set up12:58
jamyeah, I see it running now13:01
jamI hope it lands first try13:01
jamlooks like it landed13:22
perrito666voidspace: 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.jpg13:38
=== rogpeppe2 is now known as rogpeppe
TheMueperrito666: *rofl*13:44
dimiternfrobware, here's the revert PR: http://reviews.vapour.ws/r/3472/14:27
dimiternstill testing on 1.914:27
frobwaredimitern, OK. Was going through the process14:27
frobwaredimitern, trying to identify which merge commits we want to revert14:27
dimiternand 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 it14:27
frobwaredimitern, I think I only have 4 - does that sound about right?14:28
dimiternfrobware, yeah, perfect14:28
frobwaredimitern, OK will pull your branch in a bit.14:28
dimiternfrobware, ta!14:29
mupBug #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:44
frobwaredimitern, I got two merge conflicts. Did you see more than that?14:52
dimiternfrobware, I can't remember the exact number14:53
frobwaredimitern, bridgescript.go and environs.go14:53
dimiternfrobware, the bridgescript one is due to adding head -n1 in one of the follow-up PRs14:54
=== ses is now known as Guest84440
dimiternfrobware, and the environs.go (dummy provider) is changed in at least 2 of the 3 PRs IIRC14:55
frobwaredimitern, I have a slightly different tree to you: https://github.com/frobware/juju/tree/1.25-redux15:02
dimiternfrobware, I'm comparing now mine and yours against upstream 1.2515:12
mupBug #1531886 opened: Status fails during upgrade <upgrade-juju> <juju-core:Incomplete> <juju-core structured-metadata:Triaged> <https://launchpad.net/bugs/1531886>15:17
frobwaredimitern, did you squash your commits for the revert? I was looking at `git log' in your tree and only see the 1 commit.15:20
frobwaredimitern, 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:21
dimiternfrobware, both branches mine and yours have the same diff15:25
frobwaredimitern, they're not identical15:25
dimiternfrobware, well, I didn't do it by reverting individual commits, but manually c/p chunks of the PRs15:26
frobwaredimitern, I think it is better to record them as individual reverts15:26
dimiternfrobware, oh, yeah - in 2 places they differ in environ.go (dns[i] -> dns[l] and a comment + in the tests a name)15:26
dimiternbut those are irrelevant15:27
frobwaredimitern, I find the log history makes it clear what happened. http://pastebin.ubuntu.com/14430590/15:27
dimiternfrobware, I have a habit of not trusting git to do the right thing.. so that's why I did it manually15:27
frobwaredimitern, I trust git more than Emacs. :)15:27
dimiternfrobware, hehe15:27
dimiternfrobware, well, I'm fine if you want to do it your way - esp. after I verified both diffs15:28
frobwaredimitern, yes - it's good that we have, more or less, the same result.15:28
frobwaredimitern, the 'more or less' is just cosmetic AFAICS15:29
frobwaredimitern, as a preferences I prefer the discrete steps.15:29
frobwaredimitern, I will test anyway. Trying on 1.8.2 right now.15:29
dimiternfrobware, sounds good, I finished my tests - all fine (well, apart from 2 issues)15:30
frobwaredimitern, new?15:30
dimiternfrobware, the issues are - IPv6 causing issues when used in 1.8-15:31
dimiternfrobware, and it doesn't seem to work well with vlans on top of a single nic15:31
frobwaredimitern, and both those issues went away with devices?15:31
dimiternfrobware, the IPv6 issue I fixed as part of these PRs15:32
dimiternfrobware, like skipping IPv6 subnets when discovering which one to use for address allocation15:32
dimiternfrobware, otherwise it barfs on the first one, which ultimately causes allocation to fail (with A-C on)15:33
dimiternfrobware, now retrying with 1 NIC only, no VLANs on 1.915:33
frobwarecherylj, 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
frobwaredimitern, ^^15:34
dimiternfrobware, 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:34
frobwaredimitern, I think that's better on the maas-spaces branch15:35
dimiternas it complains eth0.100 already exists15:35
dimiternyeah it is indeed15:35
frobwaredimitern, cut+paste the /e/n/i and try running the bridge-script from the maas-spaces branch15:36
dimiternfrobware, good idea - will try on another node15:36
frobwaredimitern, shamefully I don't think the script reads from stdin.15:36
* frobware blushes.15:37
bogdanteleagaanyone used the new arm provider?15:37
dimiternbogdanteleaga, there's an arm provider now?15:38
dimiternnews to me15:38
bogdanteleaga:)15:39
bogdanteleagaazure arm provider15:39
bogdanteleagato be more exact15:39
katcojcastro: so for bug 149597815:41
mupBug #1495978: Juju does not deploy CentOS images in LXC <adoption> <centos> <containers> <juju> <lxc> <system> <juju-core:Triaged> <https://launchpad.net/bugs/1495978>15:41
katcojcastro: for the local case, you can probably use the new lxd provider15:42
dimiternah :)15:42
katcojcastro: it looks for a default image name, and that image could be a centos image15:42
frobwarebogdanteleaga, 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
dimiternno, not yet15:42
jcastrokatco: oh if the new provider makes this bug go away then absolutely!15:42
dimiternfrobware, that's not an arch, it's the MS's acronym for the new az api15:42
bogdanteleagafrobware: it's just a fancy name that probably everybody will misunderstand at first15:42
bogdanteleagait just comes from azure resource manager15:42
jcastrokatco: what's the tldr on when we can start playing with the lxd provider?15:42
katcojcastro: well it's not a 1:1 match; what i'm describing would only work for the local case15:43
frobwarebogdanteleaga, ah - I see.15:43
katcojcastro: i.e. matty's comment about lxc/kvm15:43
jcastrombruzek: ^^^15:43
frobwaredimitern, you should be able to run the script on your laptop - no need for a deployed node15:44
katcojcastro: https://blueprints.launchpad.net/juju-core/+spec/charmer-experience-lxd-provider15:45
katcojcastro: it was going to be in 1.26, it's currently landed in master, but will be released in 2.0 looks like15:45
jcastrook so should I tell eco to start banging on it for the alpha then?15:45
dimiternfrobware, yeah, but first need to get the /e/n/i15:46
dimiternfrobware, btw I added both of us to the revert card and linked your redux branch in there15:46
frobwaredimitern, ok - thought you were going to deploy a node from maas-spaces branch to run the script.15:46
katcojcastro: sure; it's very stable. was slated to be released15:46
frobwaredimitern, ack15:46
katcojcastro: just got pushed back because of our change in release schedule15:46
jcastrokatco: 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
katcojcastro: absolutely.15:47
cmarsjcastro, i've been using the lxd provider quite a bit, and find it to be very stable15:47
katcojcastro: very confident in the stability15:47
frobwaredimitern, heh. when you click on the leankit link the card flashes at you...15:47
jcastrowow that totally changes my life15:47
katcojcastro: and it's soooo much better for local stuff15:47
jcastroomg, I am doing this today then15:47
katcojcastro: doooo it! lemme know if you have issues15:47
jcastrowhat do I need? dev ppa?15:47
dimiternfrobware, yeah - some "improved UX" attempt I guess15:48
katcojcastro: you need lxd installed and then >= 1.26-alpha2 of juju15:48
jcastrokatco: ok so we should be banging on this already, I'll get the word out15:49
jcastroI had no idea it was this far along, awesome15:49
katcojcastro: sorry, how could we have gotten the word out better?15:50
rick_h_jcastro: yea, the alpha release ppa15:51
frobwaredimitern, do you have objections if we merge my branch? It's easier to look at the individual commits to see what was reverted.15:51
dimiternfrobware, not at all - go for it15:54
frobwaredimitern, 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:55
frobwaredimitern, it's great given the two approaches we're reverting the same thing. :-D15:56
cheryljfrobware: I'm on the cross team call, so that's why I'm "ignoring" you.  We're wrapping up :)15:56
dimiternfrobware, +1 :)15:56
dimiternfrobware, I figured out why the 1.25 bridge script was doing it wrong15:58
frobwaredimitern, and that's true on maas-spaces too?16:00
dimiternfrobware, http://paste.ubuntu.com/14430801/16:01
dimiternfrobware, the maas-spaces one does the right thing16:02
frobwaredimitern, just trying to see what's wrong...16:02
dimiternfrobware, well always using $PRIMARY_IFACE in the vlan-raw-device stanza is the cause for the errors I was seeing16:03
dimiternrather than the correct vlan device, e.g. eth0.10016:03
frobwaredimitern, isn't that what maas-spaces is doing too?16:04
dimiternfrobware, check the paste - it has all details :)16:04
frobwaredimitern, If I grep for vlan-raw-device it is always eth016:04
dimiternfrobware, what I'm seeing as a result of the maas-spaces script looks correct (although I haven't tried it live)16:05
frobwaredimitern, for 1.25 or maas-spaces16:05
frobwaredimitern, just to be clear though. In your PB I see that the vlan-raw-device is always eth0.16:05
jcastrokatco: I can't seem to find how to configure the lxd provider in the devel docs16:06
katcojcastro: k sec16:06
dimiternfrobware, sorry - I meant bridge_ports most likely16:07
dimitern(looking at maas-spaces bridgescript_test as well)16:07
katcojcastro: https://docs.google.com/document/d/1ID-r22-UIjl00UY_URXQo_vJNdRPqmSNv7vP8HI_E5U/edit#heading=h.w4gb7d5kh9wd16:08
frobwaredimitern, in the 1.25 case we've omitted the iface for the underlying bridge port.16:08
katcocherylj: any reason the upcoming release notes aren't checked into the devel section of the docs on jujucharms.com?16:08
katcocherylj: not really sure how that whole process works16:08
dimiternyeah16:09
frobwaredimitern, :(16:09
dimiternfrobware, sorry, I've just realized I need to go out and will miss the OS call16:10
dimiternback later16:10
frobwaredimitern, k16:10
cheryljkatco: I'm not sure either.  sinzui? ^^16:11
jcastrokatco: it seems in the devel docs you'd just replace this page: https://jujucharms.com/docs/devel/config-LXC16:11
katcojcastro: 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 workflows16:12
sinzuikatco: 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 notes16:12
katcosinzui: 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-notes16:13
katcosinzui: seems like the 2.0 release notes should be in devel16:13
sinzuikatco: we don't submit release-notes for alpha/betas.16:14
jcastrohey so I thought documenting in the doc docs was the final sign off for a feature?16:14
cheryljjcastro: it wouldn't prevent the feature from being merged and available in an alpha16:15
jcastrocherylj: yeah I just thought there was a step in the process where it was like "check that the feature is documented"16:16
cheryljjcastro: 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-2516:17
jcastrooh ok so it's not per-feature it's a milestone?16:18
cheryljjcastro: well,  documentation is tracked per feature, but the date is the same for all features16:18
jcastrook, I'll leave some notes in this 2.0 release notes doc16:19
sinzuikatco: 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:21
jcastrokatco: ok, good news and bad, it bootstrapped and I can go into the unit with lxc but `juju status` and `juju ssh` hang16:41
katcojcastro: hm. those should work just fine16:41
katcojcastro: there are instances running?16:42
jcastroyes16:42
jcastrothe bootstrap instance is running16:42
jcastroalso I am on xenial, so I might be a little more bleeding than normal16:42
katcojcastro: does the log provide any information when you run status?16:43
katcojcastro: i don't know if anyone's tested it on xenial, but if it bootstraps it should work i think.16:43
jcastroit's unclear to me where the logs are16:44
katcojcastro: juju help debug-log16:45
jcastroyeah that doesn't work, I suspect for the same reason ssh and status don't work16:47
* jcastro tries a rebootstrap16:49
katcojcastro: did you freshly set up lxd or had that been installed/working already?16:50
jcastrofreshly installed, launching new images by hand seems to work fine16:50
jcastrojuju did fire up an instance and I can get to it with the lxc tools, seems like it doesn't know about it though16:51
katcojcastro: what's the os for the image?16:51
jcastrotrusty16:52
katcojcastro: ah. that's the problem.16:54
katcojcastro: errr or i think it is? release notes seem to suggest that's ok16:55
katcojcastro: can you try with wily?16:55
katcojcastro: trusty doesn't have >= 1.3 so i don't think the tools would work16:56
jcastrohuh so weird, I couldn't destroy env because it was hanging16:56
jcastroso I killed the instance by hand16:56
jcastroand rebootstrapped16:56
jcastronow it's working like a champ16:56
katcojcastro: did you specify --upload-tools as well?16:56
jcastroyes16:56
jcastroholy shit, this is fast katco16:56
katcojcastro: yeah it is16:56
katcojcastro: glad it's working. wondering why it hung though.16:56
katcojcastro: god knows --upload-tools is full of mystery and terror16:57
jcastroI'll chalk it up to crazy guy with xenial for this one, but I'll see how the other guys get on16:57
katcojcastro: could be something with thtat16:57
katcojcastro: awesome ty for testing it out16:57
jcastromind if we just dump our notes in this gdoc?16:57
jcastroI'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
katcojcastro: that's a question for cherylj since it's intended to be release notes16:57
jcastroholy smokes, I know I said this before, but this is really fast katco16:58
katcojcastro: notice machine 0 is just a container so you can do HA and do things like deploy openstack locally16:59
katcojcastro: as well as theoretically use centos. i don't know if anyone's tried that yet. not sure if we have tools built for it17:00
jcastroI'll ask bruzer to try it17:00
* perrito666 just deployed an openstack in lxd with lxd provider17:02
voidspacefrobware: dooferlad: http://reviews.vapour.ws/r/3473/17:02
frobwarevoidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3474/ -- dimiter I reused your commit message.17:05
cheryljfrobware: mgz is going to test your changes to back out the devices patch17:05
jcastrokatco: what's the experience like if someone was all-trusty on say, their laptop?17:05
katcojcastro: meaning trusty as the host?17:06
frobwarecherylj, mgz: magic. See the review request: http://reviews.vapour.ws/r/3474/17:06
jcastrokatco: yeah17:06
katcojcastro: officially, that doesn't work right now because trusty only has go1.1 i think17:07
frobwarejcastro, I was curios about this too.17:07
mgzfrobware: that one, not 3472? :)17:07
katcojcastro: unofficially, if you just use the ppa, it works great17:07
frobwarejcastro, katco: I was contemplating taking my laptop to wily but would prefer not to.17:07
cheryljfrobware, 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
katcojcastro: wwitzel3 's lightning talk in seattle was to show openstack running on his trusty laptop17:07
cheryljfrobware: I think this one:  bug 152528017:07
mupBug #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:07
katcofrobware: as a dev, you'd be fine. just use a version of juju you compile yourself or the ppa17:08
frobwarecherylj, correct. and I just discarded the DNS fix/review.17:08
katcofrobware: it's only main that wouldn't work17:08
cheryljfrobware: okay, when bug 1525280 does land in master, we'll need your DNS fix there as well17:08
jcastrokatco: ok so I tell people either wily or xenial as a minimum then?17:08
katcofrobware: 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 fine17:09
katcojcastro: yes17:09
frobwarecherylj, yep and the one for the default gw. BTW: did you create a bug for that?17:09
cheryljfrobware: 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
cheryljfrobware: unless you disagree?17:09
katcojcastro: although there is movement in getting go1.5 in trusty, so that may happen at some point17:09
frobwarecherylj, and the bad time can include a note to set a default gw?17:09
katcojcastro: at which point the next release into trusty would work17:10
cheryljfrobware: that was my thought17:10
cheryljfrobware: what do you think?17:10
frobwarecherylj, it's all text. :)17:10
cheryljheh17:10
cheryljfrobware: I'll bring it up in the release call today17:10
jcastrocherylj: mind if I get people dropping lxd notes in this doc or want me to split it off?17:10
cheryljjcastro: if there are things that you find are preventing people from using lxd, then yes, add them do the release notes.17:11
frobwaremgz, 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
cheryljjcastro: if there are other issues that should just be included in the documentation, maybe they should be in a different doc.17:11
cheryljkatco: is there a separate doc you guys are working on for documenting lxd in jujucharms.com?17:12
katcocherylj: no17:12
mgzfrobware: gotcha17:12
frobwarecherylj, inferring the default gw is a lower barrier to entry for the end user. I would want that.17:12
cheryljfrobware: if it's an easy code change, then yeah, I would agree17:13
cheryljfrobware: I can open the bug for you17:13
frobwarecherylj, please. thx.17:13
jcastrocherylj: is there a reason we should keep the release notes gdoc not public?17:23
cheryljjcastro: they are released publicly with the alpha / beta builds.17:24
frobwarecherylj, card for 1528217 forward port to master - https://canonical.leankit.com/Boards/View/101652562/11935867217:24
jcastrook so what if we want public feedback? Perhaps we should split this off?17:24
dooferladfrobware, voidspace: http://reviews.vapour.ws/r/3475/17:39
dooferladwill get to your reviews now.17:39
mupBug #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>17:59
frobwarecherylj, thanks for opening the bug18:16
cheryljfrobware: np :)18:17
* frobware EOD18:19
cheryljmgz: were you able to get frobware's changes to revert 1483879 in a feature branch to test?18:25
mgzcherylj: it's build-revision 348718:35
mgzvarious maas tests still pending18:35
cheryljmgz: awesome, thanks!18:37
mupBug #1531954 opened: Trying to use Juju without a bootstrap node has a confusing error <juju-core:New> <https://launchpad.net/bugs/1531954>18:50
dooferladfrobware: you have a +1 for http://reviews.vapour.ws/r/3474/18:57
dooferladfrobware: I would say LGTM, but some of those reverts make me sad.18:57
=== Makyo is now known as Guest3473
wallyworldkatco: hey, did you want a chat?21:11
katcowallyworld: hey, yep. 1:1?21:11
wallyworldok21:11
mupBug #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:30
natefinchericsnow: 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 deploy21:33
ericsnownatefinch: we're going to do that stuff in a worker, if I remember right21:34
ericsnownatefinch: so the transaction won't factor in21:34
natefinchericsnow: 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 time21:35
ericsnownatefinch: I'm pretty sure we don't have all the info we need, but I may be wrong21:35
cheryljhey jog, I'm looking at the test run for the revert-maas-devices branch and I see that there's an OS deployer timeout21:44
* jog looks21:44
cheryljjog: It looks like the services are still coming up.  Maybe things were slow?  I see nova-compute/0 is still installing things21:44
jogcherylj, there are other lxc's still in pending, nova-compute/0's workload status is 'blocked' maybe waiting for relations to complete...21:51
jogspecifically LXCs on machines 5 and 6.21:52
jogI'm looking to see if there is log information about what's going on there.21:53
cheryljjog: 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
cheryljjog: 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 ready21:53
cheryljjog: I can also look at the lxcs for machine 5 and 621:54
cheryljI see that they're "started"?21:55
jogcherylj, sorry I think I was looking at the wrong one.21:58
cheryljah, phew21:58
jogcherylj, the failure is due to the workload-status for all charms not setting down to 'active' or 'unknown'22:06
cheryljjog: yeah, I was wondering that.  I think, however, that it might've been premature?22:09
jogpossibly... mgz recently added the workload verification code22:09
cheryljI see that at least the nova-compute/0 unit was still chugging along after the test timed out.22:09
cheryljjog: Can we queue that branch up for a retest, at least for the 1.9 os deployer test?22:10
jogyeah and rabbitmq-server/0 is still running a hook22:10
=== alexisb is now known as alexisb-afk
jogcherylj, a second run is going on now22:11
cheryljjog: ah, perfect!22:12
jogcherylj, hmm... we are only waiting 3 minutes22:14
cheryljjog: wow, that seems short22:14
jogthat's after all unit agents become ready22:14
cheryljoh22:15
cheryljwell, still seems a bit short given the size of the deployment22:15
jogI'll hot fix in a longer timeout22:15
cheryljthanks!22:15
jogwe'll need another run after this current test22:15
cheryljif it fails again22:16
cherylj(in the same way)22:16
jogright22:16
jogother Openstack tests have passed today, on master and structured-metadata22:16
cheryljit 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 ready22:17
jogI 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 applied22:19
wallyworldmenn0: hey, you were going to email mario that mgopurge binary? i asked him last night and he hadn't received it yet22:24
menn0I emailed it to him soon after we talked22:32
menn0wallyworld:22:32
wallyworldmenn0: ok, i'll need to follow up with him and see why he didn't have it22:33
menn0wallyworld: he sent me his email privately via IRC22:33
menn0wallyworld: I just checked my sent mail and it's there22:33
wallyworldmenn0: ok, ty. no idea why he said he didn't get it22:34
menn0wallyworld: virus scanner or spam filter?22:34
wallyworldyeah, could be22:34
menn0wallyworld: I'll sent it to you now as well22:34
wallyworldok, ty22:34
menn0wallyworld: you should have the email now as well22:35
wallyworldmenn0: yep, just got it, tyvm22:35
menn0cool22:35
mwhudsonBroadcast 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 password23:06
mwhudsonis there something i can do to shut this spam up?23:06
perrito666mwhudson: soon, that is sadly something you cannot turn off in the current version of mongo, we aim to upgrade it soon23:08
mwhudsonah ok23:08

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!