[01:03] menn0: https://github.com/juju/juju/pull/6873 [01:03] menn0: that's the other half [01:37] thumper: looking [01:39] menn0: just doing extra-info for model config now [01:39] thumper: done [01:39] menn0: ta [01:40] man, I was complaining about azure's SDK documentation but their web UI is really slick. [01:40] babbageclunk: well at least that's something :) [01:40] click click click [01:50] menn0, babbageclunk: https://github.com/juju/juju/pull/6874 [01:50] thumper: looking [01:55] thumper: why are we making it a string rather than an object though? [01:57] I guess they're happy feeding it through yaml unmarshalling themselves [01:59] thumper: LGTM'd [02:05] babbageclunk: yeah [02:05] babbageclunk: string allows more flexibility and simpler checks [02:05] babbageclunk: also what I agreed with :) [02:06] thumper: it does make it hard for anything else to use it at the same time, but I guess it's per-model. [02:06] yeah, is per model [02:06] I think if we are going to have multiple things attempt to store data we probably want to think this through a bit more [02:06] and have a different place to store it [02:07] and different API etc [02:07] thumper: What are they using it for out of curiosity? He doesn't say in the bug. [02:07] not sure to be honest [02:08] conjure-up stuff [02:08] hmm... [02:08] babbageclunk: let my look at Tattrs [02:08] which is map[string]string [02:10] ew... [02:10] $ juju model-config info [02:10] ERROR key "info" not found in { ""} model. [02:11] that's not a great error message [02:15] ah well [02:18] babbageclunk: looked at storing as Tattr, I don't think that is a goer... [02:18] there is too much special casing around it for it to be robust [02:18] like, it doesn't deal with spaces very well [02:19] babbageclunk: so I'm back to previous thought, that if we are wanting to store more structured user data, we do it properly with different API can collection [02:19] * redir eods [02:38] thumper: yeah, I think you're probably right. [02:39] babbageclunk: jam mentioned annotations in the review, and I think that would be the way to go [02:39] add a 'juju annotation' cli [02:39] that would work for models or applications or units [02:39] or parhaps machines [02:40] and have the behaviour be the same in general as the model-config [02:40] ish [02:44] babbageclunk: do you have a few minutes to chat? [02:45] I want to talk about the state pool [02:45] thumper: sure. standup hangout? [02:45] sure [03:03] thumper: I'm EOW (started early today). See email for the final PR for the charm URL changes that's merging right now. [03:05] ack [03:05] menn0: have a good weekend [03:05] menn0: see you in just over a week [04:14] holy crap [04:14] babbageclunk: every AllWatcher created creates a state pool for all models [04:14] babbageclunk: each GUI connection creates an all watcher [04:15] babbageclunk: it could just be connecting GUIs to the controller killing things [04:15] I'm going to refactor things so that the AllWatchers created use the single state pool [04:16] and looks at exposing the state pool through the facade base objects [04:16] this may be a bit of surgery [04:16] but shouldn't be too bad [04:16] * thumper hopes [04:17] well, that is tomorrow sorted [04:22] thumper: every state object stores a list of all transactions for every model even if it only uses some of them [04:26] thumper: state/watcher/watcher.go 'current[watchKey]int64' tracks the revno of every object seen in the transaction log [04:26] I'd like to see them sharing that underlying watcher if possible [04:26] thumper: ooh, that might be it. [04:27] gah, using the resource API to update tags on azure resources requires specifying the API version per resource type. :( === frankban|afk is now known as frankban [08:43] Bug #1658549 opened: Security issue: jujud is not owned by a user on the system [08:43] Bug #1658549 changed: Security issue: jujud is not owned by a user on the system [08:43] Bug #1658549 opened: Security issue: jujud is not owned by a user on the system [09:07] Morning, is there a way (even a hack) after all to be able to deploy CentOS workloads locally with LXD ? Related bug here -> https://bugs.launchpad.net/juju/+bug/1495978 [10:00] morning [10:01] deanman: ill be gone for about an hour, but I dont think that woul work [10:01] deanman: have you tried jus passing the series and see what hapens? (assumin you have centos templates) [10:08] perrito666, I have simple charm that has only centos7 defined in its metadata. [10:09] Checking logs it nags about `machine-0: 12:08:29 INFO juju.tools.lxdclient no image for ubuntu-centos7 found in https://streams.canonical.com/juju/images/releases/` [10:10] so sometime ago it was hinted that you could trick it by creating a new alias for a local centos7 image with the name `ubuntu-centos7` which didn't work. [10:10] so open to any other suggestions :-) === benji_ is now known as benji === alexisb__ is now known as alexisb-afk [16:33] morning juju-dev [16:35] redir: morning [16:35] redir: hey, by any chance have you ever added a config value? [16:36] in config/config.go? [16:39] perrito666: HasDefaultSEries and PreferredSeries [16:39] funcs not values... [16:39] redir: care to evacuate some doubts for me? [16:40] I'll try [16:40] redir: ho? [16:40] sure [16:40] standup ho [16:40] omw === frankban is now known as frankban|afk === alexisb-afk is now known as alexisb === thumper is now known as thumper-busy [21:03] brb going to run a couple errands [21:03] or bbiab [21:46] * thumper-busy rages against the code [22:19] ah the typicall rage against the machine :p [22:22] * redir back [22:56] if this works, fair dinkum, it'll be a miracle === thumper-busy is now known as thumper [23:06] babbageclunk: mornign [23:06] thumper: morning - how's the releaser stuff? [23:06] quick hangout? [23:06] thumper: actually it's afternoon now [23:06] thumper: sure [23:07] 1:1 [23:17] * redir wonders what a fair dinkum is