[00:15] <mup> Bug #1560732 changed: Azure endpoint ACLs disappear after machine-0 restart <juju-core:New> <https://launchpad.net/bugs/1560732>
[00:24] <perrito666> man, lint really hates some juju files
[00:26]  * arosales can't get update-clouds to pick up changes to .local/share/juju/credentials/cred.yaml
[00:26] <arosales> so list-credentials doesn't see the latest
[00:26] <perrito666> creds
[00:26] <perrito666> isnt it?
[00:27] <arosales> is there a way to force juju to pick up the update?
[00:27] <arosales> perrito666: are you saying cred.yaml should be creds.yaml?
[00:27] <arosales> I can bootstrap with the current config
[00:27] <perrito666> nah, I got confused, ignore me
[00:27] <arosales> ok
[00:28] <arosales> and what is the recommended way to set a different region for a cloud
[00:29] <arosales> set-default-region?
[00:29] <wallyworld> redir: your email should be fixed now
[00:32] <redir> loos like it wallyworld, many thanks
[00:32] <redir> *looks
[00:32] <arosales> I think set-default-region is what I am looking for . . .
[00:33] <wallyworld> arosales: yes, that is the command you are looking for
[00:34]  * wallyworld likes jedis
[00:35] <wallyworld> arosales: as of beta 3, there will be no need to edit credentials.yaml by hand - you have commands like add-credential and set-default-region etc to do it all
[00:35] <wallyworld> arosales: you can also list/show credentials contents with/without secrets
[00:37] <arosales> wallyworld: well I edited the cred.yaml to add another user and show-credentails didn't pick up my changes
[00:37] <wallyworld> redir: could you subscribe to the canonical lists using your canonical email address. they will reject requests from your personal address
[00:37] <wallyworld> arosales: pastebin it if you like and i'll help
[00:38] <redir> wallyworld: I will, they did
[00:42] <perrito666> wallyworld: so, I have the manta removal ready too
[00:42] <perrito666> should I propose it against master too?
[00:43] <wallyworld> perrito666: does it depend on anything ?
[00:43] <anastasiamac> redir: r u in #canonical?
[00:43] <perrito666> wallyworld: on this http://reviews.vapour.ws/r/4303/ but I am not sure how to tell reviewboard that
[00:43] <perrito666> the depends-on field is a text field
[00:43] <perrito666> ericsnow: ?
[00:43] <wallyworld> perrito666: the reason for asking - can it be proposed agains admin-controller-model
[00:44] <perrito666> mm, I can try
[00:44] <wallyworld> perrito666: you don't do it in rb - you propose against a branch in gh
[00:44] <perrito666> wallyworld: I wanted the fancy version
[00:44] <arosales> wallyworld: http://paste.ubuntu.com/15476275/
[00:44] <perrito666> wallyworld: ill propose against admin-controller-model
[00:44] <wallyworld> perrito666: rb will pick it up automatically
[00:44] <wallyworld> just propose in gh and rb will do the right thing
[00:45] <perrito666> wallyworld: rb has fancy depends sadly I dont know how to use it, ill propose against admin-...
[00:45] <wallyworld> arosales: file should be called credentials.yaml
[00:47] <wallyworld> arosales: are you running tip of master? or a packaged beta? if tip, you can use the interactive add-credential and also autoload-credentials
[00:47] <arosales> wallyworld: beta2
[00:47] <wallyworld> beta3 will add tools to better manage credenrtials
[00:47] <arosales> I'll rename to credentials.yaml
[00:47] <wallyworld> ok, ping if that doesn't work
[00:47] <arosales> wallyworld: so should I update https://jujucharms.com/docs/devel/getting-started
[00:47] <arosales> or does this not mater in juju 2.0 ga?
[00:48] <wallyworld> if it says cred.yaml then yeah, let me look
[00:49] <wallyworld> arosales: it looks ok at first glance but is a little out of date eg list-clouds does not include lxd, manual or maas
[00:50] <arosales> wallyworld: no dice, http://paste.ubuntu.com/15476290/
[00:50] <arosales> wallyworld: well there is no specific mention of the credentails.yaml location or the exact naming requirement
[00:51] <arosales> only "juju add-credential aws -f mycreds.yaml"
[00:51] <wallyworld> arosales: no! you want ~/.local/share/juju/credentials.yaml
[00:51] <arosales> ok
[00:51] <wallyworld> arosales: the release notes contain that info
[00:51]  * perrito666 's kindgom from a straight merge
[00:52] <wallyworld> arosales: but for beta3 - no need to deal with this stuff anynmore thankfully
[00:52] <wallyworld> it's all very manual in beta2
[00:53] <arosales> wallyworld: ok that works
[00:53] <wallyworld> arosales: awesome, sorry about the hassle with it, it's wip :-)
[00:53] <arosales> wallyworld: I do like setting my defaults in a yaml file so I always don't have to specify them at the command line
[00:54] <wallyworld> yep
[00:54] <arosales> wallyworld: no worries
[00:54] <arosales> glad to be trying it out, and thanks for the help
[00:54] <wallyworld> sure, thanks for testing for us :-)
[00:54] <wallyworld> beta3 will be awesome
[00:55] <perrito666> wallyworld: https://github.com/juju/juju/pull/4857
[00:55] <arosales> wallyworld: I am looking forward to it
[00:55] <perrito666> going for dinner, bbl
[00:55] <mgz> don't promise too big wallyworld :P
[00:55] <wallyworld> thank perrito666
[00:55] <wallyworld> mgz: i'm optimistic :-)
[00:55] <perrito666> wallyworld: and for the other one http://reviews.vapour.ws/r/4303/
[00:55] <wallyworld> perrito666: ta, will look
[01:06] <redir> how does one undeploy? i.e. a failed deploy of a charm?
[01:07] <mgz> redir: depends on the reason
[01:07] <mgz> redir: machine didn't come up? retry-provisioning
[01:07] <redir> mgz: correct on failure and thanks
[01:08] <mgz> redir: install hook failed? resolved --retry
[01:08] <redir> didn't come up on aws
[01:09] <mgz> for debug purposes it's often useful to use the underlying cloud commands to see what juju is seeing
[01:10] <redir> mgz such as ec2-provider? or other commands?
[01:11] <mgz> I tend to use euca2ools against ec2, there are lots of options
[01:14] <redir> mgz oic. Thanks
[01:14] <redir> retry-provisioning worked
[01:14]  * redir eod
[01:22] <cherylj> wth happened on the last CI run?
[01:26] <anastasiamac> cherylj: hurddles?
[01:27] <mgz> cherylj: which last one...
[01:27] <cherylj> mgz: http://reports.vapour.ws/releases/3803
[01:27]  * thumper wonders how much he just broke...
[01:28] <cherylj> everything.  You broke everything, thumper
[01:28]  * cherylj slow clap
[01:28] <cherylj> just kidding :)
[01:28] <thumper> :)
[01:29] <mgz> jenkins is intermittently returning that atm
[01:29] <mgz> I hadn#'t seen it'd affected quite so many tests
[01:30] <mgz> cherylj: I did something dangerous 1 hour ago, but I see that's from 2 hours ago so am much pleased
[01:30] <cherylj> haha
[01:30] <mgz> I may just restart the frontend machine
[01:30] <mgz> and look at its juju logs
[01:31] <mgz> /apache logs
[01:31] <cherylj> mgz: so from the last full run on master, we had the windows build failures, which I already fixed.
[01:31] <cherylj> mgz: and bug 1558901
[01:31] <mup> Bug #1558901: TestAddLocalCharmSuccess read has been closed <ci> <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1558901>
[01:32] <cherylj> mgz: and that charmstore v5 ppcel failure
[01:32] <mgz> cherylj: I have a fix for that
[01:32] <cherylj> oh?
[01:32] <cherylj> you're my hero, mgz
[01:32] <mgz> I am just doing three things at once so haven't proposed yet
[01:32] <cherylj> mgz what's the fix
[01:32] <mgz> cherylj: we also had secgroup exhaustion on canonistack
[01:33] <mgz> cherylj: rather than doing approx
[01:33] <mgz> switch obj:
[01:33] <mgz> case someTagType{}
[01:33] <mgz> instead do:
[01:33] <mgz> switch obj.(type)
[01:34] <mgz> case someTagType
[01:34] <mgz> which doesn't confuse some gcc const optimiser
[01:34] <cherylj> ah
[01:48] <thumper> boo
[01:48] <thumper> allWatcherStateSuite.TestStateWatcherTwoModels
[01:48] <thumper> intermittent test failure
[01:49] <axw> wallyworld: sorry for delay, reviewed
[01:49] <wallyworld> np, ty
[01:52] <wallyworld> axw: a small one also http://reviews.vapour.ws/r/4305/
[01:57] <mup> Bug #1560757 opened: allWatcherStateSuite.TestStateWatcherTwoModels intermittent failure <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1560757>
[02:32] <axw> wallyworld: forgot to mention, cmd/modelcmd merge looked find
[02:32] <axw> fine*
[02:32] <wallyworld> axw: gr8, ty
[02:38] <axw> wallyworld: one other thing we're missing, "juju logout"
[02:39] <wallyworld> axw: yeah, i have indicated that will slip to next week
[02:39] <wallyworld> along with tidying up controller listing
[02:39] <axw> wallyworld: ok
[02:39] <wallyworld> to show logged in controllers etc
[02:39] <axw> wallyworld: tidying up controller listing?
[02:39] <axw> ok
[03:40] <wallyworld> axw: if you get time, here's a charm deployment bug fix http://reviews.vapour.ws/r/4308/
[03:49] <axw> wallyworld: lgtm. should probably check with uros to make sure the charm store should be allowing that
[03:49] <axw> seems a bit weird to allow in charm store charms
[03:49] <axw> local case is sane tho
[03:49] <wallyworld> axw: yeah, he was the one who pinged me about the issue; my comments in the bug are a guess,he just sent me a pastebin; i have a meeting this arvo to follow up
[03:49] <wallyworld> but the fix is good regardless
[03:50] <axw> ok
[03:51] <axw> wallyworld: for list-controllers, I'm going to add cloud type to controllers.yaml. the rest is already in bootstrap config, and can't be expected to exist in controllers.yaml anyway (e.g. if you do "juju register", most of that info is gone)
[03:52] <wallyworld> axw: what about when we start to support heteroegeous controllers?
[03:52] <wallyworld> cloud type shouild be on the model?
[03:52] <wallyworld> for future proof
[03:53] <wallyworld> we could include the admin model cloud type or something for now when we list
[03:53] <axw> wallyworld: I'd prefer not to special case some model like that
[03:53] <axw> wallyworld:
[03:54] <axw> wallyworld: tho I suppose we could just check the UUID
[03:54] <axw> hrmmmmm
[03:54] <wallyworld> it would just be the default for now for list controllers - i meant yeah check the uuid
[03:54] <wallyworld> if model uuid == controller uuid
[03:55] <axw> wallyworld: what if the user doesn't have access to the admin model though?
[03:55] <wallyworld> we can still tell them what type of cloud it is though - this is client side right?
[03:55] <wallyworld> i'm going frm memory, need to read the bug again
[03:55] <axw> wallyworld: how...? they can't list the models they don't have access to
[03:56] <wallyworld> hmmm, right we may need to refresh models
[03:56] <wallyworld> if they don't have access, can we not report the cloud type then
[03:56] <axw> wallyworld: I'm saying if you don't have permissions to do it. but yes, that too
[03:57] <wallyworld> i guess though people would want to know cloud type regardless of if theyhave admin model access
[03:57] <axw> most of the time, yeah
[03:58] <wallyworld> but that holds only for homogenoues controllers
[03:58] <wallyworld> since it doesn't make sense otherwise
[03:58] <axw> wallyworld: well, there's the cloud that the controller runs in
[03:58] <axw> wallyworld: and the cloud(s) that it manages
[03:59] <axw> currently one and the same, but later on cloud-that-it-runs-in is still valid
[03:59] <wallyworld> yes but if you don't have admin access, then what do you want to know that for
[03:59] <axw> true.
[03:59] <wallyworld> if you can create a model of your own in whatever cloud you want
[03:59] <axw> wallyworld: I wonder if we shouldn't just use bootstrap config for this
[03:59] <axw> wallyworld: all this info is in bootstrap config already
[04:00] <wallyworld> it is yes
[04:00] <wallyworld> but not on everyone's machine
[04:00] <wallyworld> i do like adding it to model metadats for that reason
[04:00] <wallyworld> since that gets refreshed
[04:01] <wallyworld> axw: so the person who asked for this would be a controller admin, we could do it per model so long as you have admin access, and get feedback
[04:01] <wallyworld> it will satisfy that initil use case
[04:02] <wallyworld> we can easily change / extend to get from bootstrap config. but even then, if you have bootstrap config you'd be admin
[04:03] <axw> wallyworld: I think I could live with having it on model details, but I'm not so keen on requiring a model refresh to get the admin model
[04:04] <wallyworld> axw: sgtm, you would expect to have that
[04:04] <axw> wallyworld: what sounds good? expect what?
[04:05] <wallyworld> not having a model refresh because it's not needed because you'd expect to have those model details
[04:05] <wallyworld> axw: i was just suggesting having it on model for the reasons outlined, if there's a show stopper then we can think of something else
[04:05] <wallyworld> but to me it makes sense anyway :-)
[04:23] <axw> wallyworld: seeing as adam wants the maas-server and other info anyway, I'm treating them as orthogonal. we'll render bootstrap config if we have it, which addresses his immediate needs. we can add type to model if/when it's needed. people can already do "juju get-model-config type" if they need to
[04:24] <wallyworld> axw: sgtm
[04:28] <wallyworld> axw: later when you are free, here's a pr to remove manta from joyent. credentials entry nicer now http://reviews.vapour.ws/r/4309/
[04:37] <axw> wallyworld: will take a look after lunch
[04:37] <wallyworld> axw: np, there's a queue anyway
[05:10] <axw> wallyworld: done
[05:10] <wallyworld> ta
[06:11] <wallyworld> axw: i had one question/suggestion
[06:11] <wallyworld> thoughts?
[06:13] <axw> wallyworld: yeah, I was thinking that too, for the type anyway. the name is pretty much useless, because it's always going to be "admin"
[06:14] <axw> wallyworld: how about this: I'll remove name, take type up to the top level, and if that's all that's in config, omit config
[07:07] <wallyworld> axw: sgtm
[07:07] <wallyworld> axw: a small fix http://reviews.vapour.ws/r/4314/
[07:11] <axw> wallyworld: looking
[07:15] <axw> wallyworld: LGTM, just one request
[07:15] <wallyworld> sure ty
[08:02] <axw> wallyworld: are any of the other cards more important to you than others?
[08:02] <axw> oh, there was the list-models one
[08:06] <wallyworld> axw: yeah, i retested that but couldn't repro
[08:06] <wallyworld> axw: i reckon we should print the current controller when listing models
[08:07] <wallyworld> axw: as for cards, anything usability related, so the text when registering if there's no current model etc, or warning when --config has unknown values
[08:09] <wallyworld> axw: also, roger suggested renaming controller apiendpoints and servers to APIEndpoints and ResolvedAPIEndpoints
[08:09] <wallyworld> well i guess that's one rename
[08:44] <axw> wallyworld: yeah, the field names there already aren't great
[08:44] <axw> ok, I'll just pick off some stuff
[08:45] <wallyworld> ta
[08:49] <wallyworld> axw: have started manually testing restore, something looks broken. i manually kill the controller, the only machine, and restore -b, and it detects that there's no controllers and then proceeds to try and connect continually to the (killed) controller ip
[08:49] <wallyworld> i have soccer but will look later, unless you are able to take a look while i'm gone
[08:49] <wallyworld> the original admin-secret issue is fixed, tis occurs after that
[08:52] <urulama> wallyworld: multi-series charms are ok now
[08:52] <wallyworld> urulama: yay, awesome
[08:52] <urulama> wallyworld: indeed, thanks for the quick fix
[08:53] <wallyworld> np, i'm an "expert" :-)
[08:53] <urulama> LOL
[08:53] <wallyworld> urulama: still a bit concerning that the stored charm metadat *seems* to lack series
[08:53] <wallyworld> we'll need to dig into that
[08:55] <urulama> wallyworld: you're using charmstore v5 to get the blob, right? if you're using v4, that would indeed be the case, you'd get a blob where metadata doesn't have series
[08:55] <wallyworld> urulama: not sure tbh, i think it's v5 since i think i merged master after those changes landed
[08:56] <urulama> wallyworld: ok, let's dig in for beta4
[08:56] <wallyworld> yep, i'll add it to the list
[08:58] <wallyworld> axw: yeah, so it finally timed out
[08:58] <wallyworld> 1-85dd-bc5bff067743/api: dial tcp 54.237.98.19:17070: getsockopt: connection timed out
[08:58] <wallyworld> 2016-03-23 08:56:58 ERROR cmd supercommand.go:448 getting API info: addresses for [] not found
[08:59] <wallyworld> off to soccer, look check back later
[08:59] <wallyworld> will
[09:08] <voidspace> babbageclunk: heya, morning
[09:08] <voidspace> babbageclunk: how was your first day?
[09:08] <babbageclunk> voidspace: Hi, great thanks!
[09:09] <voidspace> babbageclunk: did you get company email and access to HR systems working?
[09:09] <TheMue> babbageclunk: heya, greetings from a former team member
[09:09] <voidspace> babbageclunk: and yay, you're working with us - that's great :-)
[09:09] <babbageclunk> voidspace: Yup yup.
[09:09] <babbageclunk> TheMue: Cheers!
[09:09] <voidspace> babbageclunk: we have standup meetings at 10am - can you see them on your calendar?
[09:09] <voidspace> babbageclunk: if not I can give you the link
[09:10] <voidspace> TheMue: o/ morning
[09:10] <TheMue> voidspace: o/ heya
[09:10] <voidspace> babbageclunk: I'm going to have a chat with Tim about work changes on the MAAS 2.0 provider in about half an hour
[09:10] <voidspace> babbageclunk: you can join us if you like, so you can help with the work
[09:11] <babbageclunk> voidspace: yup, Dimiter invited me to them. I guess I should go into one of the chill areas for that.
[09:11] <voidspace> babbageclunk: getting your HR stuff done *and* getting a dev environment setup is pretty good for day 1
[09:11] <babbageclunk> voidspace: :)
[09:11] <voidspace> babbageclunk: getting MAAS setup in KVM will probably take a chunk of day 2...
[09:12] <babbageclunk> voidspace: Yeah, I'd like to join in the MAAS talk
[09:12] <babbageclunk> voidspace: ok - any tips on where to start? I've got virt-manager installed.
[09:12] <voidspace> babbageclunk: this guide is helpful
[09:12] <voidspace> https://insights.ubuntu.com/2013/11/15/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/
[09:12] <voidspace> babbageclunk: I think that's the one I used
[09:13] <voidspace> babbageclunk: the important thing is to setup a network in virt-manager for the instances to communicate
[09:13] <babbageclunk> voidspace: ok, cool - I'll start working through that.
[09:13] <voidspace> babbageclunk: and so that maas can manage dhcp for that network
[09:14] <voidspace> babbageclunk: once you get it installed you can repeat with MAAS 2.0...
[09:14] <voidspace> babbageclunk: for this work we really need *both* unfortunately
[09:17] <babbageclunk> voidspace: send me a link for the MAAS chat with Tim?
[09:17] <voidspace> babbageclunk: yep, when he lets me know where :-)
[09:17] <babbageclunk> voidspace: cool cool
[09:17] <voidspace> babbageclunk: when setting up the KVM instances for MAAS I generally give the MAAS controller a 20gb disk and the nodes 10gb
[09:18] <voidspace> babbageclunk: that link is a little old for setting up maas - setting it up through the web ui is pretty easy
[09:18] <voidspace> babbageclunk: the important thing is getting the network setup, and then when you install ubuntu on the maas controller you need to manually configure networking
[09:19] <voidspace> babbageclunk: i.e. pick an ip address on the subnet of the network you created in virt-manager
[09:19] <voidspace> babbageclunk: for me, the virt-manager network is 172.16.0.0/24 and I give the controller 172.16.0.2
[09:21] <babbageclunk> voidspace: ok, thanks.
[09:29] <babbageclunk> voidspace: stupid question: despite that link saying 13.10, there's nothing wrong with using 15.10, right?
[09:31] <voidspace> babbageclunk: for maas 1.9 I use trusty (14.04)
[09:31] <voidspace> babbageclunk: for maas 2.0 you will need to use xenial (16.04)
[09:31] <voidspace> babbageclunk: 15.10 would be fine for maas 1.9 though - possibly better, not sure :-)
[09:36] <babbageclunk> voidspace: thanks
[09:38] <babbageclunk> voidspace: And just grab the current daily desktop image for xenial from here? Or is there a better source?
[09:39] <babbageclunk> voidspace: oops http://cdimage.ubuntu.com/daily-live/current/
[09:39] <voidspace> babbageclunk: yeah, start with the daily - update/upgrade dance will pull in changes anyway
[09:39] <voidspace> babbageclunk: except use the server image not desktop
[09:40] <babbageclunk> voidspace: Where can I find the server one?
[09:40] <voidspace> ah
[09:40] <voidspace> hang on
[09:41] <voidspace> let me google that for you...
[09:41] <thumper-afk> o/ voidspace
[09:41] <thumper-afk> voidspace: calling
[09:41] <babbageclunk> voidspace: ok, I did that instead, sorry!
[09:41] <voidspace> thumper-afk: I couldn't find the tab that was making the noise!
[09:41] <thumper-afk> heh
[09:41] <voidspace> thumper-afk: can we do it in a hangout so babbageclunk can join?
[09:41] <thumper-afk> ack
[09:42] <thumper> voidspace: was trying
[09:42] <thumper> voidspace: make one
[09:42] <voidspace> thumper: babbageclunk: https://plus.google.com/hangouts/_/canonical.com/juju-maas2
[09:42] <babbageclunk> voidspace: incoming
[09:45] <voidspace> babbageclunk: where are you punk?
[09:45] <babbageclunk> voidspace: "requesting to join video call"
[09:46] <voidspace> babbageclunk: can you not join with your canonical id?
[09:46] <menn0> babbageclunk: hi!
[09:47] <menn0> babbageclunk: on the first screen when you join a hangout, the Google account in use is shown in a small font at the bottom. It's often wrong when you click an arbitrary link to a hangout.
[09:47] <menn0> but you can switch it
[09:54] <babbageclunk> menn0: Hi! Yeah, I worked that out after a bit.
[09:54] <menn0> babbageclunk: it took me weeks, so you're doing well :)
[09:54] <babbageclunk> menn0: On now, not understanding a whole lot! Reminds me of the first meetings I went to at BATS.
[09:55] <menn0> babbageclunk: that's quite normal
[10:01] <dooferlad> voidspace, dimitern, babbageclunk: standup?
[10:02] <voidspace> dooferlad: in a meeting with thumper right now
[10:02] <dooferlad> voidspace: everyone?
[10:03] <voidspace> dooferlad: me and babbageclunk
[10:03] <dooferlad> voidspace: is it relevant to me, or should I wait until you are done?
[10:03] <voidspace> dooferlad: dimitern: postpone a little bit please
[10:03] <voidspace> dooferlad: it's about 2.0
[10:04] <mup> Bug #1560888 opened: bootstrap aws fails but leaves instance alive <juju-core:New> <https://launchpad.net/bugs/1560888>
[10:04] <voidspace> dooferlad: maas 2.0 I mean
[10:04] <voidspace> dooferlad: so not relevant to you I don't think
[10:05] <dooferlad> voidspace: ack
[10:22] <voidspace> dooferlad: dimitern is on holiday now
[10:22] <dooferlad> voidspace: ah
[10:46] <mup> Bug #1560920 opened: State.RestoreInfoSetter code/tests woefully inadequate <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1560920>
[10:47] <babbageclunk> voidspace, thumper - where'd everyone go?
[10:47] <voidspace> babbageclunk: we're there...
[10:48] <voidspace> babbageclunk: you're a square
[10:48] <voidspace> babbageclunk: we're done
[10:48] <babbageclunk> voidspace: ok, won't join back in!
[10:49] <voidspace> babbageclunk: liar
[10:54] <thumper> right, off to bed
[10:55] <thumper> later folks
[10:55] <voidspace> thumper: g'night and thanks
[10:59] <wallyworld> axw: found restore issue, fixing
[11:00] <jam> perrito666: so because of the earlier problems I went ahead and added the push hook to my work area. But it turns out that go-1.6 is slow enough with "vet" && "build" that half the time the push fails because it takes to long to run verify.bash
[11:00] <jam> yay
[11:00] <jam> so it tends to be more of a "git push" ^C, ./scripts/verify.bash, "git push --no-verify"
[12:17] <axw> wallyworld: what was it?
[12:17] <axw> never mind, I see your PR
[12:17] <wallyworld> axw: found another issue - i think i need to set the current model to admin also
[12:17] <wallyworld> or else bootstrap eventually fails after ages
[12:18] <wallyworld> still need to diagnose that
[12:22] <axw> wallyworld: ok. your changes LGTM, I'll be around for a little longer if you want me to review
[12:22] <axw> not a lot longer tho
[12:22] <wallyworld> axw: np, ty
[12:23] <wallyworld> axw: it gets all the way through bootstrap and eventually times out after starting jujud agent, so hopefully is a small problem
[12:35] <wallyworld> axw: retesting, i think i need to set the original controller uuid into the cfg used t create the environ
[12:42] <axw> wallyworld: is NewGetBootstrapConfigFunc not already doing that?
[12:42] <axw> wallyworld: when you restore, it's expected that your controller details on disk match what's in the backu
[12:42] <wallyworld> let me check
[12:42] <axw> p
[12:43] <axw> wallyworld: (one of the limitations I'd like to get away from, by making backups portabe)
[12:43] <axw> portable*
[12:43] <wallyworld> axw: i was just looking at the symptoms which were in the log info messages which is that the code to open the admin model after the agent starts simply fails
[12:44] <wallyworld> claiming the model cannot be found
[12:44] <wallyworld> was hoping to avoid detailed debugging, but seems like i lost that bet
[12:53] <axw> wallyworld: double check that the ca-cert and private key extracted from metadata are valid?
[12:53] <wallyworld> axw: it finally completed this time after i set current model to "admin", yeah i missed where we were setting the controller uuid
[12:54] <axw> wallyworld: huh, ok
[12:54] <wallyworld> so it didn't like having current model set to a model with an invalid uuid
[12:54] <axw> wallyworld: I see. because you were on the default model I guess?
[12:54] <wallyworld> yup
[12:54] <axw> and it didn't match what was in the new hosted model
[12:54] <wallyworld> but jeez, it took a long time after the agent started
[12:54] <wallyworld> yep
[12:55] <wallyworld> cause we generate a new one
[12:55] <wallyworld> hence my todo to clean that up
[12:55] <wallyworld> i'd like to support multi-model properly
[12:56] <axw> wallyworld: yeah, needs an overhaul. we shouldn't need anything on the client except the backup file
[12:56] <wallyworld> axw: sadly CI is part way through a admin-controller-model branch run, so then it will run master etc, so it will be ages before we see another run
[12:56] <wallyworld> yep
[12:57] <axw> joy
[12:57] <wallyworld> needs to be rewritten :-(
[12:57] <wallyworld> for 2.1 i guess
[13:01] <wallyworld> axw: nearly http://reports.vapour.ws/releases/3807
[13:02] <wallyworld> not sure why the failing joyent tests aren't listed
[13:03] <wallyworld> axw: TestAddUserAndRegister seems to be failing regularly on windows sadly
[13:03] <axw> wallyworld: doh. so that and restore are the last things it appears?
[13:03] <voidspace> babbageclunk: back by the way - just making tea for the carpet cleaner man
[13:04] <wallyworld> axw: yeah, i need to check the joyent logs since those tests are shown as failing
[13:04] <voidspace> babbageclunk: and then seeing how bad it is trying to merge master onto drop-maas-1.8
[13:04] <wallyworld> axw: that windows test could be this branch, need to check
[13:04] <voidspace> babbageclunk: if dimitern landed the multi-nic support on master it may be very bad...
[13:04] <voidspace> babbageclunk: in which case I'll postpone
[13:05] <babbageclunk> voidspace: Having trouble getting the maas controller set up - can install and configure everything, but then when it reboots post install I just get a weirdly corrupted screen.
[13:06] <wallyworld> axw: ah ha
[13:06] <wallyworld> validating "credentials" credential for cloud "joyent": unknown key "manta-key-id"
[13:06] <axw> wallyworld: doh :)
[13:06] <wallyworld> we need to get the creds updated
[13:06] <axw> wallyworld: I've gotta go. I have a bunch of changes to make the error messages for no-current-controller and no-current-model more readable, but need to update tests befroe I can propose
[13:07] <wallyworld> axw: np, ty, see you tomorrow
[13:07] <axw> bonne nuit
[13:07] <wallyworld> Gute Nacht
[13:08] <axw> well that's not a very nice thing to say
[13:08]  * axw actually goes
[13:10] <jamespage> jam, anastasiamac: hey - so smoser and I are discussing what the virt attribute should be set to for the multi-hypervisor openstack cloud stuff
[13:11] <jamespage> 'lxd' and 'kvm' is my preference - what do you think? its inline with virt terms used by juju already...
[13:11] <jamespage> but that is a deviation from anastasiamac changes which are currently lxd and qemu in goose I think...
[13:14] <anastasiamac> jamespage: I have not changed goose
[13:14] <anastasiamac> jamespage: in juju we are expecting "lxd" and "qemu"
[13:14] <anastasiamac> jamespage: if u'd like different values, it's a simple change but change nonetheless (on our end) \o/
[13:15] <jamespage> anastasiamac, yeah I understand that - just trying to see if we can get some consensus on what these values should be
[13:15] <anastasiamac> jamespage: note that you can specify anything you like in simple streams
[13:15] <jamespage> as we already use virt types in other parts of juju
[13:15] <jamespage> anastasiamac, how does juju map to the stream data ?
[13:15] <anastasiamac> jamespage: but if u want to filter and use it in constraints, these are the values :D
[13:15] <jamespage> anastasiamac, right
[13:16] <anastasiamac> jamespage: each provider can have different values
[13:16] <anastasiamac> jamespage: for ec2, it's "pv" and "hvm"
[13:17] <anastasiamac> jamespage: for azure, "Hyper-V", etc..
[13:18] <jam> anastasiamac: http://www.innervoice.in/blogs/2014/03/10/kvm-and-qemu/
[13:18] <jam> kvm != qemu AFAICT
[13:18] <anastasiamac> jamespage: so, to answer ur q, we don't really "map" so much as "compare" what we see in simpel streams with what we expect on instance type and what was given as a contraint
[13:19] <anastasiamac> jam: jamespage: I have only used the values as "lxd" and "qemu" since this is what you gave :D I understood it as a requirement :P
[13:21] <jam> jamespage: virtmanager seems to treat them differently, though it looks like its how it runs it, not the actual file format.
[13:21] <jamespage> yes that is the case
[13:21] <jam> so as anastasiamac we're probably agnostic
[13:21] <jam> name it what you want, and ask Juju to run the one that you named it.
[13:22] <jam> jamespage: as for LXD, its support for image formats seems to actually want to have a root.tar.gz + some extra metadata
[13:22] <anastasiamac> jam: this would b true if we did not validate constraints...
[13:23] <jam> anastasiamac: ah, we restrict what you can pass in?
[13:23] <jam> http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:download.sjson
[13:23] <jam> you can see there are 2 files
[13:23] <jam> root.tar.gz and lxd.tar.xz are what the LXD codebase reads
[13:24] <anastasiamac> jam: we validate constraints if they are given
[13:24] <jamespage> jam: well that's not quite true for lxd in openstack - we just use the root.tar.gz
[13:24] <jamespage> jam: the other part of this change is populating stream data in the openstack cloud with appropriate virt attributes
[13:25] <jam> jamespage: so *I* don't have any clue what the extra data is, just that if you do "lxc launch ubuntu:trusty" it grabs both files, combines them somehow and validates the LXD hash matches the "combined_sha256"
[13:25] <anastasiamac> jam: jamespage: if u populate virt in simple streams with "lxd" and "qemu" now, juju tip is ready for it :D
[13:26] <jamespage> anastasiamac, yes I understand that
[13:26] <jamespage> sorry - my question is about what this should be, not what we have right now...
[13:26] <jamespage> jam, anastasiamac: we do juju deploy --to lxd:0 or --to kvm:0
[13:26] <jam> jamespage: kvm does feel like it is going to match up better with what other people are going to be using.
[13:26] <jamespage> should this be consistent with that....
[13:26] <jam> jamespage: correct "kvm:0" and "lxd:0"
[13:26] <jamespage> yup
[13:27] <jam> jamespage: but that is for containers inside the machine
[13:27] <jamespage> so this is a 'what is the juju experience question...'
[13:27] <jam> if Openstack has multiple hypervisors
[13:27] <jam> I have no idea what the exact syntax is
[13:27] <jamespage> juju deploy mysql --constraints="virt-type=lxd"
[13:27] <jamespage> juju deploy mysql --constraints="virt-type=kvm"
[13:27] <jamespage> I think
[13:27] <rick_h_> jam: jamespage anastasiamac I think it should be kvm please
[13:27] <jam> juju deploy --constraints virt=kvm
[13:27] <jam> jamespage: I wonder if it is confusing to have both syntaxes
[13:27] <rick_h_> jam: jamespage anastasiamac we're talking and folks are asking for kvm and trying to map qemu isn't a win for clarity/etc.
[13:28] <jamespage> rick_h_, that was my take...
[13:28] <jamespage> but wanted to chat :-)
[13:28] <jam> jamespage: :). I would tend to agree, but I would actually focus on what people think of in Openstack terms vs Juju terms.
[13:28] <jamespage> I think that they think kvm or lxd
[13:28] <jamespage> not lxc or qemu
[13:29] <rick_h_> jam: exacly, all our RFI and such ask for KVM support
[13:29] <jamespage> LXD vs KVM after-all
[13:29] <jamespage> ;-)
[13:29] <jam> virt-type=cgroup-machine-containers ?
[13:29] <rick_h_> jam: and our whole discussion is kvm, lxd, and hyper-v
[13:29] <jamespage> ohh now that is a good question....
[13:29] <rick_h_> lol
[13:30] <jamespage> anastasiamac, jam: the test cloud is currently populated with 'lxd' and 'kvm' for virt attributes
[13:30] <natefinch> rogpeppe, ericsnow: https://github.com/juju/charmrepo/pull/80 - changed GetResource to return bytes + full metadata, using multipart body.
[13:31] <jamespage> if we're agreed that's all good then I'll ask smoser to land my simplestreams changes...
[13:32] <anastasiamac> jamespage: "lxd" and "kvm" are reasonably awesome. I'll change values on juju side  \o/
[13:32] <rick_h_> ty anastasiamac
[13:32] <jamespage> anastasiamac, +1 great
[13:32] <voidspace> babbageclunk: wasn't multi-nic support that had landed, just a trivial conflict
[13:32] <rogpeppe> natefinch: do you really think the multipart thing is less ugly than using headers?
[13:32] <babbageclunk> voidspace: oh, nice.
[13:33] <anastasiamac> jamespage: can I keep access to my wonderful cloud for a while longer - like a week more :D?
[13:33] <jamespage> anastasiamac, sure
[13:33] <voidspace> babbageclunk: I've pushed and run tests, about to create PR
[13:33] <anastasiamac> jamespage: tyvm!
[13:34] <rogpeppe> natefinch: you do know that encoding/json always reads all the bytes of the object into its buffer before parsing, right?
[13:35] <babbageclunk> voidspace: I recreated my controller, but I still get weird graphical corruption after reboot
[13:36] <babbageclunk> voidspace: sent you a screenshot
[13:37] <voidspace> babbageclunk: not got the screenshot, but...
[13:37] <natefinch> rogpeppe: gah, no, I didn't realize it just reads the whole thing..
[13:37] <voidspace> babbageclunk: I sometimes get that and a "force reset" cures it
[13:37] <voidspace> babbageclunk: however, I usually don't bother - because I boot without opening the display and then ssh in
[13:37] <natefinch> rogpeppe: I hoped it was smarter than that... though it may be a technical limitation, I guess
[13:38] <natefinch> rogpeppe: and yes, I think the multipart thing is way less ugly
[13:38] <voidspace> babbageclunk: yeah, that looks like what I sometimes get - see if a "force reset" helps
[13:38] <voidspace> babbageclunk: alternatively wait until CPU activity settles down and try ssh'ing in anyway
[13:38] <rogpeppe> natefinch: well, we're gonna read everything into memory anyway, right?
[13:38] <rogpeppe> natefinch: so we're O(n) space anyway
[13:39] <natefinch> rogpeppe: I figured if we accidentally try to deserialize a 100 meg zip file, it would bail early and not load 100 megs into RAM
[13:39] <rogpeppe> natefinch: tbh I like endpoints that I can easily use with command-line tools, and multipart responses are awkward
[13:39] <rogpeppe> natefinch: hopefully we're talking to the server we expect to be talking to
[13:40] <rogpeppe> natefinch: we could accidentally try to deserialize a 100 meg JSON object...
[13:40] <natefinch> rogpeppe: it may be more difficult to use some CLI tools with the endpoint, but it makes the code - which is what we maintain, way way simpler, and think that's well worth it.
[13:41] <rogpeppe> natefinch: +79 -51
[13:41] <rogpeppe> natefinch: really simpler?
[13:41] <natefinch> rogpeppe: I didn't add headers for all the other fields we were going to have to support to support the full resource
[13:42] <rogpeppe> natefinch: wouldn't it be better just to have another endpoint to return resource metadata?
[13:43] <rogpeppe> natefinch: which would be consistent with the way we treat charm archives, for example
[13:43] <natefinch> rogpeppe: I was just saving us a round trip
[13:43] <rogpeppe> natefinch: i don't think it's worth it
[13:43] <rogpeppe> natefinch: send 'em both concurrently if you care
[13:44] <babbageclunk> voidspace: gah, why does my irc connection keep dropping?
[13:44] <natefinch> rogpeppe: I'm still unclear on why you think this is worse.  Just because of the multipart stuff?
[13:44] <rick_h_> natefinch: is there an api call to just get the binary and one to just get the metadata?
[13:45] <rick_h_> natefinch: e.g. how can the gui load the metadata and then offer a download link for just the bytes to the browser through the api?
[13:45] <rogpeppe> natefinch: mostly API consistency. it's something we don't do currently, and i'm not sure there's enough reason to set a precedent here.
[13:45] <rogpeppe> natefinch: and yes, the multipart stuff seems ugly to me.
[13:45] <natefinch> rick_h_: that's a good point. Certainly having an enpoint for just the metadata seems like it would generally be useful
[13:46] <rick_h_> natefinch: yes, clients will want to get at that without the bytes please
[13:46] <voidspace> babbageclunk: no idea - did you get my messages?
[13:47] <voidspace> babbageclunk: can you ssh in despite the corruption?
[13:47] <natefinch> rick_h_: we have an endpoint that returns all the metadata for all resources for a charm... that's likely what the GUI would use, btw.  But we can add an endpoint for a one-by-one call, too
[13:47] <babbageclunk> voidspace: I got some messages...
[13:47] <babbageclunk> voidspace: yup, I can ssh in
[13:47] <rogpeppe> natefinch: BTW I think it might be unnecessary to provide a way to get the resource without specifying a revision.
[13:48] <rick_h_> natefinch: yes, should be filterable at least as we attempt to do things like allow upload/current data, etc. on specific resources
[13:48] <voidspace> babbageclunk: you don't need the display anyway
[13:48] <rick_h_> natefinch: at some point in time we'll want to show the charmstore history of a resource
[13:48] <natefinch> rogpeppe: yes, I assumed we'd always be requesting metadata for a specific revision of a resouce
[13:48] <babbageclunk> voidspace: Sweet, not blocked on that anymore.
[13:48] <rogpeppe> natefinch: the client code doesn't seem to assume that
[13:49] <rogpeppe> natefinch: (lines 279, 293 in the old file)
[13:49] <voidspace> babbageclunk: if you've installed maas you should be able to get to it via the web ui
[13:50] <natefinch> rogpeppe: oh, good point.. that's actually old code that should have been removed.  At one point I had toyed with allowing -1 for a revision, but we decided it wasn't really necessary
[13:50] <voidspace> babbageclunk: probably at http://172.16.0.2/MAAS
[13:50] <natefinch> rogpeppe: (there was more surrounding code to support it, I just forgot to remove that part evidently)
[13:50] <rogpeppe> natefinch: that also removes the need for the revision header too
[13:50] <anastasiamac> mattyw: ping
[13:50] <mattyw> anastasiamac, hey there, have a review for me?
[13:50] <natefinch> rogpeppe: yep
[13:50] <rogpeppe> natefinch: probably good to leave the hash header in there so match what archives do
[13:51] <anastasiamac> mattyw: read my mind \o/ trivial plz - https://github.com/juju/juju/pull/4875
[13:51] <anastasiamac> mattyw: oops, here is rb link http://reviews.vapour.ws/r/4324/
[13:51] <natefinch> rogpeppe: also useful to be able to double check that you got the right data
[13:51] <rogpeppe> natefinch: exactly.
[13:52] <mattyw> anastasiamac, I normally ignore people that don't send rb links, but I'll make an exception ;)
[13:52] <rogpeppe> natefinch: and a header seems like a good fit for that
[13:52] <natefinch> rogpeppe: definitely
[13:52] <anastasiamac> mattyw: I sent both just to be special :D
[13:53] <mattyw> anastasiamac, if you're sure that's the fix then LGTM
[13:53] <natefinch> rogpeppe: so I'm going to rename GetResource to DownloadResource, to make it more obvious, and make a new GetResource that returns metadata
[13:54] <rogpeppe> natefinch: I think GetResource is still right
[13:54] <rogpeppe> natefinch: it's consistent with GetArchive
[13:54] <anastasiamac> mattyw: tyvm \o/
[13:55] <rogpeppe> natefinch: the resource info will probably be a meta endpoint, right?
[13:55] <natefinch> rogpeppe: yes
[13:55] <natefinch> rogpeppe: that doesn't help me name the function in the client wrapper though :)
[13:55] <rogpeppe> natefinch: and hence amenable to Meta
[13:56] <natefinch> rogpeppe: GetResourceMeta?
[13:56] <rogpeppe> natefinch: no, I don't think you need a new API entry point
[13:56] <rogpeppe> natefinch: the existing Meta method should be up to the job
[13:56] <rogpeppe> natefinch: well... maybe
[13:57] <rogpeppe> natefinch: probably not actually
[13:58]  * rogpeppe tries to think of a decent interface that allows bulk getting of heterogenous meta endpoints with dynamically specified paths
[14:00] <rogpeppe> natefinch: failing that, ResourceInfo would work OK as a name
[14:01] <natefinch> rogpeppe: ResourceMeta perhaps
[14:01] <natefinch> rogpeppe: to run against id/meta/resource
[14:02] <rogpeppe> natefinch: yeah, maybe
[14:03] <rogpeppe> natefinch: or just don't make an entry point yet
[14:03] <rogpeppe> natefinch: and use Get directly
[14:03] <rogpeppe> natefinch: then you can tailor your call to how you actually end up using it
[14:04] <katco> rogpeppe: i'm afraid i've kidnapped him into a meeting :)
[14:04] <rogpeppe> natefinch: because then you have freedom to get as much metadata on as many charms as you like in one request, including arbitrary resources
[14:04] <rogpeppe> katco: how could you?! :)
[14:05] <katco> rogpeppe: hehe ;p
[14:06] <babbageclunk> voidspace: ok, I've created an admin and connected to the web gui
[14:07] <babbageclunk> voidspace: the doc says to run maas-import-pxe-files, but that doesn't exist. Are they already downloaded?
[14:08] <dooferlad> babbageclunk: hey, did you get anywhere with a KVM MAAS? https://github.com/dooferlad/kvm_maas is a helper script that me and jam put together with a link to some instructions to get going
[14:08] <dooferlad> babbageclunk: they are imported by MAAS via the GUI
[14:09] <voidspace> babbageclunk: they aren't, but you can start importing boot images from the web ui
[14:09] <voidspace> babbageclunk: there should be a tab in the UI for images
[14:09] <dooferlad> babbageclunk: http://maas.ubuntu.com/docs/install.html#post-install-tasks
[14:10] <babbageclunk> dooferlad: Ooh, that looks useful - just setting up the controller at the moment, then I'll have a go with this.
[14:10] <voidspace> babbageclunk: great, my controller hard disk is corrupted
[14:11] <ericsnow> natefinch, rogpeppe: +1 on ResourceInfo (and leave GetResource as-is)
[14:11] <rogpeppe> ericsnow: i'm suggesting not doing ResourceInfo for now
[14:12] <rogpeppe> ericsnow: leave it like most of the other endpoints
[14:12] <ericsnow> rogpeppe: a meta endpoint for a specific resource revision isn't an option, no?
[14:12] <babbageclunk> voidspace: doh.
[14:12] <rogpeppe> ericsnow: if we end up with lots of places getting resource info, then let's do it then
[14:12] <rogpeppe> ericsnow: as then we'll know what the common pattern is
[14:13] <babbageclunk> voidspace, dooferlad - ok, thanks - was trying to follow the old (but KVM-specific) doc rather than the newer one
[14:13] <rogpeppe> ericsnow: i'm sorry that'll mean you need to write less code :)
[14:14] <jam> cherylj: tych0: two new reviews for LXD related patches http://reviews.vapour.ws/r/4318/ and http://reviews.vapour.ws/r/4323/ and if cherylj you could let me know if it is ok to land on Master
[14:14] <ericsnow> rogpeppe: lol
[14:14] <jam> they are primarily testing fixes for now.
[14:14] <cherylj> jam: I'd really like to hold off until after we ship beta3
[14:15] <ericsnow> rogpeppe: TBH, we'll still write a ResourceInfo method either way--either on the client or on a wrapper around the client
[14:15] <jam> cherylj: so should I create a feature branch for LXD stuff? I'd like to build off my work, though I guess if we get beta3 out Friday it won't be sitting particularly long
[14:15] <rogpeppe> ericsnow: the thing to avoid is doing that and then looping through lots of resources calling that method
[14:15] <cherylj> jam: we're trying to get things out tomorrow
[14:16] <tych0> jam: both look fine to me
[14:16] <cherylj> jam: you can create a fb if you'd like.  It won't get a CI run until after beta3
[14:16] <ericsnow> rogpeppe: we only need it for downloading, which isn't something we'll do for many-at-once
[14:18] <ericsnow> rogpeppe: you're saying we should support a bulk call for getting resource info at a specific revision?
[14:18] <rogpeppe> ericsnow: tbh, if you're just doing it in one place, why not just do it in that one place?
[14:18] <ericsnow> rogpeppe: makes sense
[14:18] <rogpeppe> ericsnow: well, there are many possibilities
[14:18] <rogpeppe> ericsnow: and i *think* at the moment my inclination is to make the user of csclient decide how best to do it
[14:19] <ericsnow> rogpeppe: regardless, there isn't a point to doing the multi-part GetResource stuff :)
[14:19] <rogpeppe> ericsnow: indeed
[14:20] <ericsnow> rogpeppe: so you're suggestion is that users use the Get endpoint to do bulk calls that accomplish the same thing as a hypothetical ResourceInfo endpoint?
[14:22] <rogpeppe> ericsnow: yes, until it seems that there's a pattern that can be factored out
[14:23] <ericsnow> rogpeppe: I'll have to take another look at it but I didn't see how the Get endpoint could accommodate resources at specific revisions
[14:23] <rogpeppe> ericsnow: one mo
[14:23] <ericsnow> rogpeppe: np
[14:26] <babbageclunk> dooferlad: Do I need to install a rack controller on my maas controller?
[14:27] <dooferlad> babbageclunk: I haven't looked at MAAS 2 really. voidspace should be able to answer that one.
[14:27] <babbageclunk> dooferlad: ahh - am I getting confused between docs for 2.0 and 1.x?
[14:28] <voidspace> babbageclunk: yes
[14:28] <voidspace> babbageclunk: for 2.0 you do
[14:28] <voidspace> babbageclunk: and probably you are confused, yes
[14:28] <ericsnow> babbageclunk: welcome, BTW :)
[14:28] <ericsnow> babbageclunk: I'm hoping things have gone smoothly for you :)
[14:28] <babbageclunk> voidspace: ok, and for 1.x how do I set up DHCP?
[14:28] <voidspace> babbageclunk: let me look at the docs - my MAAS is down at the moment
[14:29] <babbageclunk> ericsnow: Hi! Yes, so far. Although I'm geting confused by MAAS stuff at the moment
[14:29] <voidspace> babbageclunk: you have to tell MAAS to manage DHCP, but I can't recall how to do that for MAAS 1.9
[14:29] <voidspace> I can remember for 2.0
[14:29] <voidspace> babbageclunk: if you get MAAS installed and setup in one day you're doing better than most of us managed the first time
[14:29] <voidspace> although to be fair it has improved since I did it the first time
[14:30] <ericsnow> babbageclunk: be careful; if you figure it out then you're responsible for explaining it to people <wink>
[14:30] <voidspace> babbageclunk: http://maas.ubuntu.com/docs1.9/cluster-configuration.html
[14:30] <voidspace> babbageclunk: so, under the "clusters" tab you should see the interface with the subnet
[14:30] <voidspace> babbageclunk: you need to edit that
[14:31] <rogpeppe> ericsnow: something like this could work, though I'm not sure of the exact proposed endpoints: http://paste.ubuntu.com/15479784/
[14:31] <voidspace> babbageclunk: and put in "appropriate values" for everything - including changing it from unmanaged to having maas manage dhcp
[14:31] <voidspace> babbageclunk: for the dynamic range do something like 172.16.10 -> 172.16.128
[14:32] <voidspace> babbageclunk: and then for static range 172.16.0.129 -> 172.16.0.255
[14:32] <rogpeppe> ericsnow: then the Meta map would have an entry for each requested resource
[14:32] <mup> Bug #1560624 changed: cmd supercommand.go:448 failed to bootstrap model: no matching tools available <cdo-qa> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1560624>
[14:32] <voidspace> (172.16.0.10 -> 172.16.0.128 but I'm sure you got that)
[14:32] <ericsnow> rogpeppe: ah, meta endpoints can use a path (in the includes)
[14:32] <voidspace> babbageclunk: you still here?
[14:33] <rogpeppe> ericsnow: yeah, the idea is that you can ask for info on a particular meta endpoint with $id/meta/resource/$name-$rev
[14:34] <rogpeppe> ericsnow: it's the same deal as it is now with the extra-info endpoint
[14:34] <babbageclunk> voidspace: sorry, was reading docs - none of this matches what I see in the gui
[14:34] <voidspace> babbageclunk: what do you have in the GUI?
[14:34] <voidspace> babbageclunk: what version are you running?
[14:35] <voidspace> babbageclunk: are you setting up 1.9 or 2.0 - I just gave you the instructions for 1.9
[14:35] <ericsnow> rogpeppe: that's specific to a single charm URL though, right?  how would a single call for multiple charms, each with different resources, work?
[14:35] <babbageclunk> voidspace: on the clusters tab, I see 1 cluster called "Cluster master"
[14:35] <rogpeppe> ericsnow: one mo
[14:35] <babbageclunk> voidspace: 1.8.3
[14:35] <babbageclunk> voidspace: :(
[14:35] <voidspace> babbageclunk: nice :-)
[14:35] <rogpeppe> ericsnow: ah, you can't do that
[14:35] <rogpeppe> ericsnow: well, you kinda could
[14:36] <voidspace> babbageclunk: you probably need to add a ppa and update maas to 1.9
[14:36] <ericsnow> rogpeppe: not that *we* need that (right now)
[14:36] <voidspace> babbageclunk: it should be a clean upgrade though
[14:36] <babbageclunk> voidspace: but even after changing the url to have 1.8, the docs don't match
[14:36] <voidspace> babbageclunk: what OS did you go for?
[14:36] <babbageclunk> voidspace: 15.10
[14:36] <voidspace> babbageclunk: can you click on the cluster master?
[14:37] <babbageclunk> voidspace: Ah, ok - should I edit the interface in there?
[14:37] <voidspace> babbageclunk: yes, I missed that step out - sorry
[14:37] <voidspace> babbageclunk: I think the ppa you want is ~maas/stable
[14:37] <rogpeppe> ericsnow: if the meta endpoint doesn't exist, it's just omitted from the result. so a request like /meta/any?id=$id1&id=$id2&include=resource/$r1&include=resource/$r2 where the resources are the union of all the required resources would work
[14:37] <voidspace> babbageclunk: sudo add-apt-repository ppa:~maas/stable
[14:37] <rogpeppe> ericsnow: you'd potentially get some extra data in the results though
[14:37] <voidspace> babbageclunk: then apt-get update/upgrade dance should work
[14:37] <ericsnow> rogpeppe: well, the "resource" meta endpoint could support identifying the charm in the meta path
[14:38] <rogpeppe> ericsnow: no
[14:38] <ericsnow> rogpeppe: :)
[14:38] <rogpeppe> ericsnow: well, not if it's like all the other meta endpointa
[14:38] <rogpeppe> s
[14:38] <ericsnow> rogpeppe: k
[14:38] <ericsnow> rogpeppe: we can cross that bridge later if it comes up :)
[14:38] <rogpeppe> ericsnow: 'cos a meta endpoint is directly associated with an entity
[14:38] <rogpeppe> ericsnow: in the end, just make several concurrent requests...
[14:39] <ericsnow> rogpeppe: sounds good
[14:39] <ericsnow> rogpeppe: thanks for all the help
[14:39] <rogpeppe> ericsnow: we *should* support HTTP2 in the near future so that becomes not a great deal worse than making a single request
[14:39] <rogpeppe> ericsnow: np
[14:41] <babbageclunk> voidspace: ok - upgrading to 1.9 now
[14:42] <voidspace> babbageclunk: cool, are you writing this up by the way?
[14:42] <babbageclunk> voidspace: yup, keeping notes
[14:43] <voidspace> babbageclunk: great, thanks
[14:54] <rogpeppe> ericsnow: i'm thinking of adding a more general metadata request API to csclient; something like this perhaps: http://paste.ubuntu.com/15479991/
[14:55] <ericsnow> rogpeppe: I like how that encapsulates the functionality clearly
[14:55] <babbageclunk> voidspace: ok, on 1.9 now, that should reduce confusion!
[14:56] <voidspace> babbageclunk: cool
[14:56] <voidspace> babbageclunk: I'm going to reboot and fsck in the hope of recovering my maas 2.0 install
[14:57] <voidspace> babbageclunk: hmmm... maybe I have an alternative 2.0 install
[14:57] <voidspace> babbageclunk: I still need to fsck, but maybe not immediately
[14:57] <voidspace> babbageclunk: I have two versions of MAAS 2.0 - one from their next-proposed ppa and one from an experimental ppa
[14:58] <voidspace> it's my next-proposed one that is hosed, looks like experimental is still running
[14:58] <voidspace> at least with that I can make API calls
[14:58] <voidspace> which I need for the design doc I'm writing
[14:59] <rogpeppe> ericsnow: then your bulk resource request could look like this: http://paste.ubuntu.com/15480026/
[15:00] <ericsnow> rogpeppe: nice
[15:01] <voidspace> nope, dammit - that's hosed and can't even apt update
[15:01] <rogpeppe> ericsnow: going to lunch now
[15:01] <voidspace> nor see any boot images or boot sources
[15:01] <voidspace> fsck
[15:01] <ericsnow> rogpeppe: good luck <wink>
[15:02] <mup> Bug #1561023 opened: charmstore v5.WillIncludeMetadata gccgo build failure <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1561023>
[15:03] <babbageclunk> voidspace: stink
[15:05] <voidspace> and after a reboot I can update
[15:05] <voidspace> fair enough
[15:06] <voidspace> babbageclunk: once you have MAAS running you need to enlist and commission a couple of nodes
[15:06] <voidspace> babbageclunk: you don't need to install an OS on them as commissioning does that anyway
[15:06] <voidspace> hah, except after a reboot maas doesn't seem to be running
[15:06] <voidspace> will upgrade and re-reboot
[15:07] <babbageclunk> voidspace: do I need to set up DHCP/DNS management?
[15:07] <voidspace> babbageclunk: I will have to go get my daughter from school soon
[15:07] <voidspace> babbageclunk: yes
[15:07] <voidspace> babbageclunk: that's needed for the nodes to pxe boot
[15:07] <mgz> rogpeppe, cherylj: review please, https://github.com/juju/charmstore/pull/582
[15:07] <voidspace> babbageclunk: do that via the cluster controller
[15:09] <babbageclunk> Cool
[15:09] <cherylj> mgz: out of curiosity, were you able to verify that it fixes the issue on one of the ppc slaves?
[15:09] <mgz> cherylj: yeah, it compiles with that change
[15:09] <cherylj> mgz: sweet
[15:13] <marcoceppi> katco: natefinch I tried resources! I got errors
[15:13] <natefinch> marcoceppi: doh
[15:13] <katco> marcoceppi: :( otp but what happened? ericsnow ^^^
[15:13] <marcoceppi> katco natefinch false alarm!
[15:14] <natefinch> marcoceppi: not an error, a feature? ;)
[15:14] <marcoceppi> oh man
[15:15] <marcoceppi> it worked
[15:15] <marcoceppi> but I goofd
[15:15] <marcoceppi> stupid github
[15:16] <marcoceppi> hehehe this is so awesome
[15:17] <natefinch> marcoceppi: awesome! :)
[15:17] <katco> marcoceppi: :D
[15:22] <voidspace> brb
[15:23] <natefinch> marcoceppi: https://www.youtube.com/watch?v=9cQgQIMlwWw&t=6
[15:23] <marcoceppi> dis mai jam
[15:26] <babbageclunk> voidspace: Hmm, my new node doesn't want to PXE boot.
[15:32] <mgz> cherylj: https://github.com/juju/juju/pull/4878
[15:34] <babbageclunk> voidspace: It gets a sensible-looking ip address and shows some messages including "Booting under MAAS direction"...
[15:35] <babbageclunk> voidspace: but then there's a message saying: Loading ubuntu/amd64/generic/trusty/no-such-image/boot-kernel... failed: No such file or directory
[15:36] <marcoceppi> natefinch katco it's a bit unwieldy, but works pretty sweet: juju deploy ../../build/charm-svg --series trusty --resource webapp=$HOME/Projects/svg.juju.solutions.tar.gz --resource python-jujusvg=$HOME/.go/bin/python-jujusvg
[15:37] <babbageclunk> voidspace: which is weird, because the image I downloaded on the cluster was 15.10 (wily) rather than trusty
[15:39] <natefinch> marcoceppi: nice.
[15:39] <babbageclunk> voidspace: trying with a trusty image downloaded as well
[15:41] <voidspace> babbageclunk: you need trusty downloaded for enlisting I think
[15:41] <babbageclunk> voidspace: that would do it
[15:42] <voidspace> babbageclunk: I have maas 2.0 with an enlisted node
[15:42] <voidspace> so I can query the machines api (via the command line interface) and see the result
[15:42] <voidspace> which gets me unblocked for the moment
[15:49] <babbageclunk> voidspace: yay, enlisted!
[15:51] <voidspace> babbageclunk: cool, next commission
[15:51] <voidspace> babbageclunk: and then you have a successful install
[15:52] <voidspace> babbageclunk: normally for juju you'll need two machines - one to bootstrap the juju controller to and then one to deploy something to
[15:52] <voidspace> babbageclunk: but for this work one machine will be enough as it will be a while before we even get a successful bootstrap
[15:54] <voidspace> babbageclunk: you could setup the power type on the enslisted node so that maas can power it on & off
[15:54] <voidspace> babbageclunk: but I usually just manually power them on / off
[15:56] <redir> morning
[15:57] <babbageclunk> voidspace: what should the poe
[15:58] <babbageclunk> voidspace: duh power type be
[15:58] <voidspace> babbageclunk: virsh
[15:58] <voidspace> babbageclunk: followed by a connect string and password
[15:58] <voidspace> babbageclunk: which I can never *remember* how to construct (the connect string)
[15:58] <voidspace> so I usually don't bother
[15:58] <voidspace> not hard though
[16:01] <rogpeppe> mgz: have you raised a gccgo issue about the problem fixed by https://github.com/juju/charmstore/pull/582 >
[16:01] <rogpeppe> ?
[16:01] <babbageclunk> voidspace: Unfortunately I didn't set the power type before commissioning it. Now the node is off, but VMM can't talk to it
[16:03] <voidspace> babbageclunk: that's fine if you bootstrap to it you can just manually power it on
[16:03] <voidspace> babbageclunk: you should be able to add the power details with it switched off though
[16:05] <babbageclunk> voidspace: bah, scrapped that node and tried again
[16:06] <mgz> rogpeppe: I was going to try and catch mwhudson about it
[16:07] <mgz> this should not be a problem for much longer :hope:
[16:07] <rogpeppe> mgz: if you can make a tiny test case, just report it on golang.org/issue
[16:09] <babbageclunk> voidspace: yeah, it was just because way it turned off after enlisting left <something, either VMM or libvirt> confused about its state - meant that it thought it was on, so I couldn't start it, but it was actually off, so trying to stop it failed.
[16:09] <babbageclunk> voidspace: there's probably a proper way to get them back in sync
[16:12] <voidspace> cool
[16:17] <babbageclunk> voidspace: no, I'm still stuck. What do I need to do to get the node to move from Commissioning to Ready?
[16:17] <babbageclunk> voidspace: Is it the power?
[16:18] <babbageclunk> voidspace: If I just power up the node it just says No bootable device
[16:20] <voidspace> babbageclunk: ah, that's a maas bug :-/
[16:21] <voidspace> babbageclunk: it's not commissioned then
[16:21] <voidspace> babbageclunk: there is a workaround, let me find it
[16:21] <voidspace> babbageclunk: they're supposed to have fixed that last week
[16:21] <babbageclunk> voidspace: :(
[16:21] <babbageclunk> voidspace: in 1.9?
[16:21] <voidspace> oh
[16:21] <voidspace> no that's in 2.0
[16:21] <voidspace> it's commissioning but says no bootable device?
[16:21] <voidspace> that's weird, it should pxe boot
[16:21] <babbageclunk> voidspace: that's right
[16:22] <voidspace> babbageclunk: let me boot 1.9 and see what I get
[16:22] <babbageclunk> voidspace: aha - the nic is turned off in the boot options.
[16:23] <voidspace> that would do it
[16:23] <babbageclunk> voidspace: sweet, that seems to be doing it now
[16:23] <voidspace> cool
[16:24] <voidspace> babbageclunk: worth adding a note to your doc
[16:28] <voidspace> babbageclunk: bbiab
[16:30] <babbageclunk> voidspace: ok, I'mma try dooferlad's script for adding nodes now.
[16:41] <mup> Bug #1561088 opened: EnsurePasswordSuite.SetUpTest on windows <blocker> <ci> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1561088>
[16:56] <bogdanteleaga> mgz: http://reviews.vapour.ws/r/4328/
[17:05] <mgz> bogdanteleaga: ta
[17:06] <mgz> rogpeppe: I filed https://github.com/golang/go/issues/14931
[17:07] <mgz> cherylj: ^see bogdan's change
[17:09] <mgz> bogdanteleaga: you can $$fixes-1561088$$ land that
[17:10] <bogdanteleaga> mgz, done
[17:14] <mgz> we'll get a blessed master yet.
[17:17] <bogdanteleaga> mgz, haha
[17:17] <mgz> bogdanteleaga: I got it, didn;t have the bug high enough prio
[17:20] <babbageclunk> dooferlad: to run your kmaas script, what should the value of maas_name be?
[18:21] <cherylj> bogdanteleaga: thank you very much for picking up that bug!
[19:05] <bogdanteleaga> cherylj, np I almost didn't see the 2nd test suite in the same file
[19:35] <tych0> ahoy mates
[19:35] <tych0> what's the status of 2.0 final? i think we have one more non-trivial LXD change coming down the pipe
[19:36] <tych0> just want to be sure to get it in before 2.0 final is tagged
[20:01] <rick_h_> tych0: so beta3 is getting put together, final is still a little bit out
[20:01] <rick_h_> tych0: what kind of change?
[20:01] <tych0> rick_h_: s/lxcbr0/lxdbr0, basically
[20:02] <tych0> the actual code change for juju should be pretty minor
[20:02] <tych0> but the UX will suffer
[20:02] <tych0> at least for the lxd provider
[20:02] <rick_h_> tych0: k, when would that go out? I'd just want to keep it in sync that the 'released' beta of both work together for folks beta testing right now
[20:02] <tych0> rick_h_: well, we're not going to do it until there is a patch for juju
[20:02] <tych0> i haven't had time to write the patch yet
[20:03] <rick_h_> tych0: ok, can you email jam and andrew and have them in sync please?
[20:03] <tych0> andrew?
[20:03] <rick_h_> foo.../me goes to look
[20:04] <rick_h_> tych0: froboware
[20:04] <tych0> sure
[20:04] <tych0> will do
[20:04] <rick_h_> ty
[20:06]  * mwhudson waves at mgz
[20:06] <mgz> mwhudson: wotcha. I filed an upstream bug, apparently it's fixed in gcc 5 and my google fu just sucks
[20:07] <mgz> was easy enough to work around anyway (bug 1561023)
[20:07] <mup> Bug #1561023: charmstore v5.WillIncludeMetadata gccgo build failure <ci> <gccgo> <ppc64el> <juju-core:Fix Committed by gz> <https://launchpad.net/bugs/1561023>
[20:58] <redir> cherylj: ping
[20:58] <cherylj> redir: hey there
[20:58] <redir> Hi, is now a good time/
[21:00] <redir> ^^ if not, ping me when it is cherylj
[21:01] <cherylj> sure, I have a few minutes
[21:22] <redir> tx
[21:30] <mup> Bug #1561212 opened: register logic can lead to user lockout <docteam> <juju-core:New> <https://launchpad.net/bugs/1561212>
[21:50] <thumper> wallyworld: you around?
[21:52] <wallyworld> thumper: yeah, in release standup
[21:52] <thumper> wallyworld: chat when you're done?
[21:52] <wallyworld> sure
[22:00] <thumper> rick_h_: you around?
[22:03] <wallyworld> thumper: 1:1?
[22:04] <thumper> yeah
[22:26] <voidspace> thumper: hey, hi
[22:26] <voidspace> thumper: do you need me to send you an email as well?
[22:26] <thumper> voidspace: nah, got the docs
[22:26] <thumper> will attempt to get vmaas setup
[22:26] <thumper> and poke some ideas around gomaasapi
[22:27] <thumper> voidspace: do you have anything in a gomaasapi branch yet?
[22:28] <voidspace> thumper: not yet I'm afraid
[22:28] <thumper> voidspace: that's fine, I'll start one
[22:28] <voidspace> thumper: by the end of the day I was trying to sketch out interface design and went through looking at the endpoints we actually useed
[22:28] <voidspace> thumper: less than I thought
[22:28] <voidspace> thumper: a proper interface design would need to look at the parameters and the data we used from the returned values
[22:29] <voidspace> thumper: but really that would need knowing the 2.0 endpoints we need to use instead and the structure of the data it returns
[22:29] <voidspace> thumper: and of course that's not documented so it's a lot of work
[22:29] <voidspace> thumper: if you get vmaas setup (did you see Christian's doc?) and start on the gomaasapi infrastructure
[22:29] <voidspace> thumper: I can pick that up in the morning
[22:29] <voidspace> thumper: and we can fill gomaaasapi out as we start using it
[22:30] <thumper> yep
[22:30] <thumper> we'll see how far I get today
[22:30] <voidspace> thumper: the open question is to whether convert to the new API layer for devices/subnets/spaces
[22:30] <voidspace> thumper: yep, cool - thanks
[22:32] <voidspace> thumper: right, I won't send this email then - I'm signing off
[22:32] <voidspace> g'night and good luck :-)
[22:32] <thumper> voidspace: ack
[22:33] <voidspace> I burned too much time on one of my maas 2.0 vms which is borked
[22:33] <voidspace> fortunately I had a spare and that was only partly borked :-/
[22:34] <thumper> hmm...
[22:35] <thumper> how do you bork a vm?
[22:35]  * thumper wonders
[23:06] <mgz> easiest review evar for https://github.com/juju/juju/pull/4882 plz
[23:10] <anastasiamac> mgz: LGTM :D
[23:11] <mgz> anastasiamac: thanks!
[23:11] <anastasiamac> mgz: and u too for the fix \o/
[23:11] <mgz> he who didn't notice in review can fix it :D
[23:13] <anastasiamac> mgz: yep, it's in juju commandments \o/