[00:19] thumper: next MM PR: http://reviews.vapour.ws/r/5057/ [00:19] sorry that it's a bit large [00:23] * thumper looks [00:45] thumper: https://github.com/juju/juju/pull/5564 [00:45] ^ pinger fixes from the last two days [00:45] minus the removal of the recover() in ping.ping [00:45] that'll live another day [00:47] ok, I'll look shortly [00:47] * thumper afk for a walk [00:52] Bug #1592609 opened: Unit stuck in allocating with juju 1.25.5

[00:53] axw: the CloudCredential attributes on BootstrapParams appear unsed in master right now, correct? [00:55] wallyworld: yeah, one of the issues I found when validating :) [00:56] axw: cause restore is broken - i am fixing it by adding cloud and region info to bootstrap params when we restore with -b, but credential info is not at hand [00:56] wallyworld: doh, sorry [00:56] axw: i can propose and land this fix and you can then take alook? [00:56] wallyworld: sure [00:56] ok, will push when i check tests [00:56] wallyworld: it's fixed in the validation branch, but I can't land that until the add-model bits are done [00:57] wallyworld: I can pull it out if it's pressing [00:57] ok, let me propose this and we'll take a view [01:17] Bug #1592613 opened: juju status reports incorrect number of cores for arm64 machines === natefinch-afk is now known as natefinch [01:31] wallyworld: in the 1:1 when you're ready. [01:31] be right there [01:48] wallyworld: I think I'm going to add a cloud facade anyway, need to be able to determine the cloud type for a controller in order to finalize credentials [01:49] we should probably be exposing the credentials schema over the API, rather than relying on the providers, but that will have to come later [01:50] axw: ok, otp, will still aim to push a restore pr fix soon as i can [02:21] davecheney: just one question on the PR === akhavr1 is now known as akhavr [02:45] axw: a quick restore fix http://reviews.vapour.ws/r/5059/ [02:58] wallyworld: responded [02:58] ta [03:05] axw: returning *config.Config and jujuclient.BootstrapConfig is no good because BootstrapConfig doesn't contain a Credential struct. so i needed to cobble together a new struct that had everything [03:05] maybe i can rework a bit [03:05] wallyworld: I think the second option I suggested would work? [03:06] wallyworld: that would give you enough to construct the *config.Config, and the the names to pass in [03:06] yeah probs, i guess i was trying to avoid return 2 structs instead of one, but the name of the franken struct does suck [03:07] wallyworld: I've gtg out for a little while, will take another look when I return [03:08] np ty [03:11] thumper: w.Wait() is not a channel [03:11] :( [03:28] thumper: heard you're working on the fslock stuff... anything you need help with? [03:34] natefinch: perhaps when i get to CreateMutexEx :) [03:34] the docs are pretty clear [03:35] and I have a win machine here [03:35] but it isn't set up for go [03:36] thumper: setting up for go is pretty easy [04:34] thumper: http://stackoverflow.com/a/2332868 [04:34] ^ name spitballing [04:34] mutex fits our use case [04:44] Bug #1570368 changed: juju commands timeout while a bootstrap is in process

