[00:41] Juju and MAAS: ERROR No matching node is available - with Ready nodes | http://askubuntu.com/q/295992 [01:05] MAAS JUJU still get bad archive mirror | http://askubuntu.com/q/295999 === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === koolhead17|afk is now known as koolhead17 === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === jcsackett_ is now known as jcsackett === defunctzombie is now known as defunctzombie_zz === stevanr_ is now known as stevanr === ubot5` is now known as ubot5 [10:39] I made the mistake of installing raring, that means I cannot utilize juju right? [10:39] or is there a repo somewhere with charms for raring? [10:45] epic_, most charms target precise officially, but will work with raring [10:46] also you can use juju to manage a precise environment from raring [10:46] i.e. juju client on raring - deployed environment == precise [11:17] ok [11:18] but I have a maas cluster of two raring machines, and I wanted to use juju to deploy openstack onto them, is there a way ? :) === jppiiroi1en is now known as jppiiroinen|afk === rogpeppe1 is now known as rogpeppe [12:50] epic_: You can "force" juju to deploy the precise version of your charm on to raring machines. set default series in your environments.yaml to raring then use juju deploy cs:precise/ There's no guarentee every charm will work with raring but it might be easier than re-provisioning everything :) === wedgwood_away is now known as wedgwood === jppiiroinen|afk is now known as jppiiroinen [13:33] hazmat: ping [13:37] ~20 minutes until UDS, first session is on Juju Docs! [13:37] http://summit.ubuntu.com/uds-1305/meeting/21699/servercloud-s-juju-docs/ [13:38] arosales: we can probaly remove the session for social pages on charms [13:39] rick has the assets from design, they just need to implement it, there's really nothing to discuss [13:42] sidnei, pong [13:42] hazmat: see pvt === Makyo|out is now known as Makyo === rbasak-test is now known as rbasak [14:12] https://plus.google.com/hangouts/_/10bbba04970621a9233d57c88c7d469acc185e86?authuser=0&hl=en [14:12] marcoceppi: arosales marcoceppi ^^ [14:12] evilnickveitch: ^ [14:12] jcastro, the social pages for Juju we still may want to have as there are some additional feedback loops some folks wanted to discuss. May be a quick session though. [14:13] ok [14:13] arosales: http://youtu.be/E2peuYklMxw === victorp_ is now known as victorp-uds [14:34] jamespage, vmaas vms vs juju vms group thing starting up if you've got a few.. https://plus.google.com/hangouts/_/90577076c19891cc3206c77d3e16988d1e1f130e?authuser=0&hl=en [14:35] in a openstack ha then mongodb sessions right now [14:35] hazmat, ^^ [14:35] ack [14:41] jcastro, has luca spoken to your team about calling "reviewed" charms "recommended" [14:41] ? [14:42] no [14:42] wait, don't tell me [14:42] we're renaming them again? [14:56] mattyw, fwiw I was on vacation yesterday so could not attend charm helpers session. Strawman I'd like to discuss with you later is that GUI team tries to merge host.py and our utils stuff to produce merged low-level bits, and we are responsible for getting higher-level charm-support tests to pass with merge. Requirement is that merged result has a test coverage rating as high or higher than existing host.py, whatever [14:56] that is. Busy now, but can talk later [14:56] sinzui: jcastro don't do anything yet! [14:57] sinzui: jcastro we are looking into the UX of a better name for it. Recommended was an option but will most probably not be used. We're researching it. [14:57] * jcastro nods [14:58] gary_poster, is that meant for me or matt wedgewood? [14:58] mattyw, sorry, matt wedgwood! bad assumption, apologies [14:59] gary_poster, no problem (I'm the cloud-green matt w) [14:59] oh cool, hi mattyw :-) [15:00] gary_poster: I think that's fine. I'm working on hook environment stuff now. [15:00] cool wedgwood, thanks, sounds good [15:23] hazmat: hey, the ppa is updated now, all series? [15:25] dpb1, yes [15:26] dpb1, by all series.. that being raring, quantal, precise [15:26] hazmat: ah, I see. the lucid build is still old [15:27] hazmat: is it possible to kick a lucid build too? [15:28] dpb1, checking [15:29] dpb1, it looks like its barfing on dh_python2 [15:29] https://launchpadlibrarian.net/139956755/buildlog.txt.gz [15:30] hazmat, you guys finished now? [15:31] jamespage, yup [15:31] bah [15:31] nm [15:31] jamespage, more to be discussed, lots of details and directions to be ironed out [15:32] :( [15:40] hazmat, dpb1: is that really a lucid build? [15:41] jamespage, apparently yes.. who knew :-) [15:41] I don't think lucid has dh_python2 [15:41] jamespage: know of a quick way to fix it? [15:46] revert back to pycentral/pysupport .. [15:46] afaik [15:46] k [15:49] hazmat, dpb1: openstack packaging used todo this just after lucid [15:51] jamespage, support lucid with dh_python2 or use pycentral/pysupport? === defunctzombie_zz is now known as defunctzombie [15:51] i assume the latter.. cause it still works even throws deprecation warnings [15:51] it had some hacks to support dh_python2 and pycentral/support [15:52] upstream activity backported to lucid until precise arrived [15:53] barry ref'd this bug re lucid/dh_python2 https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/788524https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/788524 [15:53] <_mup_> Bug #788524: backport dh_python2 to lucid (and maverick if appropriate)

