[00:05] <thumper> davecheney: as commented, I'd agree no floats if we were charging people, but I don't think we are
[00:05] <thumper> as it is just used for ordering, I think floats are ok
[00:07] <davecheney> thumper: i think it's going to bite us in the arse
[00:07] <davecheney> and ordering could easily be acomplished by
[00:07] <davecheney> const millicent = 1
[00:07] <davecheney> const cent = 100 * millicent
[00:07] <davecheney> etc
[00:08] <thumper> what's this about go constants being untyped?
[00:09] <davecheney> they are untyped
[00:09] <davecheney> they are ideal
[00:09] <thumper> it makes constants like C #defines
[00:10] <thumper> which are horrible
[00:10] <thumper> why would they replicate that?
[00:10] <davecheney> probably, but a little more specified
[00:10] <davecheney> so you don't need 100000000000000ULL
[00:10] <davecheney> it works pretty well in practice
[00:21] <bac> davecheney: could you have a look at https://codereview.appspot.com/7610046 again?
[00:22] <davecheney> bac: sure
[05:50]  * davecheney has just filled up all the WIP slots on the review lane
[06:28] <jam> davecheney: poke about hp bootstrapping
[06:29] <jam> just to check what your OS_REGION_NAME is set to. It needs to be something like: export OS_REGION_NAME="az-3.region-a.geo-1"
[06:29] <jam> if it is just 'region-a.geo-1' then we can't find which compute region you actually want (az-1, az-2, az-3)
[06:32] <davecheney> jam: ahh, that is probably it
[06:34] <davecheney> error: cannot start bootstrap instance: cannot find image satisfying constraints: No such flavor
[06:34] <davecheney> http://www.vh1.com/celebrity/bwe/images/2009/10/FLAVA-FLAV-DAYLIGHT-SAVINGS-TIME.JPG
[06:40] <davecheney> jam: do I need to supply a default-image-id or something to run on hp ?
[06:40] <jam> davecheney: yes, you need default-image-id. I thought that 'juju init' would report an HP image
[06:40] <davecheney> i didn't use juju init
[06:40] <jam> davecheney: default-image-id: "75845"
[06:41] <davecheney> ta
[06:41] <jam> default-instance-type: "standard.xsmall"
[06:41] <davecheney> oh god, number cannot be string
[06:41]  * davecheney pulls hair out
[06:42] <jam> davecheney: where was that? I've gotten it working with the above config on Windows, so I would think you wouldn't have a problem.
[06:42] <davecheney> don't quote 75845
[06:42] <davecheney> then yaml tries to 'sense' the type of the key
[06:42] <jam> davecheney: http://paste.ubuntu.com/5627423/
[06:43] <jam> I'm using a ""
[06:43] <jam> I think it is supposed to be a string
[06:43] <davecheney> wow, bootstrap just pooed a screenful of binary data at me, ending with, returned unexpected status: 400; error info: {"badRequest": {"message": "Cannot find requested image 75845: Image 75845 could not be found.", "code": 400}}
[06:43] <davecheney> is that image for region a, or region b ?
[06:44] <jam> davecheney: there is nothing in region b
[06:44] <davecheney> hmm, i'm using region-a
[06:44] <davecheney> but using the indentity endpoint in region-b
[06:44] <jam> yeah, I just got the same, it worked last week. :(
[06:44] <jam> apparently they expired their images
[06:44] <davecheney> bzzzzzzzzzzzzzt
[07:14] <rogpeppe> mornin' all
[07:55] <dimitern> morning!
[07:55] <dimitern> jam: sorry about the meeting yesterday - got the mail to late to attend
[07:55] <jam> dimitern: np
[07:56] <dimitern> jam: so it's going to be a regular weekly meeting at 19h UTC ?
[07:56] <jam> yeah
[07:56] <jam> I think 16h UTC
[07:57] <jam> yeah, 16h is what I see on the calendar
[07:57] <jam> which is 17/18 DST
[07:57] <jam> for you,  I believe
[07:57] <dimitern> jam: weird.. it showed as 20-20:30 local for me
[07:58] <jam> If it was the email I sent, it was 20-20:30 local time in Dubai
[07:58] <jam> not CST
[07:58] <jam> CET?
[07:58] <dimitern> jam: I see :)
[08:17] <dimitern> mramm: can you add the monday meeting to the juju calendar please?
[08:18] <mramm> which monday meeting?
[08:19] <dimitern> mramm: the juju cross team meeting (or smth)
[08:19] <mramm> I'll get it added
[08:20] <dimitern> mramm: cheers!
[08:22] <rogpeppe> dimitern: https://codereview.appspot.com/7650048/ is up for review if you fancy it
[08:22] <dimitern> rogpeppe: click
[08:30] <dimitern> rogpeppe: while i'm on it - https://codereview.appspot.com/7497047 ?
[08:30] <rogpeppe> dimitern: looking
[08:50] <dimitern> rogpeppe: reviewed
[08:50] <rogpeppe> dimitern: thanks!
[09:04] <jam> mgz: /wave
[09:04] <mgz> jam: mumble?
[09:05] <jam> soitenly
[09:49] <dimitern> rogpeppe: ping
[09:49] <rogpeppe> dimitern: pong
[09:49] <dimitern> rogpeppe: how about that CL?
[09:50] <rogpeppe> dimitern: sorry, i've been chatting with mark
[09:50] <dimitern> rogpeppe: np, no rush
[10:15] <jam> mgz: mumble is timing out for me right now, so I'm going to go grab a snack, bbias
[10:20] <mgz> jam: mumble kicked me...
[10:20] <mgz> and I can't reconnect
[10:20] <jam> mgz: try one more time
[10:20] <jam> I'm back on it
[10:22] <jam> mgz: still no love?
[10:25] <mgz> it's back
[10:47]  * dimitern quick lunch
[11:33] <dimitern> i'd like a review on https://codereview.appspot.com/7497047
[11:54] <rogpeppe> dimitern: reviewed. not very well, i'm afraid though - i'm having difficulty wrapping my head around it.
[11:55] <dimitern> rogpeppe: tyvm
[11:56] <dimitern> rogpeppe: the idea is to have multiple service settings (per charm url), and the refcount is used to track and clean them
[11:57] <dimitern> rogpeppe: we need this in order to keep the old settings until there are any units that might use them (before they are upgraded to the new charm)
=== BradCrittenden is now known as bac
[12:01] <rogpeppe> dimitern: one difficulty i have is that we're building a quite involved set of txn ops, and i have no idea what it might look like eventually, nor how the various asserts and ops might play together
[12:02] <dimitern> rogpeppe: well, there are tests to make sure the refcounts are handled correctly
[12:03] <rogpeppe> dimitern: are there any concurrent-change tests?
[12:03] <rogpeppe> dimitern: i suppose we know that the whole txn must go through as a unit, so maybe it's not worth it
[12:04] <rogpeppe> dimitern: i'm just concerned that there are many possible txn "programs" this code can be building and i'm not clear that the tests are exercising all possibilities.
[12:05] <dimitern> rogpeppe: no concurrent tests, but I don't think they'll be that useful, and moreover i can't really wrap my mind around how to do it
[12:05] <rogpeppe> dimitern: i wonder if you could enumerate a few cases for me, showing the whole set of txn ops produced for a SetCharm in various cases
[12:06] <dimitern> rogpeppe: if you refer to settingsInc/Dec ops they are used only in a few places (add/destroy service mostly)
[12:06] <rogpeppe> dimitern: they're used by SetCharm
[12:06] <dimitern> rogpeppe: you mean service.SetCharm, right?
[12:06] <rogpeppe> dimitern: yeah
[12:07] <rogpeppe> dimitern: hmm, maybe i should download the branch and put a few printfs in
[12:09] <dimitern> rogpeppe: please do, if you can
[12:09] <dimitern> rogpeppe: so, cases:
[12:10] <dimitern> rogpeppe: we need to make sure the config is compatible, and also check the charmurl is different (not already set)
[12:10] <wallyworld_> mgz: https://pastebin.canonical.com/87106/
[12:11] <rogpeppe> dimitern: because you're not allowed to change the charm url once it's set?
[12:11] <dimitern> rogpeppe: no, because it's already set
[12:11] <rogpeppe> dimitern: so you can't upgrade to a charm from a different URL?
[12:12] <dimitern> rogpeppe: the crux of the ops happens in changeCharmOps
[12:12] <dimitern> rogpeppe: you can't upgrade to the same url
[12:12] <rogpeppe> dimitern: ah, i see
[12:13] <dimitern> rogpeppe: and also we need to either create or replace the settings for this charm and service
[12:13] <dimitern> rogpeppe: i suppose adding more comments inline will help with understanding better what's going on
[12:14] <dimitern> rogpeppe: and we inc the new, dec the old, adding asserts as needed
[12:15] <rogpeppe> dimitern: yeah, i think that would help me, at any rate
[12:16] <dimitern> rogpeppe: ok, i'll then
[12:18] <mgz> wallyworld_: ta
[12:19] <rogpeppe> dimitern: FYI, here's an example of the ops we're producing: http://paste.ubuntu.com/5628008/
[12:20] <wallyworld_> mgz: lp:~wallyworld/juju-core/rsyslog-conf   <-- wip, bootstrap = good, unit nodes = bad
[12:20] <dimitern> rogpeppe: wow that's nifty how did you generate it?
[12:21] <rogpeppe> dimitern: github.com/davecgh/go-spew/spew is really handy :-)
[12:21] <dimitern> rogpeppe: cool :) thanks
[12:24] <rogpeppe> dimitern: i produced the output above with simply: 		spew.Dump(ops)
[12:24] <rogpeppe> dimitern: (oh except i ran Edit x/^ +/x/ /c/	/ on it because i prefer tab indentation and that's not the default)
[12:25] <dimitern> rogpeppe: nice!
[12:38] <mgz> wallyworld_: so, first thing to try is just copying /var/lib/cloud/instance/scripts/runcmd and running it, see what errors you get if any
[12:38] <wallyworld_> ok, will do
[12:38] <mgz> it looks from your cloud-config it should be safe to run again at a later stage
[12:39] <mgz> but I note there's no set -e
[12:39] <mgz> so everything should be getting run, regardless of exit codes
[12:40] <mgz> the other thing that comes to mind...
[12:40] <wallyworld_> mgz: running runcmd manually orked
[12:40] <mgz> are the perms on the config being borked somehow? this runs as root, I expect rsyslog isn't fusyy, but you never know
[12:41] <wallyworld_> rsyslog.conf can be owned by root
[12:41] <mgz> right, and your issue was it wasn't present at all...
[12:42] <wallyworld_> yes, "sudo sh ./runcmd" worked and generated the onf file and restarted syslog and everything is act expected
[12:42] <wallyworld_> but it's not running on boot
[12:42] <wallyworld_> or so it seems
[12:43] <mgz> I think it is... from the output
[12:43] <mgz> before the key generation, there's a line from wget
[12:43] <mgz> then a note about rsyslog start/running
[12:44] <wallyworld_> ah yes, missed that
[12:44] <mgz> ...I'd hurl in a `cat /etc/rsyslog.d/25-juju.conf` before that restart cmd
[12:46] <mgz> I wonder if this was just the port thing
[12:46] <wallyworld_> can't see how - it's just echoing to a file to generate the conf
[12:46] <mgz> and just the lack of output, and somehow confusion over the conf file existing was borking stuff
[12:47] <wallyworld_> i'll dig some more tomorrow, too tired now, thanks for help
[12:48] <mgz> I don't see what's special about the non-provisioning state apart from the send-logs-too part
[12:48] <wallyworld_> yeah
[12:48] <mgz> er... non-bootstrap node, whatever we're callig it
[12:56] <mgz> a ghost!
[13:07] <jam> mgz: mumble?
[13:08] <mgz> ghost!
[13:27] <abentley> jam: I've updated the branch to remove references to format 2.  Could you land it for me, please?
=== wedgwood_away is now known as wedgwood
[13:28] <jam> abentley: sure, I'll try
[13:29] <abentley> jam: Thanks.
[13:31] <jam> abentley: in progress now
[13:32] <jam> abentley: done
[13:32] <jam> rev 1022
[13:32] <abentley> jam: Thanks!
[13:33] <jam> abentley: can you run the test suite on trunk just to be sure? I'm running it here
[13:33] <abentley> jam: Okay.
[13:38] <bac> dimitern: sorry, i sent the email before pushing the code.  i'll ping you when it is done
[13:38] <dimitern> bac: sure, np
[13:39] <dimitern> bac: I got the habit of leaving draft comments on rietveld and then just lbox propose-ing - it sends them along
[13:39] <bac> dimitern: it does?  oh that's great.  i thought i had to do it manually
[13:40] <dimitern> bac: yes, it's nifty (both submit and propose do this)
[13:45] <rogpeppe> dimitern: yeah, and it has the nice advantage that you don't post comments saying "done" when you haven't actually pushed the changes yet...
[13:47] <dimitern> rogpeppe: exactly :) i use this a lot!
[13:48] <dimitern> rogpeppe: btw I don't know why with your benchmarking branch one of the cases was run 50 instead of 100 times (like in your dump)
[13:48] <rogpeppe> dimitern: it runs it more times if it runs faster
[13:48] <rogpeppe> dimitern: it tries a small number of iterations first
[13:48] <dimitern> rogpeppe: I see
[13:49] <rogpeppe> dimitern: obviously yours was a little bit slower than mine and pushed it over the boundary
[13:49] <dimitern> rogpeppe: no doubt - it has a teensy core i3 (one of the slowest)
[13:49] <rogpeppe> dimitern: SSD?
[13:50] <dimitern> rogpeppe: yes and a good one
[13:50] <rogpeppe> dimitern: i'm surprised that doesn't make a bigger difference actually. i suspect it's all io bound
[13:50] <rogpeppe> dimitern: i just got the SSD that i could order with the laptop
[13:54] <dimitern> rogpeppe: mine is OCZ Vertex 128G
[13:55] <dimitern> rogpeppe: is supports sata3 i think, but my mb is too old
[13:55] <rogpeppe> dimitern: i've no idea how to find out what mind is...
[13:55] <rogpeppe> s/mind/mine/
[13:55] <dimitern> rogpeppe: :) just fiddled about in google about this - sudo hdparm -d /dev/sda
[13:55] <dimitern> ops
[13:56] <dimitern> not -d: -i instead
[13:56] <rogpeppe> dimitern: one of the great things about macs is it's very easy to find out all the gory details of the machine specs
[13:56] <dimitern> rogpeppe: how?
[13:56] <rogpeppe> dimitern: apple menu, About, Details.
[13:57] <rogpeppe> dimitern:  HDIO_GET_DMA failed: Inappropriate ioctl for device
[13:58] <bac> dimitern: changes pushed
[13:58] <TheMue> rogpeppe: isn't the answer simple - always too slow and too small (any system). ;)
[13:58] <dimitern> rogpeppe: ah, yes - ubuntu used to have something like that (easily accessible somewhere... not the About this Computer in the tray menu though)
[13:58] <rogpeppe> TheMue: actually i find it's pretty quick.
[13:58] <dimitern> rogpeppe: -i is the info, -d is get/set dma sorry - see above
[13:58] <dimitern> bac: sweet!
[13:58] <rogpeppe> dimitern: ah, i thought -d was the "dump" option :-)
=== teknico__ is now known as teknico
[13:59] <TheMue> rogpeppe: i'm happy right now too, it has been a geeks statement that hw can't be fast enough. :D
[13:59] <rogpeppe> dimitern: TOSHIBA THNSNC128GCSJ
[13:59] <dimitern> rogpeppe: well, I was instantly afraid it was something bad, so checked :)
[14:03] <dimitern> bac: nice, good to go
[14:04] <bac> dimitern: by that you mean, submit?
[14:04] <TheMue> rogpeppe, mramm: hangout?
[14:05] <abentley> jam: All tests ok.
[14:06] <jam> a
[14:06] <jam> abentley: yep, same here
[14:06] <dimitern> bac: yeah, at least on my part I like it
[14:07] <bac> dimitern: ok.  dfc already said LGTM and i addressed his issue.  so off it goes.
[14:38] <dimitern> rogpeppe: can you take a look at https://codereview.appspot.com/7497047 again to see if it makes more sense now? added more comments
[14:38] <rogpeppe> dimitern: will do
[14:39] <dimitern> mramm: what happened to the OCR card?
[14:40] <dimitern> mramm: I mean any steps towards it? what do you think?
[14:40] <rogpeppe> anyone other than dimitern fancy doing a review of https://codereview.appspot.com/7650048/ ?
[14:40] <rogpeppe> also there's a fairly trivial followup which actually makes the StateWatcher work: https://codereview.appspot.com/7663048
[14:41] <dimitern> rogpeppe: I'll take the follow-up
[14:41] <rogpeppe> dimitern: ta!
[14:47] <dimitern> rogpeppe: what will happen to other two watchers in state/state.go - watcher, pwatcher? should they be removed (eventually)?
[14:47] <rogpeppe> dimitern: no - they're what all the other watchers (including the allWatcher) build on
[14:48] <dimitern> rogpeppe: but having them in State as fields - wouldn't it be a bit confusing?
[14:49] <rogpeppe> dimitern: you mean allWatcher vs watcher?
[14:49] <dimitern> rogpeppe: yes, and pwatcher
[14:49] <dimitern> (the fields, not the actual impl)
[14:49] <rogpeppe> dimitern: the fields are needed (and used) by all the other watchers
[14:50] <niemeyer> So, is allWatcher going to receive data about every single thing that happens in the environment?
[14:50] <rogpeppe> dimitern: but if you can think of better names, please feel welcome to suggest
[14:50] <dimitern> rogpeppe: no, just asking, sgtm
[14:50] <niemeyer> By the way, state importing from state/api/params when state/api depends on state seems slightly backwards
[14:50] <rogpeppe> niemeyer: currently, yes (because that's what the GUI requires). in the near future we will summarise and hopefully avoid seeing everything.
[14:51] <niemeyer> rogpeppe: Ugh!
[14:51] <rogpeppe> niemeyer: there have been some awkward cyclic import issues around there. the params package is there precisely to avoid a cyclic import.
[14:52] <niemeyer> rogpeppe: There are many ways to avoid cyclic imports
[14:52] <rogpeppe> niemeyer: we need to work with the GUI as it currently is before moving forwards.
[14:52] <niemeyer> rogpeppe: Often, though, cyclic imports means that the organization itself isn't great
[14:52] <rogpeppe> niemeyer: perhaps you're right.
[14:52] <rogpeppe> niemeyer: suggestions welcome.
[14:52] <niemeyer> rogpeppe: I had several suggestions before:
[14:53] <niemeyer> 1) Implement the proper API that makes the GUI work with it
[14:53] <niemeyer> This could require changes in the GUI, of course
[14:53] <rogpeppe> niemeyer: i'm not sure what that means
[14:53] <niemeyer> rogpeppe: Not implementing allWatcher
[14:53] <rogpeppe> niemeyer: i could not get the GUI folks to change their entire structure at this point, i'm sorry.
[14:54] <niemeyer> rogpeppe: Well, you actually could.. we've talked about this before in a call as I remember it
[14:54] <niemeyer> rogpeppe: Spending an awful lot of time to put something broken in juju-core is no better than fixing the GUI
[14:55] <rogpeppe> niemeyer: i believe that even when fixed, the GUI will want information about the status of all units, even if it's in summary form.
[14:55] <niemeyer> rogpeppe: That's a broken design
[14:56] <rogpeppe> niemeyer: is it broken to want to know how many units are in a failed state?
[14:56] <niemeyer> rogpeppe: Nobody can possibly see 100k units at once in a meaningful way
[14:56] <rogpeppe> niemeyer: sure they can - *summarised*
[14:57] <niemeyer> rogpeppe: Heh.. that's a pretty different API than the watch API we have in place
[14:57] <rogpeppe> niemeyer: really?
[14:57] <niemeyer> rogpeppe: You wouldn't be watching a unit.. you'd be watching a single summary document
[14:58] <rogpeppe> niemeyer: yes, either that, or summarising changes into a summary held in memory
[15:00] <rogpeppe> niemeyer: that's the next phase in the allWatcher implementation (it's probable that the name "allWatcher" may no longer be appropriate after those changes)
[15:04] <niemeyer> rogpeppe: This is a massive infrastructure to compute "100 units in failing state"
[15:04] <niemeyer> rogpeppe: That's a single database query
[15:04] <niemeyer> rogpeppe: Indexed
[15:05]  * rogpeppe goes off to die
[15:06] <dimitern> :D
[15:06] <niemeyer> http://www.dilbert.com/2013-02-25/
[15:07]  * rogpeppe can't muster a smile.
[15:09] <dimitern> in such cases i remember monty python's "always look at the bright side of life"
[15:12] <niemeyer> rogpeppe: We just need a proper plan for how to move forward
[15:14] <niemeyer> rogpeppe: Perhaps this conversation took place and I'm just not aware, but given the conversations we had when I was pushing things closer, I though there was agreement on certain things that are clearly not the case at the moment
[15:15] <niemeyer> rogpeppe: It's not necessarily bad, but it's definitely the kind of thing that needs alignment to avoid digging a big hole
[15:15] <niemeyer> rogpeppe: I'll send a public sync up email
[15:16] <niemeyer> rogpeppe: Or half-public, perhaps
[15:19] <mramm> niemeyer: I don't think the hole is quite that big
[15:19] <mramm> niemeyer: we can pretty easily change both sides -- either now or later
[15:20] <mramm> niemeyer: which is not to say that digging holes and then patching them in later is the best thing to do
[15:20] <niemeyer> mramm: Agreed. My concern at this point is mostly that I had discussed this with rogpeppe and hazmat in a call before, and it felt like the direction was a different oen
[15:20] <niemeyer> one
[15:21] <niemeyer> mramm: I don't want to be right, though.. I just want us to know that we're not digging that hole, and have a plan
[15:22] <mramm> niemeyer: yes, but unfortunately that was 2+ months ago and discussions have happened since then
[15:23] <niemeyer> mramm: Excellent
[15:23] <niemeyer> mramm: Discussions is what we need
[15:23] <mramm> niemeyer: I know roger and gary have been in pretty constant communication
[15:23] <niemeyer> mramm: Why is it hard to build the GUI on top of the existing watchers in watcher.go?
[15:23] <mramm> niemeyer: I have not been present in all of those meetings myself
[15:24] <mramm> niemeyer: my (partial) understanding is that there are many things that the gui needs to know that are not yet watched in watcher.go
[15:24] <niemeyer> mramm: Why is it hard to change the GUI to not require a "give me everything that ever changes in the whole environment" model?
[15:25] <mramm> niemeyer: I think everybody agrees that we are going to change the GUI not to require that
[15:26] <mramm> niemeyer: I think the only question is how that happens -- timelines, how steps in that direction get defined, etc
[15:26] <niemeyer> mramm: i understand that. I'm simply surprised that, given the timelines, it's easier to rebuild watcher.go from the ground up.
[15:27] <mramm> niemeyer: Why do you say from the ground up?   Am I missing something about the implementation?
[15:27] <niemeyer> mramm: None of the logic in state/watcher.go is being used
[15:32] <mramm> niemeyer: ok
[15:32] <niemeyer> mramm, rogpeppe: There's no one dying.. and perhaps what is being one is the best possible way to do things.
[15:32] <mramm> that is much more useful information than anything I've seen so far
[15:33] <mramm> alarm bells are less helpful than specifics
[15:33] <niemeyer> mramm, rogpeppe: But if nothing else, we need to be aware of the reasons for going in that direction, and why doing less would be harder
[15:34] <niemeyer> mramm: My email was mostly a request for information..
[15:34] <mramm> and questions like "hey, is there a reason we couldn't reuse any of the logic in state/watcher?" are much more likely to advance the discussio
[15:34] <niemeyer> mramm: I assumed that these topics were well covered internally
[15:34] <mramm> discussion
[15:34] <niemeyer> mramm: That question happened months ago
[15:35] <niemeyer> mramm: Either way, I'm sending a mail to canonical-juju
[15:35] <mramm> ok, what was the answer then?
[15:35] <mramm> niemeyer: please do not do that yet
[15:35] <niemeyer> mramm: It's a sync up mail
[15:36] <mramm> niemeyer: please send it to me first
[15:36] <mramm> you can do what you want, of course
[15:37] <mramm> but I think that it would be very valuable to focus this issue on technical discussion
[15:37] <niemeyer> mramm: Don't worry, it's not a heat-up email.. it's just a way to get a written down plan about where we're headed to
[15:37] <mramm> and remove the high-stakes sort of alarm trigger words that have been used thus far
[15:38] <hazmat> fwiw i do agree that a summary doc (effectively getting aggregate  unit counts to state up to the service level would be cut out alot of traffic)
[15:38] <mramm> my understanding at this point (not being in all the meetings) is that we all sort of agree on the future
[15:39] <gary_poster> y
[15:39] <hazmat> there's some concern about the latency for fetching the actual unit once the ui is interactive, ie. pay up front costs, and keep the rest of the traffic async delta
[15:39] <mramm> where we will have summary documents, and not just a firehose of data
[15:40] <hazmat> but that may have been pushed by some of the zk communication overhead.. even simple things like login where adding multi-second latency due to libzk issues (patches extant).
[15:40] <mramm> I think we all agree that being notified of every change to a twenty thousand node nova compute center would be problematic
[15:41] <mramm> hazmat: yea, I don't think it makes sense long term for the gui to think that it can effectively keep the entire state in memory...
[15:41] <mramm> one of the reasons we went to mongo is that we don't want to have to be able to keep the state in memory on the server -- let alone on somebody's phone ;)
[15:41] <hazmat> agreed, there was a notion that it could shift to indexed db and keep only working set in memory.. but yes.. simplicity would be better served by summary
[15:42] <hazmat> and invalidation refs
[15:42] <hazmat> mramm, html5 apis like indexeddb or even localStorage allow for quite alot of client side state not in mem
[15:43] <mramm> hazmat: sure
[15:44] <mramm> niemeyer: so, with respect to the current situation -- I'm pretty sure we agree on end-state
[15:44] <mramm> niemeyer: the discussion right now is about how to most expediently get there
[15:46] <dimitern> hazmat: the only issue with local storage is the quota limit of 5MB (i think at least in chrome, ff maybe as well)
[15:47] <hazmat> dimitern, right.. hence indexeddb
[15:47] <dimitern> hazmat: there's no quote there?
[15:47] <dimitern> *quota
[15:47] <mramm> dimitern: hazmat: but let's be clear here, with a reasonable mongo database you *don't* need to keep the entire state in memory for the GUI
[15:48] <hazmat> indexeddb and webworkers both have  good support on mobile
[15:48] <hazmat> dimitern, 50mb
[15:48] <dimitern> mramm: except some of it - basically for performance reasons
[15:48] <mramm> sure
[15:48] <mramm> some data needs to be local
[15:49] <mramm> but that is a subset of the whole state
[15:50] <hazmat> the original collection view that the gui was supporting, needed to be able to display effectively all of a service's units with state and ip info on a single view.
[15:50] <hazmat> with dynamic sized units and filtering.. it seems the future designs have moved into a paging / filtering mode
[15:50] <dimitern> hazmat: i though you display only services, not individual units
[15:52] <hazmat> dimitern, try clicking through a service on the ui.. you get to a service overview with  units, and to a unit details with ability to manipulate a unit (resolved, retry, delete, etc).
[15:53] <dimitern> hazmat: right, I see it now
[15:55] <hazmat> anyways.. i'm much more confident of paging through a result set of units w/ mongodb and low latency then zk (where each node is at *least* one  round trip)
[16:18] <mramm> hazmat: clicing through can query more data right (sorry, was distracted for a bit)
[16:21] <hazmat> mramm, yup... but keep in mind we get some pretty bad client physical separation to api servers that also adds to latency.. ie  southamerican client querying to an openstack .. the full push delta work minimized the perceived user latency when the app was loaded, previously it would be like random pauses as you clicked through some pages.
=== teknico_ is now known as teknico
[16:42] <hazmat> one of the larger concerns is making sure the client is operating on a correct server side representation when performing actions
[16:42] <hazmat>  realistically only the server can enforce that
[16:42] <hazmat> which means the client needs to send revision handles to contexts its operating on
[16:43] <hazmat> there's also one significant api abberation in the juju-cli.. all the others operate on setting state to goal state.. but add-unit operates as a delta
[16:43] <rogpeppe> hazmat: agreed
[16:44] <rogpeppe> hazmat: but i'm not sure about the "needs to send revision handles" part
[16:44] <rogpeppe> hazmat: as long as we have sensible operations and unique handles for entities, i think we're ok
[16:44] <rogpeppe> hazmat: (we don't currently have the latter, unfortunately)
[16:44] <hazmat> rogpeppe, its last write wins then.. two clients writing out to config
[16:45] <rogpeppe> hazmat: yeah. i think that's reasonable.
[16:47] <niemeyer> hazmat, rogpeppe, mramm: So, sync up mail sent..
[16:49] <niemeyer> Hopefully demoted of emotion and any kind of blame.. just trying to see if we can get a written plan
[16:51] <niemeyer> I'm heading off to lunch, back in a bit
[16:53] <mramm> niemeyer: have fun at lunch
[16:54] <mramm> niemeyer: hopefully we can get down to technical specifics and hammer out anything that needs hammering out
[16:57] <mramm> I just noticed that you sent to canonical-juju, that alleviates my concern, I was flipping back and forth between IRC conversations, and mis-read you to say you were going to send a message to canonical-tech
=== deryck is now known as deryck[lunch]
[18:06] <mgz> fuuuu
[18:10] <rogpeppe> done for the day
[18:11] <rogpeppe> g'night all
=== deryck[lunch] is now known as deryck
[18:50] <niemeyer> mramm: Yeah, certainly not a topic relevant for tech..
[19:45] <benji> hi all, I have gone through one review round on https://codereview.appspot.com/7600044/ and now need a second +1
[19:49] <benji> by the way, while we're discussing reviews, I have a question: my current understanding that two LGTM reviews (with or without "trivials") are all that are required for approval (after any "trivials" are addressed to the branch author's satisfaction).  Is that the case?
=== BradCrittenden is now known as bac
[21:05] <m_3> _thumper_: hey... lp question about moving bugs to new branches if you gotta sec
[21:05] <_thumper_> m_3: hey, otp right now
[21:05] <m_3> ack
[21:36] <niemeyer> benji: It used to be.. but if someone questions it, that counts too
[21:37] <niemeyer> benji: I mean, two LGTM + 1 "I don't get it" == hold
=== wedgwood is now known as wedgwood_away