| m_3 | med_: right back at you... thanks man | 01:35 |
|---|---|---|
| med_ | heh. | 02:35 |
| hazmat | SpamapS, i'm a fan of juju-tools | 02:45 |
| niemeyer | Good morning everybody | 11:48 |
| Tribaal | hi niemeyer | 11:54 |
| niemeyer | Tribaal: Heya | 11:54 |
| niemeyer | m_3: ping | 13:32 |
| vila | SpamapS: DNS lookup failed: address 'store.juju.ubuntu.com' not found , known bug ? | 15:01 |
| drussell | how far (if at all) are we along the road of having a decent api for juju? | 15:46 |
| 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:55 |
| 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:56 |
| SpamapS | drussell: there's a strong desire to have a REST api yes. | 15:57 |
| drussell | SpamapS: so a strong desire, but it's quite a way off? | 15:58 |
| === fenris is now known as Guest60985 | ||
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| hazmat | jcastro, thanks | 16:06 |
| 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:17 |
| hazmat | benji, cool | 16:28 |
| koolhead17 | hi all | 16:33 |
| _mup_ | juju/rest-agent-api r404 committed by kapil.thangavelu@canonical.com | 16:34 |
| _mup_ | notes on a rest api | 16:34 |
| 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:36 |
| _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:40 |
| 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:42 |
| m_3 | hazmat: awesome... looking now | 16:43 |
| m_3 | hazmat: thanks for including the classic restful version of the api too | 16:50 |
| m_3 | hazmat: I love the fact that the /commands part should make it pretty quick to get a web-based api working | 16:52 |
| 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:53 |
| m_3 | awesome | 16:54 |
| === niemeyer_ is now known as niemeyer | ||
| drussell | benji: thanks for the infoQ! | 17:09 |
| drussell | hazmat: nice! thanks for that, will take a look | 17:09 |
| SpamapS | koolhead17: we don't let everyone edit the wiki because it is raw HTML ... | 17:13 |
| koolhead17 | SpamapS: yeah. so i was wondering are we planning to put custom slides template there? | 17:14 |
| koolhead17 | i have to make slide for my talk so i thought i could you the custom one :P | 17:16 |
| 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:17 |
| === niemeyer_ is now known as niemeyer | ||
| === koolhead17 is now known as koolhead17|zzZZ | ||
| arosales | m_3: thanks for filling in and representing a MongoDB@Boulder, did you get some good interest? | 17:33 |
| m_3 | yeah, great audience level-wise... asked great questions | 17:34 |
| m_3 | make a plea for more mongo-charmers help to extend the charms we have | 17:35 |
| m_3 | s/make/made/ | 17:35 |
| 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:36 |
| 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:37 |
| arosales | sounds like you had some good stuff to show. | 17:38 |
| m_3 | yeah, I think it went over well | 17:38 |
| === fenris is now known as Guest57960 | ||
| arosales | hopefully folks will be enticed to join the mongo-charmers | 17:40 |
| SpamapS | m_3: I was excited to charm MediaGoblin because it uses MongoDB .. but then they announced they're going to SQL ;) | 17:41 |
| m_3 | maria though? | 17:42 |
| SpamapS | m_3: no, sql alchemy... so in theory, any sql | 17:45 |
| SpamapS | m_3: I believe they're targetting sqlite and pgsql | 17:45 |
| === Guest57960 is now known as ejat | ||
| vila | SpamapS: oh, so 'local:' is to force juju to use --repo ? | 19:12 |
| SpamapS | vila: right | 19:18 |
| 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:19 |
| vila | SpamapS: Or is there a simpler way ? (I need the keystone charm and probably the other openstack related ones but keystone first) | 19:20 |
| SpamapS | vila: right thats how | 19:21 |
| === fenris_ is now known as Guest43512 | ||
| === Guest43512 is now known as ejat | ||
| 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:17 |
| hazmat | and swift-proxy not being distinguishable from swift-storage | 21:18 |
| 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:20 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| hazmat | at least thats how i assume the nova-volume/nova-cloud-controller both ended up working using the same 'nova' interface | 21:42 |
| m_3 | that's something we can start trying to catch in chrm reviews | 21:44 |
| 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:46 |
| m_3 | instead of... what... alphanumer on the charm-name for interface impls? | 21:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| hazmat | adam_g, just trying to establish the posssible relations for a service | 21:59 |
| 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:00 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:13 |
| hazmat | adam_g, that works | 22:17 |
| hazmat | hmm | 22:17 |
| hazmat | yup that works, the cycle is fine | 22:18 |
| adam_g | cool, running out to lunch. i'll update after | 22:18 |
| koolhead17 | hi all | 23:34 |
| m_3 | koolhead17: hey.. good to see you back at 17 :) | 23:40 |
| koolhead17 | m_3: hehe :) | 23:40 |
| 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:41 |
| 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:45 | |
| 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:46 |
| koolhead17 | m_3: hmm. i would stick to wordpress :P | 23:47 |
| m_3 | ha! | 23:48 |
| m_3 | right | 23:48 |
| SpamapS | koolhead17: all cloud images have python-software-properties since 10.10 | 23:51 |
| 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:52 |
| m_3 | SpamapS: it really would be a great set of charms... separating the "business logic" from the scalable presentation layer | 23:54 |
| * koolhead17 is trying to run JUJU on AWS for the first time :) | 23:57 | |
| 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 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!