[15:53] <_mup_> Bug #788524: backport dh_python2 to lucid (and maverick if appropriate)

[15:54] hazmat: best of both worlds: https://pastebin.canonical.com/91141/ [15:54] also refs the openstack usage === defunctzombie is now known as defunctzombie_zz [15:54] heh, ya, that is the bug that I was looking at too [15:55] wedgwood: not sure it needs to be resolved right now... it's pretty easy to change [15:55] that patch (minus the stray .deb file) seems to work on my lucid machine [15:56] wedgwood: oh nm... we wanna get stubs into charms sooner rather than later [15:56] :) [15:56] m_3: indeed, but also means changing charms [15:57] wedgwood: So what you're saying is just anything in tests/ gets run regardless of +x ? [15:57] suppose windows criteria could be different than unix [15:57] I can see value in ordering [15:57] also having files there that _don't_ get executed [15:57] m_3: upon consideration, +1 to ordering [15:57] having multiple scenarios [15:57] I like the test manifest idea. "Run these things" [15:58] I was thinking ordering was more about "failing early" on simple tests [15:58] m_3: well I can see the "don't want it executed, don't put it in tests/, put it in tests/lib" [15:58] Or another subdirectory and just not walk trees when testing [15:58] and less about setup/teardown... that (imo) should happen within each scenario [15:58] m_3: +1 for sure [15:58] marcoceppi: yeah, stick to tree level 0 in there [15:58] yep, we agree that order is important [15:58] A lot of my use cases have very unique setups with different charms and initial configs [15:59] ok, so then any naming scheme's fine with me [15:59] what about a single command that's expected to handle running tests? [16:00] m_3: wedgwood: I can drop the implicit .test and just run things in lexi ordering in the tests folder [16:00] wedgwood: the juju-test command? [16:00] hell, even worth considering tree level 1... i.e., $CHARM_DIR/tests//{01.setup.sh,02.run.sh,03.teardown.sh} [16:00] m_3: bah! [16:00] wedgwood: what about that single command? [16:00] wedgwood: ack, it's too noisy [16:00] marcoceppi: I'm thinking mycharm/tests/run_tests [16:00] m_3: why couldn't that be $CHARM_DIR/tests/scenario.sh ? [16:01] marcoceppi: excellent point [16:01] wedgwood: that would be encompased in the juju-test command though, where it would just run one or more (or all) tests in the tests directory [16:01] wedgwood: single starting point would work... let's you control your scenarios in python [16:01] wedgwood: but I guess I like separate script file per scenario [16:01] either way though really [16:02] m_3: scenarios are still possible, but shouldn't juju-test have a single mode? [16:02] so tree-level-0, executable, single file per scenario (that can optionally call as much other stuff as it likes) [16:02] If you wanted control over ordering $CD/tests/00-run-tests then you could mock scenarios you cared about in $CD/tests/scenarios and have the 00-run-tests build an order [16:02] s/mode/target/ [16:03] wedgwood: if I understand correctly, then yeah, each scenario would be a separate stack of services (include bootstrap and destroy-environment) [16:03] `juju test ` should run all of them in order I think [16:04] m_3: right, buy could could also run juju test charm-name to run just one test [16:04] with an option of calling `juju test /tests/` explicitly perhaps? [16:04] marcoceppi: good point [16:04] ah, same page [16:05] m_3: yeah, and we can make that an explict path too [16:05] maybe just juju test -f tests/blah [16:05] or something [16:05]

