| === alexlist` is now known as alexlist | ||
| thumper | wallyworld: ping | 01:42 |
|---|---|---|
| wallyworld | pong | 01:43 |
| thumper | wallyworld: hangout? | 01:43 |
| wallyworld | sure | 01:44 |
| wallyworld | you have one handy? | 01:44 |
| thumper | nope, | 01:44 |
| thumper | can make one | 01:44 |
| wallyworld | ok, your turn | 01:45 |
| thumper | https://plus.google.com/hangouts/_/697901d4a23e194d51d2d6a8e6e35c8f7cfe0102?hl=en | 01:45 |
| wallyworld | davecheney: go question for you if you are about | 03:34 |
| wallyworld | nevermind, figured it out | 03:43 |
| davecheney | wallyworld: back | 03:51 |
| wallyworld | hi, i figured it out, thanks | 03:51 |
| * thumper afk to make dinner, may pop back later to catch fwereade__ | 05:29 | |
| === thumper is now known as thumper-afk | ||
| dimitern_ | morning | 07:09 |
| dimitern_ | shit.. my bad, sorry about trunk | 07:09 |
| dimitern_ | will fix the test and propose a patch | 07:09 |
| fwereade__ | thumper-afk, hey, just woke up, not starting work quite yet, really dropped by to say hi to TheMue | 07:43 |
| fwereade__ | TheMue, ping | 07:43 |
| === mthaddon` is now known as mthaddon | ||
| TheMue | fwereade__: pong | 07:54 |
| fwereade__ | TheMue, heyhey | 07:54 |
| TheMue | fwereade__: heya | 07:54 |
| dimitern_ | https://codereview.appspot.com/9686047/ | 08:08 |
| dimitern_ | this includes a fix for the broken test as well | 08:09 |
| dimitern_ | fwereade__: ^^ | 08:09 |
| dimitern_ | wallyworld: ping | 08:09 |
| dimitern_ | rogpeppe2: need second LGTM on this, if you can have a look? https://codereview.appspot.com/10003044/ | 08:12 |
| === TheRealMue is now known as TheMue | ||
| rogpeppe2 | dimitern_: looking | 08:19 |
| rogpeppe2 | dimitern_: reviewed | 08:28 |
| dimitern_ | rogpeppe2: cheers | 08:28 |
| dimitern_ | bump https://codereview.appspot.com/9686047/ | 08:54 |
| dimitern_ | fwereade__: ping | 08:56 |
| fwereade__ | dimitern_, I will be on reviews as soon as possible | 08:56 |
| dimitern_ | fwereade__: cheers; sorry, just checking, it seems pretty quiet today | 08:57 |
| dimitern_ | rogpeppe2: the idea behind embedding baseSuite is to be able to reuse openAs mainly | 08:59 |
| rogpeppe2 | dimitern_: errorSuite doesn't use a state connection | 08:59 |
| dimitern_ | rogpeppe2: ah, you mean only there | 08:59 |
| rogpeppe2 | dimitern_: yea | 08:59 |
| rogpeppe2 | h | 08:59 |
| dimitern_ | rogpeppe2: ok | 09:00 |
| dimitern_ | rogpeppe2, fwereade__: another CL https://codereview.appspot.com/10044043 | 09:15 |
| dimitern_ | fwereade__, rogpeppe2: and another (the corresponding work on client-side) https://codereview.appspot.com/10026044 | 09:45 |
| dimitern_ | fwereade__, rogpeppe2: oops, forgot to change MachinerMachine, will repropose | 09:49 |
| fwereade__ | dimitern_, ha, I already LGTMed, didn't spot that | 09:49 |
| fwereade__ | dimitern_, thanks | 09:49 |
| rogpeppe2 | dimitern_: BTW, about the machiner needing only the life status, won't it need to know the provisioning nonce too? | 09:50 |
| dimitern_ | fwereade__: I would've missed if not for your comment on the earlier CL | 09:50 |
| dimitern_ | rogpeppe2: well, not the machiner per se, the machine agent needs that though | 09:51 |
| rogpeppe2 | dimitern_: same difference from the API perspective | 09:51 |
| dimitern_ | rogpeppe2: I was thinking of having another facade for the MA | 09:51 |
| dimitern_ | fwereade__: thoughts? ^^ | 09:51 |
| rogpeppe2 | dimitern_: what's the difference between the MA and the machine agent from the API perspective? | 09:51 |
| rogpeppe2 | s/machine agent/machiner/ | 09:52 |
| rogpeppe2 | dimitern_: i think that having a separate facade for each entity that want to talk to the API is verging on insanity, but i realise i'm probably the only one that thinks so | 09:52 |
| rogpeppe2 | s/want/wants/ | 09:53 |
| fwereade__ | rogpeppe2, do you know off the top of your head where agents download cs: charms from? env storage, or the charm store? | 09:53 |
| rogpeppe2 | fwereade__: env storage, i'm pretty sure | 09:53 |
| rogpeppe2 | fwereade__: but i may be wrong | 09:54 |
| dimitern_ | rogpeppe2: well, aiui the facades give us extra security by not exposing methods that the entities that use them don't need | 09:54 |
| fwereade__ | rogpeppe2, hmm, how do we do a charm store Get in the api server? | 09:54 |
| rogpeppe2 | fwereade__: we've got to | 09:54 |
| rogpeppe2 | fwereade__: we've got to fetch the charm in order to push it into env storage | 09:54 |
| fwereade__ | rogpeppe2, that shouldn't have a JUJU_HOME, though | 09:55 |
| fwereade__ | rogpeppe2, ah! we set a global variable in the charm package | 09:55 |
| fwereade__ | rogpeppe2, hmm | 09:55 |
| fwereade__ | rogpeppe2, that was the missing piece, thanks | 09:55 |
| rogpeppe2 | fwereade__: what's the JUJU_HOME connection | 09:55 |
| rogpeppe2 | dimitern_: i'm not convinced that extra security is worth 100s or 1000s of lines of extra code | 09:56 |
| fwereade__ | rogpeppe2, I spotted the panic-if-no-charm.CacheDir, and the setting of it in Conn | 09:56 |
| fwereade__ | rogpeppe2, but missed the setting of it in jujud | 09:56 |
| rogpeppe2 | dimitern_: i'm not even sure it really buys us that much security tbh | 09:56 |
| rogpeppe2 | fwereade__: ah | 09:56 |
| dimitern_ | rogpeppe2: it's no way near 100s or 1000s of lines, maybe a few extra 100s, which is not so bad for the added benefit imho, and it's better design in general i think | 09:57 |
| fwereade__ | rogpeppe2, dimitern_, if we're talking about dropping the pointless extra API call on Machiner construction just so we fail unauthed a little earlier I'm keen to kill it | 09:57 |
| dimitern_ | rogpeppe2: well, if there's no method you can call you cannot screw things up, no? | 09:57 |
| fwereade__ | rogpeppe2, dimitern_, the Authorizer will handle that anyway, right? | 09:57 |
| dimitern_ | fwereade__: no | 09:58 |
| fwereade__ | rogpeppe2, dimitern_, if not, ignore me | 09:58 |
| rogpeppe2 | dimitern_: that is true, but vast, sprawling APIs have their own cost | 09:58 |
| rogpeppe2 | dimitern_: and i fear that is where we are heading | 09:58 |
| dimitern_ | fwereade__: we're talking whether it's worth having a separate facade for each worker/agent | 09:58 |
| fwereade__ | dimitern_, rogpeppe2: different tasks need different information, and have different auth concerns | 09:58 |
| dimitern_ | fwereade__: for the sake of better separation of who needs what and security | 09:59 |
| fwereade__ | dimitern_, basically yeah | 09:59 |
| dimitern_ | fwereade__: so having Machiner *and* MachineAgent facades | 09:59 |
| rogpeppe2 | fwereade__: that can be dealt with inside the various methods, no? | 09:59 |
| fwereade__ | dimitern_, although "better security" is here in my mind more in the sense of "comprehensible auth code" rather than actually "different macroscopic behaviour" | 09:59 |
| rogpeppe2 | dimitern_: there is really no point in having more than one facade for a given authenticating entity | 10:00 |
| fwereade__ | dimitern_, rogpeppe2, firm +1 on separating Machiner from MachineAgent | 10:00 |
| dimitern_ | fwereade__: on the api level? | 10:00 |
| dimitern_ | fwereade__: i.e. Machiner and MachineAgent as separate facades | 10:01 |
| fwereade__ | dimitern_, rogpeppe2: the machiner has a very tightly proscribed set of responsibilities, no sense exposing stuff not needed by it | 10:01 |
| dimitern_ | fwereade__: agreed | 10:01 |
| fwereade__ | dimitern_, rogpeppe2: there's enough casual conflation of the two already, I would prefer not to extend that | 10:01 |
| rogpeppe2 | fwereade__: if we're talking about security, what is the point of duplicating types for two clients that are sharing the same session? | 10:02 |
| dimitern_ | rogpeppe2: they *are* different clients | 10:02 |
| fwereade__ | rogpeppe2, with different responsibilities and usage patterns | 10:02 |
| rogpeppe2 | fwereade__: not really. certainly not from a security perspective. | 10:03 |
| dimitern_ | rogpeppe2: and separate connections | 10:03 |
| fwereade__ | dimitern_, not separate connections, surely? | 10:03 |
| dimitern_ | rogpeppe2: although a bit "virtual" | 10:03 |
| rogpeppe2 | dimitern_: they share the exact same websocket connection | 10:03 |
| dimitern_ | fwereade__: well the connection is one, but the way they access the api is through different facade factory methods | 10:03 |
| dimitern_ | hence the "virtual" part | 10:03 |
| rogpeppe2 | fwereade__, dimitern_: it seems to me that this approach amounts to duplicating a subset of the state package for every possible client. | 10:04 |
| dimitern_ | so Machiner uses the machiner facade the same way as before it would use api.State | 10:04 |
| fwereade__ | rogpeppe2, agreed -- the point is that we separate the context of the call from the call itself, and can do the auth work specific to the context; underneath, behind the API, we can absolutely share implementations for the things that make sense to do so | 10:04 |
| rogpeppe2 | it seems like utter crack to me i'm afraid | 10:04 |
| dimitern_ | and the MA similarily | 10:04 |
| fwereade__ | rogpeppe2, exactly so | 10:04 |
| fwereade__ | rogpeppe2, your problem with this is? | 10:04 |
| rogpeppe2 | fwereade__: huge amounts of wasted code. | 10:05 |
| rogpeppe2 | fwereade__: poor maintainability | 10:05 |
| fwereade__ | rogpeppe2, so a change to the provisioner's usage of a machine should always affect how the machiner sees the world? interesting perspective | 10:05 |
| rogpeppe2 | fwereade__: i think it shouldn't be too hard to partition the API so that it can be appropriate for all its clients. | 10:07 |
| fwereade__ | rogpeppe2, we already failed there -- the stuff we send down with the AllWatcher doesn't match the stuff we were sending to the agents | 10:08 |
| rogpeppe2 | fwereade__: the client interface *is* different. but i don't think we need to do the same thing for every agent. | 10:08 |
| fwereade__ | rogpeppe2, I think it's suspect to assume that every client needs the same view of the underlying entities they manipulate | 10:08 |
| fwereade__ | rogpeppe2, that smacks of special pleading | 10:08 |
| fwereade__ | rogpeppe2, most workers use very different subsets of the same state objects today | 10:09 |
| fwereade__ | rogpeppe2, the overlap STM to be pretty minimal | 10:09 |
| rogpeppe2 | fwereade__: they all deal with the same set of basic types - Machine, Unit, etc | 10:09 |
| fwereade__ | rogpeppe2, well... some of them use overlapping subsets of those basic types, but in very different ways | 10:10 |
| rogpeppe2 | fwereade__: i think i'm missing something here: where do you see a potential security problem with a shared agent state API? | 10:11 |
| rogpeppe2 | fwereade__: AFAICS the main issue we're talking about here is visibility of some fields | 10:12 |
| rogpeppe2 | fwereade__: and i can't currently think of fields whose exposure would be a problem. i'll have another look though. | 10:12 |
| fwereade__ | rogpeppe2, two sides to it -- one is "don't expose stuff there's not a known need for, security holes are subtle and quick to anger" | 10:12 |
| fwereade__ | rogpeppe2, but the more important side is | 10:13 |
| fwereade__ | rogpeppe2, that smooshing all the various security contexts into a single method | 10:13 |
| fwereade__ | rogpeppe2, is hard to understand and hard to maintain | 10:13 |
| rogpeppe2 | fwereade__: i think that maintaining n different versions of the same API is also hard to maintain (and to understand and use too) | 10:14 |
| fwereade__ | rogpeppe2, and that putting the auth for a specific context in a context-specific method is noticeably more clear and maintainable, which *is* a second-order security consideration | 10:15 |
| fwereade__ | rogpeppe2, how is it hard to maintain when we can share implementations of the bits that really are the same, and keep auth separate from that? | 10:15 |
| fwereade__ | rogpeppe2, STM like a maintainability win | 10:15 |
| rogpeppe2 | fwereade__: i'm not sure how much we'll really be able to share | 10:16 |
| fwereade__ | rogpeppe2, then your argument against maintainability evaporates, no? | 10:16 |
| rogpeppe2 | fwereade__: eh? | 10:17 |
| === rogpeppe2 is now known as rogpeppe | ||
| fwereade__ | rogpeppe2, if they're different methods, np, no burden | 10:17 |
| fwereade__ | rogpeppe, if they're not different at heart, we can share an implementation | 10:17 |
| rogpeppe | fwereade__: not necessarily. | 10:18 |
| fwereade__ | rogpeppe, either way, putting the auth for a specific context in that context, rather than having one place responsible for all the auth logic, is a clear win | 10:18 |
| fwereade__ | rogpeppe, expand on "not necessarily" please? | 10:19 |
| rogpeppe | fwereade__: it depends on the types of the methods | 10:19 |
| rogpeppe | fwereade__: and whether they contain references to other types that are implemented by the facades | 10:20 |
| jam | mgz: poke | 10:20 |
| fwereade__ | rogpeppe, are you talking about the client-side implementation burden? | 10:20 |
| fwereade__ | rogpeppe, rather than the server? | 10:20 |
| rogpeppe | fwereade__: both actually | 10:21 |
| fwereade__ | rogpeppe, the types are all in params... | 10:21 |
| mgz | hey jam | 10:21 |
| rogpeppe | fwereade__: the plan was to remove params eventually | 10:22 |
| rogpeppe | fwereade__: along with statecmd | 10:22 |
| rogpeppe | fwereade__: params was a temporary hack to get around a temporarily inevitable cycle | 10:23 |
| fwereade__ | rogpeppe, having a common vocabulary with which to talk to the various facades seems not unreasonable to me, especially since it already exists and will ease the burden of implementing common functionality in a common way | 10:24 |
| fwereade__ | rogpeppe, is there a deeper philosophical concern here? | 10:24 |
| rogpeppe | fwereade__: really, i just feel we're multiplying entities many degrees beyond necessity. | 10:25 |
| rogpeppe | fwereade__: and it tickles my spider sense badly | 10:26 |
| jam | mgz: care to do a teddy bear chat about tarmac + requirements, etc? | 10:26 |
| mgz | jam: lets do that. mumble? | 10:26 |
| jam | mgz: I'm there already :) | 10:27 |
| rogpeppe | fwereade__: i feel like we had a nice clear plan for moving forward with this and ending up with a nice clean, coherent and maintainable API, and that suddenly it's all gone to pot and i'm pretty unhappy about it | 10:27 |
| * TheMue is afk, lunchtime | 10:27 | |
| rogpeppe | fwereade__: it may be just post-holiday blues though | 10:27 |
| fwereade__ | rogpeppe, I felt like we had a short-sighted "let's copy the state api" plan that we only went forward with for want of better ideas | 10:28 |
| rogpeppe | fwereade__: that seemed like a really good, low-risk plan to me | 10:29 |
| fwereade__ | rogpeppe, the state api is, let's not forget, a port of a port of an api designed for a different language against a different backend | 10:29 |
| fwereade__ | rogpeppe, the core concepts of juju can still be dimly seen through the mist | 10:29 |
| rogpeppe | fwereade__: the one thing i really did *not* want to do was to redesign the whole thing as we moved to using a network API | 10:30 |
| rogpeppe | fwereade__: i feel we're becoming more and more vulnerable to second-system effect in this area | 10:30 |
| fwereade__ | rogpeppe, we're designing the *network API itself* -- it is definitely not the same thing as we had before, and I am really glad that we've actually done some design work that takes the different context into consideration | 10:31 |
| fwereade__ | rogpeppe, rather than implementing a port of a port of a port | 10:31 |
| fwereade__ | rogpeppe, I think it's a huge win that once we've done the machiner we will have *done the machiner*, rather than half-implemented a type which'll be needed in different contexts in the future, all of which can/will evolve in subtly different directions | 10:33 |
| fwereade__ | rogpeppe, and which exposes all capabilities to all things, and depends on authorizing all operations for all possible contexts in the same place | 10:34 |
| rogpeppe | fwereade__: but then you've got to do the same thing for the provisioner, firewaller, uniter and every other thing we might want to talk to the API. we're not designing "an API" - we're designing many, and the extra burden will continue. | 10:35 |
| rogpeppe | fwereade__: it feels like heinous duplication of effort to me | 10:36 |
| fwereade__ | rogpeppe, better to have many small APIs with clearly defined and largely non-overlapping responsibilities than to propagate the monolithic state package's design to a context that doesn't suffer the same constraints | 10:36 |
| jam | davecheney: hey, can you look at: https://code.launchpad.net/~jameinel/juju-core/timeout-bug-1183320/+merge/167264 (or https://codereview.appspot.com/9984046/ if you prefer) | 10:38 |
| jam | you wrote the original logic and test, but mgo just changed its logic behind our back | 10:38 |
| rogpeppe | fwereade__: i might be happier if the API was not segmented by agent name | 10:38 |
| fwereade__ | rogpeppe, *task* name not agent name | 10:38 |
| rogpeppe | fwereade__: even worse - there's a potentially unbounded set of tasks | 10:39 |
| fwereade__ | rogpeppe, as opposed to segmentation by domain object type? | 10:39 |
| dimitern_ | fwereade__: so we're not doing MachineAgent facade then after all? | 10:39 |
| rogpeppe | fwereade__: yes | 10:40 |
| fwereade__ | dimitern_, MachineAgent, I assumed, was for that subset of behaviour specific to the *agent* as opposed to the workers it runs -- did you have a different concept in mind? | 10:40 |
| fwereade__ | rogpeppe, so your contention is that the monolithic nature of state is a Good Thing, rather than a sad necessity dictated by the constraints of the backend? | 10:41 |
| davecheney | jam: yeah i was looking at that earlier today | 10:43 |
| davecheney | i didn' read the whole thing | 10:43 |
| davecheney | but my general approach is | 10:43 |
| rogpeppe | fwereade__: yes. in particular for clients, i think i should import "launchpad.net/juju-core/state/api" rather than "launchpad.net/juju-core/state/api/mytask" | 10:43 |
| davecheney | the retry delay cause so many headaches | 10:43 |
| davecheney | lets just rip it out ave live with it | 10:43 |
| davecheney | this *IS* a problem that must be solved in mgo | 10:43 |
| dimitern_ | fwereade__: my idea was to have state/apiserver/machineagent/ facade | 10:43 |
| davecheney | we've tried as much as we can to avoid asking for a properly configurabl retry delay | 10:44 |
| dimitern_ | fwereade__: and the corresponding state/api/machineagent | 10:44 |
| rogpeppe | fwereade__: and in fact is there a good reason we can't have that, even if we use different types for each agent on the server side? | 10:44 |
| fwereade__ | dimitern_, that sounds fine -- that's where stuff like CheckProvisioned and SetPassword should live, right? | 10:44 |
| jam | davecheney: k. I think I mostly ripped it out, with the caveat that we still have a custom dial because we need to setup the TLS stuff. | 10:44 |
| dimitern_ | fwereade__: exactly | 10:45 |
| fwereade__ | rogpeppe, keeping packages small and task-focused isn't a good enough reason? | 10:45 |
| fwereade__ | dimitern_, I think that sounds good to me | 10:45 |
| dimitern_ | fwereade__: cool | 10:45 |
| rogpeppe | fwereade__: state is far too big, i agree. but splitting it into n slightly overlapping subsets of it is not going to help matters IMO | 10:46 |
| fwereade__ | dimitern_, (*consider* the overlap between unit and machine, though, it *may* be that we can clearly define an *agent*-specific api that works for units and machines... just something to bear in mind when we implement the second one) | 10:46 |
| dimitern_ | fwereade__: i have a list of all state calls by each agent/worker | 10:47 |
| rogpeppe | fwereade__: at the very least, i think we should organise the API according to authenticating entity rather than according to the task at the other end. | 10:47 |
| fwereade__ | rogpeppe, splitting it into N non-overlapping subsets that are partitioned by underlying data model, rather than business logic, seems like a pretty serious encapsulation violation | 10:47 |
| dimitern_ | fwereade__: the MA only uses machines | 10:47 |
| davecheney | jam: consider that LGTM from me | 10:48 |
| jam | davecheney: thanks | 10:48 |
| dimitern_ | fwereade__: the only overlapping is in the agent.go where we need Life, SetMongoPassword for both units/machines | 10:48 |
| rogpeppe | fwereade__: it is a trade off, of course. | 10:48 |
| davecheney | we should be asking Gustavo to add all these features for us | 10:48 |
| davecheney | we've tried to do it ourselves, and it blew | 10:48 |
| rogpeppe | davecheney: could you raise an issue against mgo? | 10:49 |
| rogpeppe | davecheney: hiya, BTW | 10:49 |
| davecheney | rogpeppe: sure, i'll set myself on fire for an encore | 10:49 |
| fwereade__ | dimitern_, yeah, that was just a thought, leave it in the back of your mind for now :) | 10:49 |
| jam | rogpeppe: well, he added delay in mgo, which we had done in juju-core, which then broke the test that asserted it delayed the way we were doing it. :) | 10:49 |
| * davecheney waves at rogpeppe | 10:49 | |
| davecheney | had a good break ? | 10:49 |
| dimitern_ | fwereade__: sure | 10:50 |
| jam | though now it isn't configurable, and delays on all error types, etc. | 10:50 |
| rogpeppe | davecheney: i'm not sure you'll beat me to it | 10:50 |
| rogpeppe | davecheney: yeah, it was lovely | 10:50 |
| davecheney | rogpeppe: the immolation or the vacation ? | 10:50 |
| rogpeppe | davecheney: the latter. we will see about the former. | 10:50 |
| davecheney | rogpeppe: i'm on my third pint | 10:51 |
| davecheney | so i may leave it til tomorrow morning | 10:51 |
| davecheney | i think i will be able to make a lucid argument then | 10:51 |
| fwereade__ | rogpeppe, I'm afraid I need to switch subject now, but you might want to keep an eye on the upcoming conversation | 10:51 |
| fwereade__ | Makyo, ping | 10:51 |
| mgz | davecheney: when you have a moment (maybe my evening, when you're up tomorrow?) it would be good to find out what you need from me over release things | 10:54 |
| dimitern_ | need second review on these two related CLs: https://codereview.appspot.com/10044043/ https://codereview.appspot.com/10026044/ | 10:57 |
| davecheney | mgz: i can't G+ atm | 11:00 |
| davecheney | but is now a good time ? | 11:00 |
| mgz | davecheney: are you setup with the canonical mumble server? otherwise irc is fine | 11:01 |
| mgz | now is fine by me | 11:01 |
| davecheney | mgz: I'm at the pub | 11:03 |
| davecheney | so it's irc or bust | 11:03 |
| davecheney | here is how I do a 'release' | 11:04 |
| davecheney | 1. push the release now button on the recipe https://code.launchpad.net/~dave-cheney/+recipe/juju-core | 11:04 |
| davecheney | 2. wait for that to run | 11:04 |
| davecheney | 3. when it's done, for each deb that it produces | 11:04 |
| davecheney | run scripts/release-public-tools/release-public-tools.sh $DEB_URL | 11:05 |
| davecheney | so that is currently 6 debs | 11:05 |
| davecheney | which downloads the deb, extracts the tools,and pushes them back up to s3 | 11:05 |
| davecheney | mgz: do you still have the magic credentials ? | 11:05 |
| davecheney | then I apt-get update/apt-get upgrade to install that versoin of the client | 11:06 |
| davecheney | then I do a bootstrap + wordpress + mysql + releations + expose test on s3 | 11:06 |
| davecheney | sorry ,ec2 | 11:06 |
| davecheney | if that all works the then release is 'good' | 11:06 |
| mgz | ace, wasn't sure what smoketest bits you did | 11:07 |
| davecheney | and I submit a branch to bunmp the version | 11:07 |
| davecheney | mgz: i just do the wordpress+mysql test | 11:07 |
| mgz | so, there are a few other things, I just want to document this and get some feedback from you+others, but I'm stil not certain what we're targetting for releases at the moment... just ppa? or in saucy/raring backports too | 11:08 |
| davecheney | put it in the juju/devel ppa | 11:08 |
| davecheney | jamespage and davey want a release at some point | 11:08 |
| davecheney | but we need to give them the full monty tarball | 11:09 |
| davecheney | what mramm wants is jst to keep us in the habbit of making a release every week | 11:09 |
| mgz | that's easy enough to do, with a few tweaks to the process | 11:09 |
| mgz | the other thing is propogating the release to places other than ec2 | 11:10 |
| davecheney | mgz: that is something that I dropped the ball on for 1.11.0 | 11:10 |
| mgz | we now have semi-official buckets for hp/canonistack, which I don't have credentials on | 11:10 |
| davecheney | i think i might have said 'hey, can someone, um you konw, run sync-tools, or something' | 11:10 |
| davecheney | mgz: well, i know this is a contentios point | 11:12 |
| davecheney | but wallyworld and I are going to raise bundling hte tools inside the juju client deb again | 11:12 |
| davecheney | so that will be lots of run | 11:12 |
| davecheney | fun | 11:12 |
| mgz | :) | 11:12 |
| fwereade__ | Makyo, for when you're around: I've reviewed https://codereview.appspot.com/9975045/ -- give it a quick look, then we should talk and figure out the best way forward. rogpeppe, your input would also be appreciated here. | 11:16 |
| davecheney | mgz: the final part of the release is writing the release notes | 11:17 |
| davecheney | which i copy pasta from the week before, change the verstion | 11:17 |
| davecheney | then go through the cards in leankit | 11:17 |
| mgz | yeah, tis the it I like least :) | 11:18 |
| dimitern_ | wallyworld: ping | 11:19 |
| wallyworld | hi | 11:19 |
| dimitern_ | wallyworld: you're officially the OCR today :) have a look at these two please: https://codereview.appspot.com/10044043/ https://codereview.appspot.com/10026044/ | 11:20 |
| wallyworld | but it's waaaay past my EOD :-( | 11:20 |
| wallyworld | i'll look | 11:21 |
| wallyworld | also trying to watch the Australian version of the SUperbowl | 11:21 |
| dimitern_ | wallyworld: thanks! I know, but I couldn't find anybody to review them | 11:21 |
| davecheney | wallyworld: have there been any punch ons yet ? | 11:22 |
| davecheney | mgz: https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily | 11:22 |
| wallyworld | yes! just before half time. Gallen is a dirty dog | 11:22 |
| davecheney | wallyworld: good to see they are keeping with tradtion then | 11:23 |
| wallyworld | yeah, except for the Qld losing bit :-( | 11:23 |
| davecheney | mgz: thumpers' new log package might need to be added as a nested repo to the build | 11:23 |
| davecheney | actually, i'll just do that now | 11:23 |
| davecheney | it can't hurt | 11:23 |
| davecheney | wallyworld: i'm not seeing why that is a bad thing for me | 11:24 |
| wallyworld | davecheney: i can't answer that in a polite way | 11:24 |
| davecheney | i don't even follow the rugby and i'm beaming from ear to ear | 11:24 |
| wallyworld | your mean rugby league? rugby is diferent | 11:24 |
| davecheney | pfft, you all use the same size ball | 11:25 |
| davecheney | what is the difference ? | 11:25 |
| davecheney | it's just a mob of blokes with tape around their heads to stop their ears falling off | 11:25 |
| wallyworld | one is played with 15 men (rugby union, also called rugby), the other (rugby league) with 13 | 11:25 |
| davecheney | wallyworld: a significant and crucial difference | 11:26 |
| wallyworld | similar concepts but forwards are totally different in their style and attributes | 11:26 |
| wallyworld | totally different games really | 11:26 |
| davecheney | clearly | 11:26 |
| wallyworld | you being sarcastic? they are a lot different | 11:27 |
| wallyworld | really! | 11:27 |
| davecheney | i don't know how I could have made such a foolish mistake | 11:27 |
| dimitern_ | :) | 11:27 |
| jam | wallyworld, davecheney: I know dave is 3-pints in, I wouldn't be surprised if wallyworld is 2+, so realize IRC humor might get a bit lost :) | 11:28 |
| wallyworld | i haven't had a drink yet - too busy watching the football | 11:28 |
| jam | wallyworld: I would imagine rugby union is closer to rugby league than say American Football | 11:28 |
| wallyworld | oh yes | 11:29 |
| wallyworld | far less stoppages for a start | 11:29 |
| wallyworld | and only one team takes the field | 11:29 |
| wallyworld | not a different team for attack, defence etc | 11:29 |
| jam | wallyworld: so one team goes on the field, runs it up and scores | 11:29 |
| jam | then the other team goes on | 11:29 |
| jam | and does the same? | 11:29 |
| jam | :) | 11:29 |
| wallyworld | ha ha | 11:29 |
| jam | seems a bit unsporting :) | 11:30 |
| dimitern_ | jam: can you send me the g+ standup link so I can add it to my calendar please? | 11:30 |
| mgz | it's in the calendar already, | 11:30 |
| mgz | under the blue standup event | 11:31 |
| dimitern_ | mgz: I'm not using the team calender due to TZ issues | 11:31 |
| jam | dimitern_: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.162l082d3h3c5uidfclmtcds1g | 11:31 |
| dimitern_ | jam: thanks | 11:32 |
| jam | wallyworld: did g+ crash? | 11:36 |
| wallyworld | not for me | 11:36 |
| jam | anyone? | 11:36 |
| jam | wallyworld: I can't hear you if you are speaking | 11:36 |
| jam | but I don't hear anyone | 11:36 |
| mgz | jam: you dropped | 11:37 |
| wallyworld | we are all fine | 11:37 |
| rogpeppe | fwereade__: i'm looking at https://codereview.appspot.com/9975045. are you saying that we need to implement "local" charms before that branch can be landed? | 11:49 |
| rogpeppe | fwereade__: FWIW i agree we need to do it - i'm just not entirely sure of the timeline | 11:50 |
| fwereade__ | rogpeppe, not necessarily -- I'm saying that including local-repo-specific stuff on the server side is definitely wrong | 11:51 |
| rogpeppe | fwereade__: i'm not sure what stuff you're referring to there | 11:51 |
| fwereade__ | rogpeppe, I hope to have a quick chat with you and Makyo when he's available so we can figure out the least amount of work that makes progress for the gui and isn't actively wrong | 11:51 |
| fwereade__ | rogpeppe, bumpRevision | 11:51 |
| fwereade__ | rogpeppe, that has no place in the API, or in code used internally by the API | 11:52 |
| rogpeppe | fwereade__: bumpRevision is false on the server side. | 11:52 |
| rogpeppe | fwereade__: and isn't in the API, is it? | 11:52 |
| rogpeppe | fwereade__: ah, "code used internally by the API" | 11:53 |
| rogpeppe | fwereade__: does that really matter? | 11:53 |
| fwereade__ | rogpeppe, I think it does, yes... statecmd will be going behind the API, right? | 11:55 |
| fwereade__ | rogpeppe1, ^^ | 11:55 |
| fwereade__ | rogpeppe1, and it's implemented in terms that imply and use functionality that does not, and cannot, exist on the API server | 11:56 |
| rogpeppe1 | fwereade__: yeah. this particular statecmd function is so simple i don't really see the point of having it | 11:56 |
| rogpeppe1 | fwereade__: but the API server still needs to use conn.PutCharm currently | 11:57 |
| rogpeppe1 | fwereade__: which has a bumpRevision flag for the time being | 11:57 |
| fwereade__ | rogpeppe1, I must have miscommunicated, tbh, I had thought I'd explained that the necessary API was exactly and precisely a forward to state.Service.SetCharm | 11:57 |
| rogpeppe1 | fwereade__: how does the new charm get into the state? | 11:57 |
| fwereade__ | rogpeppe1, IMO we need a distinct API call for that | 11:58 |
| rogpeppe1 | fwereade__: i'm not convinced we do actually | 11:58 |
| rogpeppe1 | fwereade__: i think we want a PutCharm entry point that actually uploads bytes of a local charm | 11:59 |
| rogpeppe1 | fwereade__: and gives back a URL | 11:59 |
| fwereade__ | rogpeppe1, ok, we *will* need one to support local charms, but we can short-circuit it for cs: charms | 11:59 |
| rogpeppe1 | fwereade__: that's my thought | 11:59 |
| fwereade__ | rogpeppe1, would you agree that there's definitely no excuse for sending a deploy request, or a setcharm request, with an unrevisioned charm URL? | 12:00 |
| rogpeppe1 | fwereade__: i think a charm URL works ok as a charm handle | 12:00 |
| rogpeppe1 | fwereade__: i'm not sure i would | 12:00 |
| fwereade__ | rogpeppe1, expand please? | 12:00 |
| fwereade__ | rogpeppe1, isn't fguring out the charm to use a client-side responsibility? | 12:00 |
| rogpeppe1 | fwereade__: i think it's perhaps reasonable for an API client to call Deploy("cs:wordpress") | 12:01 |
| rogpeppe1 | fwereade__: without actually looking in the charm store itself and working out the desired revision | 12:01 |
| fwereade__ | rogpeppe1, isn't the GUI user presenting charms to usefrom the charm store anyway? | 12:01 |
| fwereade__ | rogpeppe1, what's the benefit of deploying a charm that doesn't match the one the user asked for? | 12:02 |
| rogpeppe1 | fwereade__: the GUI will not be the only API client | 12:02 |
| fwereade__ | rogpeppe1, the user's always deploying a *specific* charm from the GUI, right? | 12:02 |
| rogpeppe1 | fwereade__: perhaps. but a command-line user isn't. | 12:03 |
| rogpeppe1 | fwereade__: we're essentially making it *necessary* for an API client to talk to the charm store as well as the API. | 12:03 |
| rogpeppe1 | fwereade__: i don't really see why we need to do that | 12:03 |
| fwereade__ | rogpeppe1, that sounds like a really good thing to me | 12:03 |
| fwereade__ | rogpeppe1, know what you're asking for | 12:03 |
| rogpeppe1 | fwereade__: i'm not sure i see why you have a problem with allowing a short-form charm URL | 12:04 |
| fwereade__ | rogpeppe1, ISTM that smearing the responsibility for figuring out what charm to deploy across layers is self-evidently bad | 12:05 |
| fwereade__ | rogpeppe1, it's like all the other crazy magic that got put in the deploy API | 12:06 |
| fwereade__ | rogpeppe1, lol here's a different number of units to what you asked for | 12:06 |
| fwereade__ | rogpeppe1, service name? meh we'll infer one for you | 12:06 |
| fwereade__ | rogpeppe1, I want an API that does what you tell it, not one that makes guesses based on inferred context | 12:07 |
| fwereade__ | rogpeppe1, that's a job for the outermost layer | 12:07 |
| fwereade__ | whoops, lunch | 12:07 |
| fwereade__ | bbiab | 12:07 |
| rogpeppe1 | fwereade__: i agree that the heuristics in the Deploy call are misplaced. | 12:09 |
| rogpeppe1 | fwereade__: but that's mainly because all that information is already trivially available to the client | 12:10 |
| rogpeppe1 | fwereade__: that is not the case for the revision number. | 12:11 |
| TheMue | hmm, just missed fwereade__ | 12:17 |
| TheMue | ok, then later | 12:17 |
| * rogpeppe1 goes for lunch too | 12:18 | |
| * dimitern_ lunch | 12:22 | |
| === dimitern_ is now known as dimitern | ||
| fwereade__ | TheMue, heyhey | 12:27 |
| === wedgwood_away is now known as wedgwood | ||
| === tasdomas` is now known as tasdomas | ||
| TheMue | fwereade__: ah, there he is. but i already found the answer to my question (has been about a statement in state/machine.go. | 12:53 |
| fwereade__ | TheMue, cool | 12:53 |
| fwereade__ | TheMue, which did you pick up?> | 12:54 |
| TheMue | fwereade__: i've started with the state.Cleanup() and the same maintainer will get the mgo/txn in a second cl | 12:55 |
| fwereade__ | TheMue, two workers, please | 12:56 |
| fwereade__ | TheMue, small components, single responsibilities | 12:56 |
| fwereade__ | TheMue, and check with roger that we're calling it JobManageState -- I think we agreed that yesterday, but it's worth a check | 12:57 |
| fwereade__ | TheMue, (fwiw I would be fine with you implementing each worker in a separate CL, and then integrating them both in a single followup) | 12:57 |
| TheMue | fwereade__: the maintainer worker is small and the cleanup method call in there is very small. the txn one would be an extra method | 12:57 |
| fwereade__ | TheMue, they're using rather different models, aren't they? | 12:58 |
| TheMue | fwereade__: JobManageState? not JobMaintainState anymore? | 12:58 |
| fwereade__ | TheMue, there's currently no such thing as JobMaintainState | 12:58 |
| TheMue | fwereade__: please define models in this context? | 12:59 |
| fwereade__ | TheMue, one needs to respond to a watcher, one needs to run periodically | 12:59 |
| TheMue | fwereade__: no, thy are new, take a look in the issues you wrote. you called them JobMaintainState | 12:59 |
| fwereade__ | TheMue, I know I did, that's because we didn't know what it'd be called yet | 13:00 |
| TheMue | fwereade__: the current approach is to have a maintainer worker running jobs periodically. right now only the cleanup. | 13:01 |
| TheMue | fwereade__: manager imho is the wrong name for maintenance. | 13:02 |
| fwereade__ | TheMue, the idea is just to groups them under the rough umbrella of "things that need a state connection to function" | 13:03 |
| fwereade__ | TheMue, but you do understand that jobs are names for *groups* of tasks, right? | 13:03 |
| fwereade__ | TheMue, a job with two responsbilties runs two tasks | 13:03 |
| TheMue | fwereade__: so which task do you want to be done in a, yes, how should it be called, statemanager? | 13:05 |
| fwereade__ | TheMue, I don't think there's any call for a statemanager type, is there? | 13:06 |
| TheMue | fwereade__: my idea of a maintainer is to periodically run different tasks, like the state cleanup | 13:06 |
| fwereade__ | TheMue, we need a worker that watches for cleanup docs, and runs them | 13:06 |
| fwereade__ | TheMue, as stated in the bug | 13:07 |
| TheMue | fwereade__: and how would you name that worker? | 13:07 |
| fwereade__ | TheMue, Cleaner? | 13:07 |
| fwereade__ | TheMue, Janitor if you're feeling cute ;p | 13:07 |
| TheMue | fwereade__: ;) | 13:08 |
| TheMue | fwereade__: but here q quote why i thought the watcher will be interesting later "probably we should have a CleanupWatcher as well, changes on which cause Cleanups to run" | 13:08 |
| TheMue | fwereade__: that's why i thought we need a different approach | 13:09 |
| TheMue | fwereade__: but ok, will change it | 13:09 |
| fwereade__ | TheMue, I'm a bit confused there | 13:09 |
| fwereade__ | TheMue, it's a task that runs code n response to state changes | 13:10 |
| fwereade__ | TheMue, we need a good reason *not* to implement it in trms of a watcher | 13:10 |
| TheMue | fwereade__: what would be the problem doing it periodically? | 13:11 |
| TheMue | fwereade__: which btw doesn't mean that i will not change it | 13:12 |
| TheMue | fwereade__: i'm only interested | 13:12 |
| TheMue | fwereade__: because multiple approaches are possible | 13:12 |
| fwereade__ | TheMue, the problem is just that it's picking a different strategy from the conventional one | 13:12 |
| fwereade__ | TheMue, there may be a reason to do so, in which case, great | 13:12 |
| fwereade__ | TheMue, but in general we should be using the backend's capabilities to run code when we need to rather than just guessing, I think | 13:13 |
| TheMue | fwereade__: it only remembered me of typical database maintenance jobs | 13:13 |
| TheMue | fwereade__: that's why i went that way | 13:13 |
| fwereade__ | TheMue, this argument does not apply to the txn resumer, because we can't simply watch that | 13:13 |
| fwereade__ | TheMue, cleanup jobs are infrequent -- once per relation removal, basically | 13:14 |
| fwereade__ | TheMue, but we have the mechanism in place that stores them watchably | 13:14 |
| TheMue | fwereade__: how often do you think the watcher would raise an event? | 13:14 |
| fwereade__ | TheMue, very infrequently | 13:15 |
| TheMue | fwereade__: a number, maybe as ratio to units? | 13:15 |
| fwereade__ | TheMue, totally depends on usage patterns | 13:15 |
| fwereade__ | TheMue, in most deployments, 0% of the time | 13:15 |
| TheMue | fwereade__: that's indeed very low :D | 13:16 |
| fwereade__ | TheMue, but with a watcher-based approach, it'll be run when it needs to be, even if that usage pattern changes | 13:16 |
| fwereade__ | TheMue, it's very possible we'll end up with more cleanup types | 13:16 |
| TheMue | fwereade__: the watcher approach may have the problem later of having only one responsible machine (and so a spof). periodical cleanups could run on multiple machines, needing only a good idea of distribute the runs over the day | 13:18 |
| fwereade__ | TheMue, why would we run it on only one machine? | 13:18 |
| TheMue | fwereade__: in case of of multiple machines watching for the cleanup demand, how would those machines react? do all start the cleanup in parallel? | 13:19 |
| TheMue | fwereade__: because it's a global operation. | 13:20 |
| fwereade__ | TheMue, AFAICT State.Cleanup will work fine when called concurrently | 13:21 |
| TheMue | fwereade__: ok, due to transactional behavior, but imho still no nice coordination | 13:22 |
| TheMue | fwereade__: but we'll start with the machine 0, don't we? | 13:22 |
| fwereade__ | TheMue, right now, that is the only machine that will be running this job, yes | 13:23 |
| TheMue | fwereade__: then i'll change it into a cleaner :) | 13:23 |
| TheMue | fwereade__: heh, or duster? :D | 13:23 |
| fwereade__ | TheMue, remember we'll need a watcher for those docs too | 13:24 |
| fwereade__ | TheMue, might be best to implement that first | 13:24 |
| fwereade__ | TheMue, and I don't demand great sophistication here | 13:24 |
| TheMue | fwereade__: sure, otherwise the worker will wait for what? hmm, some nice day in the future. | 13:24 |
| fwereade__ | TheMue, something that just sends an event whenever the set of cleanup docs changes should suffice | 13:24 |
| TheMue | fwereade__: will do it as first small cl | 13:25 |
| fwereade__ | TheMue, great, thanks | 13:25 |
| TheMue | fwereade__: can start with the cleaner itself then in parallel as followup cl | 13:25 |
| fwereade__ | TheMue, I couldn't parse that | 13:26 |
| fwereade__ | TheMue, cleaner worker depends on cleanup watcher | 13:26 |
| fwereade__ | TheMue, resumer worker is independent and can be done in parallel | 13:26 |
| fwereade__ | TheMue, hmm | 13:27 |
| fwereade__ | TheMue, yeah, make it a worker for consistency's sake, it'll just periodically pass through a call to st.runner.ResumeAll() | 13:28 |
| fwereade__ | mmm, cath has made pud, I'll go take the second half of the lunch break ;p | 13:30 |
| fwereade__ | see you all in kanban | 13:30 |
| === BradCrittenden is now known as bac | ||
| TheMue | fwereade__: yes, we match. what i wanted to say is that the watcher will be the first cl, the cleaner worker then follows (i only start it while the first cl is in review). the resumer will then another one | 13:38 |
| mattyw | is there someone here I can talk to about plugins in juju-core? | 13:43 |
| mattyw | specifically it looks like any flag I have for my plugin which has - in it causes the arg list to get trimmed | 13:43 |
| mattyw | http://pastebin.ubuntu.com/5735795/ | 13:44 |
| === dspiteri is now known as Guest86044 | ||
| === thumper is now known as Guest13680 | ||
| fwereade__ | mattyw, looks like a bug to me, would you let thumper know about it please? | 13:55 |
| mattyw | fwereade__, will do thanks: here's a much better paste http://pastebin.ubuntu.com/5735830/ | 13:55 |
| fwereade__ | mattyw, it's always a pleasure to see a clear fail case :) | 13:57 |
| mattyw | fwereade__, it's also comforting to know I'm not trying to do something insane :) | 13:58 |
| dimitern | rogpeppe1: ping | 14:21 |
| rogpeppe1 | dimitern: pong | 14:21 |
| dimitern | rogpeppe1: can I ask you to have a look at these? https://codereview.appspot.com/10044043/ https://codereview.appspot.com/10026044/ | 14:22 |
| rogpeppe1 | dimitern: will do. i've got another meeting in 8 minutes though, so probably won't get through them before then. | 14:22 |
| dimitern | rogpeppe1: sure, no rush | 14:22 |
| dimitern | mgz: ping | 14:27 |
| mgz | hey dimitern | 14:28 |
| dimitern | mgz: hey, did you manage to look at the API stuff? | 14:28 |
| mgz | haave looked through the two cls you have up currently | 14:28 |
| dimitern | mgz: they are the last in line though | 14:28 |
| mgz | yeah, not super relevent | 14:29 |
| dimitern | mgz: the actual facade has landed already and the client-side stuff as well | 14:29 |
| mgz | I did see I think the first before week away too | 14:29 |
| dimitern | mgz: no, that was rejected | 14:29 |
| mgz | ..confusing :) | 14:29 |
| dimitern | mgz: if you go back in the pipeline of prereqs you'll find the first one and follow through | 14:30 |
| dimitern | mgz: https://codereview.appspot.com/9896046/ that's the first | 14:30 |
| mgz | okay | 14:30 |
| mgz | thanks | 14:31 |
| dimitern | mgz: np, ping me if you need something clarified as you go | 14:31 |
| dimitern | mgz: these are the next ones in line (in order): https://codereview.appspot.com/9686047/ (client-side machiner), https://codereview.appspot.com/10003044/ (splitting test suites server-side), then the ones still up for review | 14:33 |
| * TheMue reboots, somehow my box lags and i don't know why | 14:46 | |
| === flaviami_ is now known as flaviamissi | ||
| === fss is now known as f55 | ||
| hazmat | gary_poster, i think metrics or stats.yaml.. vitals is a term for those in the know.. | 15:00 |
| gary_poster | hazmat, I'll note., thanks | 15:02 |
| Makyo | fwereade__, rogpeppe1 I'm available for the rest of the day, minus a 15min call in ~50mins. | 15:12 |
| fwereade__ | Makyo, heyhey | 15:17 |
| fwereade__ | Makyo, would you start a hangout please? I just need a couple of mins | 15:17 |
| fwereade__ | rogpeppe1, join us if you can but don't feel obliged | 15:17 |
| rogpeppe1 | fwereade__: will do | 15:18 |
| Makyo | fwereade__, alright, once I figure out the new hangout interface. Bleh. | 15:19 |
| rogpeppe1 | Makyo: go to the top of the page, and share a hangout | 15:22 |
| fwereade__ | Makyo, back | 15:22 |
| rogpeppe1 | Makyo: it's unintuitive, i know | 15:22 |
| fwereade__ | Makyo, type to search, tick name to add, press the silly video-camera-like icon that appeared magically below the name list, IIRC | 15:22 |
| Makyo | Ah, was making it too complicated. https://plus.google.com/hangouts/_/04c2a36e9afa1c5ace4880ec2c4681cc01fb9f79?authuser=1&hl=en | 15:23 |
| Makyo | https://codereview.appspot.com/9975045/ | 15:29 |
| Makyo | fwereade__, rogpeppe1 ^^^ | 15:29 |
| dimitern | last one for today: https://codereview.appspot.com/9937045/ | 15:45 |
| dimitern | rogpeppe1, fwereade__ ^^ when you can | 15:45 |
| dimitern | rogpeppe1: last nag for today for these two: https://codereview.appspot.com/10044043/ https://codereview.appspot.com/10026044/ | 15:59 |
| rogpeppe1 | dimitern: sorry, looking | 15:59 |
| dimitern | rogpeppe1: cheers | 16:00 |
| dimitern | freenode's being ddosed wow :) interesting | 16:01 |
| === benji is now known as Guest54884 | ||
| === Guest54884 is now known as benji | ||
| === tasdomas is now known as tasdomas_afk | ||
| dimitern | i'm off, have a good evening all | 16:28 |
| === arosales_ is now known as arosales | ||
| rogpeppe1 | dimitern: you've got a review | 16:30 |
| rogpeppe1 | dimitern: g'night | 16:31 |
| dimitern | rogpeppe1: tyvm | 16:31 |
| === jamespag` is now known as jamespage | ||
| * rogpeppe1 is done for the day. g'night all. | 17:22 | |
| hazmat | rogpeppe1, cheers | 17:46 |
| === gary_poster is now known as gary_poster|away | ||
| === gary_poster|away is now known as gary_poster | ||
| === marrusl is now known as marrusl_really | ||
| hazmat | anyone run juju-core against maas? | 18:27 |
| andreas__ | hi guys, did juju bootstrap lose the -v (verbose) option?> | 19:28 |
| === andreas__ is now known as ahasenack | ||
| === f55_ is now known as fss | ||
| === Guest13680 is now known as thumper | ||
| === thumper is now known as Guest2101 | ||
| === Guest2101 is now known as _thumper_ | ||
| === Guest85983 is now known as thumper | ||
| thumper | fwereade__: ping? | 21:35 |
| wallyworld__ | thumper: g'day | 21:48 |
| thumper | wallyworld__: hey | 21:55 |
| wallyworld__ | quick chat? | 21:56 |
| thumper | wallyworld__: I have a call with mramm in 4 min | 21:56 |
| wallyworld__ | ok, after that, ping me. i'll go have breakfast | 21:56 |
| thumper | kk | 21:56 |
| wallyworld__ | i was hoping to talk to fwereade__ too | 21:56 |
| fwereade__ | thumper, wallyworld__, heyhey | 22:07 |
| thumper | fwereade__: just chatting with mramm | 22:07 |
| fwereade__ | wallyworld__, guess I'm here for you then :) | 22:07 |
| fwereade__ | wallyworld__, actually, I have to make laura's lunch for tomorrow | 22:10 |
| fwereade__ | wallyworld__, but there is an 80% chance I'll be back in 10 mins | 22:10 |
| wallyworld__ | fwereade__: ok, ping if you are free after your chore | 22:11 |
| fwereade__ | wallyworld__, ping | 22:25 |
| wallyworld__ | hey | 22:25 |
| wallyworld__ | quick hangout? | 22:25 |
| fwereade__ | wallyworld__, sgtm | 22:25 |
| fwereade__ | wallyworld__, start it? | 22:26 |
| wallyworld__ | https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6 | 22:26 |
| thumper | wallyworld__: want me to join in? | 22:30 |
| wallyworld__ | yes | 22:30 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!