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