[00:00] imbrandon: I'd assert the keys I trust separate from the sources.list I clone. :) [00:00] new machione ; scp source.list ; autokey; apt-get update [00:00] imbrandon: you really should be automating this.. you know.. with something like juju :) [00:00] yea i actually am [00:00] thus breaking out the old crifty [00:01] its all in ant scripts right now [00:01] so semi [00:01] but not all machines will be in the cloud :( i do my local dev vms like that [00:01] heh [00:02] <_mup_> juju/relation-id-option r518 committed by jim.baker@canonical.com [00:02] <_mup_> Fixed log assertion [00:02] imbrandon: you mean your local dev lxc containers? [00:02] :) [00:02] heh osx !lxc [00:02] awww [00:02] vmware esxi accross the room with vsphere ftw [00:03] nice beefy desktop with 5tb of sata drives filled with esx images :) [00:03] imbrandon: see, if you just used containers you could use a single machine with just a few MB and use overlayfs for testing stuff out. :) [00:04] I really want to see juju embrace that way of doing things for dev... so we can have a shared VFS and not re-do so many operations [00:04] yea but i can run osx ( leaglly and winsdows ) on vmware [00:04] as well as linux [00:04] i mean i do see the good parts [00:05] but there is parts i would have to replace othher ways [00:05] i use my osx vm's to test app store apps before i submit them [00:05] :( [00:05] imbrandon: I think we'll always see other OS's in vms. But you were, I thought, talking about Ubuntu server dev. [00:05] yea ... i r lost [00:06] i'm thinking i can probablt slipt up the esx machine though [00:06] easy i dont nearly use all of it [00:06] and have esx run as a dom [00:06] err xendom [00:07] then the rest be one beefy ubntu server [00:07] with lxc containers [00:07] like a vm inside a vm inside a lxc , i'm gonna need a lot of lsd to figure that all out [00:08] * imbrandon hrm [00:09] SpamapS: yea i was talking about ubuntun server dev, i did one of those assume things again and assumed you magicly knew what hardware i was working with localy :) [00:13] right now my setup is as follows, 4x 1024 linodes ( that will likely go away to aws or hp cloud ) , 2 aws micros for misc cruft reimaged often , my mac mini thats my main pc , mac book pro that never gets turned on , small ubntu file server running on a 1ghz via cpu with 4 1tb hdd raid 5'd for like my mp3s and crap , and then a beefy desktop i forget specs but core i3 dual core with 8gb ram running esxi with all my "dev" vm's that i connect to wi [00:13] :) [00:14] desktop is headless , basicly a poorman server [00:14] 3tb for mp3s.. thief. ;) [00:15] heh and movies and misc ( aka pr0n ) haha ok no pr0n [00:15] ok, time to EOD for me.. [00:15] but. .later tonight.. I swear I'll do some charm review/feedback :-P [00:15] heh kk, taker easy man [00:15] crazy week. :-P [00:15] :) [00:15] half sec, check this [00:16] @zeus:~$ ls -l Music/|wc -l [00:16] 39926 [00:16] not tooo many :) [00:16] SpamapS: ^^ [00:17] $ find ~/Music -type f | wc -l [00:17] 940 [00:17] not enough [00:17] heh www.bobs-library.com [00:17] but.. thats pretty much all the songs I actually like and listen to .. and you know.. *paid for* ;) [00:17] ( thats my step dads website, has all my music on it too ) [00:18] if you want when you get $home , i'll give you a user/pass [00:18] home? [00:18] I work at home [00:18] its time to LEAVE home :) [00:18] i tossed it up and it makes list from cron [00:18] ahhh :) [00:19] imbrandon: no thanks, I'll stick to a system that compensates artists kthxbai. :) [00:19] forgot about that, used to ppl leaving the house that i tlak to lol, but yea i know that feeling , been working from home a few years now [00:19] SpamapS: i buy 99% of it [00:19] :) [00:19] and videos [00:19] and extended albums [00:19] like for real [00:20] and yes, I'm a prick about this. Ignore me. [00:20] i probably spend more money on music and ebooks than most on $tv + other entertain [00:20] as that is most of my enterain :) [00:20] no i hear ya, i make a good little income on the side from app store, so i know the feeling [00:21] thus passwd protected site and limited few get the credentials :) [00:21] but i do share a bit , but i thinks thats ok imho [00:21] a LITLLE [00:21] not with the internets [00:22] ya know ;) [00:22] but yea the little i have thats not paid for is either crap that wasent released or way way way back on the orig napster i probably have a dozen or so tracks left misxed in [00:23] mixed* [00:56] * imbrandon forgot that all his tunes are in iTunes Match cloud too, soo they have to be legit or apple gets nasty with ya :) [00:56] SpamapS ^ :P [01:03] ohhh http://blog.openwebosproject.org/ <-- posted 1 day ago, opening up all of webos, already realeased some major componets of it 2 hours ago ( just seen on twitter ) ... hrm [01:22] marcoceppi: https://build.hpcloud.com/cli/unix rubygem , looks to be their awnser to s3cmd [02:28] <_mup_> juju/relation-id r498 committed by jim.baker@canonical.com [02:28] <_mup_> Merged trunk [02:46] <_mup_> juju/relation-id r499 committed by jim.baker@canonical.com [02:46] <_mup_> Fixed patch issues [03:03] imbrandon: cool [03:04] marcoceppi: need a guiney pig or help lemme knw, i havent got to that omg stuff yet but i'll likely do it sometime tonight and just leave ya a note for whenever you get time [03:05] unless joey put all the keys on like jcastro mentioned and i can just update stage, whatever however [03:05] There's no joey account yet, and no staging yet [03:05] ahh i thought staging was pointing to some micros [03:07] u get some hp glue happenin and we'll toss it there ( staging ) heh [03:34] <_mup_> juju/relation-hook-context r515 committed by jim.baker@canonical.com [03:34] <_mup_> Merged trunk, resolved conflicts, and updated for subordinate support [04:23] <_mup_> juju/relation-hook-context r516 committed by jim.baker@canonical.com [04:23] <_mup_> More subordinate fixes [04:34] <_mup_> juju/relation-hook-context r517 committed by jim.baker@canonical.com [04:34] <_mup_> Return internal relation and scope [05:11] ok question [05:11] I've been following this guide: http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage [05:12] yet I'm unable to connect via browser to the public-address [05:12] ping'ing the address shows it unreachable [05:12] any ideas what could be up? [05:17] <_mup_> juju/relation-hook-context r518 committed by jim.baker@canonical.com [05:17] <_mup_> Fix remaining failing test (due to cached relation hook contexts requiring a complete topology) [05:53] SpamapS: hahah i forgot too, part of my cron ( php cli app ) that builds out the site for that music also makes cache files ( two of them ) per mp3, one _filename_.json with the id3 meta data and one _filename_.serial with php binary serialized data , so my website can not do any mp3 reading at runtime and use the id3 json easy in javascript and and php can also load the object back up just one at a time to play ( flash player ) and show other det [05:53] tl:dr , there was only 1/3 actual media in that dir the more i thought aobut it :) [05:56] <_mup_> juju/relation-ids-command r509 committed by jim.baker@canonical.com [05:56] <_mup_> Merged upstream [05:57] <_mup_> juju/relation-id-option r519 committed by jim.baker@canonical.com [05:57] <_mup_> Merged upstream & resolved conflict === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === zyga is now known as zyga-afk === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [11:39] Hi, I'm trying to set up the openstack environment in my own private cloud for juju. I'm able to start/stop instances through openstack-dashboard and also log into those without problems. But I'm for now failing at making juju bootstrap an instance so the juju environment can get up and running. I get "2012-03-30 13:35:42 ERROR nova.api.ec2 [-] Unauthorized: Not Authorized" === zyga-afk is now known as zyga [12:24] sc-rm, have you set "access-key" and "secret-key" in your environments.yaml (or set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in your environment)? [12:25] sc-rm, and also made sure you have the correct "ec2-uri" and "s3-uri" in your environments.yaml? [12:35] fwereade_: openstack: [12:35] type: ec2 [12:35] default-instance-type: m1.small [12:35] control-bucket: juju-openstack-bucket [12:35] admin-secret: my_password [12:35] ec2-uri: http://172.16.0.184:8773/services/Cloud [12:35] s3-uri: http://172.16.0.184:3333 [12:35] default-image-id: c4e58b59-80e1-4e92-9479-d3be7135b826 [12:35] access-key: admin:novaproject [12:35] secret-key: f1405188-3bdf-4058-be45-ecf9e607a13f [12:35] default-series: precise [12:36] where 172.16.0.184 is the ip of the cloud controller [12:37] sc-rm, hm, nothing springs to mind -- would you try a "juju -v bootstrap" and pastebin me the result? [12:38] fwereade_: http://pastebin.com/XXuXszYk [12:41] sc-rm, hmm, so it's the security groups it won't let you see [12:42] sc-rm, can you run euca-describe-groups with those credentials? [12:43] fwereade_: no [12:43] brb [12:43] sc-rm, hmm, that would seem to be the problem then... but I'm not sure where to go from here [12:47] sc-rm, I think yu may need to give yourself the "netadmin" role [13:06] sc-rm, have you tried the nova client tools? === almaisan-away is now known as al-maisan [13:07] sc-rm, it sounds like a problem with your keystone auth setup [13:07] hi al-maisan [13:07] hello hazmat [13:09] fwereade_, i think that's just the first ec2 api used for bootstrap, its not clear the endpoint is wired up to the auth mechanism [13:09] al-maisan, re euro py.. what'd you have in mind for your talk? [13:10] hazmat, ah, could be [13:10] hazmat, I'm not really familiar with openstack tbh [13:10] hazmat: I thought of giving an intro, a quick comparison with AWS SWF and a simple example [13:14] b [13:15] hazmat: I'm able to start instances through openstack-dashboard(horizon) [13:15] al-maisan, doing a high - low split sounds good.. there's some chance i may have to bow out. [13:15] fwereade_: so a new role in keystone called netadmin? [13:16] sc-rm, I may be wrong, I was just looking at the docs myself: http://docs.openstack.org/cactus/openstack-compute/starter/content/Network_Administrator_netadmin_-d1e2232.html [13:16] sc-rm, right but the cli nova client / or eucatools are a closer to juju usage validation [13:16] hazmat: hmm .. I see, so I'd stick with what I've outlined above and you can give the advanced presentation if things work out for you [13:17] al-maisan, sounds like a plan [13:17] hazmat: great :-) thanks for touching base! [13:17] al-maisan, i'll see if i can clear up my attendance soon to not split the vote [13:18] sc-rm, ...and, yeah, looks like I'm wrong, the admin role should be able to mess with security groups according to http://docs.openstack.org/cactus/openstack-compute/starter/content/Tabular_representation_of_Roles-d1e2292.html [13:21] fwereade_: okay, is there any log on the cloud-controller where I'm able to see some information about where it tries to validate my credentials? [13:21] sc-rm, ...no, it's a little murkier than that, the "cloudadmin" role can do anything; "sysadmin" can start/stop machines; "netadmin" can change firewall rules [13:23] sc-rm, hmm, maybe try something like: [13:23] sc-rm, `nova-manage role has --user=novaadmin --role=cloudadmin` [13:23] sc-rm, `nova-manage role has --user=novaadmin --role=netaadmin` [13:23] sc-rm, but with the appropriate --user [13:25] hazmat: cool, it would be nice to meet in Florence nevertheless :-) [13:25] fwereade_: it returns false, so I guess that is the problem, I'll try to add the roles to the admin user [13:25] sc-rm, cool [13:26] sc-rm, `nova-manage role add --user=novaadmin --role=netadmin` [13:29] fwereade_: now the above commands return true, but still no luck in do euca-describe-groups [13:29] sc-rm, bother :( [13:30] fwereade_: yep ;-) but will find the problem anyhow [13:30] hazmat, what was that you were saying about wiring the endpoint up to the auth mechanism? [13:56] fwereade_: I figured it out now, so juju is able to create instances, the trick was to go to the dashboard -> settings -> ec2 credentials -> download and use that access-key and secret-key instead. [13:57] sc-rm, awesome :D === al-maisan is now known as almaisan-away [15:14] hey.. ~charmers.. wtf.. you guys left me no charms to review. ;) [15:14] *NICELY DONE* [15:16] SpamapS, lol [15:17] lol [15:19] attention Juju distro version users.. new, incompatible version landing in precise [15:20] SpamapS: does it affect PPA users as well? or is this just a "We're catching the distro package up"? [15:22] SpamapS: you mean the PPA version is getting sync'd, right? [15:23] robbiew: right [15:23] PPA users will be completely unaffected [15:23] meh...welcome to beta! [15:23] SpamapS: were you around when we switched to upstart...that was at a beta too :P [15:24] talk about new and incompatible [15:26] * SpamapS spit takes [15:26] what? [15:27] robbiew: I joined at UDS-M (and wa a Debian person before that .. ;) [15:27] so you missed it [15:27] it was awesome...we broke everything! [15:28] lol [15:31] robbiew: *nice* [15:32] robbiew: was that the karmic upstart change, or the hardy upstart change? IIRC there were two big shifts [15:32] karmic [15:32] gents, I need to be off early, I'll probably pop back in later [15:32] hardy was just introducing it...karmic is where we actually went to using it with force [15:32] of course that was only desktop...server was ignored [15:33] and paid the price...but you know that ;) [15:33] robbiew: *obviously* ;) [15:33] the chroot issue is still quite troubling actually.. [15:33] even with chroot support, people can't run Ubuntu in a chroot from a non-Ubuntu system. [15:34] "people can't run Ubuntu in a chroot from a non-Ubuntu system" [15:34] that last part is their problem [15:34] :P [15:34] zzzzzzzzzzzing! [15:34] also you can't run Ubuntu in an lxc container that is not network namespaced [15:35] Which would have been quite nice for us to be able to use LXC in juju w/o the network complexity [15:35] (don't worry I intend to suggest this as a feature for 12.10 :) [15:41] how do charmers feel about using the HEAD of the master branch of an upstream project in a charm? [15:41] etherpad-lite is currently bust as 1.0 wants nodejs 4 and npm 1.x but thats not a happy pairing anymore [15:42] current dev is good with nodejs 6 + npm 1 from the PPA we are all using.... [15:44] jamespage: HEAD is a bit aggressive, I'd love for that to just be an option, but pick a tag by default [15:44] SpamapS, I'll give upstream a poke and see when the next release is due [15:44] jamespage: for exactly the reason you're seeing.. integration is hard, mmmkay :) [15:45] SpamapS, I may be able to kludge 1.0 to work as well [15:45] jamespage: I've been messing with a charm called 'extrappa' that I splice onto my other charms to test things with different PPA's enabled. [15:46] jamespage: It might be interesting to use that to test charms w/ newer versions of stuff [15:46] tho this seems like the other way around [15:49] SpamapS, I think I'll pick a know good commit for the time being [15:53] jamespage: do they not use tags? [15:53] .. juju doesn't either.. ;) [15:53] SpamapS, they do - but they only have "1.0" which is now 7 months old [15:54] SpamapS, going to make it a config parameter to make it easier to change later [15:54] or for people to tweak if they are brave :-) [15:56] jcastro, did you hear anything back from the chris lea (guy who owns the nodejs PPA's we seem to be preferring?) [16:10] jamespage: I think you might also consider just making the node PPA the default [16:11] SpamapS, for etherpad-lite? yes absolutely [16:12] jamespage: from what I saw, npm is totally broken and dead in older releases of Ubuntu/Debian anyway [16:12] SpamapS, it is in the current dev release of Ubuntu/Debian [16:13] SpamapS, the debian maintainer has stuff in pipeline [16:13] but the upstream release pace is very fast IMHO [16:13] reminds me of working with jenkins [16:15] jamespage: btw, great quote from Jay Pipes last night at the OpenStack LA meetup. "[Jenkins] is like a suped up cron." [16:15] SpamapS, that is spot on [16:15] with green balls :) [16:15] cron with 200 x the memory footprint at least! [17:35] <_mup_> juju/relation-id r500 committed by jim.baker@canonical.com [17:35] <_mup_> Minor docstring update [17:46] beginning of relation-id support is now in trunk - 3 more branches to get approved [17:52] jimbaker: woot [17:53] heh.. [17:53] dang, looks like I've got to flush and rebuild the lxc cache nightly for local charm testing [17:53] its going to get ugly when we add the next feature to charm API and there's no --version .. [17:53] it's getting... stale [17:53] +1 for somebody to add --version [17:54] what we really need is 'charm-api-version' so conditional logic can be used in charms [17:54] it doesn't even require hard versioning... just spit out what it can... bzr480 is perfectly fine imo [17:54] m_3: hrm, I'd like to see us actually version the charm API [17:55] we've had other problems than just charm api [17:55] but ok [17:55] I'd really like the api between the juju cli <-> juju bootstrap node to be versioned [17:55] that's bitten me hard before [18:09] m_3: that is versioned since its basically the schema [18:10] What do we use "s3" for and what's the benefit of having a storage bucket vs just having that information on the bootstrap? [18:16] marcoceppi: storing charms and the "map" that clients use to find the ZK node [18:16] marcoceppi: in orchestra we *do* store these things on the bootstrap node. [18:17] marcoceppi: and the local provider as well. Just not on EC2.. since S3 simplifies things [18:17] SpamapS: so, if a provider didn't have an S3* like cloud, it could be setup to use the bootstrap? [18:17] marcoceppi: we'd have to rewrite code in the ec2 provider to make that work, but yes [18:17] marcoceppi: you'd need to have a way to find the ZK node. [18:18] marcoceppi: in orchestra, the orchestra-server env setting is used (and maas-server in maas) [18:18] marcoceppi: but in a cloud.. that address is harder to predict. :) [18:19] I see, I was referring to a provider that wasn't a traditional EC2-like provider, I imagine they would need to code their own provider code [18:20] Like, at POSSCON we chatted with the Linode guys and their API, they have a bit of a different setup though on how they manage their "VPS" servers [18:21] So, right away I noticed a few things that wouldn't jive right, was trying to figure out what it would take if someone were to write provider code for Linode [18:26] marcoceppi: the API needs some place where admins can agree to share a map to the zookeeper node. [18:28] marcoceppi: if linode has some way of tagging VMs, that works [18:40] argh.. why do we try to mkdir ~/.juju with --help [18:40] yikes [18:40] yeah, silly [18:42] makes it so we can't use help2man to generate man pages for juju [18:43] * SpamapS monkey patches [18:44] oh what a mess [18:44] env config is used to set defaults for the parser [18:53] wow.. this sucks [18:53] can't push the default config out of "~/.juju" [18:53] so cannot run --help without a writable ~ [18:53] which means, cannot run --help during package build. :-P [19:02] SpamapS, it can solved with another layer of indirection [19:02] SpamapS, what's the goal? [19:03] hazmat: run --help without trying to write to the filesystem [19:04] hazmat: buildds run as a user which has no home dir [19:04] hazmat: help2man will run 'juju --help' and parse that into a nice man page [19:04] SpamapS, gotcha [19:05] SpamapS, and you can have it generate the aggregate from all the subcommands? [19:05] hazmat: since --help is generated from the parser object, which needs the environments for some defaults.. (IMO, the wrong layer to do that..) this is not so simple. :( [19:05] or just the top level? [19:05] hazmat: no, that would be the bomb, but for now, I'm happy with a singe man page just listing the subcommands and a link to the docs [19:05] hazmat: I can get it to generate a man page per-subcommand tho [19:06] hazmat: and probably from that, I can squish them all into one. :) [19:06] but.. baby steps [19:06] first.. have to be able to run --help without a homedir [19:06] SpamapS, un momento [19:06] anyway, have an appointment.. bbiab [19:07] SpamapS, this solves that.. http://paste.ubuntu.com/907710/ [19:08] i'll commit the fix to trunk [19:12] <_mup_> juju/trunk r508 committed by kapil.thangavelu@canonical.com [19:12] <_mup_> [trivial] juju only initializes the sample when given a command, post cli parsing [21:52] hazmat: thanks btw! :) [21:54] hazmat: did you forget to bzr push ? [22:05] hello [22:05] for some reason I'm unable to do juju status without it timing out [22:05] shazzner: how's it going? :) [22:05] oh, so.. not awesome :P [22:06] SpamapS: good, back with more problems :p [22:06] shazzner: what provider? [22:06] local [22:06] shazzner: did you reboot? [22:06] shazzner: reboot == dead local provider environments [22:07] oh [22:07] haha [22:07] that blows man! [22:07] ok I'll rebootstrap :) [22:07] https://bugs.launchpad.net/ubuntu/+source/juju/+bug/955576 [22:07] <_mup_> Bug #955576: 'local:' services not started on reboot < https://launchpad.net/bugs/955576 > [22:07] ah [22:07] shazzner: /win 10 [22:08] hah doh [22:08] SpamapS: thanks :) [22:08] shazzner: there are > 100 bugs that need love.. ;) [22:09] I wish I could help with them, I'd only introduce worser bugs :p [22:30] hazmat: that patch breaks a test [22:31] hazmat: http://paste.ubuntu.com/907956/ [22:31] hazmat: very easy fix [23:05] SpamapS, huh.. yeah.. that's what i merged to trunk [23:06] except i used ['bootstrap'] [23:06] hazmat: you never pushed [23:06] oh.. right.. i forget i unbind'd on the checkedout [23:06] hazmat: I chose status since it is the most benign command. ;) [23:07] SpamapS, fair enough.. i choose boot as benign initial command [23:07] well not benign [23:07] SpamapS, its pushed [23:28] hazmat: cool. I'll pick it up on the next (hopefully final) upload of juju to precise ;) [23:58] <_mup_> Bug #969706 was filed: juju.unit.tests.test_workflow.UnitRelationWorkflowTest.test_depart_hook_error non deterministic behavior < https://launchpad.net/bugs/969706 >