would have to match a file in $CHARM_DIR/tests otherwise [16:05] explict path might be easier to impl [16:05] but really whatever works [16:06] m_3: right so you could do that or possibly just have an additonal option to supply a full file path [16:06] to sum up my concern about naming schemes: I'd like to structure my tests in a way that works with my chosen programming language. [16:06] in the event you're cool and want to have tests outside of the charm [16:06] hell, I'm happy with just making bits I'm _not_ interested in testing non-executable temporarily [16:06] (during dev) [16:07] wedgwood: ack on your concern. I'm just going to have it execute whatever the hell you have in tests directory so you can name them as you see fit. [16:07] wedgwood: yeah, understand... I'm fine with picking one set of names [16:07] I'll try to err on the site of flexibility rather than being too opinionated on things like naming and structure [16:07] marcoceppi: +1 [16:07] marcoceppi: I think that's flexible enough. some sharp edges, but probably safe [16:08] wedgwood: we can dull those edges in the next few weeks, for sure [16:08] I'd like to just get something out that people can use without too many scrapes [16:08] fits along with the "flexible framework" yet opinionated helpers/examples [16:08] marcoceppi: and when we tackle windows, we may need a manifest file. there's no way to tell from naming or filesystem bits what is and isn't an executable. [16:08] yup, or rely on tree depth [16:09] wedgwood: yeah, I think we'll need to cross that bridge when we get there, but I'll keep that in mind on these first few cuts [16:09] wedgwood: thanks for the feedback! [16:10] I need to start using that one more in talks... "flex framework, opinionated charms/helpers" [16:10] marcoceppi: looking forward to seeing your work! [16:11] m_3: where should we start storing juju plugins? Given juju-test will likely be the first one [16:11] yeah, awesome guys [16:12] marcoceppi: good question man... not really sure... there're pros/cons with each option [16:12] marcoceppi: we can package `juju-plugins` or `juju-contrib` [16:12] I'd probably lean to juju-plugins, contrib sounds too...official :) [16:12] marcoceppi: we can have a juju-plugins project where each plugin has to be pulled separately [16:13] marcoceppi: so we get packages like `juju-plugin-testing` [16:13] makes it explicit to the user that this is something _other_ than juju-core [16:13] m_3: ack [16:13] hello there, I'm working on a monitor charm (observium) https://code.launchpad.net/~chilicuil/charms/precise/observium/trunk and currently it deploys the server part, however no enable clients, those machines (the ones who are going to be monitored) needs to install snmpd, I'd like that it could be done via some kind of connection between the charms, I suppose it would require modification in the charms which will be clients, is this correct? [16:13] juju-plugins- for groups of pugins [16:14] m_3: like juju-plugins-charm :) [16:14] get all the charm-tools juju plugins [16:14] marcoceppi: yeah, so I think a plugins project... maybe repo per plugin?... and then we can create package-groups [16:15] chilicuil: this is a perfect use for "subordinate" services [16:15] m_3: just started the plugin project, I'll just createa a repo for juju-test and have it building in a ppa...maybe the juju/pkgs ppa? [16:15] chilicuil: you'd create something like 'observium-emitter' that attaches as subordinate to any service [16:15] m_3: I'll look for it at the documentation, thanks! [16:15] chilicuil: then that subordinate charm adds snmpd and friends [16:16] hum. Do plugins need to be the same license as core? [16:16] marcoceppi: yeah, same pa as core imo [16:16] ppa [16:17] chilicuil: np [16:17] marcoceppi: no clue [16:17] marcoceppi: they're more one-off things... so make them as open as possible I'd think [16:17] I wish I was a laywer [16:17] haha [16:18] I wouldn't wish that on you [16:18] haha [16:18] although it might be helpful in a bar in DC :) [16:19] marcoceppi: we can add lp:juju-plugins to the juju project group in lp [16:19] awesome [16:19] I'll set up the mirror for github [16:20] m_3: ta! [16:22] github.com/juju-plugins [16:22] what's the lp project? [16:22] lp:i-am-not-a-lawyer [16:23] jk, lp:juju-plugins [16:23] :) [16:25] marcoceppi: I expect at some point there will also be plugins that're bundled with core, but nothing to do for that really [16:25] should just work [16:25] m_3: so are we creating directories in a single bzr branch, or a branch per plugin? [16:26] just don't know [16:26] how heavyweight is repo per plugin? [16:26] you clone it and simlink the plugin iteself into your ~/bin dir [16:27] or do you wanna just clone a single repo and then symlink selections [16:27] we can do both [16:27] depends on how many plugins you have [16:27] I think it's a good idea, but doesnt' scale quite well in github unless you merge all the branches in to one section [16:27] if they're all in one repo, then it's harder for us to create `juju-plugins-testing` and `juju-plugins-charm` packages [16:28] lets do different repos for now [16:28] well, maybe it isn't though [16:28] I've got a charm which works under pyju - and fails under juju-core when running the relation_changed hooks. it looks like I get "no relation id specified" when running relation-set, does this make any sense? [16:29] marcoceppi: I'm kinda thinking one repo === defunctzombie_zz is now known as defunctzombie [16:29] * marcoceppi shrugs [16:29] just in different dirs? [16:29] marcoceppi: you know what? it doesn't really matter right now... we can change this pretty easily [16:30] marcoceppi: so maybe one repo... trunk on lp:juju-plugins... file per plugin (no need for subdirs) [16:30] marcoceppi: then we can add a packaging branch at any time to package selected bits [16:30] marcoceppi: with the full expectation that this will probably change [16:31] ack [16:34] marcoceppi: I think it's a good idea to treat this as a big bucket... over time an individual plugin might "grow up" and need its own repo [16:34] m_3: good point [16:35] marcoceppi: I could see Makefiles and other supporting crap associated with installing a single plugin... at the point it's no longer a single file of script, it gets a separate repo [16:41] mattyw, are you using upload-tools [16:41] hazmat, no I'm not [16:41] mattyw, can ic the charm? [16:41] priv msg if nesc === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz [17:42] gary_poster: GUI session in about 20 min? [17:43] y jcastro thanks. on call now. hangout link? [17:43] I haven't created it yet [17:43] I will in about 15 [17:43] just wanted to give you a heads up [17:43] cool thanks === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz [18:58] jcastro, is there a separate irc channel then.. #ubuntu-uds-servercloud-2 ? [18:58] oh.. nm [18:59] alguien habla español [19:02] arosales, Your user stores for charm testing rock [19:03] they should be added to author profiles [19:05] sinzui, I can't take credit for that. I think marcoceppi did those in https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-charm-testing [19:05] there are good though :-) [19:05] Holy grammar hell, batman. I should have proof read those after I got off the plane [19:12] grammar was never a barrier for developers. My fingers don't believe in plurals and tenses. [19:13] marcoceppi, incidentally new deployer impl support for pyjuju is coming [19:13] hazmat: \o/ thanks for the update [19:14] marcoceppi, and deployer integrates what amounts to gowatch (available from the jujuclient api impl) [19:14] perfect [19:15] marcoceppi, what i really want is a way for charm authors/charm farmers to be able to manually kick off a test run on a particular charm or mp, and get notified of results. [19:15] i mean its icing.. but its delicious [19:15] ;-) [19:16] hazmat: yeah, you're not the only one asking for this. When local lands it'll be easy enough for charmers (sans ~) to just juju test

