[01:35] med_: right back at you... thanks man [02:35] heh. [02:45] SpamapS, i'm a fan of juju-tools [11:48] Good morning everybody [11:54] hi niemeyer [11:54] Tribaal: Heya [13:32] m_3: ping [15:01] SpamapS: DNS lookup failed: address 'store.juju.ubuntu.com' not found , known bug ? [15:46] how far (if at all) are we along the road of having a decent api for juju? [15:55] vila: yes, you need to add '--repository path/where/your/charms/are local:charmname' [15:55] drussell: juju has a rich cli API that is very stable. :) [15:55] 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] (I can do lightning, and we can both do the charm school perhaps?) [15:55] SpamapS: rubbish for automation tho ;o) [15:56] drussell: shell scripts are the oldest form of automation :) [15:56] SpamapS: hehehehe [15:56] SpamapS: are we looking to do anything extra? REST etc? [15:57] drussell: there's a strong desire to have a REST api yes. [15:58] SpamapS: so a strong desire, but it's quite a way off? === fenris is now known as Guest60985 [15:59] SpamapS: is there any kind of roadmap available? [15:59] drussell: resources are severely limited and dedicated to providing features necessary for production usage. REST is just a nice to have. [15:59] lol [16:00] SpamapS: "lol == no" then :o) [16:00] drussell: the link in the topic is a decent view of whats being worked on now [16:01] SpamapS: sure, have looked at the bug view, thanks [16:01] jcastro, sounds good solo talk talk, duo school [16:01] 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] 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] jcastro, thanks [16:17] 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] benji, cool [16:33] 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] 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 < https://launchpad.net/bugs/925567 > [16:42] 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] hazmat: awesome... looking now [16:50] hazmat: thanks for including the classic restful version of the api too [16:52] hazmat: I love the fact that the /commands part should make it pretty quick to get a web-based api working [16:53] m_3, indeed, the cli api effectively encoded as rest, its pretty useful.. also it becomes the backing for the cli [16:53] works well for automation [16:54] awesome === niemeyer_ is now known as niemeyer [17:09] benji: thanks for the infoQ! [17:09] hazmat: nice! thanks for that, will take a look [17:13] koolhead17: we don't let everyone edit the wiki because it is raw HTML ... [17:14] SpamapS: yeah. so i was wondering are we planning to put custom slides template there? [17:16] i have to make slide for my talk so i thought i could you the custom one :P [17:17] niemeyer, not working with ethernet? [17:17] hazmat: It hasn't disconnected, but the speed is _awful_ [17:17] hazmat: Can't hear a single word [17:17] I'm trying to do some jujuing here [17:17] niemeyer, hmm.. okay.. good luck === niemeyer_ is now known as niemeyer === koolhead17 is now known as koolhead17|zzZZ [17:33] m_3: thanks for filling in and representing a MongoDB@Boulder, did you get some good interest? [17:34] yeah, great audience level-wise... asked great questions [17:35] make a plea for more mongo-charmers help to extend the charms we have [17:35] s/make/made/ [17:36] m_3: cool, sounds like you wer able to get a MongoDB with replicaset up and running [17:36] yup... we had two environments going [17:36] one I set up ahead of time with a mongo replset (3 nodes) and a node.js app fronting that [17:37] nice [17:37] one I spun up from scratch right there [17:37] we ran out of time for the second one to come up completely [17:38] sounds like you had some good stuff to show. [17:38] yeah, I think it went over well === fenris is now known as Guest57960 [17:40] hopefully folks will be enticed to join the mongo-charmers [17:41] m_3: I was excited to charm MediaGoblin because it uses MongoDB .. but then they announced they're going to SQL ;) [17:42] maria though? [17:45] m_3: no, sql alchemy... so in theory, any sql [17:45] m_3: I believe they're targetting sqlite and pgsql === Guest57960 is now known as ejat [19:12] SpamapS: oh, so 'local:' is to force juju to use --repo ? [19:18] vila: right [19:19] 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] SpamapS: Or is there a simpler way ? (I need the keystone charm and probably the other openstack related ones but keystone first) [19:21] vila: right thats how === fenris_ is now known as Guest43512 === Guest43512 is now known as ejat [21:17] m_3, SpamapS an experiment in generating test plans [21:17] http://paste.ubuntu.com/826934/ [21:17] that's just from the dependency set not from the providers per se [21:17] there's some ambiguity in our dependency graphs that becomes apparent [21:17] 'nova' satisified by nova-cloud-controller and nova-volume [21:18] and swift-proxy not being distinguishable from swift-storage [21:20] the nova one i think is a bug in the charms [21:20] the swift-storage vs. swift-proxy distinction is little harder to make out, they both provide and require 'swift' [21:37] hazmat: cool man [21:37] 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] so that's just depth-first walking as best you can? [21:38] m_3, its a bit more than that [21:38] m_3, its doing a combination of every subgraph traversal [21:38] so for any given dependency there might be multiple implementors [21:39] gotcha [21:39] each plan represents one of those dependencies be satisified by a different participant, the number of plans gets bigger exponentially [21:40] as the depth of the graph increases [21:40] i'm thinking just solving each subgraph with one dfs traversal might suffice better [21:40] to minimizing the plan set [21:41] 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] 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] at least thats how i assume the nova-volume/nova-cloud-controller both ended up working using the same 'nova' interface [21:44] that's something we can start trying to catch in chrm reviews [21:46] hazmat: do you mean the 'provides' in the metadata of those charms? [21:46] might be worth trying to match interface first, then do a rough substring match on relation-name to charm-name to disambiguate [21:47] instead of... what... alphanumer on the charm-name for interface impls? [21:48] adam_g, yup [21:48] 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] if thats not the case, i can remove the 'provides' section of the metadata [21:49] 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] they plugin different into nova [21:49] their distinct protocols and dependencies that can be solved [21:49] one can't substitute for the other [21:50] 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] just that its distinct for each [21:51] 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] 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] 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] that is, never 'juju add-relation nova-volume:foo nova-cloud-controller:foo' [21:59] adam_g, just trying to establish the posssible relations for a service [22:00] 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] 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] 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] *optional [22:05] 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] 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] 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] 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] ? [22:17] adam_g, that works [22:17] hmm [22:18] yup that works, the cycle is fine [22:18] cool, running out to lunch. i'll update after [23:34] hi all [23:40] koolhead17: hey.. good to see you back at 17 :) [23:40] m_3: hehe :) [23:41] m_3: was going through log of juju session. it was great [23:41] though am scared of mongo/node.js [23:41] hifi stuff :P [23:45] koolhead17: thanks [23:45] 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] [23:46] 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] m_3: hmm. i would stick to wordpress :P [23:48] ha! [23:48] right [23:51] koolhead17: all cloud images have python-software-properties since 10.10 [23:52] m_3: I still want to make our infinite-scaling ajaxterm :) [23:52] SpamapS: yeah, that thought crossed my mind yesterday :) [23:52] SpamapS: i was going to bootstrap my JUJU instance from my oneiric box :D [23:54] 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] koolhead17: awesome [23:58] SpamapS: thanks. Access Key ID == access key and Secret Access Key == secret key [23:58] m_3: to be honest am using this whole magic AWS infra for first time :PO