[05:04] wallyworld: sorry was out for longer than expected. LGTM [05:04] no worries ty [05:59] perrito666, rofl === akhavr1 is now known as akhavr === Makyo|away is now known as Makyo [06:55] wallyworld: what incantations do I need to make to register a facade? I've got a RegisterStandardFacade call, updated allfacades, updated the client facadeversions.go... [06:57] axw: got two minutes? [06:57] thumper: yup? [06:58] axw: priv msg hangout link [07:16] wallyworld: never mind, I was missing the "restrctedRootNames" bit [07:17] axw: ah sorry, had popped out to get coffee, was an emergency [07:17] no worries [07:52] wallyworld: do you think it would be reasonable to move authorized-keys out of model config? and have it stored separately in state? we already manage them specially [07:52] I'd rather like to not see long lines of authorized keys in model config [07:53] axw: i think so - a lot of stuff in model config schema only exsits there so we can collect it all up when bootstrapping [07:54] wallyworld: I've got a new facade for managing creds now, need to add auth and write tests [07:54] yay [07:54] wallyworld: just live tested with AWS successfully, specifying a cred that doesn't exist in the controller auto uploads [07:54] and tells the user [07:54] awesome [08:04] If I've got a juju model with a lxd container running on it, how can I ssh into the container? The container doesn't have a public address, so I need to ssh from the host machine, but that doesn't have the juju ssh key on it (I think). Is the right thing just to scp the private key to the host machine and ssh from there to ubuntu@? Or is there a better way of doing this? [08:07] babbageclunk: I'd use sshuttle or (if just for a simple test), ssh -L2222::22 and then ssh -i ~/.local/share/juju/ssh/juju_id_rsa ubuntu@localhost -p 2222 [08:08] dimitern: Oh, I keep forgetting about sshuttle! Thanks dimitern. Copying the key around definitely felt wrong. [08:08] babbageclunk: :) it should [09:27] fwereade_: ping? [09:32] babbageclunk, heyhey [09:34] fwereade_: So, about workload version - I think you're right it should be done at unit level. [09:37] fwereade_: Should I just keep doing that now? I don't really follow what Rick was suggesting - I'm not very familiar with resources. And I'm not very clear on what jam was suggesting - the status stuff is a bit more involved and I'm not sure how to add version info into it. [09:37] fwereade_: So I've t [09:39] fwereade_: oops. I've parked my application.SetWorkloadVersion branch and done a unit.SetWorkloadVersion branch instead, but I should probably understand rick_h_ and jam's suggestions better before going too far with it. I didn't see a response from thumper - have you heard anything from him? [09:41] babbageclunk, sorry, processing [09:41] fwereade_: :) [09:45] wallyworld: problem. we've renamed the "--service" flag to "--application" in the status-set hook tool. that's going to break a bunch of charms [09:45] wallyworld: I think we should probably alias that. [09:45] axw: yep, fair point [09:45] I'll file a bug [09:45] just tried deploying cassandra, and it blew up [09:45] it may be a blocker for brta9 [09:46] axw: i had to tweak the dummy provider to not break with no controller id on Open(), running more tests now, can look at bug after that [09:47] axw, wallyworld: minor but related thing - I see a traceback with "KeyError: 'services'" when tab completing in the juju command (specifically juju scp). Already known? Should I raise a bug? [09:48] babbageclunk: not known to me, raise abug and the tab completion fairies will need to fix it [09:48] wallyworld: ok cool [10:02] babbageclunk, based on conversation, I'm not entirely certain I understand what problem we're solving; added another comment but I think I too need guidance from rick_h_ and/or jam [10:02] wallyworld: I dug a bit more, looks like it was already fixed, I just hadn't installed it since the change. [10:02] ah cool [10:03] Bug #1592733 opened: rename of status-set --service flag to --application breaks charms [10:04] babbageclunk: I'm heading back to the hangout now. if fwereade_ wants to join us that would be fine with me [10:04] fwereade_: joooooooooin ussssssssss [10:10] * dimitern needs to step out for ~30m [10:20] axw: http://reviews.vapour.ws/r/5062/ [11:21] babbageclunk: you mentioned in your email a while back that "juju deploy foo --to lxd" didn't work [11:21] did you try "juju deploy foo --to lxd:" ? [11:21] or is the point of that email "why do I need to type the colon" ? [11:22] jam: yeah, I did - that didn't work. [11:22] jam: with the colon it fails [11:22] somewhat surprising. [11:22] jam: The point of the email was actually "this works now" - so maybe it didn't work! [11:23] jam: (The email I mean.) [11:42] dimitern: are you interested in chatting soon? [11:42] jam: let's do it now if you can? [11:43] k, just need a quick stop and brt, see you in standup [11:43] ok [11:47] fwereade_: just to check again having familiarised myself with the status code - you're saying store workload version as a status but with a different global key to the unit global key (probably the unit global key with #wlversion in it somewhere). Sound right? [11:48] babbageclunk, yeah, sgtm [11:48] fwereade_: [11:48] babbageclunk, cheers [11:51] babbageclunk, # tacked on the end, anyway: a disambiguating namespace like '#sat#workload-version' might be a good idea (sat[ellite], bad name; still, dyswim?) [11:51] fwereade_: yeah, that makes sense. [11:51] babbageclunk, ta [12:08] dimitern: i'd love a small review to allow old charms to work with new set-status for beta 9 http://reviews.vapour.ws/r/5062/ [12:18] dimitern: ping [12:18] dimitern: in order to validate LinkLayerDevices I need to validate ParentName references a real device on a real machine [12:19] dimitern: which means I need to parse ParentName as a global key (potentially) [12:19] dimitern: do you think I should duplicate or move (or make public) the parsing code? [12:20] dimitern: core/description doesn't yet depend on state - so making it public and adding a dependency seems like a bad idea [12:20] dimitern: it's only string parsing, and not much code, so duplicating it seems best [12:29] voidspace: pong; sorry, otp so will respond as I can [12:29] dimitern: ok [12:29] dimitern: I've duplicated for the moment - only a few lines of code [12:30] voidspace: I don't think we should export the parsing code, as it's an implementation detail [12:30] voidspace: and as fwereade_ correctly pointed out, ParentName being a global key should have never be allowed to escape the state package [12:31] dimitern: right [12:32] dimitern: I still need to parse it for the moment, so I'll duplicate the code until we solve the problem (add ParentMachineID maybe) [12:32] voidspace: what would've been better is to have a ParentName() always returning plain names, and add a ParentMachineID() to return a non-empty id in the case currently handled with ParentName as global key [12:32] voidspace: +1 [12:32] :-) [12:32] those global keys are pretty ugly [13:01] Bug #1592811 opened: 2.0 beta8: networking broken for dense deployment and vsphere as provider

