[02:35] <enmand_> Is there a default charm repository installed with Juju on Oneiric?
[02:36] <enmand_> Or does it rely on store.juju.ubuntu.com? (Which doesn't seem to exists?)
[06:37] <hazmat> enmand_, there are local repos
[06:37] <hazmat> in oneiric ootb
[06:40] <SpamapS> hazmat: backportpackage can fix that btw
[06:41] <SpamapS> hazmat: I actually just finished backporting the oneiric txaws to ppa:clint-fewbar/fixes
[06:46] <SpamapS> hazmat: the whole dh_python2 mess does make things hard to backport tho
[07:26] <eagles0513875> hey guys
[07:26] <eagles0513875> where can i see what charms are available in the juju repo
[08:10]  * eagles0513875 waves to fwereade in here :)
[13:16] <enmand_> hazmat, where are the local repos in Oneiric? Are they in a package besides juju?
[16:16] <m_3> hazmat: try logging out of the labs webpage and log back in
[16:18] <m_3> Ryan_Lane: euca-run-instances -k wmflabs-mmm-20111016 -t c1.medium ami-00000004
[16:22] <Ryan_Lane> hazmat: what error are you getting when trying to log into canonical-bridge?
[16:23] <SpamapS> enmand_: there's a package in ppa:juju/pkgs called 'charm-tools' that will include a command, 'charm getall'
[16:23] <SpamapS> enmand_: it uses bzr to checkout all of the charms from https://launchpad.net/charm
[16:26] <enmand_> Ah, OK
[16:26] <enmand_> So, there is no default charm set for Oneiric?
[16:27] <m_3> SpamapS: morning
[16:33] <m_3> SpamapS: is it easy to enable lp review features for lp:charm?
[16:36] <Ryan_Lane> heh. I figured it out
[16:36] <Ryan_Lane> bad config
[16:36] <Ryan_Lane> I'm working on fixing it
[16:42] <Ryan_Lane> if puppet will ever actually run :(
[16:46] <Ryan_Lane> m_3: it's working now
[16:48] <SpamapS> m_3: enable them? err.. they're built in to it.
[16:50] <SpamapS> m_3: what features are you looking for?
[16:52] <m_3> SpamapS: just a +1 from anyone in charmers before promulgation
[16:53] <m_3> I guess the lp review stuff comes automatically with merge proposals
[16:53] <m_3> SpamapS: but we don't have such things for charms atm
[16:55] <m_3> SpamapS: (features like submit for review, pending review state, pending review queue for charmers, etc)
[16:56] <m_3> Ryan_Lane: testing now...
[16:56] <SpamapS> m_3: well if we were more careful and didn't just push to lp:charm/foo then we could use reviews
[16:57] <SpamapS> charm-tools still uses bound branches.. which it probably shouldn't.. :-P
[16:57] <SpamapS> m_3: the review stuff is easily enforcable by policy
[16:57] <Ryan_Lane> and I confirmed, if you log out and log in, it changes your access and secret key
[16:57] <Ryan_Lane> working on fixing that now
[16:58] <m_3> SpamapS: gotcha... can we do this alongside "charmstore" landing?
[16:58] <m_3> Ryan_Lane: gotcha
[16:59] <m_3> Ryan_Lane: s/euca-run-instances/euca-ran-instances/ !
[17:00] <SpamapS> m_3: the charm store stuff I don't know about.. but if bzr branches are in use, the review stuff is built in
[17:00] <Ryan_Lane> sweet
[17:00] <m_3> SpamapS: cool
[17:01] <m_3> total "Dude, where's my car?" moment :)
[17:02] <SpamapS> m_3: I believe the charm store bits will always push to a personal branch... but I really don't know
[17:02] <SpamapS> NO WHAT DOES IT *SAY*
[17:02] <SpamapS> ;)
[17:08] <hazmat> the use of bzr in the charm store will be transparent
[17:09] <hazmat> Ryan_Lane, for some reason i get .. Permission denied (publickey).
[17:09] <hazmat> on ssh attempts
[17:10] <Ryan_Lane> hmm
[17:11] <hazmat> Ryan_Lane, i had a look from m_3's login shell it all looks normal
[17:11] <Ryan_Lane> lemme look at logs
[17:11] <Ryan_Lane> Invalid user kapil from 12.70.135.2 ;)
[17:11] <hazmat> RoAkSoAx, never mind
[17:11] <hazmat> Ryan_Lane, yeah.. just saw that
[17:11] <hazmat> doh
[17:11] <hazmat> user fail ;-)
[17:11] <Ryan_Lane> :D
[17:12] <Ryan_Lane> your novarc is likely broken too
[17:12] <Ryan_Lane> lemme fix the problem I'm having, and fix that for you
[17:12] <hazmat> Ryan_Lane, oh? yeah.. i'm unable to connect to the swift storage it seems
[17:12] <Ryan_Lane> swift storage?
[17:12] <Ryan_Lane> we don't have swift storage
[17:13] <Ryan_Lane> but your access and secret keys are bad
[17:14] <hazmat> Ryan_Lane, oh.. is there a s3server (from nova) running?
[17:14] <Ryan_Lane> ah
[17:14] <Ryan_Lane> only if that's the object store
[17:14] <Ryan_Lane> and that would be glance
[17:14] <Ryan_Lane> err
[17:14] <Ryan_Lane> wait. no
[17:14] <Ryan_Lane> glance is just for service images
[17:14] <hazmat> glance is the image store, it layers ontop of the object store
[17:14] <Ryan_Lane> we have no object store
[17:15] <Ryan_Lane> no volume support right now either
[17:15] <Ryan_Lane> did you guys need volume support for this?
[17:15] <hazmat> Ryan_Lane, that's problematic for juju, we use the objectstore to distribute charms to the instances.. nova include a very simple s3server that just stores things in a directory
[17:15] <hazmat> Ryan_Lane, we don't need the volume support
[17:16] <hazmat> its nice to have, but not required, the object store is
[17:16] <Ryan_Lane> they got rid of the objectstore in cactus, I believe
[17:16] <Ryan_Lane> ah. wait
[17:16] <Ryan_Lane> there's a nova-objectstore package still around
[17:16] <Ryan_Lane> gimme a sec
[17:17] <hazmat> Ryan_Lane, its in the source tree at nova/objectstore/s3server.py
[17:17] <Ryan_Lane> yep
[17:17]  * hazmat updates his branch
[17:17] <Ryan_Lane> I didn't have the package installed
[17:17] <Ryan_Lane> it's now on virt1
[17:18] <hazmat> Ryan_Lane, cool.. currently the generated novarc are referencing a dead s3 server url .. do you know what the correct one is/will be?
[17:18] <Ryan_Lane> it's correct now
[17:19] <Ryan_Lane> I just brought the service up
[17:19] <hazmat> Ryan_Lane, awesome thanks
[17:19] <Ryan_Lane> yw
[17:19] <Ryan_Lane> lemme know if it has any issues
[17:19] <Ryan_Lane> I need to fix your credentials, likely
[17:20] <hazmat> Ryan_Lane, yeah.. that seems to be the remaining issue
[17:20] <SpamapS> hazmat: btw, I tried txaws against ceph's RADOS .. worked well except creating buckets.. but I think that may have been a lighttpd fail, not RADOS
[17:21] <hazmat> SpamapS, nice
[17:21] <hazmat> SpamapS, is there a charm for that?
[17:21] <hazmat> ceph that is
[17:21] <SpamapS> hazmat: yes, the ceph charm
[17:21] <SpamapS> but its kind of.. in flux. ;)
[17:21]  * hazmat checks charm world
[17:22] <SpamapS> Should work for a single node, or 3 node cluster. The difficulty is elasticity.. ceph is just growing things to make that easy
[17:22] <Ryan_Lane> hazmat: I need to fix the code that keeps changing your credentials, then I'll fix your credentials. heh
[17:22] <hazmat> Ryan_Lane, sounds good
[17:23] <hazmat> SpamapS, fair enough.. i'd prefer gluster for most distributed fs usages now.. i still think of ceph as more on the experimental side
[17:23] <hazmat> ie. only widely deployed by its creating org
[17:24] <SpamapS> hazmat: the CEPH guys would agree for the mounted FS case. But their objectstore is apparently already seeing extremely heavy use.
[17:24] <hazmat> SpamapS, outside of dreamhost?
[17:24] <SpamapS> hazmat: no
[17:24] <SpamapS> :)
[17:24] <hazmat> which has a team of 40 devs to support it ;-)
[17:24] <SpamapS> er, I think its closer to 4
[17:24] <hazmat> oh.. gustavo mentioned they where hiring like crazy for it
[17:25] <SpamapS> hiring and having are two different things. :)
[17:25] <SpamapS> They've only just recently starting treating CEPH as more than an experiment
[17:26] <SpamapS> Honestly, with storage, I'm not sure super automatic elasticity is all that awesome of an idea.
[17:26] <SpamapS> if your CPU bound thing has a problem coming up or down, oh noes, it goes slower
[17:27] <SpamapS> if your I/O bound thing loses data... you are screwed
[17:27] <SpamapS> So I may just make the ceph charm deploy ceph and build the config file, but let admins do the work of adding/removing nodes
[17:31] <hazmat> ah.. charm world doesn't pick it up because its not a trunk branch
[17:32] <hazmat> we'd have to introduce an extra namespace layer to allow for deploying charm branches
[17:33] <SpamapS> no don't do that ;)
[17:33] <SpamapS> I forgot I haven't promulgated it yet
[17:33] <SpamapS> Because its changing a lot
[17:34] <m_3> SpamapS: do you have an environments.yaml entry from openstack?  i.e., wanna see the s3-uri for the nova objectstore
[17:35] <SpamapS> s3-uri: http://x.x.x.x:3333
[17:35] <hazmat> m_3, the one in my home dir should be fine
[17:35] <m_3> SpamapS: does it require additional path like /services/Eucalyptus does?
[17:35] <hazmat> on the gateway
[17:35] <SpamapS> no path specified at all in mine
[17:35] <m_3> gotcha... cool... just checking we're trying to call the right thing
[17:35] <m_3> it
[17:36] <hazmat> m_3, its a credential problem
[17:36] <m_3> hazmat: right
[17:39] <SpamapS> mo credentials, mo problems
[17:42] <SpamapS> man, I need a giant RAM disk to do local deploys on
[17:43] <m_3> SpamapS: dude, local deploys rock!
[17:43] <SpamapS> Yeah, but now that I don't have to wait for amazon..
[17:43] <m_3> but yeah, dualcore/8G on the laptop doesn't cut it
[17:43] <SpamapS> I have to wait for my local disk
[17:44] <m_3> I know
[17:44] <m_3> it's always something
[17:44] <SpamapS> If I had 8G I could make 4G for deploys :)
[17:44] <m_3> wanna replace my cd-rom with SSD
[17:44] <SpamapS> I've been shopping for SSD's for that very reason.
[17:44] <m_3> there's a kit for that in the mbp
[17:45] <SpamapS> Maybe I should enable write caching on my laptop disk
[17:46] <SpamapS> that actually helps quite a bit. :)
[17:47] <SpamapS> just have to remember to turn it off after deploy ;)
[17:48] <m_3> http://virt1.wikimedia.org:3333/
[17:48] <m_3> shows that we can create the bucket at least
[17:49] <hazmat> SpamapS, it doesn't take that long for local deploys.. its mostly just the package install, ssd make it rock... i'm still waiting for a native 7mm ssd to come on the market
[17:49] <SpamapS> hazmat: but then you're shortening your SSD's life
[17:50] <hazmat> SpamapS, not concerned, i got it to use it ;-)
[17:50] <m_3> http://pastebin.com/EUaafbPA
[17:51] <SpamapS> Hrm.. I dunno. at $500 for a big one.. I want to use it for more than a year. :-P
[17:51] <m_3> grabbing food for a sec
[17:51]  * SpamapS is now wondering if his assumptions of endurance are false tho
[17:51] <hazmat> SpamapS, the wear level is pretty good on the devices, and the sandforce controllers are pretty awesome about dedup
[17:53] <SpamapS> ok, so most can sustain 20GB/day for 5 years
[17:54]  * SpamapS is ordering now.. F'it
[17:57] <hazmat> SpamapS, just make sure your compatible size wise with your laptop
[17:57] <SpamapS> ta
[17:58] <Ryan_Lane> hmm. the only thing that I see so far that'll deliver a 403 is if the object already exists
[17:59] <SpamapS> hazmat: yeah I've been looking into it
[17:59] <Ryan_Lane> yeah. it'll only give a 403 if the file or directory exists
[17:59] <Ryan_Lane> did you guys do a test write into the file you need to create with juju?
[17:59] <Ryan_Lane> err. object
[18:00] <Ryan_Lane> odd. it's giving a 405...
[18:00] <Ryan_Lane> I don't even see that in the code
[18:01] <hazmat> Ryan_Lane, i'm still getting errors on auth.. 405 might be coming from pylons
[18:04] <SpamapS> hazmat: btw, ceph is now the second time where I have 'relation-set' the base64 of a file on disk.. I wonder if we can't get a 'relation-file /etc/hosts' to make sharing files easier
[18:06] <Ryan_Lane> hazmat: errors on auth where?
[18:06] <Ryan_Lane> to nova?
[18:06] <hazmat> Ryan_Lane, to s3server
[18:06] <Ryan_Lane> ah. right
[18:06] <Ryan_Lane> yeah
[18:06]  * hazmat checks if novarc has changed
[18:07] <Ryan_Lane> oh. wait
[18:07] <Ryan_Lane> let me fix your secret and access keys
[18:08]  * m_3 looks for variation of s3cmd that'll work with nova object-store
[18:08] <hazmat> Ryan_Lane, cool thanks
[18:08] <SpamapS> m_3: it works fine but you have to skip verifying your settings and manually edit the config
[18:09] <SpamapS> m_3: ~/.s3cfg .. its obvious where to change the hostnames
[18:09] <m_3> SpamapS: thanks
[18:09] <SpamapS> m_3: note that txaws comes with some handy commands for using S3
[18:10] <Ryan_Lane> hazmat: heh. seems your keys are fine
[18:10] <Ryan_Lane> pylons giving back 405?
[18:10] <hazmat> hmm
[18:10] <Ryan_Lane> I dunno what that is
[18:12] <hazmat> http://pastebin.com/8PrAvyCf
[18:13]  * hazmat tries with s3cmd
[18:13] <hazmat> m_3, its a hidden option only in the config file of s3cmd
[18:15] <hazmat> Ryan_Lane, it seems to be fine manually... i'll dig into debugging it
[18:15] <hazmat> oh
[18:15] <hazmat> that's the problem
[18:15] <Ryan_Lane> ?
[18:15] <hazmat> me and m_3 are probably using the same bucket ;-)
[18:16] <m_3> oh no way
[18:16] <hazmat> hmm
[18:16] <hazmat> nope that's not it
[18:16]  * hazmat goes back to drawing board
[18:18] <Ryan_Lane> it's possible this is missing function calls you need
[18:18] <Ryan_Lane> this is the super simple, kind of shitty object store
[18:18] <SpamapS> we're using that one in canonistack
[18:18] <Ryan_Lane> it seems it doesn't even have authentication
[18:19] <SpamapS> Its shittiness is worked around in txaws and juju quite a bit ;)
[18:19] <Ryan_Lane> heh
[18:19] <SpamapS> it should have auth
[18:19] <SpamapS> its used for image uploads
[18:19] <Ryan_Lane> glance is used for image uploads
[18:19] <Ryan_Lane> and glance doesn't have auth either ;)
[18:20] <SpamapS> Hmmmmm.. right.. I thought somebody told me that this was used to facilitate those image uploads
[18:20] <Ryan_Lane> we are using cactus
[18:20] <SpamapS> Oh
[18:20] <SpamapS> snap
[18:20] <SpamapS> and anything works?
[18:20] <SpamapS> you know Diablo's out.. ;)
[18:20] <Ryan_Lane> cactus is perfectly stable for us ;)
[18:20] <SpamapS> We had to fix quite a few diablo bugs for juju to work
[18:20] <Ryan_Lane> I wasn't comfortable upgrading a few days before the hackathon ;)
[18:20] <SpamapS> Yeah
[18:20] <SpamapS> its non-trivial
[18:21] <SpamapS> Big component of the essex design summit was how to do upgrades
[18:21] <m_3> vast understatement?
[18:22] <Ryan_Lane> the objectstore hasn't changed at all I believe
[18:22] <Ryan_Lane> it is deprecated
[18:23] <hazmat> ah.. its cactus
[18:24] <SpamapS> hazmat: I wonder if the nova bugs with groups were all introduced during diablo
[18:24] <m_3> swift on an instance and we can just use that s3-uri?
[18:24] <SpamapS> if they were in cactus too..  there will be problems. :p
[18:25] <Ryan_Lane> bugs with groups?
[18:25] <SpamapS> Yeah nova couldn't handle the group management that juju does for firewall management
[18:25] <Ryan_Lane> ah
[18:25] <Ryan_Lane> security groups you mean?
[18:26] <SpamapS> instances would fail to start because of at least 1 bug
[18:26] <SpamapS> yeah
[18:26] <Ryan_Lane> ah
[18:26] <Ryan_Lane> I haven't seen any security group issues yet
[18:27] <Ryan_Lane> they may have been introduced in diablo
[18:27] <hazmat> Ryan_Lane, juju create's a security group that allows intra group traffic, it broke diablo for a while
[18:27] <hazmat> Ryan_Lane, there are a couple of bugs fixed wrt to juju usage in the diablo release
[18:28] <Ryan_Lane> ah. ok
[18:28] <hazmat> i'm going to see how far i get with it
[18:28]  * Ryan_Lane nods
[18:42] <_mup_> Bug #875903 was filed: Zookeeper errors in local provider cause strange status view and possibly broken topology <juju:New> < https://launchpad.net/bugs/875903 >
[18:44] <hazmat> so the 401 unauthorized is actually from trying to describe the security groups
[18:45] <hazmat> SpamapS, re that bug, did you hibernate?
[18:46] <hazmat> SpamapS, the session expiration is fatal atm, and a hibernate will trigger it, since there isn't any heartbeat and then the clock advances
[18:47] <hazmat> status should be verifying against the agent presence nodes
[18:48] <SpamapS> hazmat: no, just been fiddling with it for 1 or 2 hours straight
[18:48] <hazmat> else its just reporting against recorded state
[18:48] <SpamapS> hazmat: I saw this one before too
[18:48] <SpamapS> hazmat: I bootstrapped quite recently
[18:49] <SpamapS> anyway, time for weekend stuff
[18:49] <hazmat> SpamapS, cheers
[18:52] <m_3> SpamapS: later man... thanks!
[18:53] <m_3> hazmat: euca-describe-groups is authorized from the cli
[18:53] <hazmat> m_3, yeah.. saw that
[18:56] <m_3> could also euca-authorize -P tcp -p 22 -s 0.0.0.0/0 junk-group
[20:39] <backburner> will juju work with openstack ?
[20:47] <m_3> backburner: yes, it's been tested with diablo I think
[21:11] <enmand_> There are nova-cloud-controller and nova-compute charms, I believe
[21:11] <enmand_> I haven
[21:11] <enmand_> I haven't been able to find information or documentation on deplying Ubuntu Cloud Infrastructure and OpenStack yet though
[21:11] <enmand_> In Oneiric, I mean
[21:26] <m_3> enmand_: juju can deploy openstack using those charms... it can also deploy services _on_ openstack
[23:19] <enmand_> m_3, yeah, I found the openstack charms and all, and I read some of the deploying on OpenStack stuff