[00:15] hazmat: lp:charmrunner still won't let me push to it [00:16] hazmat: also your changes are in lp:~hazmat/+junk/charmrunner so they don't get built into the packages [00:32] m_3: lp:juju/docs I think [00:34] SpamapS: thnks [00:36] m_3, ugh.. [00:36] huh [00:37] m_3, the newest version is on pypi.. updating the branch [00:39] m_3, you should be able to push now as well [00:49] hello [00:49] I need to get back to work on my charm, but I had a general idiotic question about juju [00:50] I've been doing a lot of testing against AWS, but I have a server that I'd like to just test deploy to [00:50] <_mup_> juju/enhanced-relation-spec r19 committed by jim.baker@canonical.com [00:50] <_mup_> New relation-info command and other relation id discussion [00:50] is it possible to configure an enviornment to a bare metal server, deploy openstack, then configure to deploy to that new openstack instance? [00:51] shazzner_: if you just want to use one server, use the local provider [00:52] SpamapS: ah good point, is there documentation on configuring for local? [00:53] also I might want to try out openstack for other reasons [00:54] found this: http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage [00:54] shazzner_: you can use devstack to get openstack up on a single server [00:54] hmm last time I looked at devstack it require a specific hardware configuration that I didn't have, I'll look into it again [00:55] oh I see the documentation on devstack [00:55] ok, some reading to do :) [00:57] shazzner_: you are probably confusing devstack with crowbar [00:57] probably haha === fenris is now known as Guest65492 [03:24] <_mup_> juju/force-upgrade r459 committed by kapil.thangavelu@canonical.com [03:24] <_mup_> force upgrade impl === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [13:40] SpamapS, it doesn't really appear that go supports plugins [13:44] hazmat: indeed it doesn't. any particular reason we need them? [13:44] rogpeppe, just a conversation from yesterday about out of tree provider plugins [13:45] hazmat: ah, i understand [13:45] rogpeppe, we were discussing if LoadLibrary/dlopen was sufficient to support the use case [13:45] but that's not clear to me [13:45] i don't think it probably is [13:46] hazmat: but perhaps just linking against the new provider might be sufficient [13:49] hazmat: also, it would be reasonably straightforward to provide an "external provider" interface that talked with a provider through a local pipe. [13:50] rogpeppe, once its out of process any rpc form would suffice [13:50] hazmat: yeah [13:50] rogpeppe, including using zk ;-) [13:50] so its just a question of launching the process [13:51] hazmat: i'm really thinking of something that implements the environs.Environ interface [13:51] hazmat: which could be a piece of Go code that sees an environ type of a particular form and launches a process as appropriate [13:52] hazmat: we could do it with no changes to the current code (only thing is the provider type would probably be "external" rather than the actual provider type. [13:52] ) [13:53] rogpeppe, sounds good, atm the need is theoretical [13:53] m_3, what's the new jenkins charm test url? [14:08] Good morning all [14:09] hazmat: for the record, here's how i'd imagine the API to an external provider: http://paste.ubuntu.com/871477/ [14:11] rogpeppe, i'd go for a proper net conn/rpc but its not particularly relevant atm [14:11] hazmat: io.ReadWriter can be a proper net conn [14:12] hazmat: (the rpc details are all hidden behind the API) [14:15] rogpeppe, ah ic.. yeah.. os.StdIn threw me.. but indeed it could be any net conn [14:17] hazmat: yeah. i thought the standard thing could be to read a directory containing executables with external providers, and start them up (if needed) with a duplex pipe on their stdin === almaisan-away is now known as al-maisan [14:43] Hey, what is a reliable example charm.. is it still wordpress? [15:22] Daviey: yeah, though I find thinkup more interesting. :) [15:22] Daviey: mediawiki is also a decent choice. [15:23] Daviey: and our beloved python-moinmoin [15:24] SpamapS: heh, really just want a golden charm to use as part of openstack ci testing [15:24] So something that uses a bunch of instances, and certainly reliable. and fast :) [15:27] Daviey: lots of instances, I'd go with mediawiki [15:28] Daviey: because its really mysql+memcached+mediawiki [15:28] Daviey: and all of those deploy from the ubuntu archive, so they will be fast in theory. :) [15:29] SpamapS: super.. and can screenscrape a string from the default mediawiki landing page. [15:29] Super! [15:30] Daviey: you can even set the string you want by setting the title [15:31] SpamapS: don't get cocky now. :) [15:31] Daviey: juju set mediawiki name=x49493hfasdfasdf9a1 and then look for that [15:33] hazmat: still charmtests.markmims.com [15:33] SpamapS: nice! [15:35] hazmat: thanks for the ownership change... I'll try to push [15:37] worked [15:46] I thought destroy-service griped at you if the service you're killing has active relations [15:49] m_3, guru meditation unavailable [15:49] m_3, it doesn't [15:49] m_3, the relations get destroyed [15:49] m_3, your jenkins appears to be hosed [15:49] hazmat: yeah, bouncing to pick up the new charmrunner changes [15:50] let you know when it's back up [15:50] m_3, thanks [15:50] most changes can be caught during an upgrade, but I edited some charmrunner packages manually and wanted to wipe [16:03] hazmat: so elastic ips (bug #937949)... would it be reasonable to update these with zkcli or are addresses stored in the agents themselves? [16:03] <_mup_> Bug #937949: juju status shows addresses that are out of sync < https://launchpad.net/bugs/937949 > [16:05] m_3, hmm.. so the cli always uses the latest ip address as given by the provider, but the inter unit communication uses addresses recorded by the unit agent at startup [16:05] the unit agent does not have any knowledge when the address changes [16:05] we could setup some sort of poll update for it [16:06] hazmat: right... so I'll never be assigning an elastic ip to a bootstrap node... they'll always be able to phone home [16:07] m_3, hmm.. [16:07] m_3, we effectively send a machine and unit agent the dial home address when we launch the machine, if it changes at runtime its problematic [16:07] right [16:07] m_3, but in this context its not really an issue outside of the status inconsistency [16:07] because the private address doesn't change [16:07] the cli seems to use a mix of the two.. 'juju ssh 4' works fine but 'juju ssh ' doesn't [16:08] but in general fluid networking isn't something we've dealt with very well [16:08] m_3, yeah.. for anything relating to a unit address it delegates to the stored value [16:08] I've had problems changing relations with a unit that's been assigned an elastic ip [16:09] m_3, really? the private address is the same. [16:09] example: head(varnish) gets an elastic ip [16:09] but had a problem destroying and re-relating related services [16:10] m_3, if you have an example i'd be happy to take a look [16:10] sorry didn't keep the stack up and really have time to debug it... happened last week [16:10] er a recipe to reproduce [16:10] lemme see if I can reproduce [16:10] it's secondary atm tho... I can keep the head up without an elastic ip for now [16:11] just was wondering if I can fix the elastic ip problem manually by sshing into 0 and zkcli.sh [16:13] (charmtester still pending btw) [16:14] SpamapS: server meeting? [16:14] Daviey: as usual, 0800 is the worst possible time for it. :) [16:15] just now back from dropping son off [16:15] :( [16:27] hazmat: charmtests.markmims.com is back up... about to pound it with jobs [16:31] m_3, what's the instance size [16:32] m_3, and how many instances are actually running tests at a given moment? [16:33] m1.large [16:33] m_3, doesn't look like you have the latest changes [16:33] three currently, but that'll change based on the environments we feed in to test [16:33] m_3, that value should be converted in the cli [16:33] i.e., one per series or not [16:33] not at point of usage, but at point of ingest [16:33] ie.. add_argument(type=float [16:34] ah, gotcha [16:34] lemme see why it's not picking up the latest... it's doing an easy_install iirc [16:35] m_3, yeah.. that's going to get bzr revs [16:35] er.. not going to get [16:35] yeah, it's just 'easy_install -q charmrunner' [16:35] m_3, un momento, i'll fix correctly and publish new version, eta 10m [16:36] I'd really like to just include it into the charm-tools package eventually [16:36] thanks [16:40] m_3 done [16:41] bouncing [16:41] m_3, its more a juju-jitsu thing.. imo, but its mostly immaterial to me.. if you want to package it up sounds good to me.. i'm going to add env/stack dump/load next [16:42] given infinite time, i can accomplish infinite things ;-) [16:42] ha! [16:42] yeah, it'd be useful to get something like snapshot working for other providers [16:43] that's what people want to see once this is stable [16:43] but one thing at a time [16:58] the decision to put things in one place or other goes like this. If it does anything with charm *content* or *lists* , it should be in charm-tools. Everything else goes in jitsu [17:00] SpamapS: sounds good === al-maisan is now known as almaisan-away [17:44] SpamapS: m_3: hey we should catch up today [17:44] I have some questions! [17:44] and I wanna hear about strata [17:44] jcastro: yup [17:44] jcastro: sure, we have a team call, then you [17:58] jcastro: invite out [17:58] m_3: ^^ [18:03] SpamapS, can i join in? [18:15] SpamapS: I'm uncertain of the changes proposed to the charm-tools package, I don't know if they're...generic enough [18:16] which changes? [18:19] SpamapS: https://code.launchpad.net/~gmb/charm-tools/add-charm-helpers/+merge/96204 [18:21] SpamapS, come back [18:21] ugh.. unicode decode errors all over the charm browser [18:21] * hazmat shakes fist at jamespage [18:22] ;-) [18:22] X crash [18:22] hazmat: re-invite pls [18:23] SpamapS, done [18:29] hazmat, i didn't see those decode errors, but http://charms.kapilt.com/charms/precise/hadoop produces "Internal Server Error" [18:29] jimbaker, yeah.. its there under the hood [18:29] its a unicode decode error [18:30] hazmat, i assume we should be able to handle unicode in charms? [18:31] jimbaker, its a template rendering problem, there's probably some ascii string getting mixed causing the issue [18:31] hazmat, sure [19:22] jimbaker, it was one of the readme files on disk, fixed now [19:23] nijaba: just now saw your bug comment re drupal. PING === marrusl_ is now known as marrusl [19:36] <_mup_> Bug #885297 was filed: Drupal Charm from documentation should exit 0 when related host is not up < https://launchpad.net/bugs/885297 > [19:44] hazmat, sorry - was it something I put in a README? [19:45] jamespage, i think you were just testing hazmat's code ;) [19:45] jimbaker, I see :-) [19:46] i believe it's this little bit: HDFS™ [19:46] innocuous enough [19:48] jcastro: buildbot master/slave promulgated [19:48] * m_3 rings the bell [19:48] ALRIGHT! [19:49] jamespage, no worries, not your fault at all [19:50] jamespage, it was a good unit test ;-) [19:50] hazmat, straight copy/paste from the upstream website.... [19:50] jamespage, cool, we just didn't have any unicode readme's before that [19:51] i wasn't encoding the file off disk properly [19:51] i've switched all readme processing to assume utf8 [19:52] hazmat, I'd not actually realised that by pushing them to ~charmers they would appear on the charmstore... [19:52] thats WIP for precise still [19:52] hazmat: all of the readmes were "unicode" before that. You didn't have any *wide character* readmes before that. :) [19:52] SpamapS, true [19:52] thats really the reason python got it wrong, and still gets it wrong.. because they missed the difference there [19:52] jamespage, yeah.. that's the case, i need to switch it to only consider it official when its set as the branch tip [19:53] SpamapS, py3 to the eventual rescue [19:53] hey jamespage, in case you haven't realized this yet. Your READMEs on these charms are basically going to become the canonical resource for deploying H* on ubuntu [19:53] ie. promulgated [19:53] jamespage, yeah.. that's a nice readme [19:53] so it's a good thing they are complete! [19:54] jcastro, we need to start being better about asking people to add a sensible extension for format.. right now things are really all over the place. [19:54] .rst / .markdown etc [19:54] oh, we just say README right there [19:54] what do you want the extension to be? [19:54] hazmat: does py3 assume utf8? [19:54] jcastro, whatever standard extension there is for the format the author is using [19:55] SpamapS, internally all strings are unicode, wrt to input/output its explicit encoding if you want strings, else its a byte stream [19:55] hazmat: we support .rst and markdown, what else? is that the only 2? [19:55] hazmat: ok so perhaps py3 got it better than I had thought. :) [19:55] SpamapS, i haven't really played with py3 at all outside of demos for user groups.. the anger has not come, and without anger this is no experience ;-) [19:56] jcastro, really any of the mappings here.. should be good https://github.com/github/markup [19:57] ok so steal that basically [19:57] jcastro, ie. any of those extensions. [19:57] ok, after this mail I'll use this as a reason to do a MP on the docs properly this time [19:57] and of course .txt [19:57] ugh.. hopefully not .pod [19:57] well, what do you support? [19:57] ok so we'll accept a pod but just make fun of the person? [19:58] jcastro, keep in mind though we're not rendering the format inline [19:59] jcastro, where are all the ideas/bug reports? ;-) [20:00] sorry I haven't gotten there yet, one more email to go! [20:00] where's the project again? sorry, I was doing well today but then got distracted by Clint's wild ideas [20:02] * SpamapS whispers in jcastro's idea "Wear peanuts for shoes. Eat a donut in the rain. Purple Hair...." [20:03] m_3: pretend we have a config option in a charm for node.js from a PPA vs node from the repo, what would your ideal command look like? [20:04] I'm working on that node email [20:06] jcastro: we should standardize on that... jamespage uses "release" with "distro" or "trunk" (http://paste.ubuntu.com/871998/) [20:06] jcastro: I'm good with that... 'juju set node-app release=trunk' [20:06] jcastro: is that what you're asking? [20:06] yeah [20:07] jcastro: marco talked about a charmhelper for that too... lemme look [20:07] we'd need a PPA right? [20:07] "ppa" [20:07] nope, nothing in helpers [20:07] sure [20:08] 'ppa' -vs- 'trunk'/'head'/'tip'/'edge' [20:08] I don't think in helpers [20:08] I think we had talked about it [20:09] jcastro: see if he'll own the one we already have instead of rewriting a new one... he can rewrite that one at will [20:09] right [20:14] SpamapS: hey, so got a charm-tools MP with no tests [20:14] SpamapS: but the helpers look great [20:15] SpamapS: they were added as a result of a charm review, so I'm tempted to merge it and then ask peeps for tests afterwards [20:15] SpamapS: how much of a stickler should we be on this? [20:16] it's probably asking them for quite a bit more work [20:28] m_3: smoke tests wouldn't be though, right? [20:29] m_3: if the charm that makes use of them is tested, I'd accept that as coverage. :) [22:05] SpamapS: see mail wrt. evan's deploy script [22:05] SpamapS: I feel bad that he had to make this. [22:15] <_mup_> juju/force-upgrade r460 committed by kapil.thangavelu@canonical.com [22:15] <_mup_> force upgrade unit state support [22:15] m_3, the helpers are crack [22:15] m_3, there executing juju from the units [22:17] and the buildbot charms are a quite odd as well, install juju wrappers, symlinks from outside of the charms.. [22:19] https://bugs.launchpad.net/juju/+bug/904201 <- woot! [22:19] <_mup_> Bug #904201: need supporting code to model machine constraints < https://launchpad.net/bugs/904201 > [22:25] hazmat: hmmm... maybe I got the old branch mistakenly... they fixed the reviewed problems [22:29] had some problems while promulgating... maybe barfed it [22:32] hazmat: those're fixed... just branched lp:charms/buildbot-master and slave and they're good [22:32] no wrapper and no cross-charm links anymore [22:35] m_3, cool, then perhaps its just their readme that needs an update [22:35] robbiew, just the first of several [22:35] aye [22:36] but indeed, WOOT!