[03:49] hi all, anyone awake? I have seen someone can live upgrade a service to a newer version and roll back [03:50] but I am not sure how to do that in the command [06:40] ahlo [06:41] what is the juju thing I been hearing about? === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [09:19] bbcmicrocomputer, nice work on the solr charm BTW [09:20] jamespage: thanks! [09:20] bbcmicrocomputer, I currently working on the lucene/solr3 packaging for quantal - will bump it up to 3.6.0 [09:20] jamespage: when I get some time, I'd love to hookup Hadoop to it, so you can use Hadoop to build your indexes [09:21] bbcmicrocomputer, that would be sweet === almaisan-away is now known as al-maisan [09:26] jamespage: the bump in package version is great .. what do we normally do with charms in such situations, do we add Ubuntu flavour logic to them so they use packages on Quantal and download on Precise? [09:30] bbcmicrocomputer, good question - charms are linked to a distro anyway so its possible to have a different charm for quantal [09:30] but it would be nice to have that as a feature in the charm - I suspect it would be quite easy to backport the package to precise anyway.... [09:31] bbcmicrocomputer, have you tried the existing solr 1.4 packages in Ubuntu? any feedback? I'd like to make the solr 3.6.0 packaging rock as much as possible [09:33] jamespage: yeah, I tried the 1.4 packages.. the charm uses its layout in most cases [09:33] bbcmicrocomputer, good - I've kept much the same for 3.6.0 [09:34] bbcmicrocomputer, I just adopted the package in Debian as it had been orphaned - hope to get the 3.6.0 version uploaded before Debian freeze this month [09:34] jamespage: in general they were good, no problems [09:34] bbcmicrocomputer, OK - well let me know if you see anything that would make deployment easier [09:34] jamespage: sure, np [09:34] bbcmicrocomputer, just out of interest does the charm use the built in solr replication stuff or the older snap* scripts [09:35] I could look but I'm feeling lazy [09:35] jamespage: built-in [09:35] jamespage: those snap scripts are .. well, a bit hacky [09:35] bbcmicrocomputer, good [09:35] it was definately old school [09:36] last big solr implementation I did that was the only option - I think it was 1.2 but I can't remember exactly! [09:36] jamespage: plus the 3.6 release they finally closed up some of the security holes regarding the select and qt= [09:36] +1 [09:36] jamespage: i.e. it's disabled by default [09:37] jamespage: which at least makes URL based password restrictions possible [09:37] jamespage: 1.2 must have been nasty, it's only really started to grow up as a project recently [09:38] jamespage: the config file itself is already a nightmare to get through [09:38] bbcmicrocomputer, yeah - I hate xml config - esp ones like solr [09:38] its really code IMHO [09:38] jamespage: yeah [13:00] jamespage: I'm starting to review your Hadoop Charm [13:01] lynxman, think the action is on me ATM [13:01] jamespage: Ah alright, I'm the reviewer for today so just starting by the newest :) [13:02] jamespage: I'll change it to work in progress then [13:05] lynxman, just pushed a new version if you want to review.... [13:06] jamespage: yay! [13:39] morning gang [13:47] m_3, g'morning [14:03] jcastro: let me know whenever you're around [14:04] m_3: morning! [14:04] hi [14:04] jcastro: hey, let me DM you [14:19] juju masters: where does juju pull the SSH key from when you run juju bootstrap? I've run ssh-keygen -t rsa, I've got the id_rsa and id_rsa.pub in my ~/.ssh directory, but when I run juju bootstrap and then juju status, I get "Invalid SSH Key" and if I access the node, ubuntu user's ~/.ssh/authorized_keys is empty. [14:19] I'm trying to understand where that node's authorized_keys file gets populated- I'm using maas as the infrastructure. [14:21] cheez0r: not sure with maas [14:22] juju usually pulls your ~/.ssh/id_rsa.pub [14:22] m_3: Do you know if juju bootstrap populates the key, or is that supposed to be done by the infrastructure? [14:23] cheez0r: lemme look [14:26] cheez0r: looks like it uses user-data for cloud-init [14:26] where is that populated? [14:27] /usr/share/pyshared/juju/providers/common/utils.py ( format_cloud_init ) [14:27] also look at cloud_init.py in the same directory... shows how it adds authorized keys to user-data [14:28] jamespage: have you talked to Mark Baker today yet? [14:28] cheez0r: I'm assuming maas provides preseed files for cloud-init... don't know though [14:28] jcastro, yep - all set [14:29] cheez0r: note that "invalid ssh key" can be a sign of something else... make sure your juju versions match [14:30] m_3: it's a freshly built infrastructure using maas, I don't think they can not match using that system, but I dunno [14:30] It apt-get updates all of the systems out of the gate [14:30] i.e., everything is using precise? you can find juju cli version with `dpkg -l | grep juju` [14:31] yes, everything's in precise. [14:31] environments.yaml has a 'juju-origin' entry [14:31] 'ppa' -vs- 'distro' [14:31] mine is set for default-series: precise [14:31] if juju-origin is not there, then it's defaulting to distro [14:31] what's your juju cli version? [14:32] 0.5+bzr531-0ubuntu1 [14:32] perms on ~/.ssh/ ? [14:32] this is definitely an issue with ssh keys not being propagated. [14:32] keys are not on the target node. [14:32] they're all fine. [14:32] ok... hmmmm [14:34] so after I bootstrap, if I manually add the key to the node, juju status still doesn't work, and I get errors "failed while receiving a server response" "server refused to accept the client" [14:35] check out the provisioning agent log maybe? probably /var/log/juju [14:36] also `ps awux | grep juju` on the bootstrap node [14:36] sorry, maas has been on my todo list... just lower on it than other stuff :) [14:36] no doubt' [14:37] is there a freenode maas channel?... lemme look [14:37] yeah, I'm on it [14:38] I'll dig and see if I can come up with anything... I think maas is not doing anything special with ssh keys (just from grepping around in juju/providers/maas) [14:39] m_3: not afaict [14:39] I think it provides a preseed file for cloud-init to read... doesn't do a live metadata service like ec2's 169.254.169.254 [14:39] that preseed file should have authorized keys to inject in the new instances [14:40] cheez0r: maybe look for that preseed file somewhere on the new instance... might be able to read it to see if authorized_keys looks good [14:41] hrm, ok [14:41] let me play. [14:41] I'll see if I can spin up some maas nodes today in kvm slices [14:42] thanks bud- I'm hammering away at a 12 node cluster that I'm trying to get running maas + juju + openstack [14:43] in the default preseed file I see no way to configure ssh keys [14:43] cheez0r: it should just create a user ubuntu with pass ubuntu [14:43] no, it should not. [14:43] it should pull my ssh public key and embed it into the bootstrapped node. [14:44] cheez0r: from there on when you mark a system to be used in juju it adds an authorized_keys file with the juju ssh key in it [14:44] cheez0r: I was still typing :) [14:44] maas default creates an ubuntu user with no password set and embeds an SSH key into the node. [14:44] so I'm thinking my problem is with maas. [14:45] cheez0r: not according to my experience, good luck though :) [14:46] well, I'm working with the maas dev guys in #maas, feel free to join us and hash it out ;) [14:47] cheez0r: good for you [14:51] lynxman: to validate, check the preseed file in /var/lib/cobbler/kickstarts/ubuntu-server.preseed at the line 'd-i passwd/user-password-crypted password !' [14:51] if it's got a bang at the end of that line, it's not setting a password, if there's a crypt string there, it is. [14:51] cheez0r: thanks [14:52] cheez0r: thats intentional [14:52] cheez0r: I've been involved in the project from the beginning and somehow that change didn't come to my attention [14:52] cheez0r: you want SSH key auth. :) [14:52] * lynxman shrugs and keeps reviewing charms [14:53] SpamapS: I do indeed, which is what I'm troubleshooting now. ;) I was ensuring I knew what I thought I did, which isn't always the case. [14:55] SpamapS: morning.... what's the new little critter's name? [14:55] cheez0r: when you use juju, maas shoves your ssh key into cloud-init [14:55] m_3: Adrian [14:55] awesome... 'grats [14:56] SpamapS: it's supposed to, but it is not for some reason. I'm trying to debug that now. [14:56] SpamapS: congrats! :) [14:56] cheez0r: you should see the results of that in the console on first boot [14:57] cheez0r: and you can always boot the box in recovery mode to look at /var/log/cloud-init-output.log [14:57] anyway.. back to baby stuff [14:59] thanks Spa [14:59] err, SpamapS [15:02] SpamapS: man, MarkBaker and James Page's webinar is already better than ours. They have cool accents. [15:02] http://www.brighttalk.com/webcast/6793/49171 [15:02] charm school! if you're interested in hanging out [15:03] lynxman: hey so on your review for the juju charm, does that mean you're going to promulgate it? [15:06] I can promulgate it as long as it's reviewed [15:06] yeah it's just not clear to me if he was finished or not [15:08] that's one that makes me wish a charm could be either standalone _or_ subordinate depending on how you wanna deploy it [15:08] jcastro: I might ask for negronjl opinion as well [15:08] jcastro: it looks brilliant to me [15:08] * jcastro nods [15:12] jcastro: I want a british accent [15:12] heh [15:13] m_3: hey don't forget puppetconf! [15:13] also I think meesh needs your oscon travel info to book your stuff [15:13] yeah, it's in email [15:13] <3 [15:13] m_3: I'm applying for puppetconf too :) [15:17] lynxman: cool [15:23] m_3: it'll be fun :) [15:24] yup [15:24] need to figure out my submission [15:44] m_3: we did a presentation last year with adam_g about juju+puppet masterless intregration [15:45] lynxman: well, and clint's charms now [15:45] m_3: maybe some more practical presentation about that? [15:45] lynxman: we have a django / summit charm that's puppet masterless [15:46] m_3: that'd be a cool one [15:46] lynxman: teyo made it clear that they wanna see us using std modules... not having to adapt them in any way [15:49] m_3: yeah but that'd be for integrating juju tighter into puppet [15:50] m_3: I reckon its still a valid demo, maybe with a twist? [15:50] yup [15:50] I'm thinking "puppet and juju... sitting in a tree" [15:50] m_3: lol, yeah [15:54] lynxman: juppetto? [15:54] we've already got jujustrano underway [15:54] m_3: even juju enterprise :D === al-maisan is now known as almaisan-away [16:02] m_3, i like the idea of standard modules. it would be a nice win if puppet actually works best when run with juju [16:02] jimbaker: yeah... it's interesting [16:03] jimbaker: so the django charm separates out an "install" manifest from a "database" manifest [16:03] jimbaker: that separation is critical to juju [16:03] jimbaker: but we'd have to see how to do that with the std puppet modules [16:04] jimbaker: perhaps there's a way we can selectively call parts of a manifest from each particular hook [16:04] dunno [16:04] jimbaker: the modules are a little more monolithic than we need... I think [16:04] gotta play with it [16:05] s/parts of a manifest/parts of a module/ [16:07] m_3, it would seem feasible given the DSL aspect of puppet [16:09] yeah, just don't know how the modules are organized [16:43] m_3, juppetto I like [16:43] :-) [16:53] juju charm review queue zero, wh00t! \o/ [16:53] you mean 5. :) [16:53] oh, refresh lag [16:53] jcastro: ;) [16:55] jamespage: that was awesome [16:58] lynxman: whoohoo! [17:00] lynxman, nice one [17:01] ta [17:03] lynxman: I didn't think apt-add-repository prompted users if executed on server environments from a script [17:09] marcoceppi: I reckon it does (found myself there) and I can't remember exactly if this was pre-precise or on precise itself so I just add -y to be safe [17:09] marcoceppi, lynxman there's a -y flag for it [17:09] that won't prompt [17:09] hazmat: that's what I recommended to use [17:09] * hazmat nods [17:09] hazmat: right, I've noticed that precise charms upgraded from oneiric work when adding ppa's without the -y flag though [17:10] Atleast in my tests, but -y is better in the long run - if that ever changes [17:12] marcoceppi: it's just to be safe, for certain [17:12] * marcoceppi nods [17:13] heya getting a weirdissue [17:13] juju deploy glance [17:14] alright reviewing queue done for today, now moving to the pub :) [17:14] * lynxman waves [17:15] says that the entry for glance cannot be found [17:17] yet I see it on jujucharms.com [17:39] EerieMok: that is strange, I get that too [17:42] Sounds like the charmstore is having issues [17:42] hazmat: ^ around? [17:43] jcastro: perhaps we should do some fake accents for our webinars? [17:43] jcastro: I'll be Austin Powers, you be Scarface [17:43] lynxman: Queue length: 0 [17:43] lynxman: NICE [17:44] me checks [17:45] jcastro, EerieMok it might not be approved [17:45] https://help.ubuntu.com/community/UbuntuCloudInfrastructure#Ubuntu_Cloud_Live_Image [17:45] charmstore publishing to the default namespace requires review [17:46] Then that tutorial is basically broken unless you do the optional step 2 xD [17:46] http://jujucharms.com/charms/precise/glance [17:46] hazmat: glance is definitely approved [17:46] that looks like the default namespace to me [17:46] SpamapS, but is it promulgated [17:46] approved, promulgated, same thing [17:46] lp:charms/glance points to it [17:47] SpamapS, so its a bug in charmstore then [17:47] There are a few other charms that are broken too [17:47] (on the charmstore) [17:48] argh [17:48] points at 'precise' [17:48] instead of 'trunk [17:48] * SpamapS throws things [17:49] EerieMok: will fix shortly [17:51] hazmat: I think we need to get jujucharms.com and the charm store to use the same algorithm [17:51] and they *both* should expose their import logs [17:53] so was the charmstore pointing to something like precise/glance/precise ? [17:54] SpamapS, fair enough.. i think two things, show a url [17:55] SpamapS, er. show the store address for it, and show if its promulgated [17:55] SpamapS, there still installable [17:55] EerieMok, you can install with cs:~charmers/precise/glance [17:55] wow glance doesn't even come close to passing charm proof [17:56] I actually just grabbed the bzr and have a local repo [17:57] SpamapS: hey so I don't think: https://bugs.launchpad.net/charms/+bug/998241 [17:57] <_mup_> Bug #998241: New Charm: keystone < https://launchpad.net/bugs/998241 > [17:57] EerieMok: thats a better choice for production anyway [17:57] IMO that should still be displayed in the queue [17:57] SpamapS, ie show it its available in the default namespace it would show cs:precise/glance ... else cs:~charmers/precise/glance [17:57] because we'd want to check on it on occassion right? [17:58] actually i can add those to the review queue [17:58] jcastro: no, I don't think so. We only want things in the queue that require action now. [17:59] ok so what happens in this case, adam says he fixed it [17:59] but doesn't change the status. [17:59] it slips through the cracks [18:00] SpamapS, anything in the default namespace that isn't installable/in the store should be in the review queue, they need attention [18:02] also found 2 with code and bugs, just not linked and not subscribed the charmers, so sorry to remove the 0. :D [18:03] lynxman: nice job getting those done though! [18:03] jcastro: haha no problem, will hammer those tomorrow :) [18:03] jcastro: just send more my way, will be glad to get them done [18:03] <3 [18:04] SpamapS: or perhaps be more explicit "Fix this and that, when you're ready for the next round flip it back to fix committed" or something [18:04] jcastro: I've told everyone to mark it as "New" again [18:04] that works [18:05] negronjl: we'll need the graphs for "time to first response" and "average queue size" eventually as well [18:06] jcastro: in the server team we do keep track of Incomplete with response bugs ... its available as a bug search. But I don't think that should be in the queue.. perhaps a separate thing.. hm.. requires thought [18:06] SpamapS: ok, we'll talk about it next call or something [18:06] adam_g: btw, I'm adding a copyright file to glance, since it doesn't have one. [18:07] * jcastro gets scared of losing contributions when people forget to flip the right switch in lp [18:08] negronjl: have you tried --ignore-warnings yet btw? [18:08] negronjl: http://paste.ubuntu.com/1029058/ [18:09] negronjl: thats options.ignore minus warnings [18:09] * SpamapS fixes in trunk [18:14] jcastro: fear isn't usually a great motivator toward excellence. :) [18:14] SpamapS: so what's the deal with glance? the stale /precise branch screwing things up? [18:15] oneiric/glance/trunk and precise/glance/trunk both look good... and lp:charms/glance points to precise/glance/trunk [18:16] m_3: I fixed it [18:16] m_3: lp:charms/glance was not pointed at the trunk branch [18:16] We really need to fix that in the charm store code [18:16] ah... oops [18:16] charm store should ignore the branch name if it has an official pointer [18:17] yeah... and/or not screw it up when upgrading series [18:17] Though the 'trunk' branch had 7 extra commits that the 'precise' one didn't [18:17] right... [18:17] all fixed now [18:17] i think the precise branch was pre-existing [18:17] but we couldn't fix at the time b/c of stacking [18:17] iirc [18:18] lynxman: you need to push to ~charmers before promulgating btw [18:18] lynxman: you now own lp:charms/juju and lp:charms/drupal6 [18:18] actually we need to make promulgate verify that [18:19] since 99% of the time we want ~charmers as the owner [18:19] there's also a nova-compute/precise branch lying around too [18:20] oh, nevermind... they're all still hanging about [18:21] hanging around is fine [18:21] being official is not ;) [18:21] right... really like to remove them though [18:21] its ok. I'm still quite certain that the charm store is useless without a way to fork the charm you've deployed. [18:21] yeah, it's good for demos... that's about it [18:22] neat trick and all, but not being able to fix the charm myself means our default deploy method is quite flawed. [18:22] ok filed bug 1010145 [18:22] <_mup_> Bug #1010145: promulgate makes it too easy to promulgate the wrong branch < https://launchpad.net/bugs/1010145 > [18:23] Like Damian from Clerks, I'm not supposed to be here today.. so.. if somebody else wants to tackle that.. that would be great. :) [18:24] yeah, I'll take a look [18:28] jcastro, SpamapS: i am at the M$ azure event all day today [18:28] oh didn't know you were there [18:28] they excited about ubuntu over there? [18:29] jcastro: i am still working on the charts. Sorry for the delay. I've been swamped [18:30] SpanapS: not sure what you are talking about re: ignore warnings [18:31] is anyone going to be at the Texas Linux Fest in Aug? [18:31] they're finally holding one in san antonio :) [18:35] SpamapS: thanks [20:05] hey folks, I'm working with a maas environment in juju, I bootstrapped the environment successfully, I deployed a bunch of charms and added relationships, but all of the agent-states in the juju status remain in 'not-started' for the nodes and 'pending' for the charms. [20:05] Any thoughts? [21:40] cheez0r, i'd suspect cloud-init is not running on them [21:40] cheez0r, same problem as you had with the bootstrap node [21:41] cheez0r, if you could pastebin the /var/lib/cloud/instance/user-data.txt from some of them that would help confirm [23:36] SpamapS, ping