[00:49] huwshimi sorry? [00:50] no the env destroy calls call the ecs [00:50] ah [00:51] huwshimi https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L1070 [00:51] hatch: Oh, I see my confusion is from the uncommitted machines just get removed directly [00:52] yeah it's almost impossible to keep the execution flow of this app in the head now haha [03:35] huwshimi hey I'm going to take off, need anything before I do? [03:35] hatch: I don't think so. Thanks for those reviews, all that stuff has landed. [03:35] hatch: I'll hook up your deleted state stuff tomorrow [03:36] sounds good, I'll do the copy/paste fix in the morning and have it landed for you [03:36] hatch: Have a good night [03:37] you too, cyas === uru__ is now known as urulama [07:45] mornin' all [07:47] rogpeppe: morning [07:47] urulama: hiya [07:48] so, push(hash), push(hash), remove(hash) results with a CS without (hash) blob? [07:50] rogpeppe: i'm a bit lost in what you wrote yesterday. I thought that we used names with blobstore, just that names are hashes. so, what's the difference between "file name" and "file name as a hash"? [07:51] urulama: the issue is that the refcount is maintained on the hash, not on the name [07:51] urulama: ManagedResource (the juju/blobstore exposed API) deals only in names [07:52] urulama: we use the hash for the name, but that doesn't actually help [07:52] rogpeppe: ok. stay with me here, i've been in document/talk land for too long in last weeks to see the implementation code before my eyes :) [07:53] rogpeppe: so. if i push (hash-of-wp) and push(hash-of-wp), don't i get two WP-s with different revision numbers? [07:53] urulama: WP? [07:53] or what happens with push(H), push(H), remove(H)? [07:53] WP = wordpress [07:54] urulama: by "push" you mean "post" ? [07:54] urulama: i'm not quite sure what level you're talking about here [07:55] rogpeppe: sorry, yes, s/push/put [07:55] urulama: in the underlying blobstore, if you do PutForEnvironment(wp); PutForEnvironment(wp); RemoveForEnvironment(wp), then wp will be removed [07:56] urulama: those are not the semantics we'd like [07:56] urulama: and i'd been stupidly assuming that the above sequence would result in a blob in the blobstore with refcount=1 [07:56] rogpeppe: why do we need to ref-count? what's the use case that if I put something in twice, and remove once, that it should stay there? [07:57] urulama: if two charms or bundles or resources are identical, we want them to share the blob and not duplicate the storage space for that [07:58] rogpeppe: ah, ok, that explains all of it. [07:58] urulama: i actually think that ref counting is questionable given our requirements. [07:59] rogpeppe: why? [07:59] urulama: my first thought was not to ref count, but just do a simple GC [07:59] urulama: because even with ref counting, you'll need a GC [07:59] urulama: and if you don't need to ref count, everything becomes simpler (and quicker) [08:00] rogpeppe: GC as in ... if there's a blob "hanging" without reference, just remove it, and do this once-in-a-while? [08:00] urulama: the reason you need a GC even with ref counting, is that there are always going to be windows where you've incremented a ref count, but not added the catalog entry [08:00] urulama: yup [08:01] s/windows/time windows/ [08:01] rogpeppe: ok, gc seems fine and simple/controllable solution. however, how does it help with put/put/remove example? [08:03] urulama: well, Remove is a no-op on the (well, my) blob store. We just remove the catalog entry (outside of the blob store) [08:04] urulama: ref counting is ok too, really (though, as I've said, you probably want a GC too). ref counting assures timely collection of resources. [08:05] urulama: but what isn't great is that juju/blobstore doesn't provide us with the capability to refcount hashes directly [09:37] frankban: morning [09:37] urulama: morning [09:37] frankban: nice PR ... looking [09:38] urulama: thanks! [09:38] rogpeppe: could you please take a look at https://github.com/juju/charmstore/pull/70 ? [09:38] frankban: looking [09:38] thanks [09:39] frankban: sent you a summary of a blobstore discussion with rogpeppe this morning in case you are interested. feedback welcome. [09:40] urulama: interesting thanks [09:54] rogpeppe: good idea re just using the entity doc. do we want to send url.Revision as entityCharm.Revision()? [14:41] hatch: you around? [14:42] I am [14:42] The args that are included in an ECS command… ['django', 1] [14:43] The first one seems to be the service name, but what's the second? The integer? [14:44] kadams54 they map to the respective env call [14:44] hatch: bug 1349565--did you spot that on ec2, or local? [14:44] Bug #1349565: visiting a /inspector url in a real env causes the charmbrowser to be blank [14:44] jcsackett ec2 although I don't think it would matter [14:45] hatch: Ah, so in this case (add unit), it would be (service, numUnits, toMachine, callback, options) [14:46] options is an ecs argument, it gets stripped off before saving into the changeset [14:46] https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L1237 [14:50] hatch: i was looking through the code to see about the refactor we talked about yesterday and realized i should probably try to actually reproduce, and it appears resolved on local. i'm trying ec2 now. [14:53] jujugui call in 7 [14:54] jcsackett interesting....I don't recall anyone doing any work on it, so you could visit the url like /inspector/mysql/charm for example? [14:54] hatch: yeah, going straight to /inspector/juju-gui or /inspector/juju-gui/charm worked fine. [14:56] mm interesting, when you get the ec2 version up, if it works i'd like to give it a try just to be sure it wasn't one computer vs another or something [14:56] I don't recall anything landing that would fix the problem [14:58] jujugui call in 2 [15:00] "It's taking too long to connect you to this video call. Try again in a few minutes." [15:00] urulama kadams54 call [15:01] hatch: trying ^^^ [15:01] Attempt #2 also seems to be stalled. [15:09] hatch: boo. ec2 does indeed fail. [15:10] jcsackett phew* [15:10] :) [15:10] hatch: phew? why phew. [15:10] that's *bad*. [15:10] :p [15:10] it means i have to go fix it now. [15:10] lol I suppose, but also good because if it was fixed....by nothing....it might have been a spurious error [15:11] jcsackett so this might be part of the real fix stuff to just render the inspector and have it wait for data [15:11] hatch: yeah, i think that's the case, but there are, as always, edge cases. :p [15:30] luca so this added services thing would only be visible when mv is visible? [15:32] hatch: ah no, I should of said in the email... [15:32] yes....yes you should have :P [15:32] hatch: the added services sidebar is the default sidebar for the canvas [15:32] hatch: you will be able to click a button (not shown in the prototype) that shows the charm browser [15:32] http://giphy.com/gifs/what-despicable-me-minion-4JseZwbYRmq2Y [15:33] hatch: rofl [15:33] lol [15:34] ok lets gloss over that little bit for a second..... [15:35] what purpose does this serve vs the canvas? I kind of feel like the only thing the canvas does now is show general relations [15:35] if both are visible at the same time....it's kind of like a duplicate of information [15:35] I can reply to this in the email, just figured we could chat about it first :) [15:37] hatch: well, in the first iteration this allows you to a) show/hide a service from view and b) highlight a service and it’s related services AND which services it can connect to. [15:37] ahh so it's kind of like a filtererer [15:38] hatch: when viewing MV, this will allow you to filter your list of machines. If you don’t want to see machines with Apache on it then you can turn that service off and it will hide the machines it is on, if it is the only service on that machine. [15:38] hatch: you’ll be able to switch them all off for instance and then switch wordpress on and only see wordpress machines [15:39] hatch: and in future iterations networks will also be listed in the added services bar, this means that user could be able to hide networks and the services inside them all at once. [15:39] hmm ok as a filter I could see this being a pretty cool feature [15:39] hatch: we’ve also spoken about being able to group services and this would act in the same way as networks [15:39] hatch: yeah [15:39] so now as far as it being the default.... [15:40] hatch: it also exposes key information like, how many units a service has and other environment wide services. [15:40] I'm thinking that maybe the charmbrowser should be the default but it remember which one you have active....I don't want new people to have to 'find' the charmbrowser [15:40] so this way once the user has switched to this view, then it remembers it and stays here [15:41] Makyo how goes the review? :) [15:44] hatch, I thought jcsackett took it, saw his tag. I can look now if you want though. [15:44] Makyo: i took my tag off thinking you would take it. [15:44] :p [15:44] review volunteer collision. :Pp [15:44] I'm on it, then!\ [15:44] * jcsackett laughs [15:44] sorry about that. [15:45] lol [15:50] Done [15:52] thanks [16:27] guihelp: looking for someone with ECS experience to do a pre-impl chat on this "don't autoplace units" work. [16:28] sure [16:28] standup? [16:28] Sure [16:28] I'm there [16:39] Out for lunch [16:42] bac: https://github.com/CanonicalLtd/charmstore-charm/pull/2/files#r16115122 [16:42] * bac looks [16:45] jrwren: do you have that charm currently running? [16:45] i mean, do you currently have it deployed somewhere? [16:51] bac: No, I just removed it. [16:51] bac: would you like me to deploy it somewhere? [16:55] jrwren: next time you have it running do a 'juju get charmstore'. i think you'll see the descriptions for the items in config.yaml are not rendered very well. but, i may be wrong. have you tried that? is that why you didn't put in line-breaks? [16:57] bac: I have tried it, and that is why I didn't put in line breaks. [16:57] bac: if I put in line breaks I get very terrible rendering. [16:57] jrwren: ok, cool. [16:58] jrwren: so, like this 'juju get' will dtrt? [16:58] bac: I'm tempted to file a bug about it. I feel like the yaml should be able to be more readable [16:58] +1 [16:59] bac: yes, juju get charmstore inserts line wraps. [16:59] bac: I wanted to use yaml | line wrap feature, but if I do that, then it ruins the juju get line wrap inserting [17:00] bac: Output of juju get charmstore: http://pastebin.ubuntu.com/8037699/ [17:00] nice [17:01] yeah, i wish they would dedent the description before doing their own wrapping [17:02] bac: *gasp*. I now think it was my fault. I should have used > instead of | [17:03] using | is ugly: http://pastebin.ubuntu.com/8037729/ [17:05] using > is a little less ugly, but it is not good: http://pastebin.ubuntu.com/8037742/ [17:05] bac: Do you think I should file a bug? [17:06] jrwren: why the single-quotes? [17:07] yeah, i'd file a bug. the charm author should not have to go through such hoops to get nice output. [17:15] hatch: back from my run when you're ready to chat [17:16] cool, almost done writing a psudo spec [17:20] bac: I don't know from where those single quotes come. They are not written in the yaml. [17:20] bac: filing a bug. [17:22] bac: I updated that PR with your suggestions. Thank you for them. [17:22] np [17:22] thanks for the branch! [17:25] kadams54 https://gist.github.com/hatched/101a2b25a2558fd5f6c2 [17:26] Is there a real need for a public method to return a list of unplaced units in the ECS? [17:27] Right now I just do db.filterByMachine(null) [17:27] Would there ever be a situation where the list of unplaced units in the ECS would differ from the DB? [17:27] hmm [17:28] not if everything is working properly [17:28] :) [17:28] good point though [17:34] kadams54 so this looks like 4 branches too so you can split it up into 4 cards and tackle the smaller problems [17:34] Will do [17:49] g'night all [18:22] hatch: what do you think of having the db have a loaded attribute that gets set once data syncs the first time? [18:22] jcsackett the issue is that we can't know when that is [18:22] it's only 'deltas' [18:22] there is nothing saying that 'this' is a special delta [18:23] I mean - technically the first big delta is that one - but there is no guarantee [18:23] hatch: sure, but this is a bit better than the inspector waiting on an add signal or something. [18:23] * hatch puts thinking cap on [18:23] gimme a couple mins to think this one through [18:23] hatch: b/c that way, the inspector fires up, sees no model, waits on data, but if the charm doesn't exist, data is never coming and we'll need a wait timer. [18:24] hatch: whereas if the db says "units are ready" after the signal, inspector can say "are units ready? yes, okay this just doesn't exist." [18:24] and if units aren't ready, render and set once() for loading the data once it's ready. [18:24] s/units/services or s/units/charms in everything i just said. [18:25] :) [18:28] jcsackett ok for the best user experience we need to make it feel fast even if it's not, and not showing the inspector then rendering it when the data comes in will make it feel laggy [18:28] so.... [18:28] we should render the inspector into a 'waiting for data' state [18:28] once it's data shows up then populate the proper elements [18:28] hatch: ok, but sometimes data will never come. [18:28] if the data doesn't show up in some pre-determined time then we will close it and throw a notification [18:29] at least we are saying "you asked for an inspector, here it is, oh, your data doesn't exist you fool....closing" [18:29] :) [18:29] hatch: but that requries a wait timer, which is generally sub-par. [18:29] probably don't call them a fool in the notificaton though [18:29] :) [18:29] hatch: i'm not sold that doing so is superior to the 'loaded' attribute idea. [18:30] the loaded attribute is a non-starter because the charm data they are requesting may not come in the initial load [18:30] you could add a listener on the db waiting for any change events, then parsing them for the data the inspector needs [18:30] then it's not a poll [18:30] that doesn't solve the the case of /inspector/this-charm-never-existed [18:31] that way we'll still need a wait timer; and given the fun we've had with those i'm -1 on it. [18:31] sure, we put a setTImeout on that listener, if it's not called within.....5s? 10s? then we close the inspector and throw a notification [18:31] hatch: realistically in the first delta how often is the data not going to arrive? [18:32] no idea, but it's a bug that'll be impossible to track down because joe-user will say "visited linked url and it just loaded a blank block" [18:33] I much prefer the more resiliant approach [18:33] hatch: it won't load a blank block; if you go to /inspector/charm-does-not-exist and the insepctor sees there should be data, we throw up a notification and close the inspector. [18:33] hatch: and i find bugs around timers to be equally frustrating for joe user and us to sort. [18:34] (the throw up inspector is what we do now in the case where after 30s the data still hasn't loaded) [18:34] s/throw up inspector/throw up notification/ [18:34] right, so your approach is identical to mine except mine isn't dependent on the data showing up all at once [18:35] if juju-core ever decides to change how that initial delta is sent out we're in trouble [18:35] we don't treat any deltas as 'special' now [18:35] so I'd prefer to not start [18:36] i wouldn't say this is treating one as special. it's a relative indication that data has come through. [18:36] data has come through, but not what data [18:36] and it's not on the delta; it's on db.services:add happening. [18:36] or db.services:charms [18:36] dammit, i cannot type today. [18:36] haha [18:36] anyway, i don't want to (and have no idea how to) listen for *a* delta coming through. [18:37] i'm interested in watching for when services gets a service loaded. or charms gets a charm loaded. [18:37] so you want to create an attribute in db.charms which means 'initial load completed' ? [18:37] and setting "ready" flags on those. [18:38] I'm just not sure we can rely on the first call to db.charms.add to trigger that it's done it's initial load [18:38] hatch: call? [18:38] sure standup [18:38] cool === perrito6` is now known as perrito666 === tvansteenburgh1 is now known as tvansteenburgh [21:03] quiet in here :) [21:13] hatch: i think this may need to wait until after MV 1.0 [21:13] jcsackett yeah? [21:13] too indepth? [21:13] ccccccbljtrvggekgghgkkfkvbcrbhflnvuilfgvhcnko check the model to determine whether we're going [21:13] dammit. [21:13] so, we need to get rid of the ghost inspector first. [21:13] as in, release that. [21:14] b/c everything we discussed should be, i think, the responsibility of the service inspector. [21:14] but we need to get the service model before we create the inspector now to check if we're doing a regular or a ghost. [21:15] hatch: unless you think it's reasonable for the browser.js dispatch code to partially render the inspector, etc etc etc. [21:15] ahhh so all of the old code is messing it up [21:15] a bit. [21:15] well I think that the inspector should handle its own rendering [21:16] so that you just pass it data and it does with it what it should [21:16] hatch: yeah. [21:16] jcsackett what if you put the retries in the inspector to be like 10s? [21:16] as a temp fix [21:17] i'll give that a try and throw it at ec2. [21:17] oh, wait, no. it won't work. [21:17] b/c the retry is for the service, and it's not finding the charm that's the issue (once we're inside the inspector code) [21:18] i could update the check to be for model *and* charm, and enter retry if we don't have both. [21:18] that might be the right shim for now, actually. [21:18] and we'll throw in a card that's blocked on MV 1.0 for doing this the right way. [21:18] ...or just leave this one if that doesn't work, i suppose. [21:18] (there is a reasonable chance it will not work :p) [21:19] hatch: you down with more temporary shimming with a card for 1.0 proper fix as we discussed? [21:19] haha yeah I was just going to suggest doing the temp fix with looping for both things to be ready [21:19] I'd prefer a temp fix than it brick the app if someone hits the seemingly valid url [21:19] hatch: yeah. [21:19] cool with doing the temp fix? [21:19] i am. [21:19] disappointed, but cool with it. [21:20] esp since we now have a fully fleshed out idea for the *right* way once MV is released. [21:20] yeah - I think we have bigger fish to fry to try and get mv 1.0 out [21:20] right [21:20] yeah, this got huge and hairy with a quickness. [21:21] ok, i'll do the temp. it'll take me awhile to test it, but i think that should largely work. [22:56] Makyo I think I found a case where your impl doesn't cover, commented in the pr [22:58] kk [22:59] goooood morning huwshimi [22:59] Morning [23:03] hatch, good catch (except we can't delete uncommitted units yet). I'll poke at it tomorrow. [23:04] Makyo right, but that will be coming in mv 1.0 though [23:04] That's why I'll poke at it tomorrow. [23:04] Gotta get James' car from the shop now. [23:04] what? NO DO IT NOW!!!! [23:04] :P [23:04] uh oh, broke car? [23:05] A gasket in his turbo busted and leaked oil into it, so he's been burning oil. [23:05] ouch, expensive fix [23:05] huwshimi the deleted flag branch has landed, do....your.....worst! [23:06] hatch: A brilliant, thanks for that! [23:08] hatch: How do you mock an object so that you can use .get() for the properties? [23:09] (in this case 'env') [23:09] ok sec [23:10] hatch: Also has your daylight savings time changed? [23:11] huwshimi https://gist.github.com/hatched/ee86418459e37e60ca24 [23:11] huwshimi no we don't do DST [23:11] hatch: Oh, I was sure I sure I used to start before your EOD [23:12] it's 5:12pm here now [23:12] you usually start at 4:30 [23:12] I just assumed you were starting later [23:12] :) [23:14] huwshimi my example there assumes you want to return different values depending on the key passed in [23:14] Maybe I haven't noticed since DST changed in April :) [23:14] you can skip all that switch bs if that's not the case [23:14] hatch: No that's what I want to do, [23:14] great [23:14] heh yeah we don't do DST, in the summer, it's light no matter what, in winter it's dark [23:15] switching one hour either way would make no difference