[00:04] hey, does anyone know if juju ssh 1/lxc/0 works ? [00:04] can you ssh directly to a contianer === tasdomas is now known as tasdomas_afk [03:11] https://bugs.launchpad.net/gwacl/+bug/1216744 [03:11] <_mup_> Bug #1216744: Destroying role instances always leaves a VHD file behind [04:05] jtv2: so I explained azure to davecheney, Ian and axw and there was only medium swearing [04:07] he was very restrained [04:07] gold star [04:07] bigjools: tell them they're naïve fools and won't know what hit them. [04:07] Joking. [04:07] to be fair most of it was from Ian and it's hard to tell the difference [04:08] shhh he's here [05:29] * davecheney is trying to figure out why juju status resolves an instance id to an Instance twice to talk to the state server [05:30] I wondered why you had that look on your face [05:31] bigjools: no, that is just my face [05:45] jtv2: can you check the vhds container in whatever storage account you were using for azure - I think there's a bug as I have about 20 29.3GB blobs left behind. [05:47] bzzt === tasdomas_afk is now known as tasdomas [05:55] bigjools: http://paste.ubuntu.com/6027561/ [05:56] axw: https://bugs.launchpad.net/juju-core/+bug/1216768 [05:56] <_mup_> Bug #1216768: Azure provider: Authentication error when using public tools [06:15] axw: another nice bug https://bugs.launchpad.net/gwacl/+bug/1216744 [06:15] <_mup_> Bug #1216744: Destroying role instances always leaves a VHD file behind [07:19] question about lxc [07:20] are local containers addressable on the local lan ? [07:20] ie, do they DHCP from the host's network [07:20] or are they bound to 10.x addresses [07:23] Im trying to use juju with local (aka, LXC). I already have lxc setup, but i did have to change the bridging in order for LXC instances to be accessible from other computers on the LAN. So instead of lxcbr0, i just have br0. juju doesnt seem to like that. Does juju only work when the bridge is NAT'ed? [07:25] MACscr: i don't think nat'ing is the issue here [07:25] you've changed the name of the interface [07:25] juju expects it to be called lxcbr0 [07:25] you've shortened it to br0 [07:25] i think if you fix that [07:25] it'll work [07:25] every tutorial states to use br0 when setting up the public access [07:26] MACscr: sure [07:26] but i guess i can try renaming it [07:26] but juju is different :) [07:26] right, its a shame its hard coded [07:27] MACscr: yup, it is hard coded at the moment [07:28] _BUT_ it is hard coded to the default [07:28] im 99% sure this change isnt going to work [07:28] as the juju probably wants to be its own private network so it knows what IP's its assigning, etc [07:29] MACscr: you're probably right [07:29] with dhcp, the ip isnt being assigned until its booted, not when its created [07:29] environ.go [07:29] 39:const lxcBridgeName = "lxcbr0" [07:29] at the moment, the name of the bridge interface is hard coded [07:29] amazing that a developer would do that [07:33] are there any developers in here that know if NAT has to be used with LXC on the actual host? [07:33] they did that because it is the default name of the LXC interface [07:33] ubuntu@ip-10-248-6-186:~$ ifconfig lxcbr0 [07:33] lxcbr0 Link encap:Ethernet HWaddr ee:6f:ad:c0:96:91 [07:34] ^ this is a fresh lxc install [07:34] i agree that it isn't as flxebile as one would like [07:34] yes, i know its default, but obviously its meant to be reconfigured [07:34] but it does sound like a reasonable default [07:35] but the name doesnt matter, the issue is that with juju needing it to be that way, i highly doubt anything it creates using the local method will allow any of those instances to be accessible outside the host [07:35] MACscr: i think you are right [07:35] i was incorrect there [07:35] i was focusing only on the first problem of getting the lxc provider working [08:11] can any developers concur with that statement of mine? That seems to be a pretty huge limitation of LXC and pretty much means it can be only used for limited testing [08:51] fwereade: ping for when you're around. I had a question about "statecmd". [08:52] jam, heyhey [08:52] fwereade: I trust your return to Malta was met with great fanfare and celebration? [08:52] jam, haha [08:53] jam, it's nice to be back [08:53] fwereade: so I updated "juju add-unit" to use the API instead of a direct state connection which seems good. rog mentions here https://codereview.appspot.com/13212043/ that we should probably get rid of statecmd (since it was only for sharing implementation between the API and the CLI). [08:53] which is fine [08:53] but I'm looking at AddServiceUnits [08:53] and it does weird things like [08:53] NewConnFromState [08:53] so it can do Conn.AddUnits [08:53] but why do we need conn? [08:54] jam, for AddUnits I'm 90% sure we don't any more *except* that Deploy does (or might...), and it uses AddUnits internally [08:54] fwereade: well the implementation of AddUnits is on Conn [08:54] jam, the only reason for the conn in the first place is to access provider storage [08:55] so it *feels* like if I'm getting rid of statecmd/addunit.go I should be moving Conn.AddUnit somewhere else [08:55] but where? [08:56] jam, api.Client, I think, is the ideal [08:56] fwereade: we have api.Client.AddServiceUnits which is what I'm using. It is backed in the apiserver which uses state/statecmd/addunit [08:56] which uses Conn.AddUnit [08:56] my point is that it seems really strange on the server side [08:56] to get a NewConnFromState in order to AddUnit on it. [08:57] jam, sure; moving AddUnit up to client and sharing that implementation between AddServiceUnit and Deploy would be just fine as far as I'm aware [08:58] jam, it's just fiddly because Deploy might need Environ access to upload a local charm [08:58] jam, but we should be exposing that capability over the api regardless [08:59] fwereade: conn.AddUnits isn't called by anyone except tests and statecmd as near as my grep-fu tells me [09:00] conn.DeployService can call conn.AddUnits [09:00] I don't particularly mind conn having AddUnits, it just seems strange to need Conn in the apiserver. [09:00] Am I just wrong on that? [09:00] hi rogpeppe [09:00] I thought today was "Summer Bank Holiday" for you [09:00] jam, no, I think Conn is really inappropriate there [09:00] I know mgz is out. [09:00] sorry to interrupt, but i had a dev question earlier. Did anyone read it? DaveChaney sent me here [09:01] jam: it is indeed the auguest bank holiday today [09:01] jam: i am not here :-) [09:01] rogpeppe: I started a chat with fwereade about removing statecmd, I would be interested to hear your thoughts if your ephemeral self wants to chime in. [09:02] MACscr: mgz is probably the best person to chat with, and he is off today for the UK holiday. He should be around by this time tomorrow. [09:02] MACscr: thumper would be another person to ask, but he is in AU so is usually gone by now. [09:02] jam: briefly, perhaps [09:03] MACscr, the RelationList question sent to juju-dev? sorry, just saw that [09:03] I guess if you were chatting with davecheney then thumper is in a similar timezone. [09:03] okie dokie. Thanksffor the tips [09:03] fwereade: what are your thoughts? [09:03] fwereade: the one in IRC from a bit ago is about LXC needing lxcbr0 [09:03] rogpeppe: so I'm happy to remove statecmd, but it revealed some other ugliness. [09:03] namely, it is using NewConnFromState inside the API server to call Conn.AddUnits. [09:03] rogpeppe, I'm +1, the cli and the gui should be using the exact same implementation [09:03] And he and I seem to agree that Conn shouldn't be used inside the API Server. [09:04] rogpeppe, it's really all about the conn nastiness [09:04] jam: +1 to that [09:04] fwereade: yeah, we need to eliminate that [09:04] jam, I don't really see the need for Conn at all once we're api-only [09:04] rogpeppe: but it is unclear to me where to move Conn.AddUnits to avoid duplication. [09:04] fwereade: in particular we need a way to upload charms [09:04] jam: what else uses Conn.AddUnits? [09:04] rogpeppe: we do, but "not yet" given that AddUnits doesn't actually upload anything [09:05] rogpeppe: Conn.DeployService [09:05] and statecmd.AddServiceUnit [09:05] and some tests [09:05] fwereade: im not to concerned about the name, thats an easy fix. My concern is about LXC by default being NAT only and i have a feeling juju will only work that way. Thus anything it creates with LXC wont be accessible outside the host. [09:05] and the builddb charm [09:05] jam: all that will be inside state/api eventually, right? [09:05] jam: or can be, at any rate [09:06] jam: if we choose it to be [09:06] rogpeppe: that is sort of my point. *Where* does the functionality in Conn.AddUnits go. [09:06] jam: into state/api, no? [09:06] rogpeppe: why would it go on the client side? [09:06] jam: sorry, doh [09:06] jam: into state/apiserver/client [09:07] rogpeppe: how does the current conn.DeployService call into that/ [09:07] ? [09:07] jam: well the current conn.DeployService should also end up in state/apiserver [09:07] rogpeppe: does Conn have an API connection? [09:07] rogpeppe: I'd rather not have to move-the-whole-world to get one bit to land :) [09:07] MACscr, ah, sorry, I was thinking of the wrong question then; and mgz is the expert, but the answer is basically that juju *will* be handling container addressability, but will only be creating containers if the cloud has addresses available to assign to the them [09:07] jam: perhaps it's not appropriate to move Conn.AddUnits until we can do tat [09:07] that [09:08] MACscr, fwereade: I think this is about local provider [09:08] as in your personal machine [09:08] no "cloud provider" availabel [09:08] available. [09:08] fwereade: correct. Local [09:08] jam: no, Conn doesn't have an API connection. [09:08] MACscr: how are IP addresses assigned? [09:09] jam: the point is that probably all the stuff that's talking directly to state inside the juju package can eventually move into state/apiserver [09:09] MACscr: that is the key point that I can see. As we have to play some games with lxcbr0, and I don't know how that works with third-party DHCP assigning addresses [09:09] MACscr, the local provider is explicitly a dev tool; we're not currently planning to handle addressability from outside [09:09] the way i have LXC setup now, it gets the IP's assigned through DHCP from my router and the bridge setup is called br0. LXC isnt setup that way by default [09:10] rogpeppe: k, for now, I'll get rid of statecmd, leave in NewConnFromState and file a bug about APIServer should not depend on Conn. Sound good? [09:10] fwereade: ^^ [09:10] fwereade: ah, thats very disappointing. Very unrealistic to use a physical machine or full VM just for a single service [09:10] MACscr: 'juju deploy --to" or the future container work handle both of those. [09:11] jam: i don't think you can get rid of statecmd completely yet, no? just gradually whittle it down as you implement the various CLI commands in the API [09:11] rogpeppe: no, just getting rid of statecmd/addunit.go [09:11] right [09:11] I overstated earlier. [09:11] jam: SGTM [09:11] jam: it's just good to have an idea of where we're heading [09:11] MACscr, would you explain your use case a bit more? do you have a cloud we don't support, that you want to run a local provider on? [09:12] * rogpeppe fades away again [09:13] fwereade: I have a management server that i want to run some LXC instances on. Also, when i deploy openstack, i want to put multiple services like ceph-mon and nova, etc, all all the same 3 physical servers [09:13] the only servers that will be separate will be ceph-osd and the compute nodes [09:13] keystone, etc, as well will be on the 3 nodes i just mentioned [09:14] and probably some other openstack services i dont know yet =P [09:14] MACscr, ok, I agree that it's nicer and cleaner to have your service units running in LXC containers, but you can colocate already without containers; you just don't get the benefits of isolation [09:15] oh, i wanted to install the juju-gui on my management node, that was my first and original request/problem [09:15] MACscr: so for 13.10 we are hoping to natively support containers inside machines provided by another cloud (it already mostly works when MaaS is providing the machines). Which might sort this out in a better way. Then you can use "juju deploy --to" for all of the openstack bits you want on the same physical machine. [09:16] so it seems with juju has to deploy the gui, it seems to require that it runs on a separate server (no idea why) [09:16] MACscr, we're actively working on manual provisioning, which would let you set up your containers as you prefer, but that isn't ready today [09:16] MACscr, not at all, but service units get fresh machines by default [09:17] MACscr, `juju deploy juju-gui --to 0` should put it right where you need it [09:17] so 0 would pretty much be localhost? [09:18] oh, damn, sorry, fwereade gets it now [09:19] MACscr, on the local provider, I think that would *probably* work but is not recommended [09:20] MACscr, if you're dealing with actual hardware would you consider using maas for your environment? [09:20] fwereade: huh? Why would i need two management nodes just for using juju-gui? [09:20] one to deploy it and another one its deployed on? [09:21] good morning, just back from doc, now start the week ;) [09:21] MACscr, the local provider is not going to work with more than one physical node in play [09:23] MACscr, maas would require a maas server on top of the nodes it deploys, I think, if that's what you're saying? [09:23] fwereade: I understand that. Local means local only, thus not accessible outside that host. Which then means i cant even use juju-gui unless i have two physical hosts if i want to access it on the lan [09:29] MACscr, tell me when I say something wrong: [09:29] MACscr, you would like to use the local environment on a single remote machine [09:30] yes [09:30] MACscr, and control it from outside that machine [09:30] yes [09:30] without having to do port forwarding [09:32] MACscr, ok, on the understanding that this is outside design parameters, you *might* be able to deploy to machine 0 -- which will be the physical machine running the local environment -- and have it work transparently [09:33] fwereade: I'm pretty sure local provider doesn't let you do machine 0, but the maas provider has reasonable LXC support (at least with thumper's pending patch) [09:33] as in, the LXC nodes end up on br0 [09:33] like MACscr is trying today. [09:33] though i could settle at this point just being able to have juju-gui on my management node [09:34] MACscr: doesn't "juju deploy juju-gui --to 0" do that? [09:34] i have no idea, i havent tried it [09:34] jam, damn, how does it stop you? the proper way of stopping you doesn't seem to be there, but maybe it's been hacked in somewhere I didn't expect? [09:34] fwereade: I could be wrong. I know it wasn't intended to work. :) [09:35] MACscr: so you're talking about deploying openstack infrastructure. You sound like you want to use "local provider" but have it put stuff on things that aren't on the local machine, is that correct? [09:35] nope, doesnt work, it tries to install it to an LXC container and thus gives me the 'error: net: no such interface' [09:36] (as in, how are you going to deploy the openstack compute nodes, and the ceph stuff that you didn't want on the same physical machine?) [09:36] jam: sorry guys, im not trying to confuse anyone. Lets forget openstack and just go simple for now [09:36] jam, gaaah, ok, it won't work [09:37] i have a single server running LXC on it and they are all setup to get DHCP from the router and are using br0. lxcbr0 doesnt exist as that was the bridge that was just used for private nating. [09:37] all i want to do is get juju-gui to work so i can deploy openstack to my physical servers and also setup a few amazon instances [09:38] MACscr: but what is juju-gui interfacing with? What are you using it to deploy? [09:38] id like to start simple and just get the amazon instances working, but i do want to use the gu to do that so i can start testing it [09:38] the amazon instances? [09:38] MACscr, then surely you can bootstrap on amazon and deploy the gui to machine 0 there? [09:38] jam: I guess that would be just amazon to start? [09:38] it sounds like you are mixing providers (some local, some amazon, maybe some openstack), which isn't something we support today. [09:39] fwereade: no way, i dont want to use up a amazon instance just for the gui. thats just plain stupid [09:39] MACscr, juju will not run a single environment across separate clouds [09:39] MACscr: juju bootstrap (creates the controller node), juju deploy juju-gui --to 0 puts the gui on the same node. [09:40] fwereade: i never said anything about a single environement. The amazon instances are for my dns servers and I guess maas would just be for openstack [09:41] MACscr, the juju gui currently administers a single environment [09:41] so i would have to deploy two of them? [09:41] or is that even possible [09:42] i guess i just dont understand why whatever system im running the juju commands from isnt the actual controller [09:42] thus why the need to setup a different one [09:42] for just the gui [09:42] MACscr, if you're using an actual cloud, you can/should deploy it to the controller node [09:43] MACscr, so if you want to run stuff on amazon, bootstrap there and deploy to 0 and you're fine [09:43] fwereade: with MaaS, could we run the juju bootstrap node on the MaaS controller node? [09:44] that's probably more an allenap question. [09:44] jam, I'm not sure about that but I wouldn't expect a maas controller to "provision" itself [09:45] fwereade: it seems really useful in the "small scale allow me to get stuff up and running with 3 machines" case. [09:45] jam: um, it makes sense for efficiency purposes [09:45] MACscr, if you have hardware, you should be able to use MAAS, but that does currently demand an additional node to control MAAS as far as I am aware [09:45] why in the world would the controller not be the same system that you are running the juju commands on? [09:46] MACscr, your particular use case *will* be satisfied when we have manual provisioning working; that's in progress [09:46] MACscr: you might be running juju commands from your laptop, controlling Amazon nodes. [09:46] the Amazon nodes need to be able to talk to the controller node [09:46] to coordinate activities. [09:46] jam: yes, so if im running it from my laptop, its the controller, this should have the gui on it [09:47] MACscr: running 'juju' is not the controller. The "controller" is a jujud process that is running for the other nodes to talk to. [09:47] amazon nodes wouldn't have routing back to your laptop (in the general case) [09:47] ok, now thats making sense, but wouldnt that only be needed when its initially setup? I mean, after they are deployed, the controller wouldnt need to be up anymore would it? [09:48] so i dont see why the amazon nodes wouldnt be able to talk to the laptop [09:48] MACscr: as you add units, put more stuff out, they trigger hooks being run on each machine [09:48] coordinated by the controller. [09:48] MACscr: my machines are all behind NAT and not directly accessible from a public space like Amazone. [09:48] And it certainly wouldn't stay at the same IP address as I move around. [09:49] MACscr, manual provisioning is in progress (aside: that *would* allow you to add aws machines to an environment, assuming everything *is* mutually addressable) [09:49] MACscr: juju doesn't just provision machines at one point in time and then disappear. It continually monitors the system to notice when machines leave, when new nodes get added and they need to be connected to the other nodes, etc. [09:50] MACscr, and will become useful to you in its second phase, in which we support manual provisioning of an environment controller (rather than just adding machines to an existing environment) [09:51] fwereade: ok, its starting to make more sense now. Not that i agree with its design, but im starting to understand it [09:51] MACscr, ;p [09:52] ok, so a controller that is setup can only manage one type of cloud at a time? [09:52] so if i deployed the gui to an lxc instance, it would only be able to deploy lxc instances? [09:53] MACscr: that is correct (at present). [09:53] and if wanted to deploy an amazon guests, i have to setup an amazon controller too? [09:53] MACscr, today, yes, but assuming your controller is accessible to ec2 instances, manual provisioning will allow you to include those in another environment [09:53] so even if i only want to deploy and manage 4 amazon instances, i actually have to have 5 of them? one for the controller? [09:54] well i dont really care what the future holds. I need to figure things out with currently available features =P [09:54] hope that didnt sound offensive, wasnt my intent [09:54] MACscr, if you're using the complete capacity of those nodes and *don't* want to run the juju controller on one of them then, yes, you'll need another node [09:55] MACscr, np, all I heard was "I am frustrated" [09:55] MACscr, otherwise you can bootstrap on amazon, giving you machine 0, and manually deploy some of you units onto that machine [09:56] yeah, its just frustrating when you though you found a tool that was going to be perfect for your particular need and then reality hits and find out its not as cool as you though it was [09:56] thought* [09:56] lol, i forgot the T twice [09:56] its 5am, im expected to make mistakes =P [09:57] MACscr, no worries, and I'm sorry to disappoint you [09:58] MACscr, was I clear about aws? [09:58] fwereade: yeah. I think so and I really appreciate both you and jam's time to help explain things to me [09:59] MACscr, for deploying openstack, we do recommend running on maas and that -- being an entirely separate thing -- does require its own hardware [10:02] fwereade: hmm, so i couldnt install maas on the management node i have now? [10:02] heck, maybe i could install that in an LXC guest on my management node? [10:02] im trying to limit what i install on the actual management host OS [10:03] MACscr, you might be able to install it on your laptop, but maas provisions bare metal from scratch, and it won't be able to do that to itself [10:04] MACscr, assuming everything's addressable, though, I don't see why you wouldn't be able to do run maas locally and use it to provision your 3 physical machines [10:05] MACscr, that said, if you have anything running on those machines that you want to keep, don't do that [10:06] MACscr, maas will overwrite those machines with the ubuntu series juju asks for [10:10] sry, my mac got angry and i had to reboot. It has been about 3.5 weeks since the last one [10:18] fwereade: all machines or just ones i specify? I am assuming thats done through mac addresses or something like that? [10:18] MACscr, you register individual machines with the maas controller and it's then free to have its way with them [10:19] MACscr, just installing a maas controller shouldn't cause havok in itself ;) [10:22] ok, but just to verify, the maas server can be its own controller. Correct? [10:23] so when it asks for the controller ip, i can just do 127.0.0.1? [10:31] fwereade: ping [10:31] TheMue, pong [10:32] fwereade: I'm just doing the changes for string options to be also "", while others like int options react with an error. we talked about it. [10:32] MACscr, sorry, didn't see: I'm afraid I don't know, #maas would be the place for someone who does [10:33] TheMue, ok [10:33] thanks again for your time [10:33] fwereade: but here I've seen that this also influences the reading of a config.yaml [10:33] fwereade: today "" here is the same as null [10:33] neat to see at least maas planned it right by allowing the gui to run on the same node as the controller =P [10:34] fwereade: but with the change "" would be treaten as string while it is inappropriate for int, foat etc [10:34] fwereade: what do you think about it? [10:36] TheMue, I don't think "" is a valid float -- AFAIK the "" handling was new to juju-core, so I think we're safe pulling it out [10:36] fwereade: got aware of it in ConfigSuite and there TestParseSettingsYAML [10:36] fwereade: that's good news. ;) [10:36] TheMue, except, hmm -- check the python [10:36] fwereade: argh [10:37] fwereade: I hoped you would not say this :D [10:38] TheMue, sorry :( [10:38] fwereade: hehe, np, alsready looking [10:38] already [10:38] * fwereade thinks a moment [10:41] TheMue, even if it does work in python, I am sorely tempted to classify that as a bug [10:45] fwereade: after our discussion last week I would agree [10:45] fwereade: but I'll look a bit more to be sure if we have to note this in the release notes [10:45] TheMue, thanks [11:58] jam: https://codereview.appspot.com/12752044/ === gary_poster|away is now known as gary_poster [12:20] jam: do we have Juju icons and images I can use for the installer? [12:23] natefinch: I don't explicitly know of them, but I would look in the documentation branch at "lp:juju-core/docs" [12:25] natefinch: looking at it, though, juju.ubuntu.com doesn't seem to show the Juju logo (the inverted and upright juju symbol) [12:25] you can see it at https://jujucharms.com/ [12:25] Yeah, that [12:25] that's unfortunate [12:25] natefinch: when he's around, maybe poke gary poster [12:25] charm store does though [12:25] gary_poster: ^^ do you have nice Juju icons? [12:29] fwereade: it seems like state/api.Client should really be an interface. I realize there is the "you should consume interfaces but return concrete types argument", but it seems really hard to break Client up into 50 one-function interfaces. [12:30] fwereade: bonus points, though, APIConn already has Close() which just calls self.State.Close() [12:30] jam, I'd fine with that so long as the testing overlaps properly :) [12:30] jam, cool [12:31] fwereade: one bit I'm not super happy with NewAPIConn is the DialOpts. We currently pass it through a bunch of layers, but I was hoping to hide it for the CLI. [12:31] Is it ok to just use api.DefaultDialOpts ? [12:32] jam, I'm ok with that [12:33] oh hey jam. sory, didn't see you. Yeah I have svgs somewhere. Is that what you need? [12:34] jam, I was about to ask you if I mind if I share your email about the CLI API work. That looks like exactly what I was hoping for, so far. [12:36] gary_poster: svgs sound good for nate. [12:36] ack, looking [12:36] gary_poster: for the API stuff, I have one more step I'm putting together today, (hopefully) but yeah you're welcome to share it. [12:36] thanks jam! [12:38] gary_poster: an .ico file with multiple sizes would be ideal along with the svgs [12:38] gary_poster: I'm working on the windows installer for juju and want to make it look perty [12:38] natefinch: well, you can create one if you get an svg, right? That is what "scalable" is all about. [12:38] jam: yes, but if he already has one, that saves me some time wrestling with gimp :) [12:40] natefinch, ack. :-) I have a favicon.ico but that's it, and that's probably not what you need, yeah? [12:40] gary_poster: I was looking at that one, it's likely just 16x16... I can make a multisize one from the SVG, that's ok. [12:41] cool. yeah it is 16x16 [12:43] fwereade: *sad face*, APIConn.Close() exists, but api.Client().Close() does not. Time to start writing code. [12:44] back again [12:45] fwereade: could you repeat your last question here? i'm not sure if i got you right acoustically. [12:45] jam, there is a slight worry there in that Client is unique among api types in being legitimately allowed to close the underlying conn -- I'm starting to think maybe just returning an api.State is the best thing [12:46] fwereade: api.Client is a pretty unique beast, though. :) [12:46] jam, yeah, if it's commented it's probably fine [12:47] fwereade: so *today* conn.Environ from NewConnFromName is used for "juju status" to provide conn.Environ.Name(), "environment.go" to report "conn.Environ.Provider()", and "upgradejuju" (presumably to upload the tools so that it can ask to be used? [12:47] I'm surprised not to see deployer in there. [12:47] jam, BTW, I don't necessarily expect delivery, but consideration would be worthwhile: the client API is entirely unbulky at the moment, and it would probably be good to make it more so [12:47] status also directly calls "fetchAllInstances". [12:48] fwereade: more focused on bulk-operations? Or have more extraneous stuff that is unused? :) [12:48] (define bulky) [12:48] * fwereade deadpans "the former" [12:49] fwereade: you had commented on TheMue's unset changes, can you give it a look:https://codereview.appspot.com/12752044/ he seems to have responded to your requests [12:49] jam, AFAICS the deploy command uses NewConnFromName [12:50] fwereade: sure, but it uses conn.PutCharm which might touch self.Environ. It doesn't call conn.Environ stuff directly. [12:50] vs status et al [12:50] but a fair point. Conn itself is the object that is touching Environ [12:51] and we need to be careful when porting commands across. [12:51] jam, the whole Conn thing is kinda crack anyway because it's got an Environ with a config that's most likely wrong [12:52] jam, anyone actually *using* conn.Environ is playing with fire [12:52] jam, PutCharm is probably mostly ok [12:52] fwereade: well, it is one of those "this needs to be exposed in the api so we can use it there instead". [12:53] jam, because all it uses is the creds which don't change much, and the control-bucket, which is immutable [12:53] fwereade: well status accesses the Name, which isn't something we expose elsewhere. [12:54] jam, but the important point is that in general you cannot trust conn.Environ and would therefore, in an ideal world, never use it [12:54] jam, if you want to know something, get it from the API ;) [12:54] fwereade: do we have Client.Name() ? [12:54] or Client.EnvironmentName() ? [12:54] (eventually we want to put something like that into a Client.Status() sort of output.) [12:54] x [12:55] jam, we have EnvironmentInfo [12:55] jam, sure, but I expected status would be composed server-side and sent down in one go regardless [12:56] right, that was my Client.Status() as a single call [12:58] jam, cool [13:17] fwereade: https://codereview.appspot.com/12943045/ NewAPIClientFromName instead of NewAPIConnFromName if you want to give it a look [13:18] jam, cheers [13:22] fwereade: it would appear that api.State.Close is not re-entrant :( (It gives an error already closed if you call it again) [13:23] we had a test that Conn.Close() could be called multple times [13:23] which I copiesd [13:23] but then found the test wasn't actually checking the error return [13:23] adding that to Conn.Close() didn't give any errors [13:23] but for APIClient.Close() which just calls c.State.Close() underneath returns errors... [13:23] fwereade: *should* Close be idempotent? [13:26] jam, it's somewhat useful for tests -- defer an assert that something closes without error -- but I guess it's at the point where errors aren't really useful, so logging and moving on at a lower level is probably reasonable [13:49] gary_poster: I poked the notes you shared with me a little bit. We changed one of the function names, etc. [13:50] fwereade: I'm fine with it returning an error. I'm just asking if "already closed" should be an error? [13:51] It isn't for state.State.Close() it *is* for api.State.Close() [13:51] jam, ah, I see [13:51] jam, er, dunno [13:52] jam, you're implementing the client, though... make it work however seems to make most sense there ;) [13:53] fwereade: it is being passed up from rpc.Conn.Close() where it checks "if conn.closing: return errors.New("already closed")". [13:54] I guess I can wait for roger to figure out what his thought was. [13:55] and since it is an untyped error, I'm not a big fan of detecting it in api.State.Close() and suppressing it: "if err.Error() == "already closed": return nil" [14:15] perfect, thanks for updating the doc, jam. I hoped that might happen, actually. :-) === marcoceppi__ is now known as marcoceppi [14:42] jam: do we sign our installers to prevent the "publisher: unknown" dialog box from popping up during install? If so, I'll need a canonical certificate I can use with the installer. [14:46] fwereade: so, went through the whole stuff in pyjuju from all sides and i'm pretty sure we can make the change. interestingly i found something like "set foo=@filename" where the value is read out of he file [14:58] TheMue, yeah, I noticed that the other day, I have no intention of implementing it unless we have to [14:59] fwereade: so far nobody seems to miss it ;) [14:59] TheMue, exactly :) [15:08] fwereade: oh, was about to file a bug on that friday :) [15:08] but just because we expected the functionality to be there from pyjuju [15:08] sidnei, oh bother [15:08] sidnei, if it's used, please file a bug [15:09] people that didn't know it exists just used juju set foo="$( which is slightly more annoying [15:10] sidnei, yeah, fair point -- my thinking was just that if nobody had noticed yet, hopefully nobody would ever notice ;) [15:10]