=== xnox is now known as doko_
=== doko_ is now known as xnox
[01:38] <ray> Hi, guys, sync-tool give me the latest version is 1.16.5, but upgrade-juju give me 1.16.3, how does that happen? can I specify the juju version to upgrade to?
[01:40] <ray> ok, --version give me that,  on the other hand, --upload-tools should not be used
=== gary_poster is now known as gary_poster|away
=== CyberJacob|Away is now known as CyberJacob
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[11:36] <InformatiQ> does juju work with cloudstack?
[11:36] <InformatiQ> was just talking about juju with a guy using cloudstack and wasn't sure if it worked or no
[11:51] <natefinch> InformatiQ: as far as I know, no, it won't work.
[11:51] <InformatiQ> thanks natefinch i thought so too
=== gary_poster|away is now known as gary_poster
[13:36] <marcoceppi> jamespage: https://code.launchpad.net/~james-page/charms/precise/nova-cloud-controller/havana-bind/+merge/198910 LGTM, wanted to make sure it was safe to merge
[13:37] <jamespage> marcoceppi, I've tested it in HA mode - worked for me :-)
[13:38] <marcoceppi> jamespage: good enough for me
[13:47] <jamespage> marcoceppi, how do bundles appear in the charm store? I've written and openstack-on-openstack one but its not appearing?
[13:48] <marcoceppi> jamespage: you need to push to lp:~USER/charm/bundle/BUNDLE-NAME/bundle to have them show up
[13:48] <jamespage> marcoceppi, yeah - I have
[13:48] <marcoceppi> jamespage: past that, you'll have to search for either your username or the bundle name. Searching and sorting bundles in gui isn't a strong story yet.
[13:48] <jamespage> marcoceppi, https://code.launchpad.net/charms/bundles
[13:50] <jamespage> marcoceppi, well I can't figure it out
[13:50] <marcoceppi> jamespage: looks good, doesnt' appear to be in the gui, let me see if I can find it in the API
[13:51] <jamespage> marcoceppi, the bundles.yaml contains several targets but I read that should be ok
[13:51] <rick_h__> jamespage: does it pass proof?
[13:51] <marcoceppi> jamespage: yeah, that should be fine. Each target will appear as it's own bundle
[13:52] <jamespage> rick_h__, proof?
[13:52] <rick_h__> jamespage: like charm proof. It also proof's bundles
[13:52] <marcoceppi> jamespage: install charm-tools; run `juju bundle proof`
[13:52] <rick_h__> jamespage: if it doesn't pass it doesn't get ingested like a charm
[13:52] <marcoceppi> rick_h__: oh god, proof just blew up for me
[13:53] <rick_h__> marcoceppi: on this bundle or in general?
[13:53] <jamespage> marcoceppi, which charm tools version do I need
[13:54] <marcoceppi> rick_h__: in general
[13:54] <rick_h__> marcoceppi: :/
[13:54] <marcoceppi> jamespage: at least 1.2.0, 1.2.5 being the latest
[13:55] <marcoceppi> rick_h__: it seems to be having a hard time parsing the json from the api. Not sure what changed, let me poke with a sharpe stick
[13:56] <rick_h__> marcoceppi: the thing I see is a syntax issue on line 18 of bundles.py
[13:56] <rick_h__> a , vs a %
[13:56] <marcoceppi> rick_h__: yeah, I sorted that locally
[13:56] <marcoceppi> now getting an unable to parse json error
[13:56] <rick_h__> heh, and not I'm getting a json parse error
[13:57] <marcoceppi> rick_h__: so, a problem with local proof, it doesnt' take in to consideration inheritance at all
[13:57] <marcoceppi> :\
[13:57] <marcoceppi> :/
[13:57] <rick_h__> nice, server error wheee
[13:58] <rick_h__> marcoceppi: the server response is a 500 server error
[13:58] <marcoceppi> rick_h__: yeah, I'm not catching status_code in requests, should probably check that
=== BradCrittenden is now known as bac
[14:03] <marcoceppi> rick_h__: I've got a patch for the inheritance issue, I'll have it released in 1.2.6
[14:21] <rick_h__> marcoceppi: jamespage ok, so I don't believe proof supports inheritance right now. I'm not sure if charmworld does at all. There's a card to look into it, but not been high priority yet.
[14:21] <jamespage> rick_h__, OK
[14:21] <rick_h__> marcoceppi: jamespage that causes this bundle to go boom. I'll open a bug with it and the bundle file as an example file, but this is why it's not in the store, it can't ingest it
[14:22] <marcoceppi> rick_h__: is this with the remote proofing?
[14:23] <rick_h__> marcoceppi: yes, but it's a basic proofing error. It gets to the raring-grizzly and decides it has no services and hits a failed loop that dies
[14:23] <jamespage> rick_h__, OK _ I can work around that for now
[14:23] <marcoceppi> rick_h__: right, I threw my hands up for the local proof portion and said "Oh, you have an inherit key, well we'll just press on"
[14:24] <jamespage> rick_h__, will any E cause a failure? proof is not so keen on the ntp suborinate I've using with evertyhgin
[14:24] <marcoceppi> rick_h__: you probably have to do a lot more checking
[14:24] <rick_h__> jamespage: yes, an E causes it not to ingest
[14:25] <jamespage> rick_h__, E: openstack: The two services ntp:nova-compute share no common interfaces.
[14:25] <jamespage> that uses the implicit juju-info relation
[14:25] <jamespage> so it won't ever match up
[14:25] <rick_h__> jamespage: hmmm, that should work. We allow for the implicit juju-info relation. I remember working around a bug on that.
[14:25] <rick_h__> jamespage: are they specified in the bundle?
[14:26] <jamespage> rick_h__, no
[14:26] <jamespage> rick_h__, if I add :juju-info it errors that does not exist
[14:26] <rick_h__> jamespage: try to specify it and see if it works. I know we auto 'trust' any juju- relations
[14:26] <rick_h__> jamespage: k, sec looking
[14:26] <rick_h__> I know we dealt with this in some form. Checking the tests
[14:26] <jamespage> E: openstack: Invalid relation requested: :juju-info
[14:28] <rick_h__> jamespage: paste me the bundle file please? There code is there to auto trust provides/requires that start with juju-
[14:28] <jamespage> rick_h__, http://paste.ubuntu.com/6605939/
[14:32] <jamespage> rick_h__, I think I see something similar when I import the bundle in the juju gui
[14:32] <jamespage> no relations get created after the first subordinate one gets parsed
[14:33] <rick_h__> jamespage: hmm, we use some bits from the deployer to parse relations so maybe there's a raw issue there.
[14:33] <jamespage> rick_h__, maybe - I tested using deployer
[14:34] <rick_h__> jamespage: oh hmm, well the juju- realations need to be specified as the type before it'll auto pass them
[14:34] <rick_h__> it doesn't auto assume the interface in that case which is why this is getting that error at least
[14:38] <rick_h__> jamespage: http://paste.ubuntu.com/6605995/ gets rid of the juju-info relation issues
[14:38] <jamespage> rick_h__, yeah - got that
[14:38] <jamespage> just trying to sort out the other suboridnate one I have
[14:39] <rick_h__> jamespage: k, I'm missing some charms used so I'm getting proof errors in my local dev env on those. Updating my ingested charms now (which takes a bit) and will try again
[14:42] <jamespage> rick_h__, is there a keyboard shortcut to clear the build area on jujucharms.com
[14:42] <jamespage> ?
[14:42] <rick_h__> jamespage: reload, ctrl-r :)
[14:43] <jamespage> rick_h__, so I discover!
[14:43] <rick_h__> pure demo baby
[14:46] <jamespage> rick_h__, OK _ the gui accepts that branch bundle as an upload now
[14:46] <jamespage> although proof was still complaining but meh
[14:46] <rick_h__> jamespage: k, did you update the yaml?
[14:46] <jamespage> rick_h__, yes
[14:46] <rick_h__> jamespage: if so paste me the update please so I can make sure we get that in as a bug and get proof fixed
[14:46] <rick_h__> jamespage: so far bundles haven't stretched our code as you've so awesomely done :)
[14:47] <jamespage> rick_h__, http://paste.ubuntu.com/6606034/
[14:47] <rick_h__> and I'd like to make sure we get more awesome
[14:47] <jamespage> that's what works
[14:47] <jamespage> I still see
[14:47] <jamespage> E: openstack: The requested relation nova-ceilometer to nova-ceilometer is incompatible between services.
[14:47] <jamespage> but it does exist
[14:47] <jamespage> 19 services
[14:47] <jamespage> noce
[14:47] <rick_h__> ok, yea proof is purely on the charmworld manage.jujucharms.com side
[14:48] <rick_h__> so it'll 'work' in the gui just fine. But to get it listed we'll have to fix that
=== teknico_ is now known as teknico
[14:58] <hazmat> jamespage, there's a short hand for one thing relates to lots of others.  ie  - [blog, [db, memcached]]
[14:58]  * hazmat peaks at ostack on ostack bundle
[14:58] <jamespage> hazmat: oh - nice
[17:54] <dpb1> marcoceppi: what am I doing wrong here? http://paste.ubuntu.com/6606922/
[17:55] <dpb1> marcoceppi: storage is a new subordinate I'm writing
[17:57] <marcoceppi> dpb1: this is a problem with subordinates, I'm working on a fix atm
[17:57] <dpb1> marcoceppi: ok
[17:58] <marcoceppi> dpb1: I managed to get this far without ever writing a test that included subordinates. So it's trying to proxy the subordinate relationship which just doesn't work
[17:59] <dpb1> marcoceppi: is there a way to turn that off so I can proceed a bit?  Or is that needed for the rest of amulet to "work"?
[17:59] <marcoceppi> dpb1: it's only needed for sentry stuff
[18:00] <marcoceppi> dpb1: if you're not going to use any of the sentry things, you can pass sentries=False to the Deployment() call
[18:00] <dpb1> marcoceppi: I mean, I would like to eventually since this is communicating data on the relation, and I would like to test it, but I can do that just to move on.
[18:00] <dpb1> thx
[18:01] <marcoceppi> dpb1: line ubuntu = d.sentry.unit['ubuntu/0'] in your test file won't be valid anymore, but everything else will work
[18:01] <dpb1> right
[18:01] <dpb1> understood
=== nate_finch is now known as natefinch
=== gary_poster is now known as gary_poster|away
[18:32] <dpb1> subordinate relation question:  anyone see what I'm doing wrong?  http://paste.ubuntu.com/6607104/
=== psivaa is now known as psivaa-holiday
[18:50] <natefinch> dpb1: Friday afternoons are tough on the juju channels... It's  Saturday in Australia and the Europeans are all having friday dinner.  That leaves pretty much just me, and my knowledge of charms is pretty limited, I'm afraid
[18:53] <sarnold> .. and today is liable to be last workday of the year for a few..
[18:53] <adam_g> dpb1, wouldnt it be add relation  storage:block-storage ubuntu:block-storage ?
[19:15] <marcoceppi> adam_g: no, he's got that part right
[19:16] <marcoceppi> dpb1: I think you need to reverse the provides/requires
[19:17] <marcoceppi> dpb1: hum, nevermind, that doesnt' seem to be the case
[19:18] <marcoceppi> dpb1: does add-relation with --debug --show-log illuminate anything?
[20:03] <dpb1> marcoceppi: checking
[20:04] <dpb1> adam_g: no, I tried that too
[20:05] <dpb1> marcoceppi: debug show-log just dumps out my environment data as a json and some connection information, nothing interesting in there
[20:05] <dpb1> let me try and blow it away and re-do it
[20:25] <dpb1> marcoceppi/adam_g: can't repeat it on a new environment.  I'm suspecting a stale charm.
[20:26] <dpb1> natefinch: hah, no worries.  I didn't know you were us based.  I might ping you more now! :)
[20:28] <natefinch> dpb1: I'm the sole Juju dev who is US based.  We are looking to hire more though :)  Other people who know stuff are also US based, though, like Marco
[20:28] <dpb1> natefinch: ya, I bug marco a lot already. :)
[20:29] <natefinch> dpb1, me too ;)
[20:31] <ashipika> hi guys.. wondering if you could answer a conceptual question about juju.. is the idea of juju to have one charm per machine? or is it "allowed" to deploy multiple charms to a single machine?
[20:34] <natefinch> ashipika: you can have multiple.  Most of the time it'll work, but you have to watch out for things stomping on each other's data and ports etc
[20:34] <natefinch> ashipika, you can also deploy to containers, which helps a lot with the stomping problem
[20:35] <ashipika> natefinch: my thought exactly... i'm writing a charm for openfoam and i'm wondering what i should do in a stop hook.. if i try apt-get purge everything i installed i might unintentionally uninstall something another charm needs..
[20:35] <ashipika> natefinch: containers won't do in my case.. openfoam, hpc.. those guys want as little as possible between their SW and HW
[20:36] <natefinch> ashipika, it's probably not worth worrying about.  If people want it to be safe to deploy multiples, they should use containres
[20:36] <ashipika> natefinch: true.. :)
[20:36] <natefinch> ashipika, sorry, gotta run
[21:12] <dpb1> marcoceppi: at the end of a test, should I have a "juju-deployer -T" equivalent?  Is there something that amulet provides?
=== kentb is now known as kentb-weekend