[13:05] fwereade_: i'd love a small review for beta 9 http://reviews.vapour.ws/r/5062/ [13:10] fwereade_: could also use a follow-up on http://reviews.vapour.ws/r/5006/ :) [13:10] * katco disappears again for a bit [13:43] ha [13:43] I had not looked at irc for a while, and had somehow psychically gone to look at both those reviews :) [13:44] wallyworld, lgtm; katco, looking [13:44] ty [13:50] wallyworld: hey, do you know about any recent change in API server facades that wuld break the GUI? like we are getting "unknown object type "Client" [13:51] gsamfira: ping, around? We've got a user in #juju working with windows and asking about example windows subordinates and such [13:51] gsamfira: curious if you'd be interested in asking someone to chat with him and might have some samples or fodder to help the user along? [13:51] frankban: um, some of the serialisation names for the params was changed but that shouldn't affect the ability to find a facade. what facade version are you using for client? [13:52] wallyworld: no version sent, so 0 [13:52] wallyworld: ah maybe that's the issue [13:52] should be 1 i think [13:52] fwereade_: could you go to your regular nickname so I dont have to open another window? :p [13:53] wallyworld: yeah Login returns 1 [13:53] wallyworld: so the lower-cased-api-fields-geddon has been merged? will be in beta9? [13:54] frankban: yeah. i hope it won't affect too much [13:57] rick_h_, mail might be good or bogdanteleaga may be able ot help [13:57] alexisb_: rgr ty [14:01] Bug #1592832 opened: enable-ha embeds ModelCommand but should be controller-specific [14:01] Bug #1592837 opened: juju upgrade-gui is a model command but operates on controllers only [14:04] Bug #1592832 changed: enable-ha embeds ModelCommand but should be controller-specific [14:04] Bug #1592837 changed: juju upgrade-gui is a model command but operates on controllers only [14:04] * frobware discovers the tp-link switch CLI does NOT save the config by default. Grrr. [14:13] Bug #1592832 opened: enable-ha embeds ModelCommand but should be controller-specific [14:13] Bug #1592837 opened: juju upgrade-gui is a model command but operates on controllers only === fwereade_ is now known as fwereade [14:15] perrito666, sorrt [14:27] wallyworld: we'll fix the gui for that change, thanks for confirming. fyi, the embedded gui will be broken in beta9 [14:28] that's ok, we'll have a beta 10 next week [14:30] wallyworld: cool [15:03] alexisb_: ping [15:05] dimitern, heya [15:05] I am on the hangout [15:07] alexisb_: sorry, I was chatting with frobware just now - omw [15:43] Bug #1592872 opened: juju status not showing correct output when specifying a sepcific service/application [16:00] katco, sorry, wall of issues, but I think mostly very minor [16:01] fwereade: tal, and no worries [16:01] fwereade: ta for the review [16:01] katco, np :) [16:25] Bug #1592887 opened: juju destroy-service deletes openstack volumes [19:18] this channel is unusually slient today [19:19] perrito666: oh way to ruin it perrito666. jees... we had a streak going. [19:20] perrito666: this is why we can't have nice quiet things. [19:20] I am south american, we are loud [19:26] katco, perrito666: can I get one of you to give a second +1 on this revert so we can merge please: http://reviews.vapour.ws/r/5066/ [19:26] alexisb_: looking [19:26] alexisb_: ditto [19:30] alexisb_: cherylj: i don't understand the commit message... we are reversing changes made in commit Y by reverting commit X? [19:30] alexisb_: looks like a revert :) and gtm, but why is this revert? [19:30] ie, code looks good dunno about the reason [19:31] perrito666, there were facade changes without version bump and fair warning to api users [19:31] everyone is horrible broken as a result [19:31] do we fair warn in master? [19:32] perrito666, yes we should always update those we know are using our api's before breaking changes like this [19:32] we did not in this case, and we also should always keep to api versioning [19:32] alexisb_: lgtm, need an official stamp? [19:33] agree re api vers [19:33] perrito666, yes please [19:34] done [19:36] katco, not sure why the lxd bug fix is mentioned in the commit message, cheryljwhat have to provide clarity, my guess is that there were revisions to that bug fix due to it using an updated facade [19:37] alexisb_: ok; pursuant to our recent discussion about commit history, it might be worth clarifying [19:37] :) [19:37] agreed [19:38] thanks for looking katco and perrito666, I will follow-up with cherylj when she is back from lunch [19:38] alexisb_: i know she's busy, and this was probably done in 5m between people bothering her ;) [19:38] yes yes it was [19:39] and it is not like she is running an induction sprint atm [19:40] alexisb_: yeah, seriously. laziest lady i know... [19:40] katco: The commit message was just what git spit out. I think it's just saying that it's reverting the change applied on top of that lxd commit [19:40] that lxd commit was the last merge before the one I reverted [19:41] cherylj: ah that makes sense [19:41] cherylj: probably not worth changing if it's idiomatic git [19:41] ok [19:41] cherylj: in that case, i just need to update my understanding :) [19:41] heh [19:44] cherylj, you are good to merge with bz2 and perrito666 +1 [19:45] ok, merging [20:20] thumper, when you have a minute I could use a moment of your time [20:21] alexisb_: I'm free for the next 8 minutes :) [20:21] good enough [20:21] meet you in our 1x1 HO [20:25] does anyone have an opinion on this? [20:25] we only log information about API requests if the loggo level is <= loggo.DEBUG [20:25] but we log ALL API connection open/close regardless of logging level [20:25] yes, I have opinions [20:26] thumper: the right man for the job! [20:26] it would make my life much easier if we would consistently log API information (i.e. joins/parts as well as misc. API info) rather than treating joins/parts as something different [20:26] is there a reason to do so? [20:27] secrets [20:27] they were the reason [20:27] there was no consistent way to remove secrets from the details [20:27] soon we hope there will be when all providers describe config using the more descriptive way [20:27] but until then [20:27] this is what we have [20:28] thumper: ah... can i discontinue logging joins/parts if the loggo level is <= DEBUG? [20:28] joins/parts? [20:28] thumper: sorry... connects/disconnects [20:29] thumper: https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L561-L567 [20:29] thumper: i want to get rid of that and say we either log all API events, or none, depending on the loggo level [20:31] I think we should always have the notifier [20:32] thumper, ping [20:32] thumper: i seem to remember mark complaining about log spam? [20:32] babbageclunk: with you shortly [20:32] thumper: cool cool [20:32] babbageclunk: having many parallel conversations just now [20:32] alexisb_: ya? [20:32] thumper: better throw a fslock in there [20:33] katco: I don't even... [20:33] thumper, nevermind [20:33] we've logged api calls at debug for so long, if we want to only do that on trace, we should tell people on juju-dev [20:34] thumper: i'm good with that, as long as it passes your smell check as something sane to do [20:35] thumper: however it looks like we ALWAYS log requests: https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L541-L543 [20:36] thumper: so, sorry: that's really what i'm asking; can the logging of connects/disconnects safely be tucked away under debug rather than always on? [20:37] yeah, don't see why not [20:37] thumper: you have just made me very happy. [20:38] Bug #1531719 opened: Runaway memory allocation in jujud unit agent <2.0-count>