-e local but I've been mulling over adding a juju-remote-test command for queing a test on jenkins. Not sure how abused that will get though [19:17] marcoceppi, restricting it to ~charmers initially seems sane.. and helps reviewers [19:18] hazmat: yeah, would be a good starting point, though I'd favor just having automatic testing on merge request over one-off test queing [19:19] marcoceppi, true [19:20] Once we get people writing test I'd love to start diving in to all that automation deliciousness [19:23] marcoceppi, so whats missing to me is why jitsu test is not the correct path forward [19:24] ignoring the implementation but the spec itself [19:24] hazmat: do you have the spec somewhere? I haven't actually read it [19:24] Though, I don't think the juju-test implementation would be too far off what jitsu test was striving to be [19:27] hazmat: this in the docs: https://code.launchpad.net/~clint-fewbar/charm-tools/charm-tests-spec/+merge/90232 ? [19:33] marcoceppi, its the one in the old docs [19:33] marcoceppi, http://jujucharms.com/docs/charm-tests.html [19:34] hazmat: yeah, so implementation wise of just listening to signals and shelling out to the test in the tests directory (with better handling of the tests individually) is what juju-test will do [19:35] The test helper I'm working on just give an author of tests a lot easier ways to inspect a deployed environment to build better detailed tests === BradCrittenden is now known as bac === wedgwood is now known as wedgwood_away