| === alexlist` is now known as alexlist | ||
| davecheney | wallyworld: could you please tag goose for juju-1.12 | 01:11 |
|---|---|---|
| wallyworld | sure | 01:12 |
| wallyworld | rev 99 i think? | 01:12 |
| davecheney | hold up | 01:12 |
| davecheney | i need this tag, juju-1.12.0 at the same revno as juju-1.11.4 | 01:12 |
| wallyworld | ok | 01:12 |
| wallyworld | davecheney: done | 01:13 |
| * davecheney hugs wallyworld | 01:13 | |
| * wallyworld goes all gooey | 01:13 | |
| davecheney | wallyworld: what cmd did you use ? | 01:13 |
| wallyworld | bzr tag -d bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/goose/trunk -r99 juju-1.12.0 | 01:14 |
| wallyworld | rev 99 was what i did the other tag for | 01:14 |
| davecheney | ok | 01:18 |
| davecheney | i don't understand bzr tags | 01:18 |
| davecheney | but that dovetails nicely into all the other things i don't understand | 01:18 |
| thumper | wallyworld: today is a bit here and there | 01:32 |
| thumper | wallyworld: have to take the dog to the vet for a 2pm apt | 01:32 |
| thumper | did you want a quick chat now? | 01:32 |
| wallyworld | thumper: sure | 01:32 |
| wallyworld | thumper: https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6 | 01:32 |
| axw | If anyone is curious wtf the new guy is doing, I'm going to look at implementing debug-hooks. Feel free to redirect my attention though. | 01:42 |
| davecheney | axw: +1 | 01:45 |
| davecheney | axw: there is a branch for the client side part | 01:45 |
| axw | davecheney: yep thanks, I saw you made a start | 01:45 |
| davecheney | but the logic to intercede in the agent is an open problem | 01:45 |
| axw | yeah I see there's a problem with replacing the ZK ephemeral node thingy | 01:45 |
| wallyworld | thumper: found out what's up with the bot - lyc02 is down for maintenance \o/ | 02:13 |
| wallyworld | maybe we shouldn't run prod stuff on canonistack :-/ | 02:14 |
| thumper | haha | 02:31 |
| wallyworld | thumper: we don't really need to record how a machine is started because we know that from the ContainerType attribute, hence can use that to figure out how to get an address | 03:37 |
| wallyworld | may still need to record if manually provisioned perhaps | 03:37 |
| thumper | wallyworld: no... | 03:37 |
| thumper | yes, manually provisioning hits this | 03:37 |
| wallyworld | but in manual case we would just write the ip address directly to Addresses | 03:38 |
| wallyworld | so i'm not sure we need to record anything extra | 03:39 |
| thumper | wallyworld: about my desktop, it seems that there is no eth0 in my /etc/network/interfaces file | 03:40 |
| wallyworld | you need to add it | 03:41 |
| wallyworld | it won't be there | 03:41 |
| thumper | well I have an eth0 | 03:41 |
| thumper | problem is that it has a static ip | 03:41 |
| wallyworld | yes, but it doesn't have an entry in that file by default | 03:41 |
| thumper | and if futz with that, other things fail | 03:41 |
| wallyworld | you can add an entry in there with a static ip afaik | 03:42 |
| thumper | wallyworld: yeah, but that doesn't help the bridge does it? | 03:42 |
| wallyworld | or mark it as manual or something like that to tell it not to use dhcp | 03:42 |
| thumper | this is all getting very confusing | 03:42 |
| wallyworld | yes | 03:42 |
| wallyworld | those web links from yesterday had examples for nics with static ips i'm sure | 03:43 |
| wallyworld | thumper: i think i read somewhere that the host nic needs to be set to promiscuous mode using a pre-up statement on br0 bridge interface | 03:49 |
| wallyworld | not sure though | 03:50 |
| thumper | that sounds right | 03:50 |
| thumper | otherwise it is likely to filter only those for its mac address | 03:50 |
| thumper | wallyworld: I'm going to write up a proposal for something hacky that might work | 03:55 |
| wallyworld | thumper: i also read that some kernels have filtering enabled which will break it and you need to use sysctrl to fix that | 03:55 |
| thumper | bigjools: can I have access to your maas instance? | 03:55 |
| wallyworld | all very complicated | 03:55 |
| bigjools | it will cost you | 03:55 |
| thumper | wallyworld: we need a network specialist to work with IMO | 03:55 |
| wallyworld | yes indeed | 03:55 |
| thumper | to make sure we don't fuck up | 03:55 |
| thumper | bigjools: what's the cost? | 03:56 |
| wallyworld | yep. surely we have one of those | 03:56 |
| bigjools | a night in your arms | 03:56 |
| thumper | haha | 03:56 |
| thumper | but you have boy couties | 03:56 |
| bigjools | don't worry, it's not transmittable in saliva | 03:56 |
| * thumper is speechless | 03:57 | |
| * bigjools wins \\o/ | 03:57 | |
| wallyworld | so that doesn't mean he won't get it via other fluids | 03:57 |
| * thumper blocks his ears and hands over eyes | 03:57 | |
| thumper | lalalalala | 03:57 |
| bigjools | ok give me an hour or so as I need to finish a review and then I need to refresh the package and OS | 03:57 |
| bigjools | on my maas box itself | 03:57 |
| thumper | bigjools: not today, but may need for testing next week if that is ok | 03:57 |
| bigjools | sure | 03:58 |
| bigjools | what OS do you need? | 03:58 |
| bigjools | saucy? | 03:58 |
| thumper | precise | 03:58 |
| wallyworld | thumper: what are you going to try? | 03:58 |
| bigjools | you're SoL | 03:58 |
| thumper | SoL? | 03:58 |
| thumper | wallyworld: some hackery | 03:58 |
| bigjools | it's currently on raring and I ain't gonna downgrade :) | 03:58 |
| bigjools | Shit Outta Luck | 03:58 |
| thumper | how am I supposed to put charms on it then? | 03:59 |
| * bigjools rolls eyes | 03:59 | |
| thumper | bigjools: isn't this easy with maas? | 03:59 |
| bigjools | the maas server is irrelevant to what gets provisioned on nodes | 03:59 |
| thumper | ok, in which case I don't care | 03:59 |
| bigjools | yes it's trivial | 03:59 |
| bigjools | good :) | 03:59 |
| thumper | bigjools: all i need is access to something that I can bootstrap with maas and juju | 03:59 |
| bigjools | actually you probably need the saucy daily since juju broke maas recently | 04:00 |
| thumper | wallyworld: so, boostrap a maas precise image | 04:00 |
| thumper | wallyworld: shell in | 04:00 |
| thumper | wallyworld: tweak the interfaces file | 04:00 |
| bigjools | it was trying to upload zero sized state files | 04:00 |
| thumper | wallyworld: make sure I have a hacked up juju | 04:00 |
| bigjools | thumper: I will arrange that for you, no prob | 04:00 |
| thumper | wallyworld: so I can override the default network bridge with an environment variable | 04:00 |
| thumper | wallyworld: then try to start some containers | 04:01 |
| thumper | and see if they are pingable / addressable | 04:01 |
| wallyworld | bigjools: it needed to create an empty file to get a url it could use later | 04:01 |
| wallyworld | bigjools: why did that break? the test doubles worked ok | 04:01 |
| bigjools | yeah.... test doubles ... might have a been a bit different to reality :/ | 04:02 |
| bigjools | it's fixed in latest trunk for maas anyway | 04:02 |
| wallyworld | sure, but why does creating a 0 length file break? | 04:02 |
| bigjools | maas was rejecting it | 04:02 |
| wallyworld | well that sucks | 04:02 |
| bigjools | indeedy | 04:02 |
| bigjools | but no longer | 04:02 |
| wallyworld | thumper: so you are just setting up a "standard" lxc bridged environment | 04:03 |
| wallyworld | ? | 04:06 |
| thumper | wallyworld: yeah, set eth0 to manual | 04:06 |
| thumper | and bridge to dhcp over eth0 | 04:06 |
| wallyworld | i tried that and lxc didn't boot | 04:06 |
| thumper | worked for me | 04:07 |
| thumper | on ec2 | 04:07 |
| thumper | I want to try on metal | 04:07 |
| wallyworld | hmmm. ok | 04:07 |
| thumper | and maas | 04:07 |
| thumper | may be hacky | 04:07 |
| thumper | but if it leads to installing openstack nicely on containers in maas | 04:08 |
| thumper | we may be ok with it... | 04:08 |
| thumper | maybe | 04:08 |
| wallyworld | i just has to work for iom | 04:08 |
| wallyworld | it | 04:08 |
| thumper | huh | 04:08 |
| thumper | and not be entirely string, spit and duck tape | 04:09 |
| wallyworld | but it would be nice to have a network guy say "do it like this" | 04:09 |
| * thumper nods | 04:09 | |
| wallyworld | surely there's someone we can ask | 04:09 |
| wallyworld | maybe from is? | 04:09 |
| thumper | that's going to be part of my email | 04:09 |
| thumper | will fire up to mramm and william | 04:09 |
| wallyworld | so i still don't think we need to record the origin of a machine in state | 04:10 |
| wallyworld | since we can write the address to martin's new data model | 04:10 |
| thumper | I'd be happy enough if we could use hallyn's suggested hackery for IOM and MAAS with something more concrete/understandable later | 04:10 |
| wallyworld | hallyn? | 04:11 |
| thumper | wallyworld: hallyn is serge | 04:11 |
| wallyworld | ah right | 04:11 |
| thumper | wallyworld: sometimes we don't know the ip address until after the machine agent has started | 04:11 |
| thumper | wallyworld: so the machine agent needs to know how to find out | 04:11 |
| wallyworld | well, the the manual provisioning case, it just gets written directly into env | 04:12 |
| wallyworld | for lxc, can't we add something to cloud init | 04:12 |
| wallyworld | to record the correct address in state so the agent can read it | 04:13 |
| thumper | I still think that sticking something in state is the right approach | 04:13 |
| thumper | jsut gut feel right now | 04:13 |
| * thumper untangles gut feelings into an email | 04:14 | |
| wallyworld | we are sticking something in state - the addresses :-) | 04:14 |
| wallyworld | no need for any indirection | 04:14 |
| * thumper punches wallyworld for not listening | 04:16 | |
| wallyworld | huh? | 04:16 |
| * thumper punches wallyworld because he is frustrated | 04:16 | |
| thumper | perhaps more honest | 04:16 |
| thumper | stand still wallyworld | 04:16 |
| wallyworld | ouch | 04:17 |
| wallyworld | i listened, didn't necessarily agree :-) | 04:17 |
| thumper | I think we need it for later, perhaps not entirely needed now | 04:17 |
| thumper | as we can force it in | 04:17 |
| thumper | wallyworld: if you are looking for something to do, we need to be able to parameterise machines with the containers they support | 04:17 |
| wallyworld | so let's just do what we are sure we need for now and iterate later if needed | 04:17 |
| thumper | and be able to set and update that | 04:18 |
| thumper | and have the deployments honour it | 04:18 |
| wallyworld | ok. i think i have hit a roadblock with my removal of control-bucket :-( | 04:18 |
| thumper | wallyworld: so we can then only start an lxc provisioner if we support lxc | 04:18 |
| thumper | bootstrap? | 04:18 |
| wallyworld | bootstrap works fine. but the next time you try a juju command, it doesn't know what the control bucket is cause it's stored in state and it can't access state cause it needs a control bucket to do so | 04:19 |
| wallyworld | which make me wonder how we are going to support someone going to a different pc and using juju for the env they have set up elsewhere | 04:21 |
| wallyworld | thumper: so we would parameterise machines based on the provider which created them i guess? ie all ec2 machines support x,y.z; all mass machines support a,b,c ? | 04:22 |
| thumper | no, I don't think so | 04:22 |
| thumper | could be kernel limited | 04:22 |
| thumper | so some kernals support kvm, some don't | 04:22 |
| wallyworld | so how do we know then what a machine supports? | 04:22 |
| thumper | well... | 04:23 |
| thumper | some job in the machine agent will need to interrogate the machine | 04:23 |
| thumper | if lxc is not installed, no lxc containers | 04:23 |
| thumper | if kernal foo, no kvm | 04:23 |
| thumper | etc | 04:23 |
| thumper | and then sets state | 04:23 |
| wallyworld | doesn't sound very scalable to have to track all the kernal versions supporting kvm etc | 04:24 |
| wallyworld | i think also a machine could it self write into state what it supports | 04:25 |
| wallyworld | so a job would be called by cloud init and the machine would contact the state server and update its details | 04:25 |
| wallyworld | ? | 04:26 |
| thumper | your guess is as good as mine right now | 04:33 |
| thumper | and at the end of friday I have run out of fucks to give | 04:33 |
| wallyworld | np. i'll try it and see if it works | 04:35 |
| wallyworld | lots of dead ends this week :-( | 04:35 |
| thumper | sometimes you have shitty weeks | 04:35 |
| thumper | that's life | 04:35 |
| wallyworld | and the landing bot is still fucked | 04:35 |
| thumper | accept it and move on | 04:35 |
| * thumper finishes early | 04:36 | |
| jtv1 | wallyworld: a question about the "signedImageDataOnly" parameter to imagemetadata... Is that about requiring images to be signed, or does it mean the simplestreams index etc. must be signed? | 04:57 |
| wallyworld | it's about requiring that the metadata be signed | 04:58 |
| wallyworld | not the images themselves | 04:58 |
| jtv1 | Ah OK, that explains a few things. Thanks. | 05:05 |
| jtv1 | (This was actually documented as I recall, but it's one of those cases where you first need to know enough to rule out the potential for ambiguity.) | 05:06 |
| jtv1 | wallyworld: do we have anything like a test double for simplestreams? | 05:21 |
| === jtv1 is now known as jtv | ||
| jtv | wallyworld: also, there seem to be "releases" and "daily" versions of the base URL, but also "releases" and "daily" streams inside the indexes found at those base URLs. Is that correct? | 05:32 |
| wallyworld_ | jtv: yes, there are releases and daily. we use releases unless specified otherwise | 06:45 |
| jtv | wallyworld_: what I mean is, there's separate base URLs for releases and daily, but that doesn't seem to be the same thing as setting the Streams selector to "releases" or "daily," is it? | 07:23 |
| wallyworld_ | i've only ever used the base url with "releases" at the end. and within that, chosen the releases metadata as opposed to the daily metadata | 07:24 |
| wallyworld_ | i've not used a daily base url. didn't know one existed | 07:25 |
| jtv | Maybe it's outdated... there's a bug open for the "daily" one not having an Azure file. | 07:38 |
| wallyworld_ | jtv: we've always just used the release images for openstack and ec2 | 07:47 |
| wallyworld_ | jtv: as far as a test double - we have tests that set up sample data and a matching http service, but that hasn't been packaged into a re-usable instance | 07:48 |
| jtv | So I may have to export it. | 07:49 |
| wallyworld_ | export it? | 07:50 |
| jtv | Capitalize some names. | 07:51 |
| wallyworld_ | sure, but what is "it"? | 07:51 |
| jtv | testRoundTripper. | 07:51 |
| wallyworld_ | just make a new one | 07:52 |
| wallyworld_ | var testRoundTripper = &jujutest.ProxyRoundTripper{} | 07:52 |
| wallyworld_ | i guess it could be packaged | 07:52 |
| jtv | And the code that puts it in place. | 07:52 |
| wallyworld_ | i think it's all of 4 lines | 07:53 |
| wallyworld_ | the image data will be different for each test case i would imagine | 07:54 |
| rogpeppe | mornin' all | 07:54 |
| wallyworld_ | g'day | 07:54 |
| rogpeppe | wallyworld_: hiya | 07:54 |
| wallyworld_ | rogpeppe: i went to land that simplestreams branch today cause i really need it. but canonistack went down for maintenance and now our landing bot is gone | 07:55 |
| wallyworld_ | and i don't know how to restart it | 07:55 |
| rogpeppe | wallyworld_: oh dear | 07:55 |
| wallyworld_ | yeah :-( | 07:55 |
| rogpeppe | wallyworld_: mgz probably does | 07:56 |
| wallyworld_ | the IS guys said why the fuck are you running prod stuff on canonistack? | 07:56 |
| wallyworld_ | i didn't have a good answer :-) | 07:56 |
| === mthaddon` is now known as mthaddon | ||
| wallyworld_ | rogpeppe: i'm unsure about the correct way to do stuff with the api changes. in the jujud Machineagent Run() method, it is kosher to get a state object using openState() and then go machine = st.getMachine(234) and then invoke methods on the machine object? | 08:04 |
| rogpeppe | wallyworld_: the correct answer depends on what you're trying to do | 08:05 |
| wallyworld_ | rogpeppe: a code snippet http://pastebin.ubuntu.com/5914001/ | 08:05 |
| wallyworld_ | i want to write some data to the machineDoc | 08:05 |
| wallyworld_ | on which the agent is running | 08:06 |
| rogpeppe | wallyworld_: i *think* that will probably be best done in one of the machine agent workers | 08:08 |
| rogpeppe | wallyworld_: probably deployer, or maybe machiner | 08:08 |
| wallyworld_ | rogpeppe: the code to set up the supported containers is in the run method | 08:09 |
| wallyworld_ | so i have the info at hand at that point | 08:09 |
| * rogpeppe thinks | 08:11 | |
| wallyworld_ | i'll see if i can move the code | 08:11 |
| wallyworld_ | cause some more lxc sruff is done in StateWorker() | 08:11 |
| wallyworld_ | so it might make sense to put it all together | 08:12 |
| wallyworld_ | i'm just reading all this code for the first time | 08:12 |
| wallyworld_ | i think i can stick it in StateWorker() | 08:12 |
| rogpeppe | wallyworld_: i think that's reasonable for the moment. we're going to be moving away from doing anything in the state worker though, as we start to use the API for everything | 08:16 |
| rogpeppe | wallyworld_: so we'll need a SetSupportedContainers API call in the relevant worker (or perhaps on MachineAgent.State | 08:17 |
| rogpeppe | ) | 08:17 |
| wallyworld_ | rogpeppe: except i just saw that StateWorker is only run on bootstrap node. and it just calls openState() anyway. so i might leave the code in the Run method | 08:17 |
| rogpeppe | wallyworld_: no, every client runs StateWorker currently | 08:18 |
| rogpeppe | wallyworld_: otherwise nothing would work, because we haven't moved all the agents to using the API yet | 08:18 |
| wallyworld_ | ok. i'm still not across all the new design | 08:19 |
| rogpeppe | wallyworld_: can we really not tell what containers a machine supports until it comes up? | 08:19 |
| rogpeppe | wallyworld_: i'm thinking that this breaks the nice usual mode of operation: if i interpret this right, you won't be able to deploy to a given container on a machine until that machine has actually come up | 08:20 |
| rogpeppe | wallyworld_: or am i misunderstanding what SetSupportedContainers is to be used for here? | 08:21 |
| fwereade | rogpeppe, if you have any clever way of determining the answer to that question we would be most interested to hear it | 08:22 |
| fwereade | rogpeppe, wallyworld_: but I don't think we can prevent adding containers until the host's up | 08:23 |
| rogpeppe | fwereade: i'm thinking that we should probably *allow* deployment to a container before a machine's up, yes | 08:23 |
| rogpeppe | fwereade: but the deployment should fail if the container's not supported | 08:23 |
| fwereade | rogpeppe, wallyworld_: isn't that just a provisioning failure? | 08:23 |
| rogpeppe | fwereade: +1 | 08:24 |
| rogpeppe | fwereade: but perhaps that's what wallyworld_'s envisaging anyway, i'm not sure | 08:24 |
| wallyworld_ | rogpeppe: there's a method called EnsureLXCContainers | 08:24 |
| wallyworld_ | that is called at the start of the Run method | 08:24 |
| rogpeppe | wallyworld_: method on what? | 08:25 |
| wallyworld_ | so we know then if lxc is supported | 08:25 |
| wallyworld_ | MachineAgent | 08:25 |
| rogpeppe | wallyworld_: you mean EnsureWeHaveLXC ? | 08:25 |
| wallyworld_ | yeah | 08:25 |
| wallyworld_ | sorry, bad memory | 08:25 |
| wallyworld_ | rogpeppe: and yes, set supported containers is supposed to be used so that we only attempt to create a container on a host that can support it | 08:26 |
| wallyworld_ | eg not all hosts can run kvm | 08:26 |
| wallyworld_ | or lxc (eg windows) | 08:26 |
| fwereade | wallyworld_, I'm a bit worried about the inconsistency there | 08:26 |
| === tasdomas_afk is now known as tasdomas | ||
| rogpeppe | wallyworld_: i think that breaks juju's basic workflow, unfortunately | 08:26 |
| fwereade | wallyworld_, what's the benefit of having two different ways of failing the same operation? | 08:27 |
| wallyworld_ | fwereade: rogpeppe: i have to go have dinner and play soccer, i'll talk to you later this evening when i'm back | 08:27 |
| rogpeppe | wallyworld_: np, have fun | 08:27 |
| fwereade | wallyworld_, sure, have fun | 08:27 |
| wallyworld_ | fwereade: also, bot is down | 08:27 |
| fwereade | grar, ty | 08:27 |
| wallyworld_ | canonistack got nuked today for upgrade | 08:27 |
| wallyworld_ | and bot disappeared | 08:27 |
| wallyworld_ | and i have nfi how to restart it | 08:27 |
| wallyworld_ | we need to not run bot on canonistack | 08:28 |
| wallyworld_ | anywats, ttyl | 08:28 |
| fwereade | mgz, do I recall that jam handed bot-bouncing duties over to you when he left? | 08:28 |
| * fwereade getting breakfast quickly | 08:48 | |
| axw | fwereade: when you have a moment, can you please read my comment here? https://bugs.launchpad.net/juju-core/+bug/1027876 | 09:11 |
| _mup_ | Bug #1027876: cmdline: Support debug-hooks <cmdline> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1027876> | 09:11 |
| fwereade | axw, that looks pretty plausible actually | 09:27 |
| fwereade | axw, are you interested in investigating that a little bit? | 09:27 |
| axw | yeah, I'd be happy to have a crack at it | 09:27 |
| axw | it'll probably take me a little while longer than others, still learning things obviously :) | 09:28 |
| axw | thanks for taking a look | 09:28 |
| fwereade | axw, the only wrinkle I can see is clearly communicating what's going on when two users try to debug hooks on the same unit (and making sure it works if two people are doing different units on the same machine) | 09:28 |
| fwereade | axw, cool, that would be very much appreciated | 09:29 |
| axw | yeah I dd think of that as I was writing it up... only simple solution I could think of was the time out the ssh command and print something useful | 09:29 |
| fwereade | axw, I can live with a bit of inelegance there, though, it is very much a charmer-focused tool | 09:30 |
| axw | actually the flock can do that | 09:30 |
| axw | ok | 09:30 |
| axw | cool | 09:30 |
| TheMue | so, second part of syncing is in: https://codereview.appspot.com/11910043 | 09:53 |
| TheMue | anyone interested in a review? | 09:53 |
| jtv | TheMue: I think I can take it. | 09:54 |
| TheMue | jtv: thx | 09:54 |
| axw | I'm off. Have a nice weekend everyone. | 09:57 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: mgz | Bugs: 5 Critical, 76 High - https://bugs.launchpad.net/juju-core/ | ||
| fwereade | dimitern, ping | 10:18 |
| dimitern | fwereade: pong | 10:18 |
| fwereade | dimitern, any thoughts on CanDeploy? AFAICT we don't really need it | 10:18 |
| fwereade | dimitern, because we'll get unath errors out of Life for any unit we're not meant to know about | 10:19 |
| dimitern | fwereade: well it started as AssignedMachineId | 10:19 |
| dimitern | fwereade: but you're probably right | 10:19 |
| fwereade | dimitern, the plan was that we could drop all of that bit, I think -- "responsible" is now handled implicitly behind the api | 10:19 |
| fwereade | dimitern, that's what getAuthFunc does for us | 10:19 |
| dimitern | fwereade: any chance for mistakes? like recalling a unit we think we cannot access? | 10:20 |
| fwereade | dimitern, so long as we're barfing on error that aren't unath, and we're only returning unauth errors in appropriate situations I think we're good | 10:20 |
| fwereade | dimitern, and CanDeploy just duplicates the work of getAuthFunc from the other direction AFAICT | 10:21 |
| === teknico1 is now known as teknico | ||
| fwereade | dimitern, you should be able to drop the CanDeploy bit and all tests should still pass, I think | 10:21 |
| fwereade | dimitern, if that doesn't work we should look closer | 10:21 |
| dimitern | fwereade: i'll try that out | 10:22 |
| jtv | Hi folks — I was wondering why the Virtual RoundTripper in environs/jujutest/metadata.go lists files as an array of filename/content tuples? Wouldn't a map from filenames to contents be easier to understand? | 10:34 |
| fwereade | jtv, sounds like it'd eliminate possible confusion too, but I don;t specifically know about that code | 10:42 |
| jtv | Thanks. Something to keep in mind... I found it hard to get my mind around the test setup, but I figured it was a better investment than mindlessly copying what everybody else does. :-) | 10:51 |
| fwereade | jtv, +1 | 10:51 |
| dimitern | fwereade, rogpeppe: I'd like to leave the UnitTag, consts, regexpes and other common stuff between api and state that's now duplicated to be cleaned up in a follow up, if you don't mind, not to complicate this CL | 11:13 |
| rogpeppe | dimitern: sgtm | 11:13 |
| fwereade | dimitern, ah, has duplication already started elsewhere? | 11:13 |
| dimitern | fwereade: yeah, in a few places, not many | 11:14 |
| fwereade | dimitern, ok, yeah, best clear it up all in one go after this then | 11:14 |
| dimitern | fwereade: yeah | 11:14 |
| fwereade | dimitern, does CanDeploy evaporate cleanly? | 11:14 |
| dimitern | fwereade, rogpeppe: I also removed CanDeploy altogether and reverted the NotAssignedError changes, running tests now, then will test it live, if it works it should be done | 11:15 |
| fwereade | dimitern, lovely, tyvm | 11:15 |
| rogpeppe | dimitern: brill, thanks | 11:16 |
| dimitern | rogpeppe, fwereade: yep, tests pass without it, testing live now | 11:17 |
| dimitern | wallyworld_: standup? | 11:33 |
| * rogpeppe goes for lunch | 11:56 | |
| frankban | dimitern: re William question in my review, i don't see a StringsWorker in the worker package (there is only a notifyWorker), so I guess it's not yet implemented, correct? | 12:00 |
| mgz | dimitern: so, the go-bot creds, can you send them to me? | 12:01 |
| dimitern | frankban: yes it's not - so far only one worker could use it - the machiner, if others appear we can factor out the common code into a stringsworker | 12:03 |
| dimitern | mgz: just a sec | 12:03 |
| frankban | dimitern: well, the minunits worker will be the second one | 12:04 |
| dimitern | frankban: great | 12:05 |
| dimitern | frankban: we can follow the notifyworker pattern then | 12:06 |
| mgz | so, for now, people should manually land on trunk I think | 12:07 |
| mgz | if anyone is not sure how to do that or wants help, poke me | 12:07 |
| * dimitern boo we want the bot!! | 12:08 | |
| dimitern | :) | 12:08 |
| mgz | once you bot, you don't want to go back... | 12:08 |
| dimitern | sure! | 12:09 |
| dimitern | fwereade, rogpeppe: https://codereview.appspot.com/11800045/ updated | 12:13 |
| TheMue | so, first step done, a pre-check | 12:24 |
| fwereade | mgz, rogpeppe, I might have lunch before I chat to you guys, will you be around a bit later? am I blocking you at all? | 12:45 |
| rogpeppe | fwereade: i'll be around | 12:45 |
| rogpeppe | dimitern: "No, if I do the test still succeeds, but it takes 10s (LongWait) more." | 12:47 |
| rogpeppe | dimitern: i'd like to understand why that's true | 12:48 |
| rogpeppe | dimitern: i can't see why it would be | 12:48 |
| rogpeppe | dimitern: because isRemoved doesn't call Sync or StartSync | 12:48 |
| mgz | fwereade: I shall lunch as well | 12:49 |
| rogpeppe | dimitern: and anyway Sync doesn't affect anything except watchers, and waitFor doesn't use a watcher | 12:50 |
| rogpeppe | mgz: enjoy | 12:50 |
| fwereade | reviewing dimitern's branch but off shortly, cath's whereabouts are unknown | 12:51 |
| dimitern | rogpeppe: I don't know but I observed so | 12:51 |
| rogpeppe | dimitern: that's really weird | 12:51 |
| rogpeppe | fwereade: lost in a maze of twisty passages, all alike? | 12:52 |
| fwereade | rogpeppe, london streets have the occasional distinguishing feature, but yeah | 12:52 |
| rogpeppe | fwereade: ah, i thought you were still in a large country house in wiltshire... | 12:52 |
| dimitern | rogpeppe: pull the branch and try it out for yourself, if you want | 12:54 |
| rogpeppe | dimitern: am just doing that | 12:55 |
| rogpeppe | dimitern: i can't reproduce the behaviour | 12:59 |
| rogpeppe | dimitern: did you change BackingState to State in waitFor too? | 12:59 |
| rogpeppe | dimitern: because that *would* have the results you saw | 13:00 |
| dimitern | rogpeppe: I changed them everywhere | 13:06 |
| dimitern | rogpeppe: when I saw the delays of 10s | 13:07 |
| rogpeppe | dimitern: ah, that was not my suggestion | 13:07 |
| rogpeppe | dimitern: the only place it makes a difference for a call to Sync | 13:07 |
| rogpeppe | s/for/is for/ | 13:07 |
| rogpeppe | dimitern: i think it's worth using BackingState only when necessary rather than changing it as if it's magic powder :-) | 13:07 |
| rogpeppe | s/changing/using/ | 13:08 |
| dimitern | :) | 13:08 |
| dimitern | rogpeppe: ok will try | 13:08 |
| rogpeppe | dimitern: tbh, i'm not sure we should have provided BackingState at all - JujuConnSuite.Sync/StartSync would probably be a better idea | 13:08 |
| dimitern | rogpeppe: it's useful sometimes | 13:10 |
| dimitern | rogpeppe: with watchers through the api | 13:11 |
| rogpeppe | dimitern: agreed, but what would you ever need to do on it other than call Sync or StartSync ? | 13:11 |
| rogpeppe | dimitern: (genuine question) | 13:12 |
| dimitern | rogpeppe: i can't think of other uses, but jam probably has some | 13:13 |
| rogpeppe | dimitern: i can't think of any other case where it would make a difference | 13:14 |
| rogpeppe | dimitern: after all, they're both talking to the same underlying mongo | 13:14 |
| dimitern | rogpeppe: but different connections | 13:16 |
| rogpeppe | dimitern: sure, but why would that make a difference? | 13:16 |
| rogpeppe | dimitern: we don't do any caching | 13:16 |
| dimitern | rogpeppe: probably nothing, just thinking out loud | 13:17 |
| ahasenack | guys, got this in today's update of the whole juju-core stack from trunk: | 13:26 |
| ahasenack | # launchpad.net/gwacl | 13:26 |
| ahasenack | ../go/src/launchpad.net/gwacl/management.go:317: function ends without a return statement | 13:26 |
| ahasenack | I'm on raring | 13:26 |
| ahasenack | it doesn't even say if that's an error or a warning | 13:27 |
| rogpeppe | ahasenack: ah, that's because the builder is running go1.1 | 13:27 |
| rogpeppe | ahasenack: there are no warnings | 13:27 |
| ahasenack | go likes to change syntax every now and then, heh? | 13:27 |
| rogpeppe | ahasenack: go1.1 is more lenient about return statement positioning | 13:27 |
| ahasenack | rogpeppe: so what do I do? | 13:28 |
| rogpeppe | ahasenack: you could install go1.1 | 13:28 |
| ahasenack | no | 13:28 |
| ahasenack | that would hide the problem | 13:28 |
| rogpeppe | ahasenack: most of us use that | 13:28 |
| ahasenack | do you plan on backporting go1.1 to raring, quantal and precise? | 13:28 |
| rogpeppe | ahasenack: that is the plan, yes | 13:28 |
| rogpeppe | ahasenack: although i don't know where we are with it | 13:28 |
| ahasenack | then I'll get go1.1 when it's backported :) | 13:28 |
| ahasenack | although it sounds like saucy will be out before :) | 13:29 |
| rogpeppe | ahasenack: in which case, you should file a bug with gwacl | 13:29 |
| ahasenack | ok | 13:29 |
| rogpeppe | ahasenack: and perhaps propose the fix (which will be trivial) if you feel charitable | 13:29 |
| rogpeppe | ahasenack: i'm afraid i don't know where we are currently on policy around using go1.1 features | 13:30 |
| rogpeppe | fwereade, mramm: ^ ? | 13:30 |
| ahasenack | https://bugs.launchpad.net/gwacl/+bug/1205331 | 13:30 |
| ahasenack | k, filed | 13:30 |
| _mup_ | Bug #1205331: r203 doesn't build in raring <Go Windows Azure Client Library:New> <https://launchpad.net/bugs/1205331> | 13:30 |
| rogpeppe | ahasenack: i was away when the builder was changed to use go1.1, i'm afraid, so i missed whatever debate there was. | 13:31 |
| ahasenack | seems a big deal switching compilers | 13:31 |
| rogpeppe | ahasenack: the Go folks are very careful around backward compatibility, so it's not actually a big deal | 13:33 |
| ahasenack | rogpeppe: oh, I thought that bug prevented building | 13:33 |
| ahasenack | so it is a warning? | 13:34 |
| rogpeppe | ahasenack: no, it's a backwardly incompatible feature | 13:34 |
| ahasenack | so this one in particular is a big deal then | 13:34 |
| rogpeppe | ahasenack: it's a big deal if people use any go1.1-specific feature if we require 1.0.x compatibility | 13:35 |
| rogpeppe | ahasenack: that's not just a compiler-switch problem, it's a problem with using any new feature AFAICS | 13:35 |
| rogpeppe | ahasenack: that's why i *thought* we were going to continue running the bot on 1.0.2 until we could use 1.1 everywhere | 13:36 |
| ahasenack | sounds like the safer choice | 13:36 |
| ahasenack | doesn't the bot need rebuilding, given that canonistack outage? Maybe it could be rebuild with 1.0.2 | 13:37 |
| ahasenack | or is that a different bot | 13:37 |
| ahasenack | rebuilt | 13:37 |
| rogpeppe | ahasenack: mgz is restarting it, yes. he might want to use the other version, though i suspect it was changed for a reason i'm not aware of | 13:39 |
| ahasenack | maybe the tls stuff | 13:39 |
| ahasenack | I don't recall which version had which problem, but go 1.1 and tls and gwacl were involved | 13:40 |
| rogpeppe | ahasenack: it's possible that gwacl now requires go1.1 because they've forked net/http from tip | 13:44 |
| rogpeppe | ahasenack: nope, "The fork is based on go version 2:1.0.2-2." | 13:45 |
| fwereade | rogpeppe, I am not 100% sure that the last 1.0 uses have been excised -- mgz, is there anything preventing us from going 1.1 across the board? | 13:46 |
| rogpeppe | fwereade: is 1.1 now backported to precise etc? | 13:47 |
| fwereade | rogpeppe, I *think* that the most recent releases were all built with 1.1, by a variety of means which I do not have at immediate recall | 13:54 |
| rogpeppe | fwereade: so is it a problem that gwacl is using go1.1-specific features? | 13:55 |
| fwereade | rogpeppe, it may not be, but I'm waiting for mgz's response, because he has better command of the situation than I do | 13:55 |
| frankban | mgz: hi, any idea about this lbox error? http://pastebin.ubuntu.com/5914998/ | 14:24 |
| === tasdomas_afk is now known as tasdomas | ||
| mgz | frankban: you can't use lbox submit, you don't have perms on the branch | 14:26 |
| mgz | commit to trunk locally, run the tests, push to the go-bot branch as go-bot | 14:26 |
| mgz | so, the last command specifically is on bzr+ssh//go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk | 14:29 |
| mgz | you may want to do `bzr info` on it now, to double check if your ssh keys got added to the bot account | 14:29 |
| mgz | wuhah, I totally missed the hilight in the log | 14:30 |
| mgz | ahasenack: we're moving to go 1.1 becasue maintaining cross-version compat for the lifetime of our support on a young language like go isn't practical. | 14:32 |
| mgz | ahasenack: you can use ppa:juju/golang which contains what jamespage is going to get backported to older series, and what juju-core is getting built from | 14:33 |
| rogpeppe | mgz: so we can use go1.1 features now? | 14:33 |
| * rogpeppe drools slightly | 14:33 | |
| mgz | we really want our releases sorted first, but yeah. | 14:33 |
| fwereade | mgz, rogpeppe: if you're both around, do you want to talk about addresses? | 14:34 |
| mgz | lets | 14:34 |
| rogpeppe | fwereade: sure | 14:34 |
| frankban | mgz: thanks, I'll do | 14:34 |
| mgz | frankban: if you get stuck I can land for you. | 14:34 |
| fwereade | rogpeppe, mgz, I'm joining the standup call | 14:34 |
| ahasenack | mgz: so #1205331 should be marked as invalid? | 14:36 |
| _mup_ | Bug #1205331: r203 doesn't build in raring <Go Windows Azure Client Library:New> <https://launchpad.net/bugs/1205331> | 14:36 |
| ahasenack | or won't fix perhaps | 14:36 |
| ahasenack | until go 1.1 lands in raring | 14:36 |
| mgz | ahasenack: arguably we should fix that for now | 14:38 |
| frankban | mgz: bzr info bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk gives me a "Permission denied (publickey)". If you can land my branch, that would be great, otherwise I can wait for tarmac to be up again | 14:39 |
| mgz | I shallland shortly, which branch? | 14:40 |
| frankban | mgz: lp:~frankban/juju-core/minuniter-worker thanks! | 14:43 |
| === tasdomas_afk is now known as tasdomas | ||
| dimitern | fwereade: updated https://codereview.appspot.com/11800045/ | 15:21 |
| dimitern | rogpeppe: I haven't seen your response to ^^ yet? | 15:21 |
| fwereade | dimitern, nice timing :) | 15:21 |
| dimitern | rogpeppe: changed the tests to use s.State, except for waitFor | 15:22 |
| rogpeppe | dimitern: oh sorry, i got half way through then got distracted | 15:22 |
| rogpeppe | dimitern: thanks | 15:22 |
| fwereade | dimitern, https://codereview.appspot.com/11800045/diff/22001/worker/deployer/deployer.go#newcode176 | 15:22 |
| fwereade | dimitern, do we need an error return? | 15:22 |
| fwereade | dimitern, ah, I guess we check tag sanity | 15:23 |
| fwereade | dimitern, forget I said anything | 15:23 |
| dimitern | fwereade: not really, it's always nil | 15:23 |
| rogpeppe | dimitern: have you re-proposed with those changes? | 15:23 |
| dimitern | fwereade: kept it like this to match the interface of state | 15:23 |
| dimitern | rogpeppe: yes | 15:23 |
| fwereade | dimitern, I'd probably drop it then, but don't do it unless you honestly think it's a good idea, it might just be churn | 15:24 |
| rogpeppe | dimitern: oh yes, doh, reload doesn't change the patch no | 15:24 |
| dimitern | rogpeppe: https://codereview.appspot.com/11800045/diff2/22001:31001/worker/deployer/deployer_test.go | 15:24 |
| rogpeppe | dimitern: yeah, i'm stupid, ignore me | 15:24 |
| rogpeppe | dimitern: LGTM | 15:25 |
| dimitern | rogpeppe: great, thanks | 15:26 |
| dimitern | fwereade: unless you have objections, i'd like to land it, so I can start working on the (few) follow-ups | 15:27 |
| fwereade | rogpeppe, https://codereview.appspot.com/11800045/diff/22001/cmd/jujud/deploy_test.go#newcode95 | 15:31 |
| fwereade | dimitern, LGTM regardless | 15:31 |
| dimitern | fwereade: thanks! | 15:33 |
| rogpeppe | fwereade: it felt cleaner to have them as separate calls, especially as we might want to make them available to different clients | 15:33 |
| dimitern | mgz: so how's the landing dance performed? | 15:33 |
| dimitern | mgz: lp:~dimitern/juju-core/080-deployer-uses-api | 15:33 |
| dimitern | mgz: but i'd like to know how can I do it as well | 15:33 |
| rogpeppe | fwereade: and having them as separate calls maps nicely to the future address watchers, where we may well want to watch the individual addresses separately | 15:34 |
| === tasdomas is now known as tasdomas_afk | ||
| rogpeppe | fwereade: so we can just use a separate StringsWatcher for both Addresses and APIAddresses | 15:35 |
| mgz | dimitern: so, what I'm doing, | 15:35 |
| rogpeppe | fwereade: if it's slow making 3 request serially, then it's pretty trivial to make them concurrently as a future optimisation | 15:36 |
| rogpeppe | s/request/requests/ | 15:36 |
| mgz | switch to trunk. merge your feature branch. commit with --author (if not you) using roughly rvsubmit style message. run `go test ./...`. bzr push to the magic bzr+ssh://~go-bot url ^above | 15:36 |
| fwereade | rogpeppe, something's still a bit itchy... maybe it's that we will probably always want cacert with either | 15:36 |
| fwereade | rogpeppe, but, I don't feel very strongly, I'd misinterpreted anyway | 15:37 |
| dimitern | mgz: ok, I'll try now | 15:37 |
| mgz | dimitern: you probably want to wait till after me for the merge though, so we serialise nicely | 15:37 |
| mgz | ...the tests are taking too long to run :) | 15:37 |
| rogpeppe | fwereade: yeah, we'll need CACert with either, but that will still change independently. | 15:38 |
| dimitern | mgz: I'll merge and run the tests, so when I'm done to push it, I'll tell you | 15:38 |
| fwereade | rogpeppe, yeah, sgtm, cheers | 15:38 |
| rogpeppe | fwereade: cool, thanks | 15:38 |
| mgz | yeah, if you move the commit till after running tests, you can them pull/remerge then and (mostly) have got the same thing done :) | 15:40 |
| dimitern | gwacl is broken right now | 15:40 |
| dimitern | just pulled and I see this: | 15:40 |
| dimitern | ../gwacl/management.go:317: function ends without a return statement | 15:41 |
| dimitern | jtv, rvba, bigjools: any ideas? | 15:41 |
| jtv | dimitern: you need James Page's Go PPA. | 15:42 |
| jtv | We're standardized on 1.1.1 nowadays. | 15:42 |
| dimitern | jtv: can you point me there please? | 15:42 |
| jtv | The Juju project is, that is. | 15:42 |
| jtv | Yes I can | 15:42 |
| jtv | ppa:james-page/golang-backports | 15:43 |
| jtv | This was mailed out as a mandatory step a few weeks ago. | 15:43 |
| dimitern | jtv: and then what? apt-get install golang? | 15:44 |
| jtv | Just "apt-get update ; apt-get upgrade" should do it (as root obviously). | 15:46 |
| jtv | Would there be anybody available for a largish refactoring branch involving attempt strategies? It's this one: https://codereview.appspot.com/11923043 | 15:48 |
| jtv | dimitern: is it working now? | 15:50 |
| mgz | dimitern: pushed, so you can pull trunk and run the real merge/commit now | 15:50 |
| mgz | frankban: branch landed | 15:51 |
| dimitern | jtv: yeah, thanks, I have to rebuild everything, but it works | 15:51 |
| jtv | Oh, yes, forgot to say — you may get some weird errors from things that still link but no longer work. | 15:51 |
| jtv | Best to "rm -rf $GOPATH/pkg/linux_*" | 15:52 |
| dimitern | jtv: that's exactly what I did, and had to re-get goyaml and gwacl/... | 15:52 |
| jtv | I'm surprised that you had to re-get those, but who am I... :) | 15:54 |
| dimitern | jtv: i was using go 1.0.3 and haven't updated goyaml in quite a bit of time, since it was refactored to be pure go | 15:55 |
| jtv | oic | 15:56 |
| jtv | We also no longer use libcurl in gwacl. We got an unofficial patch for crypto/tls that solves the problem for us, so gwacl now contains forked copies of net/http and crypto/tls. | 15:57 |
| jtv | Hmm... that largish refactoring branch I've got up for review isn't that big really, it just looks big in Rietveld because of the number of files it touches. Launchpad calls it: 629 lines (+141/-61) 22 files modified | 15:58 |
| jtv | So it's all context. | 15:58 |
| jtv | Any volunteers? | 15:59 |
| rogpeppe | mgz: here's a sketchy sketch: http://paste.ubuntu.com/5915266/ | 15:59 |
| rogpeppe | mgz: it only waits until a machine has an address; it doesn't update addresses when they change later | 16:00 |
| rogpeppe | mgz: i think we could probably leave that as a later refinement | 16:00 |
| rogpeppe | mgz: with a couple of obvious errors removed: http://paste.ubuntu.com/5915275/ | 16:02 |
| rogpeppe | jtv: looking | 16:02 |
| jtv | Thanks! | 16:02 |
| rogpeppe | jtv: we always guarantee at least one attempt (and that's always been true) | 16:04 |
| rogpeppe | jtv: so i don't think it's necessary to set Min=1 | 16:04 |
| mgz | rogpeppe: thanks, that's really useful | 16:05 |
| rogpeppe | mgz: cool, np | 16:05 |
| rogpeppe | mgz: it's probably full of bugs :-) | 16:05 |
| jtv | rogpeppe: are you sure? I was told a few weeks back that this was an issue, but I must admit the code isn't particularly clear. | 16:05 |
| jtv | It'd be nice to have this sort of thing documented. :/ | 16:06 |
| rogpeppe | jtv: yeah, that should be documented definitely | 16:06 |
| rogpeppe | jtv: the original comment in the code says "// we always make at least one attempt." | 16:06 |
| rogpeppe | jtv: and i'm pretty sure i meant that when i wrote the comment | 16:07 |
| jtv | rogpeppe: oh, did I miss that one? Or are you saying it was lost somewhere along the way? | 16:07 |
| jtv | I'd like to fix this if it's safe to do so, obviously. | 16:08 |
| rogpeppe | jtv: it wasn't a doc comment unfortunately | 16:08 |
| jtv | So might be nice to promote it. | 16:08 |
| rogpeppe | jtv: the new code returns an Attempt with force==true, and looking at Attempt.Next, if force is true, it's guaranteed to return true, so it seems to be the case now too | 16:08 |
| jtv | To avoid misunderstandings, which new code do you mean? | 16:09 |
| jtv | I guess I'll have to see this through now and actually write the comments. :) | 16:10 |
| rogpeppe | jtv: how about this, as an addition to the comment on Next: | 16:10 |
| rogpeppe | // Next always returns true the first time it is called - | 16:10 |
| rogpeppe | // we are guaranteed to make at least one attempt. | 16:10 |
| jtv | Yes, I'll add that, thanks. | 16:11 |
| rogpeppe | jtv: the new code is the code that's currently in the tree (i updated it quite recently from goamz which had made some useful changes) | 16:11 |
| jtv | The "force" bit is a bit weird... You'd expect the "count" field to cover the same issue. | 16:12 |
| jtv | As in: initialize "count" to min(strategy.Min, 1) | 16:12 |
| rogpeppe | jtv: i remember going through a few iterations of the review of that code | 16:13 |
| rogpeppe | jtv: it's a bit more subtle than it looks | 16:13 |
| jtv | I'm sure it is. :) | 16:13 |
| rogpeppe | jtv: in particular, look at the way that HasNext sets force | 16:13 |
| rogpeppe | jtv: could you reprose that branch please? rietveld is doing that annoying "chunk mismatch" thing again. | 16:15 |
| rogpeppe | s/reprose/repropose/ | 16:15 |
| jtv | Oh dear. Yes, hang on. | 16:15 |
| jtv | rogpeppe: lbox just finished re-proposing. | 16:21 |
| jtv | I also removed all the "Min: 1" and added your documentation text. | 16:21 |
| dimitern | i merged mine | 16:27 |
| jtv | How do we merge? | 16:31 |
| mgz | jtv: you probably need to ask me or dimitern to do it, don't think red squad are in the bot ssh key set | 16:35 |
| jtv | Ah | 16:35 |
| jtv | I've got a bunch of branches lined up for landing. :) | 16:35 |
| TheMue | So, have to leave. Have a nice weekend. | 16:35 |
| rogpeppe | jtv: reviewed | 16:35 |
| jtv | Thanks rogpeppe! | 16:36 |
| jtv | And a nice weekend, TheMue | 16:36 |
| TheMue | jtv: thx | 16:36 |
| jtv | rogpeppe: you discovered something interesting... Not only does VerifyBootstrapInit() use env.Storage() a few times, but it's the only use it makes of env! | 16:38 |
| rogpeppe | jtv: yeah, so you could just pass in the storage | 16:38 |
| rogpeppe | jtv: not entirely sure if that would be a good idea though | 16:39 |
| jtv | Not sure either. I guess that means I should leave it be. :) | 16:39 |
| rogpeppe | jtv: i guess we might want to make it verify some other property of the environ in the future | 16:39 |
| jtv | Yes, we might well. | 16:43 |
| jtv | About those statements I moved out of the "if" conditions: those lines got longer during my work, so I had to break them up to keep them legible. And then they got a lot shorter again. | 16:44 |
| jtv | So you see how that happened. | 16:44 |
| ackk | hi, is the ErrorCode supposed to be present for each kind of error response from juju API? | 17:08 |
| dimitern | ackk: only if there was an error | 17:09 |
| ackk | dimitern, so if make a login request with AuthTag: foo I get an error without an "ErrorCode" field, just an "Error" one | 17:09 |
| ackk | dimitern, "user-foo" gives me back an auth error with "unauthorized access" ErrorCode, instead | 17:11 |
| ackk | dimitern, fwiw I get 'invalid entity tag "foo"' as Error in the first case | 17:12 |
| rogpeppe | dimitern, fwereade: finally, worker/upgrader: https://codereview.appspot.com/11932043 | 17:14 |
| fwereade | rogpeppe, ack | 17:14 |
| rogpeppe | fwereade: much simpler than the one in cmd/jujud; hopefully ok :-) | 17:14 |
| rogpeppe | aaaand that's me for the day | 17:15 |
| rogpeppe | happy weekends to all | 17:15 |
| jtv | nn robbiew | 17:15 |
| jtv | I mean, rogpeppe | 17:15 |
| jtv | (damn over-eager tab completion!) | 17:16 |
| rogpeppe | jtv: :-) | 17:16 |
| rogpeppe | jtv: g'night | 17:16 |
| ackk | dimitern, I was wondering if the different behavior is a bug or it's intended | 17:27 |
| dimitern | ackk: there is a test like that i think | 17:32 |
| dimitern | ackk: "foo" is an invalid tag format, so you're not even getting to the unauthorized step | 17:32 |
| ahasenack | dimitern: but no ErrorCode came back in that case, that's the question | 17:33 |
| ackk | dimitern, yeah waht ahasenack said | 17:37 |
| dimitern | ackk, ahasenack: both code and message are optional, at least one of them will be set when there's an error | 17:44 |
| ahasenack | ah, this is how software comes to display those "sorry, unknown error occurred" messages :) | 17:45 |
| sidnei | https://bugs.launchpad.net/juju-core/+bug/1205451 | 18:46 |
| _mup_ | Bug #1205451: killing instance outside of juju, doesn't get noticed <juju-core:New> <https://launchpad.net/bugs/1205451> | 18:46 |
| ahasenack | sidnei: see this comment: https://bugs.launchpad.net/juju-core/+bug/1190715/comments/4 | 19:08 |
| _mup_ | Bug #1190715: unit destruction depends on unit agents <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1190715> | 19:08 |
| ahasenack | and the rest of the bug, of course, for context | 19:09 |
| dpb1 | a new papercut one, maybe it's easy to fix? https://bugs.launchpad.net/juju-core/+bug/1205466 | 19:37 |
| _mup_ | Bug #1205466: deploy charm uses cached copy even when all services are removed <papercut> <juju-core:New> <https://launchpad.net/bugs/1205466> | 19:37 |
| dpb1 | mramm, arosales: ^ | 19:37 |
| mramm | dpb1: I'm not sure that's even a bug | 19:37 |
| mramm | you are in control of what charm updates happen if we leave it that way | 19:38 |
| mramm | and not in control if we change it | 19:38 |
| mramm | that said, I think it would be probably be easy enough to fix if that's the right thing to do | 19:38 |
| mramm | for the local charm case it seems like it might be surprising for the charm not to update | 19:39 |
| dpb1 | mramm: I can validate what pyjuju did, but it seems very weird that I'm asking for a local deployment of a charm that is no where in the deployed system, and I get an old thing installed | 19:40 |
| mramm | but for the non-local charm case it seems like having it not use the cache might be equally suprising | 19:40 |
| mramm | and having it have different behaviors between the two seems likely to be surprising as well | 19:40 |
| dpb1 | mramm: and ya, you all get to decide if you want to fix it I can see your reasoning --- just reporting that it has bitten me a number of times, and each time wastes 15 minutes or so. | 19:41 |
| dpb1 | mramm: agreed on differing behaviors. | 19:41 |
| dpb1 | mramm: that would be very unexpected | 19:41 |
| mramm | dpb1: if nothing else we should probably let people know what is happening | 19:41 |
| dpb1 | mramm: do you want me to verify what pyjuju did, or does it matter? | 19:42 |
| mramm | it does matter, but not that much -- I think the important thing is that we do the "right" thing | 19:42 |
| mramm | if it is biting people, we need to figure out a way to make it better if we can | 19:43 |
| dpb1 | mramm: OK, I leave it in your capable hands. :) | 19:44 |
| ahasenack | mramm: fwiw, I think "destroy-service", having the word "destroy" in it, should get rid of the cached copy of the charm. It's what I would expect | 19:49 |
| mramm | what if you have two service groups of the same service (two wordpress installs?) | 19:49 |
| ahasenack | you mean same charm deployed under two different service names? | 19:50 |
| ahasenack | like, juju deploy wordpress wordpress-A | 19:50 |
| ahasenack | juju deploy wordpress wordpress-B ? | 19:50 |
| ahasenack | and then juju destroy-service wordpress-B | 19:50 |
| ahasenack | followed by juju deploy wordpress wordpress-C (to keep things simple, not -B again) | 19:51 |
| mramm | right | 19:51 |
| ahasenack | I think -C would use the charm as if it's the first time it's being deployed, no cached copy | 19:51 |
| ahasenack | let's assume the deploy commands above were from a local charm, i.e., --repository ~/foo and local: prefix | 19:52 |
| mramm | but what happens when you add-unit to A | 19:52 |
| ahasenack | I would expect it to use my local on-disk copy | 19:52 |
| mramm | since that charm is no longer in the cache? | 19:52 |
| ahasenack | it would use the same charm that wordpress-A/0 has | 19:52 |
| ahasenack | so the cache would need to be service-name based | 19:52 |
| dpb1 | Yes, when you upgrade-charm, then are upgraded independently. | 19:52 |
| mramm | so what you are saying is that the cache needs to change | 19:52 |
| dpb1 | distinctly | 19:52 |
| ahasenack | so far the cache was invisible | 19:52 |
| ahasenack | implementation detail | 19:53 |
| mramm | or is it already that way? | 19:53 |
| ahasenack | but the case dpb described made it appear | 19:53 |
| mramm | ok | 19:53 |
| mramm | if the cache is service name based (which makes sense) | 19:53 |
| mramm | any new deploy should not use the cache | 19:54 |
| mramm | and we should destroy it if there are no units in that service naem | 19:54 |
| mramm | name | 19:54 |
| mramm | that does in fact seem reasonable | 19:54 |
| mramm | posted as much to the bug comments | 19:59 |
| ahasenack | mramm: +1 on your observation about unit count going down to zero not being the same | 20:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!