[01:54] <perrito666> wallyworld: hey, yes I think i got it
[01:55] <wallyworld> great :-) hope i made sense with my ramblings
[01:55] <wallyworld> you need sleep, so we'll catch up tomorrow
[01:55] <perrito666> you did, I think I stayed as close as possible :p
[01:58] <wallyworld> no problems, we can see how it turns out and adjust if the idea is too insane
[02:01] <perrito666> wallyworld: ow please sleep is a poor replacement for coffee
[02:03] <perrito666> wallyworld: ok i have updated now its backwards compatible and consistent
[02:04] <perrito666> if you go for a setstatus it will use the agent
[02:04] <perrito666> and if you call explicitly you get the right ones
[02:04] <wallyworld> perrito666: awesome ty, will look after my cuurent meeting and provide feedback, you need to sleep :-)
[02:04] <perrito666> now yes I need to sleep
[02:04] <perrito666> cheers man
[03:19] <axw_> wallyworld: updated the diagram, do you want to take a look and see if it's what you had in mind?
[03:20] <wallyworld> sure, ty, looking
[03:22] <wallyworld> axw: looks good ty
[03:22] <axw> ta
[04:38] <wallyworld> axw: if you have a moment, could you please look at a small review for a 1.22 bug http://reviews.vapour.ws/r/748/
[04:39] <axw> wallyworld: sure
[04:44] <axw> wallyworld: reviewed
[04:44] <axw> need to make lunch... bbs
[04:45] <wallyworld> tyvm
[05:08] <wallyworld> axw: so by the looks, Datastore in code is what's in the spec as Storage Provider, and Datastore.Kind is analogous to Storage Provider type?
[05:09] <wallyworld> also, i did find in the spec --disks for add-machine
[05:29] <axw> wallyworld: no, Datastore is an early name I came up with for storage instance
[05:29] <axw> I may just rename it to StorageInstance ...
[05:29] <wallyworld> ah right ok
[05:30] <axw> Kind is block|filesystem|object
[05:30] <axw> :q
[05:30] <axw> oops
[05:30] <wallyworld> and a StorageInstance will reference the provider type / pool from which it came
[05:31] <axw> wallyworld: correct
[06:08] <wallyworld> thanks axw, i need to buy some glasses
[06:08] <axw> wallyworld: nps. to be fair, someone may want the string; I don't think the backend should be in the business of rendering though
[06:09] <axw> its job is to tell the user about changes in the model
[06:09] <axw> wallyworld: there's a followup to change the API right?
[06:09] <wallyworld> yes, but the megawatcher already does some rendering i think
[06:10] <wallyworld> does there need to be an api change?
[06:10] <axw> wallyworld: I'm sure you'll need to change something in apiserver/params at least...
[06:11] <wallyworld> let me look
[06:11] <axw> wallyworld: sorry, I assumed you were splitting up the branch
[06:11] <axw> I believe you need to update AllWatcher, which uses MegaWatcher
[06:11] <wallyworld> i've not ever done much with megawatcher so am not sure of all the artefacts
[06:12] <axw> wallyworld: re rendering, perhaps you should double check with fwereade what he wants it to do
[06:12] <wallyworld> axw: looked in params, it seems the api layer just json marshals the struct directly
[06:13] <axw> huh, ok
[06:13] <wallyworld> but i can see a params_test that will fail
[06:13] <axw> so it does
[06:13] <wallyworld> i'll wait for the failure and fix the params_test
[06:14] <wallyworld> i think i had it at theback of my mind that i just needed to change the machineinfo directly but couldn't remember why
[06:37] <axw> wallyworld: any opinion on the name of the thing I was talking about before? StorageInstance? StorageUnit? (it's currently "Storage" in state, which has too many meanings...)
[06:37] <wallyworld> um
[06:38] <axw> the thing being an instantiation of a store declared in a charm
[06:39] <wallyworld> maybe StorageInstance just to make it not Storage and we can search/replace later if a better name comes up
[06:39] <axw> sounds good
[06:56] <dimitern> o/
[07:02] <axw> morning dimitern
[07:03] <axw> wallyworld: just sent you an email with a UML diagram - please take a quick look when you have a moment to see if it's what you had in mind
[07:03] <dimitern> hey axw
[07:03] <wallyworld> axw: sure, ty
[07:04]  * dimitern is amazed
[07:04] <dimitern> no blockers todat yay!
[07:05] <axw> :)
[07:05] <axw> and here I am with nothing to land
[07:05] <dimitern> just in time for the 5 branches I had in mind :)
[07:05] <axw> woot
[07:05] <dimitern> aww ;)
[07:06] <dimitern> hmm.. after all the live testing my ec2 bill grew a bit - $0.32 now hah
[07:07] <wallyworld> axw: thanks yeah, that's something we can start with and evolve over time
[07:07] <axw> wallyworld: cool
[07:34] <anastasiamac> dimitern: thnx for review on list charms
[07:35] <anastasiamac> dimitern: m moving them into a separate client but have taken ur feedback on board :0
[07:35] <dimitern> anastasiamac, cheers :)
[07:36] <dimitern> anastasiamac, I'd like to have a look when you propose it please
[07:36] <anastasiamac> dimitern: thnx! m hoping later on tonite - got my hadns full of kids atm
[07:37] <anastasiamac> dimitern: hands that is
[07:37] <dimitern> anastasiamac, np
[08:06] <anastasiamac> dimitern: committed updates with new facade
[08:06] <anastasiamac> dimitern: i have copied CharmInfo only in this PR
[08:07] <anastasiamac> dimitern: I'd like to land it b4 copying the rest of charm stuff from old client
[08:07] <anastasiamac> dimitern: like AddLocalCHarm, AddCahrm and ResolveCharm
[08:07] <anastasiamac> dimitern: this way old client's dealings with charm will be "deprecated" :)
[08:08] <dimitern> anastasiamac, good plan, but we shouldn't remove them from the old facade
[08:09] <anastasiamac> dimitern: agreed.. Hence "copy" :)
[08:10] <dimitern> anastasiamac, right :)
[08:11] <anastasiamac> dimitern: thnx for double-checking! it's amazing to work with ppl that r diligent and care!
[08:15] <dimitern> anastasiamac, oh c'mon :) thanks
[08:20] <anastasiamac> dimitern: :D
[08:57] <Muntaner> good morning, I'm quite new to Juju and having problems
[08:57] <Muntaner> am I in the right place to ask for some help?
[09:04] <dimitern> Muntaner, hey, welcome!
[09:04] <dimitern> Muntaner, You can ask questions either here or in #juju
[09:05] <Muntaner> I asked in Juju, if it's ok I can copypaste my question here
[09:05] <dimitern> Muntaner, This channel is more about Juju development, while #juju is more for users, charmers, etc.
[09:05] <dimitern> Muntaner, no need - I'll have a look
[09:06] <Muntaner> ok, thanks :)
[09:17] <TheMue> morning
[09:35] <dimitern> morning TheMue
[09:35] <dimitern> TheMue, feeling better today?
[09:35] <TheMue> dimitern: heya
[09:36] <TheMue> dimitern: in IT I would "project not yet done, but it's getting better with each iteration" ;)
[09:36] <TheMue> would say
[09:37] <dimitern> TheMue, glad to hear it :)
[09:39] <TheMue> dimitern: yeah, me too. today I'm working from a convenient place in the living room, having my cat beside me. better than alone in the home office.
[09:41] <dimitern> TheMue, :) nice
[09:41] <TheMue> dimitern: yep
[10:01]  * TheMue looks around
[10:05] <dimitern> TheMue, voidspace, sorry guys - omw
[10:05] <voidspace> dimitern: o/
[12:22] <perrito666> good morning
[12:43] <anastasiamac> perrito666: o/
[13:15] <wwitzel3> perrito666: feeling better today?
[13:18] <perrito666> wwitzel3: yes tx a lot, was a state of mind more than of body and I really didn't want to share my frustration in negative ways
[13:19] <perrito666> my grand mother used to say that you should not do hangouts when angry
[13:19] <wwitzel3> perrito666: yea, I can understand that
[13:19] <wwitzel3> perrito666: haha
[13:20] <perrito666> since she died before google rose above the search engine I might be missquoting her :p
[14:31] <dimitern> TheMue, voidspace, ping
[14:32] <TheMue> dimitern: pong
[14:32] <dimitern> TheMue, hey - we have approval for the sprint (check your mail) - please submit the form
[14:32] <TheMue> dimitern: just seen Sarahs mail :)
[14:33] <dimitern> TheMue, :)
[14:58] <wwitzel3> ericsnow, perrito666 ping
[14:58] <perrito666> wwitzel3: pong?
[14:59] <wwitzel3> oh i guess I'm a minute early
[14:59] <perrito666> says my clock I still have 1min
[14:59] <ericsnow> perrito666, wwitzel3: I'm going to the upstart-systemd-migration call
[14:59] <TheMue> dimitern: my flights are bad for the times we're planning, cannot come early enough or have to leavy too early. I would would prefer coming on Monday during morning and leave on Saturday then. what do you say?
[15:02] <dimitern> TheMue, if there are no suitable flights - yeah, but I'd still wait to hear from the travel agent to be sure
[15:03] <dimitern> TheMue, she might have better options to offer
[15:04] <TheMue> dimitern: sure, but my usual portal is very good, checking lots of flight. I have also to do one hop
[15:04] <ericsnow> perrito666, wwitzel3: I did wrap up the tests for instance and conn_availzones
[15:05] <dimitern> TheMue, which airport you usually take - hamburg or bremen?
[15:06] <TheMue> dimitern: bremen, hamburg is badly to reach
[15:07] <TheMue> dimitern: but maybe this time it's worth it, will take a look. from here to hamburg it's about 2:30h (with train and sub).
[15:12] <voidspace> dimitern: cool, thanks
[15:52] <bodie_> is there an api for hook tools or is the only way to use them to invoke them from the shell?
[15:52] <bodie_> e.g. relation-set
[15:53] <bodie_> I think it would be nice to be able to use them programmatically from within a hook or action
[15:55] <ericsnow> we only run one jujud per instance, right?
[15:55] <bodie_> I believe so
[15:55] <ericsnow> my understanding is that we *used* to run one jujud per agent (or something like that)
[15:56] <sinzui> ericsnow, 1 jujud machine per instance
[15:56] <bodie_> you could use a local http service (is that insane?)
[15:56] <bodie_> then that could be wrapped for different languages
[15:57] <bodie_> or, rpc server as we do for api/apiserver
[15:57] <bodie_> but that might be overcomplicated
[15:57] <ericsnow> sinzui: do you mean 1 jujud *per* machine per instance?
[15:58] <sinzui> ericsnow, 1 jujud as a machine agent per instance. 0-* jujud unit agents per machine.
[15:59] <ericsnow> sinzui: so there may be more than one jujud running?
[15:59] <sinzui> ericsnow, add-machine will give you a machine with just 1 jujud running on it. deploy will usually give 2 jujuds running as machine and unit.
[15:59] <ericsnow> sinzui: ah
[15:59] <sinzui> ericsnow, and with subordinates, many more juju unit agens get added
[15:59] <ericsnow> sinzui: but there is only one upstart job for jujud (or one for each jujud that runs)?
[16:00] <ericsnow> sinzui: so one jujud per machine agent
[16:00] <sinzui> ericsnow, there is an upstate job for the machine, and for each service running
[16:00] <bodie_> jujud_ip=os.Getenv("JUJUD_IP")
[16:01] <bodie_> perhaps
[16:01] <ericsnow> sinzui: ah, okay, that's just what I needed to know
[16:01] <ericsnow> sinzui: thanks :)
[16:02] <sinzui> ericsnow, this is what I see on my apache3 machine with has a lot on it
[16:02] <sinzui> http://pastebin.ubuntu.com/9762266/
[16:04]  * perrito666 notices he forgot to add something to his patch
[16:04] <sinzui> Hi voidspace ericsnow perrito666 TheMue dimitern wwitzel3: can anyone help with these two issues that block 1.21 an 1.22? https://launchpad.net/juju-core/+milestone/1.21-rc1
[16:05] <TheMue> sinzui: taking a look
[16:07] <ericsnow> sinzui: perfect
[16:13] <ericsnow> dist-upgrades don't happen on running instances, right? (other than as part of the initial start-instance stuff)
[16:14] <ericsnow> since everything in juju is series driven :)
[16:15] <sinzui> ericsnow, correct. Deploy a new service to get the new os, not upgrade an existing one
[16:28] <dimitern> sinzui, i have a clue re bug 1403738
[16:28] <mup> Bug #1403738: upgrade tests fail on multiple substrates with revision 24c1b80d <ci> <regression> <upgrade-juju> <juju-core:Fix Released by menno.smits> <https://launchpad.net/bugs/1403738>
[16:30] <dimitern> sinzui, I think the fix for that bug wasn't backported to 1.21 and hence current blocker - bug 1411502
[16:30] <mup> Bug #1411502: ERROR upgrade in progress - Juju functionality is limited <openstack> <uosci> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1411502>
[16:30] <sinzui> ah, thank you dimitern
[16:32] <dimitern> sinzui, yep - I've just checked the source of 1.21 - no backport in sight
[16:38] <alexisb> dimitern, can you delegate the two tasks you highlighted in mail for the 1.21 bugs
[16:38] <alexisb> to some us based folks so we can get them landed today if possible
[16:40] <dimitern> alexisb, two tasks? I haven't actually had time to look at the other bug, just the upgrade one
[16:41] <alexisb> well the backport tasks
[16:41] <dimitern> alexisb, sure
[16:43] <dimitern> ericsnow, wwitzel3, can any of you find some time to backport https://github.com/juju/juju/pull/1343 to 1.21, so we can unblock people affected by bug 1411502 please?
[16:43] <mup> Bug #1411502: ERROR upgrade in progress - Juju functionality is limited <openstack> <uosci> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1411502>
[16:44] <ericsnow> dimitern: if wwitzel3 can't, I'll do it
[16:44] <voidspace> dimitern: ping
[16:44] <dimitern> ericsnow, thanks! I'll assign it to you - please sync-up with wwitzel3 and reassign if needed
[16:45] <voidspace> dimitern: did you think that goamz already supported the DescribeNetworkInterfaces call?
[16:45] <voidspace> dimitern: it doesn't look to me like it does
[16:45] <voidspace> dimitern: I can implement ec2 filtering without it
[16:45] <dimitern> voidspace, it does, but the filtering by instance-id is not implemented by the ec2test server
[16:47] <voidspace> dimitern: ah, I can't see it in the goamz source code
[16:47] <voidspace> dimitern: just filtering by network name might be *easier* anyway
[16:51] <dimitern> voidspace, well, I started doing it for ec2 (the Environ.NetworkInterfaces() implementation) and realized I can't test it without the filtering
[16:51] <dimitern> voidspace, and resorted to using Instances instead and the NetworkInterfaces from there
[16:51] <dimitern> voidspace, unfortunately there were too many distractions today to finish it :/
[16:51] <voidspace> dimitern: ok
[16:52] <voidspace> dimitern: I have a basically done implementation *without* using DescribeNetworkInterfaces
[16:52] <voidspace> just filtering on the provided network IDs
[16:52] <voidspace> but I have an oddly failing test - possibly due to the test server
[16:52] <voidspace> just investigating
[16:54] <dimitern> voidspace, cheers - i need to step out now though
[16:54] <dimitern> happy weekends y'all ;)
[16:55] <voidspace> dimitern: o/ have a good weekend
[17:45] <perrito666> ericsnow: have a moment for a completely non work related question?
[17:45] <ericsnow> perrito666: sure
[17:45] <perrito666> ericsnow: priv
[18:27] <voidspace> EOW
[18:27] <voidspace> happy weekend everyone
[18:52] <ericsnow> sinzui: does bug #1411502 actually apply to 1.22?
[18:52] <mup> Bug #1411502: ERROR upgrade in progress - Juju functionality is limited <openstack> <uosci> <juju-core:Triaged> <juju-core 1.21:In Progress by ericsnowcurrently> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1411502>
[18:52] <ericsnow> sinzui: from what dimitern indicated, this should be fixed there already (with 1403738)
[18:53] <sinzui> ericsnow, I think the change is in 1.22 I believe 1.22 was master at the time
[18:53] <sinzui> ericsnow, If you agree, I will remove the task
[18:54] <ericsnow> sinzui: k
[18:54] <ericsnow> sinzui: I have a patch up for review that backports the 1.22 fix
[18:55] <sinzui> ericsnow, okay. I will remove the 1.22 since the change comes from 1.22
[19:02] <alexisb> ericsnow, perrito666 do we have an idea on this bug:
[19:02] <alexisb> https://bugs.launchpad.net/juju-core/+bug/1410876
[19:02] <alexisb> ??
[19:02] <mup> Bug #1410876: Error executing lxc-clone: lxc_container: utils.c: mkdir_p 220 Not a directory - Could not destroy  snapshot %s - failed to allocate a pty; Insufficent privileges to control  juju-trusty-lxc-template <lxc> <oil> <trusty> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core
[19:02] <mup> 1.22:Triaged> <https://launchpad.net/bugs/1410876>
[19:02] <ericsnow> alexisb: I haven't looked at that one
[19:02] <ericsnow> wwitzel3: ^^^ ?
[19:03] <perrito666> alexisb: I haven't either
[19:04] <alexisb> sinzui, lp 1410876 is a blocker for 1.21 right?
[19:05] <perrito666> alexisb: I am not sure I even know how to reproduce it
[19:05] <sinzui> alexisb, I think so since it was found in openstack testing
[19:05] <alexisb> well if we need repro steps to make progress we need to make that request in the bug
[19:07] <perrito666> sinzui: do you know how to reproduce this or should I ask for more info?
[19:08] <sinzui> perrito666, We will need more info. We obviously never saw this in our testing
[19:09] <perrito666> sinzui: ah, i assumed since you re-classified it you knew how to make this happen
[19:09] <sinzui> perrito666, No the stakeholder makes it important. it was found in oil testing
[19:17] <perrito666> aghh I hate whatever shortcut my client has that allows me to close this
[19:19] <perrito666> ericsnow: wwitzel3 did you guys knew that monday apparently is a holiday there?
[19:19] <ericsnow> perrito666: yep
[19:21] <perrito666> ericsnow: wwitzel3 then all we said was happening on monday will be happening on Tu, right? :p
[19:21] <perrito666> I am going to be sooo alone in here on monday
[19:21] <ericsnow> perrito666: yep
[19:52] <wwitzel3> back, ericsnow I haven't looked at that one
[19:52] <wwitzel3> perrito666: yeah, Mon = Tue ;)