[01:19] <axw> wallyworld: I'm going to have to take off for a while after standup, gotta take my brother to the GP
[01:19] <wallyworld> no orrie
[01:19] <wallyworld> worries
[01:31] <wallyworld> hml: standup if you're free?
[03:08] <menn0> thumper: quick one pls? https://github.com/juju/juju/pull/7129
[03:08]  * thumper looks
[03:08] <thumper> approved
[03:12] <menn0> thumper: cheers
[03:31] <anastasiamac> thumper: wallyworld: menn0: coming?
[03:32] <menn0> anastasiamac: yep
[04:56] <wallyworld> jam: if you had time later to talk about CMR, can you ping me?
[07:52] <wallyworld> axw: you have time for a smallish review? https://github.com/juju/juju/pull/7130
[09:49] <axw> wallyworld: sorry, ended up having to take my brother to the hospital ED, had to get a cast on his broken foot
[09:49] <axw> so today was a write off
[09:49] <wallyworld> axw: hope he's ok! how did he break it?
[09:50] <axw> wallyworld: skateboarding
[09:50] <wallyworld> kids these days :-)
[09:50] <ashipika> he should stick to cricket ;)
[09:50] <axw> wallyworld: yes... kids... this is my older brother :p
[09:51] <wallyworld> lol
[09:51] <wallyworld> still younger than me
[09:52] <ashipika> any of you core gents care to have a look at https://github.com/juju/juju/pull/7109 ?
[09:52] <wallyworld> sure
[09:52] <ashipika> wallyworld: thanks
[10:04] <wallyworld> ashipika: there's an issue in that a new facade method is added to uniter facade without bumping the version to 4
[10:04] <wallyworld> and the uniter client needs to check that the version it is talking to is 4 and faily gracefully if not
[10:05] <wallyworld> there's a BestFacadeVersion method or similar that is used to see what facade version is available
[10:05] <wallyworld> the client calls that and if it gets 3 back, it knows the new SLA method is not available
[10:06] <wallyworld> s/the client/the caller
[10:07] <axw> wallyworld: I'm going to be out a few hours tomorrow too. dentist for myself, then brother back to the GP. le sigh
[10:07] <wallyworld> axw: no worries, whatever you need
[10:07] <wallyworld> dentist = wallet pain :-(
[10:08] <ashipika> wallyworld: ah, yes.. forgot about versions.. )
[10:09] <wallyworld> ashipika: yeah, PITAi know
[10:09] <ashipika> wallyworld: well.. there's pain and there's the dentist :) i'll take core over the dentist..
[10:10] <wallyworld> :-)
[10:11] <jam> wallyworld: were there other CMR things, or just what you sent in the email?
[10:12] <wallyworld> jam: for now the email. was my lasy comment where i restated the semantics for network-get as per your thinking?
[10:13] <wallyworld> ie in my reply
[10:13] <jam> wallyworld: yeah, context implies "what do you want for that machine" and no relation context is "what do I need for local configuration"
[10:13] <tasdomas> wallyworld, could I ask you to take a look at this PR as well: https://github.com/juju/juju/pull/7114 ?
[10:14] <wallyworld> jam: i really want to try and avoid using public addresses where possible and supported by the provider snd deployment etc, but it will be hard to do that without a lot more development
[10:14] <wallyworld> tasdomas: sure, ok
[10:16] <wallyworld> jam: also, we'll need to see if we can allow charms to work unchanged via unit-get; not sure if that's feasible yet. but i'd prefer not to invest a lot of time into making unit-get work with CMR if possible or if we can justify avoiding it and putting the effort into making the charms more modern and use network-get
[10:17] <jam> wallyworld: you're looking more for 'relation-get' to give an appropriate 'private-address' for the remote side
[10:17] <jam> 'unit-get' is about local config
[10:17] <wallyworld> tasdomas: you already have 2 lgtms :-) did you still want me to look?
[10:18] <jam> eg "mysql$ relation-get wordpress" should give the same thing as "wordpress: network-get mydb -r mysql"
[10:19] <tasdomas> wallyworld, well, if you could quickly glance over the PR, I'd really appreciate it
[10:19] <wallyworld> tasdomas: ok
[10:21] <wallyworld> jam: relation-get is for the whole relation databag, right. there in general won't be a "wordpress" key. it will be something like "private-address" from memory
[10:21] <axw> wallyworld: reviewed your PR
[10:21] <wallyworld> axw: ty
[10:22] <jam> wallyworld: relation-get private-address is what they generally call
[10:22] <jam> private-address is the one bit of the data bag that Juju puts automatically
[10:22] <wallyworld> jam: right, that's my understanding also
[10:23] <jam> (more interesting is the call in the other direction, to be fair, but I started writing before thinking all that through)
[10:23] <wallyworld> jam: so the issue is juju doesn't really know explicitly what the charm wants to use "private-address" for
[10:23] <wallyworld> whereas when it calls network-get we can make a more informed decision
[10:23] <wallyworld> as to "my local ddress" or "what i advertise"
[10:23] <jam> wallyworld: so *relation-get* is fairly clear, because it is asking for "give me the IP address of the other application"
[10:23] <jam> so that I can talk to it
[10:24] <jam> the issue is that Wordpress and Mysql might actually coordinate on a different key
[10:24] <jam> like say
[10:24] <jam> URL
[10:24] <wallyworld> right, like postgres does
[10:24] <jam> so we want 'network-get' (instead of unit-get) so that when MySQL populates the URL field
[10:24] <wallyworld> but postgres would make that url by calling neywork-get
[10:24] <jam> it can give the context for what IP address it wants to put in there
[10:24] <wallyworld> exactly
[10:24] <wallyworld> that's why i want to not use unit-get at all
[10:25] <wallyworld> and migrate the charms we care about
[10:25] <jam> wallyworld: my understanding is that most charms actually use 'relation-get private-address' over custom URLs
[10:25] <jam> I don't think I've advocated fixing unit-get
[10:25] <jam> just 'relation-get private-address' and 'network-get'
[10:25] <wallyworld> my issue with the former is we are still guessing a bot at the the purpose of why the charm wants to use private address rather than being explicit
[10:26] <wallyworld> use of network-get ensures we don't guess anything
[10:26] <wallyworld> but we can see how it plays out i guess
[10:28] <wallyworld> axw: will comment - list vs find - list is used by model admin, it exposes connection count, charm name, other details. find is used to discover what endpoints are available. they both read from the same part of the model, hence shared code but different facade apis
[10:28] <wallyworld> tasdomas: sorry, got caught up, looking now
[10:29] <jam> wallyworld: again, we know that when Wordpress calls relation-get private-address for MySQL there isn't anything *Wordpress* could do but connect to MySQL
[10:30] <jam> which is different from "maybe I need to set a bind address for MySQL in the MySQL charm, or I need to give the public address because someone is calling me from outside my network"
[10:30] <wallyworld> jam: yeah, maybe i'm being overly paranoid about thinking there could be another reason
[10:31] <wallyworld> jam: the fun bit will be figuring out what to provide for that private-address value. eg for aws wirh models in same region etc, it can be the cloud local address. but for azure it will need to be the public address etc
[10:31] <wallyworld> and that then affects how the firewall ingress rules are done
[10:31] <jam> wallyworld: so IMO, whatever you would put in "network-get -r relation --primary-address" on one side would be what you would put in "private-address" to be seen from the other side
[10:32] <jam> if we started with CMR == public-address that would be a reasonable starting point given everything we've seen so far
[10:32] <jam> in fact, only in the very special "its all my account in AWS" is it possible to use private address
[10:32] <jam> cause otherwise its a "different network" even if they are both private, etc.
[10:33] <rick_h> jam: anything to chat over today?
[10:33] <jam> hi rick, I'll brt
[10:33] <wallyworld> jam:  true, but i was hoping to at least be able to reasonable short circuit where possible
[10:34] <wallyworld> but yeah, public address would work, so long as a public address is available
[10:34] <wallyworld> not always the case though
[10:34] <wallyworld> eg openstack
[10:40] <wallyworld> tasdomas: quick comment - the tables in the CLI output should no longer use CAPS for headers
[10:40] <wallyworld> "Title case" instead
[10:41] <tasdomas> wallyworld, ah, ok
[10:41] <tasdomas> wallyworld, thanks
[10:41] <wallyworld> np
[10:41] <wallyworld> tasdomas: we made that change for 2.0 as per Mark's guideance
[10:41] <wallyworld> so best to change the budget commands also :-)
[10:44] <tasdomas> wallyworld, will do - thanks for the heads up
[10:44] <wallyworld> np
[11:13] <mup> Bug #1674655 opened: juju kill-container fails <juju-core:New> <https://launchpad.net/bugs/1674655>
[11:21] <ashipika> wallyworld: the current uniter facade version is v4.. having added that method, do i need to bump it up to v5?
[11:21] <ashipika> wallyworld: or just fail gracefuly if talking to v3..
[11:21] <ashipika> or lower
[11:22] <wallyworld> ashipika: the issue is that 2.0.x and 2.1.x will be using v4, right? a hacky way would be to make the api call and handle the NotImplemented error as an indication the api is not supported
[11:23] <wallyworld> CodeNotImplemented i think
[11:23] <wallyworld> that would be less strictly correct bit still work
[11:23] <wallyworld> bumping to v5 shouldn't make much effor tthouhh
[11:23] <perrito666> just bump the version, is almost free
[11:23] <wallyworld> just a few lines to register the facade
[11:24] <wallyworld> we do that for the storage facade for example
[11:25] <ashipika> ack.. v5 then
[11:41] <jam> hi perrito666
[11:41] <perrito666> jam: hi
[11:53] <mup> Bug #1674655 changed: juju kill-container fails <juju-core:Invalid> <https://launchpad.net/bugs/1674655>
[11:58] <frankban> wallyworld, perrito666: do you remember what constraints can be applied to lxd and to kvm containers when creating a machine in juju?
[11:58] <perrito666> frankban: no
[11:58] <wallyworld> frankban: for lxd at least, i don't think we do much. we may honour mem for kvm
[11:59] <wallyworld> not 100% sure though
[11:59] <frankban> wallyworld: my guess was mem and disk for both?
[11:59] <frankban> I'll go with that
[11:59] <wallyworld> could do, yeah, sounds plausible
[12:00] <frankban> wallyworld: ty
[12:00] <wallyworld> frankban: i just checked
[12:00] <wallyworld> mem, core, disk for kvm
[12:00] <wallyworld> cores
[12:01] <frankban> wallyworld: ah cool thanks
[12:01] <frankban> cores
[12:01] <wallyworld> frankban: and nothing that i can see for lxd
[12:01] <frankban> wallyworld: ok the GUI will reflect that
[12:02] <wallyworld> frankban: we do need to introduce max constraints for lxd so the contaners don't use all the memory for example
[12:02] <wallyworld> right now. constraints are min
[12:03] <frankban> wallyworld: interesting, that will be a good challenge for UX
[12:03] <wallyworld> yes
[12:03] <wallyworld> we're thinking of new, separate constraints. max-mem etc
[12:06] <frankban> ah, cool
[12:06] <frankban> wallyworld: so, when using the lxd provider, do w esupport any constraints instead?
[12:06] <frankban> wallyworld: for top level machines (lxd containers in that case)
[12:07] <wallyworld> frankban: as far as i am aware, any lxd instance creted ignores constraints. the host machine on which the lxd container runs is a separate issue
[12:08] <frankban> wallyworld: ok thanks
[12:09] <frankban> wallyworld: last question, I know that the provider type for local models in juju2 is "lxd". was it "local" or "lxc" in juju1?
[12:09] <wallyworld> frankban: local i think from memory
[12:09] <frankban> wallyworld: I think I remember it was local yeah
[12:09] <frankban> thanks
[12:09] <wallyworld> that was a lot of wine ago
[12:19] <ashipika> wallyworld: had a discussion with mattyw.. and decided not to bump the facade version just because of one added method.. the api method will fail gracefully when talking to an older facade though
[12:20] <ashipika> wallyworld: otherwise we'll exceed maxInt too soon :)
[12:20] <wallyworld> ashipika: it's only a couple of lines of code - more probbly to fail gracefully
[12:20] <wallyworld> literally one register call
[12:22] <wallyworld> ashipika: see apiserver/application/application.go
[12:23] <wallyworld> the only other change is to call BestFacadeVersion in the caller
[12:25] <ashipika> wallyworld: thy will be done..
[12:25] <wallyworld> vers := root.BestFacadeVersion("Uniter")
[12:25] <wallyworld> ty :-)
[12:25] <wallyworld> if vers < 5 {} else {}
[12:26] <ashipika> BestAPIVersion or BestFacadeVersion?
[12:26] <ashipika> wallyworld: ^
[12:27] <wallyworld> ashipika: i yse BestFacadeVersion
[12:27] <wallyworld> ashipika: but
[12:27] <wallyworld> BestAPIVersion() can be used directly on the client
[12:27] <wallyworld> both work
[12:28] <wallyworld> so if you already have the client created, BestAPIVersion
[12:28] <wallyworld> if you just have the api root, BestFacadeVersion
[12:36] <mattyw> wallyworld, any ideas on the best way to test this?
[12:36] <mattyw> wallyworld, doesn't look like there are any existing mocks we can use?
[12:37] <wallyworld> mattyw: you mean unit test or real world test? for unit test, there is a way but i forget, i can check
[12:37] <ashipika> wallyworld: unit test
[12:37] <mattyw> wallyworld, unit test, we're trying to find examples, but looks like we might have to write the mocks ourselves
[12:39] <wallyworld> mattyw: i can't find any tests for existing things like this. we used to have a way. for this PR, i would ok it so long as the new stuff works
[12:48] <ashipika> wallyworld: it appears that if i create a uniter.State with api/base/testing.APICallerFunc.. the testing.APICallerFunc returns BestFacadeVersion 0..
[12:48] <ashipika> wallyworld: so a glitch in the testing.APICallerFunc allows me to test that
[12:49] <wallyworld> ashipika: that could well be. i've not dug into that code in a while. if you have found a way then awesome
[12:49] <ashipika> wallyworld: fwereade has a todo on the BestFacadeVersion in the APICallerFunc.. but it has never been done.. long term backlog
[12:49] <wallyworld> yeah, we have a lot of tech debt
[13:03] <perrito666> jam: ?
[13:08] <jam> omw
[13:09] <perrito666> o my wod?
[13:11] <ashipika> wallyworld: pushed fixes for https://github.com/juju/juju/pull/7109 ..
[13:12] <ashipika> wallyworld: no i didn't
[13:14] <wallyworld> ashipika: so no version bump?
[13:14] <ashipika> wallyworld: i.was.changing.the.wrong.branch.please.don't.ask.
[13:17] <ashipika> wallyworld: there.. i pushed.. this time the right branch
[13:17] <wallyworld> ah, that's better
[13:18] <anastasiamac> jam: feature tst PR for 'get-config' and 'juju config' as discussed: https://github.com/juju/juju/pull/7132
[13:24] <wallyworld> ashipika: looks good with a rename suggestion. thanks for the extra work on the versioning
[13:40] <perrito666> ok, while my tests re-run on CI ill go run a couple of errands, bbl
[13:40] <ashipika> wallyworld: renamed.. thanks for all the help!
[13:57] <jam> anastasiamac: reviewd
[17:54] <perrito666> annyone in need of a review? this is THE time to ask
[20:14] <mattyw> thumper, ping?
[20:15] <thumper> mattyw: hey, otp just now
[20:15] <mattyw> thumper, no problem will you be around in about 45 minutes to talk model migration?
[20:15] <mattyw> thumper, irc will be fine - unless you really want to see my face
[20:51] <thumper> mattyw: I have about 9 minutes now
[20:51] <bdx> how's it going all?
[20:52] <thumper> well... not everything is on fire
[20:52] <bdx> I'm wondering, how a new dependency is added to dependencies.tsv?
[20:52] <bdx> eehh ... good .. I guess
[20:52] <bdx> sorry
[20:52] <bdx> ha
[20:53] <rick_h> thumper: is so full of happy thoughts
[20:54] <rick_h> thumper: bdx wants to play with newrelic and juju and is trying to see how to inject the newrelic bits
[20:54] <rick_h> thumper: any hints on how to add stuff is <3
[20:54] <thumper> bdx: new library dependencies normally have to be approved by the tech board
[20:54] <thumper> but how I add things is do write the code that uses the libraries
[20:55] <thumper> then go `godeps ./... | grep 'newlibname'
[20:55] <thumper> then add that line into the dependencies.tsv file in alphabetical order
[20:55] <thumper> that way you don't override the whole file
[20:55] <thumper> but just add new bits
[20:59] <thumper> bdx: make sense?
[21:00] <bdx> thumper: yes, perfect. thank you!
[21:01] <bdx> thumper: looking at the newrelic go apm agent installation instructions, "Import the github.com/newrelic/go-agent package in your application. Create a config and application in your main function or in an init block." - where would be the best place to place this in the juju codebase?
[21:01] <bdx> thumper: in here -> https://github.com/juju/juju/blob/staging/cmd/jujud/main.go#L39 ?
[21:01] <thumper> no
[21:01] <thumper> I'd keep all newrelic stuff isolated in the new relic provider
[21:02] <bdx> thumper: newrelic provider - what is this?
[21:02] <thumper> oh...
[21:02] <thumper> what is newrelic exactly?
[21:03] <bdx> thumper: its a monitoring/alerting platform
[21:03] <bdx> thumper: they have an apm product for go applications
[21:03] <rick_h> thumper: you should test out the free newrelic platform on your django app
[21:03] <bdx> I was trying to play around with seeing what types of metrics we can get for juju via the go agent
[21:04] <rick_h> thumper: <3 getting hints at slow queries, etc
[21:05] <bdx> thumper: (sorry about the acronyms) APM - appication performance monitor
[21:06] <bdx> http://imgur.com/ysLJimx
[21:08] <thumper> otp again...
[21:10] <bdx> thumper: speaking of acronyms ... otp?
[21:12] <bdx> one true pairing?
[21:13] <bdx> on the plane?
[21:13] <bdx> :)
[21:18] <thumper> on the phone
[21:38] <niedbalski> anastasiamac, thumper I can't locate the 1.25 backport of lp#1613855
[22:40] <bdx> quick question
[22:41] <bdx> is the jujud binary that runs on controllers the same jujud binary that runs on juju deployed machines?
[22:43] <bdx> I can't seem to identify any difference between the two ...
[22:53] <menn0> bdx: the controller machine agents, workload machine agents and unit agents all use the same jujud binary
[22:53] <menn0> bdx: the behaviour of the binary changes depending on the context
[22:54] <menn0> bdx: internally, it's the workers that run that change the behaviour the most
[23:10] <bdx> menn0: thanks for that
[23:11] <bdx> the context provided by what is in mongo?
[23:13] <bdx> menn0: "it's the workers that run that change the behaviour the most" - does this mean that the workers (that exist in jujud) will run in the controller context, but not outside of that?
[23:13] <menn0> bdx: sorry, on a call. will get back to you.
[23:13] <bdx> menn0: np
[23:32] <rick_h> thumper: sent you an email with details, test it running and added your ssh key so you can sshuttle to the network and view the grafana as it runs.
[23:32]  * rick_h goes back to dishes
[23:54] <stokachu> im going to try and get a macOS version of conjure-up ready before the beta release on thursday
[23:54] <stokachu> is someone able to push juju 2.2 beta to brew?