=== defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie [03:50] Can anyone confirm that if I run relation-list in a peer relation hook, that it might be listing dying units? === defunctzombie is now known as defunctzombie_zz === marlinc|away is now known as marlinc === marlinc is now known as marlinc|away === _mup__ is now known as _mup_ === danilos__ is now known as danilos === exekias_ is now known as exekias === stevanr_ is now known as stevanr === TheRealMue is now known as TheMue === rogpeppe3 is now known as rogpeppe [11:42] mthaddon: Not sure if you review charmhelpers, but as per our conversation yesterday, here's an update for the salt support which doesn't install a daemon: https://code.launchpad.net/~michael.nelson/charm-helpers/depend-on-salt-common-only/+merge/170298 [11:42] noodles775: I saw the comment in the RT, thanks. I'll leave the review to wedgwood and others for charm-helpers though [11:43] Cool. [12:38] Is all off Juju's main code under Affero v1? [12:46] MarkDude: yes, juju is licensed agpl [12:49] v1? not v3? marcoceppi ? [12:50] Oh, I'm not sure the version exactly [12:50] Was that the license from the start [12:50] juju-core is AGPLv3 [12:50] so is juju0.7 [12:51] * MarkDude can email on it. I have been wanting to put juju in Fedora- and have seen v1 be an issue [12:51] Yay, [12:51] much easier, I can proceed now, I *might* need a clarification letter at some point so I could put it in the regular repos [12:52] A few of the other parts are not compatible with all the legal restrictions on my side. [12:53] But as far as the main part- I feel juju- used in concert with Kickstart (scripts for the Anaconda installer) has awesome possibilities === wedgwood_away is now known as wedgwood [13:00] Hi everybody ! [13:00] Hi maxired [13:01] I'm trying to use "juju-gui", from cs:~juju-gui/precise/juju-gui-68 ,a dn i'm stuck on ""Connecting to the Juju environment" [13:01] I'm not sur how to check that the juju API is running, any idea ? === BradCrittenden is now known as bac [13:07] MarkDude: you don't want that [13:07] you want to use cloud init [13:07] it's in fedora [13:08] Agreed, the cli client looks easy to integrate [13:09] the rest of the licenses appear to work, and I have a list of Juju items ALREADY available for Fedora [13:09] how's the golang stack in fedora? [13:09] +1 [13:09] * MarkDude expects no issues there [13:09] Well major ones, possible small fixes needed [13:10] * MarkDude started notes- and mostly saw a Affero v1 as issue- v3 means a bit of work on my side- but it should be fine [13:10] maxired: what version of juju are you using? [13:11] * MarkDude was reviewing the code. Looks like there is a really nice base to build off of [13:11] * MarkDude has not so secret plan of linking (in idea only) juju charms and Kickstart [13:11] marcoceppi : I was precisly looking at this. [13:12] i'm on 0.7 from ppa:juju/pkgs on the master node [13:12] MarkDude: charms are licensed sperately from juju, you'd need to check each charms license if that was the case ;) [13:13] but look's like juju 0.7 from default repository has been installed by MAAS [13:13] I'll try to change this [13:13] Admittdly it's been a while since i've deployed the gui with 0.7 [13:14] hey - is there an OS X build of go-juju anywhere? [13:14] ehg: not for go-juju, not yet at least [13:14] marcoceppi: ah, would it compile? [13:14] The charms themsleves are not as intereresting as what Juju could do for helping make a dev environment, or a few other things more technical [13:15] Bonus being we get to keep the awesome part of getting folks to dev- on the easy route [13:15] ehg: I don't see why not. I don't think there's anything platform dependant, but I'm not a juju-core developer nor do i own a mac to verify [13:15] cool, i'll get our CEO to try :) [13:15] ehg: Let us know how it works out! [13:15] Juju is full of win. Charms made elsewhere may not work for various reasons - technical , license etc [13:16] Roll out on installs of servers is a possiblity at this point [13:17] * MarkDude is hoping to get a kickstart to create Juju- and go from there [13:17] Ty jcastro , marcoceppi , everyone [13:18] Back to study, do I send my "formal letter of intent" (yay Juju rocks) to jcastro or someone else ?]\ [13:18] a letter for what? [13:18] I don't know where you hang out man, but we're ubuntu, you don't need a letter, just go do awesome stuff. :p [13:19] MarkDude : I was wrong, i'm also running juju from ppa:juju/pkgs on the execution machine [13:19] marcoceppi : I was wrong, i'm also running juju from ppa:juju/pkgs on the execution machine [13:20] Ubuntu 12.04 MaaS and JUJU's proxy issues | http://askubuntu.com/q/310153 [13:20] maxired: Well, that all _should_ work. There was a rudimentary api added to 0.7 for the gui [13:20] * marcoceppi checks [13:21] I know jcastro but despite the awesomeness of Fedora, every so often I need to do formal shit [13:22] ok let me know if you need anything [13:22] So I can forward to legal, and such- CYA on my side [13:22] * MarkDude hates having to use his title, but has to in the formal letter [13:23] * MarkDude really really wants to have Distros focus on our common themes- and juju has great possiblities [13:24] Ubuntu helps all of FOSS imho. and providing some concrete examples can help stop some sniping from at least a few troll types [13:25] Oh I should have an agreeable packager to help with this, so I can see about getting some momentum. Keep kickin ass Juju folks :D [13:25] hey we do have some RPM packaging somewhere, but it's old and for pyju [13:25] so not useful probably, just thought I'd mention it [13:26] jcastro: I'd rather pyjuju not end up in some rpm distro somewhere :P [13:26] hah yeah, we can't even get rid of it in ubuntu [13:26] it's gone from the saucy though! [13:27] I got a process with " /usr/bin/python -m juju.agents.api --nodaemon --port 8080 --logfile /var/log/juju/api-agent.log --session-file /var/run/juju/api-agent.zksession --secure --keys /etc/ssl/juju-gui" , but not listening on 8080 [13:27] maxired, hi. I'm one of the GUI people. We test against pyJuju 0.7 at least a couple times a day, but not against MAAS. We've had similar reports to this, but we have resolved everything we know about previously. [13:27] ok that sounds promising/interesting. this is on the GUI charm, I assume? [13:28] Where are they located? [13:28] * MarkDude is aware the pyju is the OLD method [13:29] Well we would look at pyju for reference, not to include :D [13:29] maxired, first question I'd have, if you've verified that nothing is listening on the gui charm on part 8080, is what you see in that logfile (/var/log/juju/api-agent.lo) [13:29] /var/log/juju/api-agent.log [13:30] ... *port [13:31] gary_poster : thanks for helping. yep, nothing actually listening on that port. [13:31] i'm am currently trying again, because there has bene previously an nginx on it [13:31] When I do juju bootstrap, the bootstrap server does not have my openstack keypair and I can not log into it. What do I have to put to include the canonistack keypair? [13:32] ok maxired. there's a (closed) bug for this, which has had some conversation. I don't think it has anything interesting but will go find it. [13:33] maxired, https://bugs.launchpad.net/juju-gui/+bug/1180095 [13:33] <_mup_> Bug #1180095: GUI charm may have difficulties working with Juju on MAAS [13:35] gary_poster : thanks [13:39] maarten__: You can add SSH keys to your environments.yaml file: http://askubuntu.com/q/205170/41 [13:40] thanks [13:40] WIth that format, you'd just put one public key per line [13:40] (if you had multiples) [13:40] gary_poster : after a new deployment, the agent is listening, but i still stuck on "Connecting to the Juju environment" [13:41] do you know how can i get logs from haproxy ? [13:42] maxired, I don't. looking. === BradCrittenden is now known as bac [13:45] maxired, benji has graciously offered to help [13:46] he'll be around presently [13:46] hi, maxired; I'm reading the backlog to get cought up [13:46] hi benji ;) thanks for helping [13:48] benji : looks like it's working right now [13:49] the first connection to the websocket as been really long [13:49] but i could login the the web ui ;) [13:49] my work here is done ;) [13:51] benji , gary_poster and marcoceppi, thanks for helping [13:51] maxired: glad you got it working! [13:51] maxired, benji, lol, excellent [13:51] i'll check in the bug tracker, but looks like my probleme was a destroyed instance of 'wordpress' wich didn't remove the nginx [13:52] maxired, on the same box to which you deployed the GUI later, I'm guessing? [13:52] yep === defunctzombie_zz is now known as defunctzombie [13:54] ok, yeah. FWIW, effectively fixed in Juju Core AIUI, maxired. [13:56] Good news i don't have to reproduce to be sure about that in order to fill a bug ;) [13:58] :-) [13:59] any link to the commit/bug ? [13:59] looking [14:00] maxired, https://bugs.launchpad.net/juju/+bug/872264 [14:00] <_mup_> Bug #872264: stop hook does not fire when units removed from service

