[00:00] oh? [00:00] we need to use a new session every time we execute a query against a collection [00:00] voidspace: and put them where? [00:00] so they shouldn't be long lived [00:00] we should fetch them when we need them [00:00] fair call [00:00] but we shouldn't create a new session just to use the name [00:00] correct [00:00] so I'm just using the name [00:00] make package constants [00:00] the pattern just seemed a bit odd [00:01] please use a named constant not just a naked string [00:01] ok, I'll have to go back and change the ones I've done already [00:01] hopefully that would be pretty mechanical [00:02] sure [00:04] voidspace: +1 to constants [00:04] yep, doing it [00:05] you also need to sleep [00:07] not quite mechanical, the const names will clash with the obvious name for the column collection - so I'll have to append a Col suffix to those [00:07] wallyworld: soon enough [00:08] you have 1 more day to work on this, right? [00:08] voidspace: or "Collection" [00:08] lol [00:08] wallyworld: yep [00:09] wallyworld: just getting this to compile will be an achievement [00:09] voidspace: make it Cxn to piss off thumper [00:09] * thumper slaps wallyworld with a wet fish [00:09] thumper: Col works for Column and Collection - and they're both [00:09] Columnection [00:09] voidspace: but it isn't both is it? [00:09] it is [00:09] it's a collection representing a column [00:09] it is either the name of the collection, or the collection itself [00:10] voidspace: non relational dbs don't have columns :-) [00:10] * thumper has no time to bikeshed names [00:10] voidspace: call them "a", "b", "c" and so on [00:10] hah, it's a collection not a column [00:10] * thumper leaves [00:10] correct [00:10] this is why you need to study maths to be a programmer [00:10] voidspace: and religion [00:10] if you haven't done algebra how else would you know that variables should have single letter names [00:11] no-one should study religion [00:11] either live it or ignore it [00:13] * wallyworld afk for a bit === Ursinha-afk is now known as Ursinha [01:02] wallyworld: made a dent in it [01:02] wallyworld: into machines.go switching to the new style collection access [01:02] wallyworld: https://github.com/voidspace/juju/compare/copy-sessions [01:02] wallyworld: hoping for compilation tomorrow [01:02] g'night all [01:41] wallyworld: https://github.com/juju/juju/pull/331 [02:07] axw: you free now? [02:08] wallyworld: just a sec, making tea [02:08] ok, no hurry [03:57] well, that's blown it [03:58] ? [03:58] at the museum thinking I could work in the cafe while the kids played [03:58] but I need to be in the discovery world with them [03:58] currently propped in the corner with laptop on my lap [03:58] not entirely comfortable [04:25] thumper: i can't stand it any longer [04:25] i'm going for afternoon coffee [04:25] do you want to do HR stuff today ? [04:33] review pls: https://github.com/juju/juju/pull/333/files === vladk|offline is now known as vladk [04:49] wallyworld: part 2: https://github.com/juju/juju/pull/336 [04:49] I'll do azure in a followup [04:49] axw: looking after i finish the current review [04:50] thanks [05:08] wallyworld: FYI, here's the followup too: https://github.com/juju/juju/pull/337 [05:08] includes the commit from 336 [05:08] rightio [05:08] axw: i'd love to get rid of the remaining old connection guff from juju/testing/conn.go i think it is [05:09] the bit that does all the side effecty state open stuff [05:10] i think the only thing we really want to keep from there is PutCharm [05:10] wallyworld: which bits can go? MongoInfo/APIInfo? I'm pretty sure things still use them... [05:11] JujuConnSuite is everywhere [05:11] axw: the newState() stuff [05:11] ah, ok [05:12] as in collapse State/BackingState [05:12] yeah [05:12] I can take a look at that after I fix up EnsureNotBootstrapped if you like [05:12] and we also do need to fix JujuConnSuite and ConnSuite (there's 2 of them) [05:12] sure, it was just a heads up - one of us will get there first [05:13] okey dokey [05:13] will be great to clean all this shit up [05:13] indeed [05:14] I was nearly tempted to remove the use of JujuConnSuite in the provisioner code, but didn't want to get too sidetracked [05:29] yeah, separate piece of work :-) === vladk is now known as vladk|offline [06:18] fwereade: hey, are you about? [06:18] axw, hey dude [06:18] fwereade: thought you may want to skim https://github.com/juju/juju/pull/336 before I land it [06:19] in case you have different ideas about how this should look [06:19] axw, cheers, I'll take a super-quick look [06:19] fwereade: description alone may be enough [06:20] axw, description LGTM [06:20] axw, I'd say that I'm not convinced that replacing the storage-based implementations is ideal [06:21] axw, I would prefer to see us move in a direction in which environs have an explicit SetStateServerInstances method [06:21] axw, (which can be backed by storage or tagging or whatever) [06:21] fwereade: which would add a tag to an instance? [06:21] axw, but post-bootsrtap, I think it's really up to the HA code to determine who's *really* meant to be a state server, and to keep the env updated with that knowledge [06:22] I see [06:22] axw, yeah -- and remove that tag from non-state-servers, I think [06:23] axw, I mean, yeah, the storage-based implementation isn't great, I'm not *attached* to it [06:23] fwereade: given that we can't do that with azure, I don't think we can get away from tying state-serveryness from provisioning any time soon [06:23] fwereade: does an Environ need to know about the state server instances at all? [06:23] axw, but I feel like where we really fall short is in maintaining the important info at an env level, and the less-than-ideal implementation backing our attempts isn't my main focus [06:24] * axw nods [06:24] rogpeppe, yes, IMO, I am not willing to discard that functionality [06:25] rogpeppe, I've heard plenty of arguments as to why it's kind of a hassle, and why we often don't need it, but IMO any time we force people to manage a juju environment via their provider dashboard we have *failed* [06:25] fwereade: i'm not suggesting that an a provider wouldn't be able to provide an implementation of the state-server-instanceid storage, but that it could be something independent of Environ [06:26] fwereade: then one could arbitrarily compose instance id storage and Environ [06:26] fwereade: just a thought. please ignore me :-) [06:27] rogpeppe, I definitely think it's part of environ's responsibility -- but equally I am fine with the idea that we could/should be able to delegate that functionality elsewhere [06:27] rogpeppe: I don't see how it could be independent, unless we require something like storage. it always has to be external to the environment, which means leaning on something provider-specific [06:28] axw, or just a little remember-my-state-servers web service that we provide independently [06:28] axw, it's not inextricably tied in *implementation* to any specific provider [06:28] right, if we had a global thingy that would work [06:28] axw, I just remain adamant that it's a responsibility of the environ interface, independent of where we actually storeit [06:28] axw: my thought is that there are many possible ways to do it (e.g. with some external web service). an instance-id storage service could be something that an Environ could be asked for, but wouldn't necessarily have to implement. [06:28] fwereade: I agree with that [06:29] rogpeppe: ah right, yes. [06:29] we could definitely delegate to some provider-independent thing [06:29] axw: rather than forcing all providers to know about all possible kinds of external instance-id storage services [06:31] fwereade: the reason i don't see it as a fundamental part of Environ is that the provider really couldn't care less about where instance-ids are stored. That's why I see it (potentially) as a service that the Environ *can* provide but not one that the Environ *must* provide. [06:32] rogpeppe, I see it as part of the responsibility of the Environ instance to keep track of what happened when you called Bootstrap -- but indeed not necessarily as something that has to be provider-specific [06:33] fwereade: i would imagine that Bootstrap could take an instance-id storage service as an argument. That storage service might have been provided by the Environ itself, or externally. === vladk|offline is now known as vladk [06:45] fwereade: the reason the storage based impl was replaced is due to the explicit direction given my mark s [06:45] by [06:45] that we should evolve towards removing cloud storage [06:46] wallyworld__, hmm, I feel like there's a bit more nuance there [06:46] wallyworld__, removing juju-level dependency on it is definitely important [06:46] i agree we also want a SetStateServerInstances, but that is somewhat ortogonal to the current work and can come later [06:47] wallyworld__, this feels like it goes further, and is close to mandating that we shouldn't use provider storage even if it exists [06:47] fwereade: exactly, that was his direction [06:48] he quited the recent swift config issues [06:48] quoted [06:48] as justification for why we need to eliminate it even if it exists [06:49] wallyworld__, heh, ok then, I don't fully agree but it's not a hill I'm interested in dying on [06:50] fwereade: i'm with you tbh [06:50] but [06:50] we have been told :-) [06:50] wallyworld__, yep :) [06:53] FWIW, the instance-id storage is the *only* place we *cannot* rely on state-server provided storage [06:53] yup [06:53] rogpeppe, understood, agreed [06:56] ISTR some general agreement that we could potentially move away from instance-id storage and store only instance addresses instead === wallyworld__ is now known as wallyworld [06:56] or potentially just state server host-ports [06:57] rogpeppe: what's the point of storing the addresses if they may be out of date? [06:57] axw: the environment itself keeps them up to date [06:57] axw: if the environment is moribund, there's not that much point in knowing its instance ids [06:59] Hi [06:59] not sure. if we use instance tagging, we can just query the env's instance pool for the start server instances [07:00] axw: the "keeping them up to date" piece of the HA work is still to do, AFAIK. that was mainly because I wanted to make that change as part of it (otherwise there's an impedance mismatch between StateServerHostPorts and the instance id storage) [07:01] Why when I add new unit to service the other units can't get relation data, even if relation-set was executed? [07:02] Egoist_, expand please? relation-set is not flushed to the state server until the hook in which it was called completes successfully, but I'm not sure that's what you're seeing? === wallyworld__ is now known as wallyworld [07:07] would anyone like to take a look over this charm store PR? it's the core of the new charm store, and i think it's quite neat actually :-] https://github.com/juju/charmstore/pull/14 [07:07] axw, rogpeppe: fwiw I think that the only impedance mismatch is in trying to use only a single piece of data for two purposes -- agents/clients need to know addresses to connect to, environs need to know instances to manipulate, it's about tuning the info to the context it'll be used in. IMO this implies we want 2 separate methods (and 2 separate watchers that'd probably still just share an impl), not that we should make environs concern it [07:07] self with addresses when it's fundamentally concerned with instances [07:08] fwereade, No, I mean that in peer relation, when I add new unit this new unit can get relation data about other unit, but other units who was in relation before adding new unit can't get relation data [07:08] fwereade: do we ever use the state server instance ids for anything other than turning into a state server address? [07:09] btw. what about charm, who is responsible about charms in charmstore? [07:10] Egoist_: the top level ("promulgated") charms are reviewed and gated for quality and appropriacy by folks at Canonical. [07:12] rogpeppe: the top level ("promulgated") charms -> You mean charms that are more important for juju like juju-gui? [07:12] Egoist_: i mean any charm that doesn't have "~" in the name [07:12] Egoist_: (which is probably all the charms you've actually seen :-]) [07:12] rogpeppe, not sure we do, that doesn't mean that addresses are the correct expression of the info at the environ level [07:13] fwereade, rogpeppe: we currently use StateServerInstances only to generate API addresses (and soon to determine whether the environment is bootstrapped) [07:13] Egoist_, at the point the old units try to get the data, what hooks have successfully run on the new unit? [07:14] I don't think provider implementations should be thinking about API addresses, though. If we somehow pulled instance ID storage out of Environ then we could make it not-the-environ's-concern, but as it is I don't think Environ should know anything about API addresses [07:14] axw, +1 [07:14] -relation-joined and -relation-changed [07:15] fwereade: [07:15] fwereade: i guess i'm trying to say that this concern is actually entirely independent of the environ. the only exception being, i guess, the fact that Environ.Bootstrap knows about it. [07:15] axw: +1 too [07:15] rogpeppe, and that we want to know it to tell if the environ's bootstrapped, too, right? [07:15] rogpeppe, "these are the instances" is a lot more direct and appropriate than "here are some addresses" [07:16] rogpeppe, (and apart from anything else addresses are deeply problematic anyway, there's this infuriating pervasive assumption that the set of state server addresses is a single property of the environment) [07:17] rogpeppe, (it's really not: different networks, different scopes -> (potentially) different set of state server addresses per agent) [07:17] fwereade: interesting. [07:17] rogpeppe, that's one of the this-really-isn't-bulk things that has had me all grumped up for a while [07:17] rogpeppe, it's not "what are the state server addresses for an environment" [07:18] :q [07:18] oops [07:18] rogpeppe, it's "what addresses should X entity use to connect" [07:18] Egoist_, what's the error you see on the old units when you try to read the relation data you set in joined/changed? [07:18] axw: lucky it wasn't your password :-) [07:18] :) [07:19] brb [07:19] fwereade: yeah, it's a maze of tunnels and there are no universal addresses for anything. [07:23] fwereade: nothing error i guess, it's from charm code and it say that relation data is no exist -> In python language relation data is None [07:23] fwereade: btw, is there any tool to debug relation problem or something like that? [07:28] Egoist_, you can use `juju run` to execute arbitrary code in a hook context; and you can use `juju debug-hooks` to start a session that gives you a session that lets you run each hook [07:28] Egoist_, but, hmm, None is very weird [07:29] Egoist_, I'd expect at least private-address to be set [07:35] fwereade: yeah, and can't get any data set by relation set [07:36] Egoist_, so, just to be clear: there's a new unit that the old ones know about (they've run its joined hook) but for which they can't see any data? [07:36] Egoist_, (they've run *or are running*) [07:37] rogpeppe: yeah, I don't see charm with '~' in name. But with who I need to speak about bugs in charms/ [07:37] ? [07:40] fwereade: there's a new unit and this unit know about other ones, but old ones can't get any relation even about themself so i don't know is they don't know about this new unit [07:41] fwereade: thev've run [07:42] fwereade, no no sorry, they are running [07:42] Egoist_, hmm, that sounds like we can isolate it to just the old units anyway then? [07:43] Egoist_, what exactly are you running on those units, and in what hook, and where did you get the unit names from? [07:43] Egoist_, btw https://bugs.launchpad.net/charms ? [07:47] morning [07:49] fwereade: what exactly are you running on those units -> trying to deploy mongodb charm maintain by myself | and in what hook -> in -relation-changed | and where did you get the unit names from -> from relation-list [07:51] Egoist_, ok, I'm scratching my head here a little bit -- is it possible you could come up with an absolutely minimal charm that repros what you're seeing and report a bug against juju-core that references the charm? [07:51] bbs [07:53] fwereade: yeah, i think i could do that [08:04] Egoist_, awesome, tyvm === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline [09:00] rogpeppe, ping? [09:01] mattyw: hiya === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [09:36] one trivial one for the OCR: https://github.com/juju/juju/pull/338 [10:00] vds: ping, you’re OCR today ;) [10:20] how do I push without running the pre-push hook? [10:21] I need to push a branch that doesn't compile [10:22] voidspace: eh, why that? [10:22] TheMue: because I've made a big change and it will be a while before it compiles and I don't want it only on my computer [10:22] I want to push my wip [10:22] I think there's a command line flag, can't find it though [10:22] voidspace: ah, to your personal repo? [10:23] TheMue: no, to master of course ;-) [10:23] TheMue: yeah, to my repo - but the pre push check runs for that too [10:23] voidspace: eh, the question mark has been by accident ;) [10:23] hehe [10:24] voidspace: hmm, isn’t the hook already running before commiting? not before pushing? [10:24] TheMue: no, it's pre-push [10:25] TheMue: at least if you follow the instructions in CONTRIBUTING [10:25] the command line flag is --no-verify [10:25] voidspace: ouch, I only have a pre-commit *blush* [10:26] pre-commit is even stricter! [10:26] * TheMue has to take a deeper look into his git hooks [10:30] so, added it too [10:31] I’m running most of it manually from inside vim, so no problems so far [10:31] cool [10:32] voidspace: could you please take a look at https://github.com/juju/juju/pull/338? it’s a very trivial one. [10:32] looking [10:32] voidspace: thx [10:32] TheMue: the hash change is markdown syntax? [10:32] I'm not familiar with markdown [10:33] TheMue: have you run it through a processor to check the output? [10:33] voidspace: yep, the === and — only work for h1 and h2, #, ##, ###, ### etc can even go further [10:33] ok [10:33] voidspace: yep, and took a look on it in GH itself which renders it fine [10:34] I think the ==== and --- look better in plain text form though [10:35] voidspace: maybe, but it’s only habituation. we want to render all docs later from md in GH direkt to HTML on j.u.c [10:35] well, I think they look more like headings - so not just habituation [10:36] ok [10:36] If we need the alternative format then fine [10:36] in other md docs nick and i use # because very often we need deeper nestings than h2 [10:37] at least we're not using latex [10:38] voidspace: hey, I wrote my golang book in latex, so please don’t complain :D [10:38] hah [10:39] voidspace: btw, my IPv6 info collection so far is at https://docs.google.com/a/canonical.com/document/d/1wfdGL_vyemT2-ncAB7KIySkKI9HbT8efKeC3Sd8ID0I/edit# [10:39] cool [10:40] voidspace: very raw, no real concept, only a collection of links and snippets [10:40] TheMue: I won't get a chance to look at it today - I'm off next week and need to get this branch as close to done as possible [10:40] even getting it to compile will be a challenge :-/ [10:40] I'll bookmark it for later [10:40] voidspace: ok, nopro [10:40] I'll be back with you guys on networking on my return [10:41] voidspace: a quick vacation? dimiter is diving on malta these days [10:42] nice [10:42] I'd love to go diving [10:42] never done that [10:42] me neither [10:43] I would like to do the opposite, flying and parachuting [10:43] I did a parachute jump last year :-) [10:43] once done a tandem jump out of 3000m, nice [10:43] cool [10:43] TheMue: you've done a tandem jump? [10:43] that's what I did [10:43] great fun [10:44] yeah, during free fall I’ve almost forgot to breathe. and then the silence, when the parachute opened and you’ve haning there in about 1000m [10:45] yep, exhilarating and amazing [10:45] hanging [10:46] voidspace: the right words [10:52] TheMue: LGTM on your PR by the way [10:52] voidspace: thx [10:54] dimitern [10:54] vladk: dimiterm is on vacation already [10:55] TheMue, pong, just got back to a decent internet connection [10:55] vladk: you’re here? have been in the hangout but nobody there [10:55] TheMue: yes, I was late [10:55] vds: hehe, it’s ok, voidspace already reviewd it [10:56] vladk: i’ve got nothing special to tell, working on ipv6 for lxc and documentation [10:57] I'm, too. I am working on moving cloudinit stuff to networker. [10:57] TheMue: ^ [11:04] vladk: ah, ok. does the networker also modify /etc/network/interfaces? [11:04] vladk: and this inside containers? [11:05] vladk: it could be interesting for routing IPv6 sub-subnets in a container (net yet absolutely shure about it, but found an interesting blog entry) [11:46] I've put off restarting for a couple weeks, guess I should probably listen to the nag window, brb [11:56] TheMue: networker requires the presence of /etc/network/interfaces, but it modifies it only for MAAS, and it creates config files for separate interfaces in interfaces.d/ directory. And this should work for all providers except manual [11:57] TheMue: what is the blog about IPv6? [12:01] good morning all [12:02] mornin' [12:02] katco: o/ [12:02] mgz: thanks for leaving dominion with reception by the way - I got it fine [12:02] mgz: sorry I missed you for the Boston expedition [12:02] I hope it was fun [12:02] I had a very quiet Saturday morning [12:03] voidspace: no probs, hope you have a good night on friday [12:03] mgz: yeah, pretty epic [12:03] got in at 5am [12:03] fwereade: ping [12:03] voidspace, pong [12:04] fwereade: I'm part way through what's turning into quite an invasive change [12:04] fwereade: and I think you at least ought to be aware of it - and ideally give a thumbs up to it [12:04] fwereade: the basic gist is that we need to be copying sessions in order to use mgo socket pooling [12:05] fwereade: which means we need to *not* be storing collections (which have a reference to the global session) on state.State [12:05] fwereade: so I've pulled them out, providing methods to get the collection (using a new session) whenever it's needed [12:05] voidspace, hmm, ok -- is it just a matter of making them funcs that return suitable collections with new sessions? perfect [12:05] voidspace, +1 [12:05] fwereade: it's *largely* a mechanical change - with a few places that need careful thought [12:06] fwereade: work so far https://github.com/voidspace/juju/compare/copy-sessions [12:06] fwereade: yeah, it's *mostly* that [12:06] fwereade: the compiler won't tell me how many places I have to change - just that there are too many... [12:06] voidspace, sounds like a nice commit on its own [12:06] vladk: http://blog.toxa.de/archives/606 [12:07] fwereade: it needs some support work - for example, when we change the password we need to re-open the state because the existing session has the wrong credentials [12:07] fwereade: the goal is to eliminate i/o timeout errors which we are pretty certain come from using the one global session [12:07] fwereade: my lunch date just arrived [12:07] bad timing [12:07] biab [12:08] well, about an hour or so - sorry [12:33] mgz: katco: standup? [12:33] wallyworld: sure, let me grab another cup of coffee. long night -.- [12:33] sure :-) [12:40] bbmuchl [12:40] in new zealand :/ [12:52] late morning everyone [12:56] hey perrito666 === gsamfira1 is now known as gsamfira [13:31] natefinch: [13:31] katco: forgot to ask - did you get access to canonicaladmin? [13:33] perrito666: can we move our meeting later? I have to call my insurance company about why they didn't cover my wife's $500 ultrasound [13:33] sure we can [13:39] wallyworld: i emailed sarah and she just said to use my login from my new-hire email(s) [13:39] wallyworld: and i haven't gone back and checked those yet [13:39] ok, np. just wanted to make sure you were ok [13:40] wallyworld: ty i will let you know if i have any issues [13:40] ok [13:40] wallyworld: cheers! :) [13:41] mgz: lmk if you have any questions regarding that PR [13:41] wallyworld: do you know why we have the upstart script redirect jujud's output to a file, rather than just having loggo write to a file? [13:42] katco: sure thing [13:42] natefinch: my guess is because bu default, loogo writes to stdout and so it's simpler just to have upstart capture that stdout data and redirect from there [13:42] but we could look at changing that [13:43] i don't imagine it would be too hard, but it would be extra code [13:43] cause we'd need to register a different writer with loggo in each process [13:43] yeah, but it's code and not text in a string that gets written to a configuration file :) [13:44] sure, understood. i'm just guessing the reason :-) [13:44] :) [13:44] wallyworld: do we expect multiple jujud processes running on the same machine? [13:44] yes [13:44] machine agent, unit agent [13:45] ahh [13:45] still, one log file each wouldn't be a terrible idea [13:45] i think they get one log file each now anyway [13:45] machine-x, unit-y etc [13:45] ahh ok, yeah [13:46] natefinch: i updated all the deps and other stuff for the licensing based on the new gojson repos. but then i noticed the readmes in those repos still referenced binary132 and i didn't have the will power to do it all again [13:47] wallyworld: I can fix the readme files... sorry, guess I forgot about those. [13:47] natefinch: np. you will need to update dependencies.tsv in both 1.20 and master [13:48] thanks for sorting it out though [13:50] welcome [13:53] wwitzel3: btw ran across this and thought you'd be interested: http://jamescooke.info/git-to-squash-or-not-to-squash.html [13:53] wwitzel3: it's an interesting question; not sure where i fall yet. i kind of like squash conceptually [13:58] katco: read that one a while back. if there was a way to persist the reflog and share it for each branch / the entire repo .. well that would be perfect :) [13:59] katco: but it is only a local copy (afaik), so for me, doesn't quite solve the problem of keeping tools like git bisect useful when large feature branches introduce subtle bugs. [14:00] wwitzel3: i'm not yet familiar enough with git to comment on that. i haven't used bisect at all. [14:01] wwitzel3: sounds like you're a few steps ahead of me in your thinking [14:17] wwitzel3: your dog is so nice [14:17] * perrito666 loves dogs [14:19] perrito666: which dog? one of them isn't mine [14:19] wwitzel3: a dog just paraded behind you while we where having the stand up [14:19] like a big sheppard [14:19] but pixelated :p [14:21] perrito666: yeah, that is a german sheppard, her name is Daisy, watching her for a friend. [14:36] natefinch, or maybe katco , can you help triage bug 1343318 . I relates to logging which has changed and will change soon [14:36] <_mup_> Bug #1343318: Node syslog full of rsyslog warnings

