[00:00] i for one think it would be awsome and probably the only project i've seen yet that it would make sense to do something like that [00:00] ok dinners calling, be back === fjlacoste is now known as flacoste [00:51] this is more of a launchpad/bzr question .. but, is it possible to checkout / branch the florence milestone? [04:24] car, florence is precise [04:24] thx [04:24] car, we keep trunk pretty stable (the ppa is a nightly build from trunk with tests) [04:25] car, there is one ugly bug in precise with local environments and restarts though [04:25] I see [04:26] bug 958312 [04:26] <_mup_> Bug #958312: Change zk logging configuration < https://launchpad.net/bugs/958312 > [04:26] else its a pretty good [04:26] cool, thx [12:12] are there any VM charms? === matsubara-afk is now known as matsubara === izdubar is now known as MarkDude [13:47] hazmat: heya [13:47] juan told me he handed over the code for the sponsorship queue over to you? [13:53] jcastro, he did [13:59] hazmat: when can we haz? I am wondering how much damage the UDS explosion left, heh [14:12] join /#ubuntu-cloud [14:13] awh... invite only [14:14] ninjix, #ubuntu-server [14:14] it just sends you to #ubuntu-server [14:14] anyways, MaaS problems? [14:15] I am testing with using a cloud-init seed iso. How do you instruct cloud-init not to look for any datasource on the post initial boot? [14:18] basically I'm want use cloud-init to rapid provision persistent machines without having to rely on PXE/DHCP/DNS etc... [14:21] hazmat: feel free to answer my question. :) [14:24] anyone have a link to a maas + juju tutorial? [14:25] https://help.ubuntu.com/community/UbuntuCloudInfrastructure#Installing_the_MAAS_server [14:25] MarkDude: hey dude, is there an equivalent of ITP bugs in Fedora? Like if I wanted to follow along your progress in a bug report? [14:26] Well 1st I talk to admin folks. [14:27] Then I will share results with juju ML [14:27] Name suggestion for the board that will apporve new charms so far? [14:27] btw i failed misseribly at making the rpm yesterday, gonna give it another go this afternoon [14:28] Fedora Unified Charms Reop [14:28] repo [14:28] FUCR [14:28] :D [14:28] lol [14:28] jcastro: thanks [14:29] We will see if that flies. I mean we created Fedora Unity, just so we could use FU at conferences [14:38] * MarkDude needs to go swear a bit. I have a computer that does everything, but , actually see the hard drive AFTER bios [15:02] jcastro, its not quite a drop in, needs some refactoring along the way. if you want a deadline, let's say monday. [15:03] hopefully sooner, but that's what i'm comfortable committing to atm [15:03] monday sounds awesome to me [16:34] SpamapS: Wanna hang out for a bit later? [16:34] I have some follow up charm workflow questions for ya [16:37] Probably the most Epic Fooball games to ever take place http://www.flickr.com/photos/imbrandon/7222206314/in/set-72157629786858262/ [16:39] Foosball [16:46] jcastro: sure let me just get through the morning email crunch :-P [16:52] \o/ [16:57] FINALY i'm ready to push the drupal charm [16:57] woot woot, time to merge and do some chovin [17:02] who's up for some bikeshedding? [17:02] we'll need a group name for the charm reviewers [17:02] I'm thinking ... ~charm-reviewers [17:02] Or, can we just reuse ~charmers? [17:03] beauticians.. snakeoil, farmers, so many possibilities [17:03] it would be great if we could get away with not having another team [17:04] jcastro, don't we already have a team for this? [17:04] * hazmat needs a mindmap of the teams [17:04] venn diagram even [17:04] we have ~charmers, which is people who have access to lp:charms [17:05] I was just wondering if we switch to this kind of review process if we need a new team, or if we can just use ~charmers, which is what we've been doing [17:05] keeping ~charmers makes the most sense to me [17:05] and if you're and ~charmers and don't want to do reviews then you can just leave the team [17:15] jcastro: we can just use ~charmers [17:15] jcastro: we would then have to subscribe the charmers to the bugs [17:17] right [17:17] ~charmers it is then! [17:20] DRAFT: https://juju.ubuntu.com/CharmsProposedProcess [17:20] SpamapS: that's basically "our process modified to be like ubuntu sponsorship" [17:27] jcastro: can charmers ever be unsubscribed from bugs in /charms ? [17:27] good question [17:27] let me try it [17:28] jcastro: looks like it can... so yeah, charmers should be fine [17:29] yep [17:29] I just tried subscribing, refreshing the bug list, and undoing that [17:29] man, this will work awesome [17:30] bzr push lp:~your-launchpad-username/charms/precise/nagios/your-branch-name [17:30] fyi, the now-out-of-context links in that page will be replaced with the big list. [17:30] s/nagios/fixed-charms-name/ [17:31] fixed [17:31] To review Ubuntu merge proposals, check out these UDD instructions. [17:31] yeah that will be replaced [17:32] ok it looks pretty good to me [17:33] ok so barring hazmat getting hit by a truck we should be good to go on this on monday [17:34] well, I mean, good for me to propose to the list for monday [17:34] SpamapS: should I modify all the bugs now? Or wait [17:34] with the subscribing, etc. [17:36] jcastro, don't forget the plane crash [17:36] jcastro: wait [17:37] jcastro: lets get the word out that the sponsorship queue will change on day X, and do it all at once. [17:50] jcastro: ok, ready to G+ in 10 [17:50] jcastro: actually make that 5 [17:53] sure! [17:53] just fire it up whenever [17:53] jcastro: SpamapS: I just looked at the proposal and it looks good to me [17:57] negronjl: hey you mentioned you wanted to try it on aws [17:57] do you have an instance up with what it looks like? [17:57] I'm curious to see how doomed we are [17:57] jcastro: I can get that done in just a minute....hold on [18:23] hazmat: wanna join us on G+? We have some queue questions [18:29] sure [18:29] uht oh :) [18:52] hi -- I have a MP that was approved, is there something else I should do? can I commit? https://code.launchpad.net/~davidpbritton/juju/dont-proxy-https/+merge/105353 [18:54] Hey can somebody review the format of this email? This is what I'm thinking of sending out to all committers to official charms next week: [18:54] http://paste.ubuntu.com/994670/ [18:55] dpb_: needs two +1's [18:55] dpb_: Its still considered "Needs review" [18:55] oh boy... thx SpamapS [18:55] dpb_: when the second +1 comes in, they will merge it for you since you're not in ~juju [18:56] dpb_: resources are a bit scarce on the review queue at the moment: https://code.launchpad.net/juju/+activereviews [18:56] SpamapS: great, I was wondering about that one. [18:56] SpamapS: ya, even for my very trivial change. :) [18:57] dpb_: indeed, yours is probably trivial enough [18:57] SpamapS: +1 on the email [18:57] negronjl: ty! [18:57] SpamapS: I have a question about it: Do we assume the new maintainer is the one with most commits or do we wait for a response before taking that action ? [18:57] negronjl: we wait [18:58] SpamapS: ok [18:58] * negronjl is out to lunch [18:58] negronjl: if nobody steps up, in about 2 weeks, we will evaluate dropping the charm or having ~charmers take temporary ownership [18:58] SpamapS: perfect [18:58] negronjl: I will send an email today that says basically "If you don't want to get nagged next week, assign yourself to any charms you are obviously the maintainer of" [18:59] * SpamapS is also out to lunch now === hspencer is now known as hspencer[afk] [19:47] Hey all -- is there any reason why stderr prints trigger an ERROR log message in juju-log? Seems like it should be informational only. (unlike a program exit, for instance) [19:55] dpb_, reported in bug 955209 - this will get fixed [19:55] <_mup_> Bug #955209: charm.log uses 'Error' for all stderr messages < https://launchpad.net/bugs/955209 > [19:56] jimbaker: sweet! thx. :) [20:56] SpamapS: i reached out to that asmi.... other cloud tool guy yesterday [20:57] he seemed very very cool and actually was JUST checking out juju and bacicly said the same thing we was about it only reversed [20:57] it was kinda funny [20:57] anyhow i think he is gonna pop in now and then and maybe collaborate on a larger "ideas" type scale [20:58] least that was what we talked about, share the pros and cons with each others approach etc etc from the get go rather than a long un-spoken silence like some rival projects [20:58] seemed really down to earth [21:01] SpamapS: is it too early to file a MIR for nginx in Q ? heh [21:20] hazmat: Hi, was there something else I needed to do for https://code.launchpad.net/~davidpbritton/juju/dont-proxy-https/+merge/105353? [21:24] dpb_, nope looks good, i'll land it [21:24] just need to get a bug in for it for the SRU process [21:24] hazmat: thx! [21:25] SpamapS, any objections to landing this one for SRU bug 993034 [21:25] <_mup_> Bug #993034: lxc deployed units don't support https APT repositories < https://launchpad.net/bugs/993034 > [21:41] <_mup_> juju/juju-status-expose-hint r537 committed by jim.baker@canonical.com [21:41] <_mup_> Adjust juju status so that exposed: false is output for a service if there are open ports but not exposed [22:08] philipballew, hey [22:09] koolhead17, hey! [22:09] not sleeping? [22:09] nopes :( === hspencer[afk] is now known as hspencer [22:09] hey hspencer :) [22:09] hey koolhead17 [22:10] hspencer, how are you doing [22:10] doin good [22:10] just workin hard [22:10] how you? [22:11] am okey not able to sleep :P [22:34] hazmat: that one is perfect for SRU [22:34] imbrandon: go ahead and file the MIR for nginx. :) [23:57] SpamapS: ping