[14:02] (I believe you destroyed the service, but I also am 90% sure that the issue is the same) [14:02] maxired, gary_poster: we do not currently implement an uninstall hook, which is what I'd expect would actually remove such things [14:03] maxired, gary_poster: we are currently working on containerization, which would let you *really* remove things, rather than just trusting to the effect of the putative uninstall hook [14:03] gary_poster : thanks, i was looking for something more specific [14:03] fwereade, when you destroy a service, don't you do a lot more drastic clean up than pyJuju did up? Or am I just thinking of containerization discussions? [14:03] maxired, ok, that's all I've got. :-) [14:04] gary_poster, we can do a lot more stuff in the DB; and we can actually guarantee that stop hooks will be run; but we don't go any further than that [14:04] fwereade : I guess you are write. stoping could be not enough if things for example start at reboot ;) [14:04] maxired, I would hope that a well-implemented stop hook would prevent the service from autostarting ;) [14:05] fwereade, gotcha, thanks. === defunctzombie is now known as defunctzombie_zz [14:17] jamespage: m_3: have either of you checked out that merge proposal from patrick hetu yet? [14:18] jcastro, remind me again - which one is that? [14:18] https://code.launchpad.net/~patrick-hetu/charms/precise/gunicorn/python-rewrite/+merge/167088 [14:18] stub, you are terrifying me with all of the postgresql MP's you have in flight [14:18] rick_h: hey so sinzui isn't around so you're the closest, tldr, some merge proposals aren't getting in the charm review queue [14:19] jcastro: yea, there's a bug for that. Sec let me find it. [14:19] https://bugs.launchpad.net/charmworld/+bug/1191823 jcastro [14:19] <_mup_> Bug #1191823: Merge proposals are missing from the review queue [14:19] "But ~charmers isn't requested to review this proposal, only ~mark-mims." [14:20] OOOHHHHH [14:20] jcastro: so not a lot we can do atm about it. [14:20] so this is a workflow bug [14:20] jcastro: yea, at least for now until we can get time to check out a better way to generate the list [14:20] ok so you know how we can "reset" a merge proposal to a non assigned to mims state? [14:21] jcastro: moved to #juju-gui since aaron is there and he looked into it. [14:21] jcastro, just fixed that [14:22] right so basically after the first reviewer reviews it, and they ping pong, we need a way to stick it back into the pool instead of assignit to the first guy [14:22] jamespage: oh awesome, so we just need to tell charmers when you're done you're first pass to do what you just did [14:23] jamespage: what did you do> :) [14:23] jcastro, requested 'charmers' review the MP [14:23] 'Request another review' [14:25] ack, found the docs, thanks, I'll send out a reminder and probably put this in newdocs [14:25] jamespage: Big one coming up now I understand -broken/-departed hooks and can rewrite the horrible replication stuff [14:26] stub, do you want to consolidate into a single merge proposal? [14:27] jamespage: The ones in the queue will get the charm in the store actually working again [14:27] jamespage: You actually prefer big MPs to smaller bite sized ones? [14:28] stub, no - I just wanted to understand if whats in the queue is all valid [14:28] time order right? [14:29] yeah - I use a bzr pipeline so they each depends on the previous [14:30] https://code.launchpad.net/~stub/charms/precise/postgresql/charm-helpers/+merge/169487 is likely rubber stamp, a separate MP to avoid noise in actual work [14:30] https://code.launchpad.net/~stub/charms/precise/postgresql-psql/devel/+merge/169851 is teensy [14:31] https://code.launchpad.net/~stub/charms/precise/postgresql/bug-1190141-client-access-fail/+merge/169928 is also teensy and fixes the worst bug atm [14:32] yeah, nothing to be scared of yet ;) [14:32] rvba, ping [14:33] stub, there are two others in the queue [14:33] https://code.launchpad.net/~stub/charms/precise/postgresql/bug-1084263-fix-broken-hooks/+merge/169486 [14:34] no - just that one actually [14:34] https://code.launchpad.net/~stub/charms/precise/postgresql/bug-1084263-fix-broken-hooks/+merge/169486 may give you a wtf moment. I think I based my implementation on a misunderstanding. But the approach works. [14:34] There is a test infrastructure one too [14:34] https://code.launchpad.net/~stub/charms/precise/postgresql/tests/+merge/169866 [14:34] But nothing scary in there [14:35] stub, OK - I'm completely confused [14:35] :) [14:35] stub, which one should I be reviewing first? charm-helpers? [14:35] I'm not helping? ;) [14:35] Yes, charm-helpers [14:35] Ok - lemme start there then [14:36] That is just upstream code I've copied in from lp:charm-helpers [14:36] stub, yeah - I see - you sure you want to include the entire project? and not just the python package? [14:38] jamespage: I don't know if it matters. Whatever best practice is considered. [14:38] stub, not sure we have one just yet [14:39] Pulling the whole thing gets the license etc. [14:39] I know for the openstack charms we have been taking the approach of pulling in the bits we want [14:40] stub, see http://bazaar.launchpad.net/~gandelman-a/+junk/charm-helpers-sync/files [14:40] I worry that will drift... people making their own little hacks. The PG charm already contains a hacked apon copy of charm-helper's ancestor. [14:41] How does that helper help with charm-store charms? [14:41] oh, I think I see [14:42] all charm-helpers-sync does is provide a standardized way to described which bits you want from lp:charm-helpers [14:42] and syncs them into your charm [14:43] stub, I'll push adam_g to get that included in charm-helpers itself [14:43] adam_g_, nudge ^^ [14:43] Right. So I don't see any reason not to switch to that. I'll go with whatever mechanism is preferred. [14:45] stub, I'd prefer to see that rather than a sync of the entire branch [14:45] wedgwood, any opinions on the above? [14:48] A point for the whole tree is it is easier to merge fixes back, perhaps. [14:48] Nah, ignore that [14:50] * wedgwood reads backscroll [14:53] jamespage: I've been doing my best to structure charm-helpers in a way that it can be included in pieces. +1 [14:54] I envision it being packaged that way too. The cli, for example, might be a separate deb [14:59] jamespage: Pushed that update anyway. Just running the test again (soon that will be tests, plural) === defunctzombie_zz is now known as defunctzombie [15:07] <_mup_> Bug #1192598 was filed: pyjuju provision-agent hangs and fails to provision instances [15:19] wedgwood, ack === defunctzombie is now known as defunctzombie_zz [15:24] stub, guess I should review lp:~stub/charm-helpers/bug-1191002-local-unit-relation-data first as that is where you are pulling charm-helpers from [15:25] jamespage: turtles, all the way down [15:25] stub, coolio [15:29] stub, that branch also adds the data that the local unit has set on a specific relation right? [15:29] (thats the bit I did not even know you could do until last week) [15:32] jamespage: Correct [15:32] stub, OK - that works for me - do you want to rebase using lp:charm-helpers now? [15:32] I think that would be good hygiene [15:32] It has landed? Sure. [15:34] jamespage: And done === marlinc|away is now known as marlinc [15:55] charm call in 5 minutes! [15:55] jcastro: do you have the URL? [15:56] setting it up now [15:56] hey can one of you prep the etherpad for this week while I fire this up? [15:57] https://plus.google.com/hangouts/_/9d5f2933f12c69245f97d157a4c372d4d61318bd?authuser=0&hl=en [15:57] if you want to participate [15:57] http://ubuntuonair.com if you want to just listen in [15:58] jcastro, I can work on the etherpad === mgz_ is now known as mgz [16:05] http://pad.ubuntu.com/7mf2jvKXNa [16:54] stub, how worried are you about backwards compat with py-juju? === defunctzombie_zz is now known as defunctzombie [17:04] jamespage: I will be worried, at least to the extent of migrating our existing systems [17:05] stub, destroy-machines in the tests is a juju-core ish - py juju does terminate machines [17:08] right, ta. Might as well change that. === niemeyer__ is now known as niemeyer [18:14] When I have a standard require/provides relation between client_service and server_service, is it possible for a unit in server_service to retrieve relation data set by other server_service units? From the server side, relation-list only appears to list client_service units and relation-get with the other unit listed explicitly seems to be failing. [18:16] stub: I believe that's what peer relations are for [18:16] This is relation state... it doesn't fit the peer relation [18:17] stub: Units of the same service don't talk to each other (normally) when it's service -> client relation [18:17] One of server_service is a master, and creates a user and password for the clients and publishes it to the relation with the client [18:18] The other server_service units ideally will republish the same information [18:19] I'm confused as I think this worked before. It might be racy in some way though. [18:20] * stub ponders about using the peer relation as a communication channel [18:30] stub: you want relation-ids [18:30] you'll need the right ID to go along with the unit [18:32] e.g. (service a) <- myrel:0 <- database -> myrel:1 -> (service b) [18:33] hmm... maybe I'm using the wrong relation id. That would explain why it used to work. [18:54] Where were the RPM charms? I have someone reviewing now [18:54] * MarkDude knows they were done the old way with Pyju [19:00] https://github.com/jujutools/rpm-juju [19:30] Ty === terryh is now known as terryh-afk === mwhudson_ is now known as mwhudson === defunctzombie is now known as defunctzombie_zz === wedgwood is now known as wedgwood_away === defunctzombie_zz is now known as defunctzombie