[14:36] natefinch, katco : Do we intend to fix this for 1.21.0, or later [14:38] sinzui: i have never triaged before; and i don't think i can comment on when things will be fixed yet, but i'm looking at the log none-the-less [14:40] sinzui: is there a way to tell what version he was running? i recently fixed a bug where rsyslog could not read from a machine-x.log [14:40] katco, understood.These are my rules, though they don't list that we can choose medium when we think we think we need to discuss it in relation to other issues in afew months: https://docs.google.com/a/canonical.com/drawings/d/1vPqrgXDduzwV_N01ORF6jdnprwykf1ofiIaEAmIwOuA/edit [14:40] sinzui: (version of juju) [14:41] sinzui: thanks for that :) [14:41] katco, The user is Canonical IS, so I believe 1.18.1, but they are also migrating some thing to 1.20.1 They will not run devel juju [14:41] sinzui: yeah, thanks :) [14:43] katco, The easy question to ask is if this work it thematically related to what we are doing, are we will to commit to fixing this in the 1.21.x series, if so, I would mark the bug high and assign it to next-stable milestone. If not, I would mark the bug as Medium because I think we will want this bug closed in the next 6 months [14:44] sinzui: gotcha. i really have to defer to a lead. i'm just not on-boarded enough to make a call. however, it's possible that this is a symptom of a regression that has already been fixed. [14:44] sinzui: https://bugs.launchpad.net/juju-core/+bug/1339715 [14:44] <_mup_> Bug #1339715: Juju 1.21-alpha1 local provider does not create all-machines.log

[14:45] katco, exactly why I asked you :) [14:45] sinzui: aha! ;) [14:49] sinzui: so just to make sure the loop is closed; do you mind if i defer to a lead? [14:50] katco, not at all [14:54] hazmat, do you want to include this bug in your "usability" mandate . bug 1343569 points out that you cannot dump the config of running service to backup or reuse it to deploy another service the same way [14:54] <_mup_> Bug #1343569: Juju should have an easy way to dump then reuse service config