[01:35] <m_3> med_: right back at you... thanks man
[02:35] <med_> heh.
[02:45] <hazmat> SpamapS, i'm a fan of juju-tools
[11:48] <niemeyer> Good morning everybody
[11:54] <Tribaal> hi niemeyer
[11:54] <niemeyer> Tribaal: Heya
[13:32] <niemeyer> m_3: ping
[15:01] <vila> SpamapS: DNS lookup failed: address 'store.juju.ubuntu.com' not found , known bug ?
[15:46] <drussell> how far (if at all) are we along the road of having a decent api for juju?
[15:55] <SpamapS> vila: yes, you need to add '--repository path/where/your/charms/are local:charmname'
[15:55] <SpamapS> drussell: juju has a rich cli API that is very stable. :)
[15:55] <jcastro> hazmat: we're signed up for lisa and I am going to do the submission soonish; I'm going to go for a lightning talk, a talk talk, and a charm school. Do you want to do the talk talk?
[15:55] <jcastro> (I can do lightning, and we can both do the charm school perhaps?)
[15:55] <drussell> SpamapS: rubbish for automation tho ;o)
[15:56] <SpamapS> drussell: shell scripts are the oldest form of automation :)
[15:56] <drussell> SpamapS: hehehehe
[15:56] <drussell> SpamapS: are we looking to do anything extra? REST etc?
[15:57] <SpamapS> drussell: there's a strong desire to have a REST api yes.
[15:58] <drussell> SpamapS: so a strong desire, but it's quite a way off?
[15:59] <drussell> SpamapS: is there any kind of roadmap available?
[15:59] <SpamapS> drussell: resources are severely limited and dedicated to providing features necessary for production usage. REST is just a nice to have.
[15:59] <SpamapS> lol
[16:00] <drussell> SpamapS: "lol == no" then :o)
[16:00] <SpamapS> drussell: the link in the topic is a decent view of whats being worked on now
[16:01] <drussell> SpamapS: sure, have looked at the bug view, thanks
[16:01] <hazmat> jcastro, sounds good solo talk talk, duo school
[16:01] <jcastro> hazmat: ok you submit the talk and I'll submit the other 2. the important dates are here: http://www.usenix.org/event/lisa12/
[16:02] <jcastro> the deadline isn't until May but if we can do this by say end of next week at the latest we'll be good to go.
[16:06] <hazmat> jcastro, thanks
[16:17] <benji> drussell: my team is building a charm using Python scripts instead of bash and have the beginings of some thin (but helpful) wrappers around the juju commands
[16:28] <hazmat> benji, cool
[16:33] <koolhead17> hi all
[16:34] <_mup_> juju/rest-agent-api r404 committed by kapil.thangavelu@canonical.com
[16:34] <_mup_> notes on a rest api
[16:36] <hazmat> m_3, drussell fwiw, these where the notes/spec i came up with on a rest api http://bazaar.launchpad.net/~hazmat/juju/rest-agent-api/view/head:/juju/rapi/rest-api.txt
[16:40] <_mup_> Bug #925567 was filed: restarted unit agents do not restore relation presence nodes <juju:In Progress by fwereade> < https://launchpad.net/bugs/925567 >
[16:42] <koolhead17> https://juju.ubuntu.com/charms?action=edit&template=SlideTemplate  says you are not allowed to edit, is this place supposed to keep custom slides design
[16:43] <m_3> hazmat: awesome... looking now
[16:50] <m_3> hazmat: thanks for including the classic restful version of the api too
[16:52] <m_3> hazmat: I love the fact that the /commands part should make it pretty quick to get a web-based api working
[16:53] <hazmat> m_3, indeed, the cli api effectively encoded as rest, its pretty useful.. also it becomes the backing for the cli
[16:53] <hazmat> works well for automation
[16:54] <m_3> awesome
[17:09] <drussell> benji: thanks for the infoQ!
[17:09] <drussell> hazmat: nice! thanks for that, will take a look
[17:13] <SpamapS> koolhead17: we don't let everyone edit the wiki because it is raw HTML ...
[17:14] <koolhead17> SpamapS: yeah. so i was wondering are we planning to put custom slides template there?
[17:16] <koolhead17> i have to make slide for my talk so i thought i could you the custom one :P
[17:17] <hazmat> niemeyer, not working with ethernet?
[17:17] <niemeyer> hazmat: It hasn't disconnected, but the speed is _awful_
[17:17] <niemeyer> hazmat: Can't hear a single word
[17:17] <niemeyer> I'm trying to do some jujuing here
[17:17] <hazmat> niemeyer, hmm.. okay.. good luck
[17:33] <arosales> m_3: thanks for filling in and representing a MongoDB@Boulder, did you get some good interest?
[17:34] <m_3> yeah, great audience level-wise... asked great questions
[17:35] <m_3> make a plea for more mongo-charmers help to extend the charms we have
[17:35] <m_3> s/make/made/
[17:36] <arosales> m_3: cool, sounds like you wer able to get a MongoDB with replicaset up and running
[17:36] <m_3> yup... we had two environments going
[17:36] <m_3> one I set up ahead of time with a mongo replset (3 nodes) and a node.js app fronting that
[17:37] <arosales> nice
[17:37] <m_3> one I spun up from scratch right there
[17:37] <m_3> we ran out of time for the second one to come up completely
[17:38] <arosales> sounds like you had some good stuff to show.
[17:38] <m_3> yeah, I think it went over well
[17:40] <arosales> hopefully folks will be enticed to join the mongo-charmers
[17:41] <SpamapS> m_3: I was excited to charm MediaGoblin because it uses MongoDB .. but then they announced they're going to SQL ;)
[17:42] <m_3> maria though?
[17:45] <SpamapS> m_3: no, sql alchemy... so in theory, any sql
[17:45] <SpamapS> m_3: I believe they're targetting sqlite and pgsql
[19:12] <vila> SpamapS: oh, so 'local:' is to force juju to use --repo ?
[19:18] <SpamapS> vila: right
[19:19] <vila> SpamapS: How do I create a repo for precise ? Put it somehwere with a precise dir underneath and then one dir per charm ?
[19:20] <vila> SpamapS: Or is there a simpler way ? (I need the keystone charm and probably the other openstack related ones but keystone first)
[19:21] <SpamapS> vila: right thats how
[21:17] <hazmat> m_3, SpamapS an experiment in generating test plans
[21:17] <hazmat> http://paste.ubuntu.com/826934/
[21:17] <hazmat> that's just from the dependency set not from the providers per se
[21:17] <hazmat> there's some ambiguity in our dependency graphs that becomes apparent
[21:17] <hazmat> 'nova' satisified by nova-cloud-controller and nova-volume
[21:18] <hazmat> and swift-proxy not being distinguishable from swift-storage
[21:20] <hazmat> the nova one i think is a bug in the charms
[21:20] <hazmat> the swift-storage vs. swift-proxy distinction is little harder to make out, they both provide and require 'swift'
[21:37] <m_3> hazmat: cool man
[21:37] <hazmat> adam_g, ping.. was wondering if you could shed any light on the 'nova' protocol provided by both nova-volume and nova-cloud-compute
[21:38] <m_3> so that's just depth-first walking as best you can?
[21:38] <hazmat> m_3, its a bit more than that
[21:38] <hazmat> m_3, its doing a combination of every subgraph traversal
[21:38] <hazmat> so for any given dependency there might be multiple implementors
[21:39] <m_3> gotcha
[21:39] <hazmat> each plan represents one of those dependencies be satisified by a different participant, the number of plans gets bigger exponentially
[21:40] <hazmat> as the depth of the graph increases
[21:40] <hazmat> i'm thinking just solving each subgraph with one dfs traversal might suffice better
[21:40] <hazmat> to minimizing the plan set
[21:41] <hazmat> but that misses some of the benefits of discovering interface changes that break parts of the graph, or discovering broken plans due to metadata
[21:41] <hazmat> it seems like some of this breakage is because charms can use the relation name as a primary distinguisher so the author doesn't need to pay as much attention to the interface in some cases
[21:42] <hazmat> at least thats how i assume the nova-volume/nova-cloud-controller both ended up working using the same 'nova' interface
[21:44] <m_3> that's something we can start trying to catch in chrm reviews
[21:46] <adam_g> hazmat: do you mean the 'provides' in the metadata of those charms?
[21:46] <m_3> might be worth trying to match interface first, then do a rough substring match on relation-name to charm-name to disambiguate
[21:47] <m_3> instead of... what... alphanumer on the charm-name for interface impls?
[21:48] <hazmat> adam_g, yup
[21:48] <adam_g> hazmat: IIRC (could be totally wrong here), i cannot create a charm that provides nothing, and only requires. those are just null place holders.  nova-volume and compute dont provide any service from Juju's POV. once they have relations to the database and message queue, they extend the service offered to the user by nova-cloud-controller (that is, the cloud as a whole)
[21:49] <adam_g> if thats not the case, i can remove the 'provides' section of the metadata
[21:49] <hazmat> you can provide a charm which provides nothing, but thats not the point i was trying to illustrate, effectively nova-cloud-controller has an optional dependency on a 'nova-volume' protocol and a 'nova-compute' protocol
[21:49] <hazmat> they plugin different into nova
[21:49] <hazmat> their distinct protocols and dependencies that can be solved
[21:49] <hazmat> one can't substitute for the other
[21:50] <hazmat> adam_g, you still want a provides for the nova-volume and nova-compute charms to model their relation with nova-cloud-controller
[21:50] <hazmat> just that its distinct for each
[21:51] <hazmat> right now its got nova-cloud-controller providing 'nova', with nova-compute depending on it, and nova-volume also providing it.. it sounds like you want both -compute and -volume to plugin as optional dependencies into -cloud-controller
[21:52] <hazmat> which would look more like cloud-controller depending on 'nova-volume' provided by 'nova-volume' and also depending on 'nova-compute' provided by 'nova-compute'.
[21:54] <adam_g> hazmat: this is for sake of modelling the over all relationship between charms, or the actual services? there is never a direct service relationship between nova-volume and nova-cloud-controller
[21:54] <adam_g> that is, never 'juju add-relation nova-volume:foo nova-cloud-controller:foo'
[21:59] <hazmat> adam_g, just trying to establish the posssible relations for a service
[22:00] <hazmat> adam_g, right now nova-compute for example depends on 'nova' which is satisifed by 'nova-cloud-controller' and 'nova-volume' which is a bit suspicious
[22:00] <hazmat> adam_g, actually more succintly said.. trying to establish the dependencies for a charm, ie what's required to deploy nova-compute for example
[22:04] <adam_g> hazmat: so, if i follow, charms should describe the service they are providing: nova-cloud-controller provides 'nova', and charms that require 'nova' (even if there is no direct relationship between the units) should list this as an option requires?
[22:04] <adam_g> *optional
[22:05] <adam_g> i'll admit i wasn't giving the provides field much thought in the nova charms because it seemed to not make a difference, but if that needs to be fixed to accomdate external charm tools, ill gladly fix
[22:05] <hazmat> adam_g, yup, the problem arises in that nova-volume also provides 'nova' when really what it and nova-cloud-controller are providing are distinct, thanks
[22:06] <hazmat> even without the external tools, the declaration defines the possibility, a human could add those two together, even though that was not the intent, and get something not working, because the charm expectation was different.
[22:13] <adam_g> hazmat: so, would it be better if: cloud-controller provides cloud-controller:nova and (optionally) requires cloud-compute:nova-compute and instance-storage:nova-volume.  -volume + -compute both require cloud-controller:nova
[22:13] <adam_g> ?
[22:17] <hazmat> adam_g, that works
[22:17] <hazmat> hmm
[22:18] <hazmat> yup that works, the cycle is fine
[22:18] <adam_g> cool, running out to lunch. i'll update after
[23:34] <koolhead17> hi all
[23:40] <m_3> koolhead17: hey.. good to see you back at 17 :)
[23:40] <koolhead17> m_3: hehe :)
[23:41] <koolhead17> m_3: was going through log of juju session. it was great
[23:41] <koolhead17> though am scared of mongo/node.js
[23:41] <koolhead17> hifi stuff :P
[23:45] <m_3> koolhead17: thanks
[23:45] <koolhead17> okey i might be stupid to ask this but do we assume every user adding a repo via add-apt-repository would be knowing that he needs deps python-software-properties ?
[23:45] <koolhead17>  
[23:46] <m_3> the IRC talks are a hard format... it's important to be able to show examples, but ajaxterm (juju-classroom charm) isn't ideal
[23:47] <koolhead17> m_3: hmm. i would stick to wordpress :P
[23:48] <m_3> ha!
[23:48] <m_3> right
[23:51] <SpamapS> koolhead17: all cloud images have python-software-properties since 10.10
[23:52] <SpamapS> m_3: I still want to make our infinite-scaling ajaxterm :)
[23:52] <m_3> SpamapS: yeah, that thought crossed my mind yesterday :)
[23:52] <koolhead17> SpamapS: i was going to bootstrap my JUJU instance from my oneiric box :D
[23:54] <m_3> SpamapS: it really would be a great set of charms... separating the "business logic" from the scalable presentation layer
[23:57]  * koolhead17 is trying to run JUJU on AWS for the first time :)
[23:58] <m_3> koolhead17: awesome
[23:58] <koolhead17> SpamapS: thanks. Access Key ID == access key and Secret Access Key == secret key
[23:58] <koolhead17> m_3: to be honest am using this whole magic AWS infra for first time :PO