[20:42] thumper: how long do you think before your revert makes it into master? [20:43] stokachu: it is trying to land now [20:43] thumper: ok cool [21:08] Bug #1592981 opened: LXD and manual provider shouldn't require auth type [21:35] Bug #1592987 opened: Cannot bootstrap MAAS: missing CloudRegion not valid

[22:12] \o/ flock impl works [22:13] \o/ [22:14] now on to windows [22:14] have fun [22:30] wallyworld, ping [22:31] alexisb_: hey, trying to get in, there's no video link [22:31] https://hangouts.google.com/hangouts/_/canonical.com/core-leads-call [22:40] axw: wallyworld: m looking at agent config file version bug 1575794 [22:40] Bug #1575794: Agent config format version should be changed for 2.0

[22:41] great ty [22:41] axw: wallyworld: m tempted to rename our format-1.18 file to just be format :D and change the variable that puts version number to 2.0 [22:42] is there any repricussion m missing? [22:42] not sure, otp, so can't devote brain space to it [22:42] anastasiamac: should be fine [22:43] anastasiamac: I'd call it format-2.0, since it may change again [22:44] axw: the problem is that this file has already been updated to contain 2.0 changes. it's no longer just 1.18 :) [22:45] anastasiamac: that's a problem regardless of the name. and if we don't include the version in the name, people will be *more* likely to change it in incompatible ways without bumping the version [22:46] axw: k. I'll rename and change the variable name and its value, adding comments to not alter contents but creating new file for next format version \o/ === jcsackett_ is now known as jcsackett === meetingology` is now known as meetingology === StoneTable is now known as aisrael