[00:03] <burnbrighter> can you guys tell me if there is stored/cached information besides .juju/cache that gets stored?  I'm finding that my originally bootstrapped node is the always the first node that is getting chosen for bootstrapping.  So that is telling me the information must be stored somewhere?
[00:04] <burnbrighter> ie. after I do juju bootstrap
[00:06] <SpamapS> burnbrighter: no, its likely just maas choosing using predictable rules
[00:06] <burnbrighter> maas, really?
[00:07] <SpamapS> are you not using maas?
[00:07] <burnbrighter> I sure am.  But I thought this problem was on the juju side
[00:08] <burnbrighter> ok, maybe someone knows something over there...
[00:10] <SpamapS> burnbrighter: or do you have placement: local maybe?
[00:12] <burnbrighter> eh, placement: local?
[00:13] <burnbrighter> oh, you mean the charms?
[00:18] <m_3> I doubt it's ordering by mac, but it's possible... mostly likely something like dnsmasq or maas itself
[00:19] <imbrandon> zomg SpamapS look what i fixed
[00:19] <m_3> `ps awux | grep dnsmasq` to see where it's caching
[00:19] <imbrandon> docs working again ( still 0,6,4 )
[00:20] <imbrandon> http://juju.ubuntu.com/docs
[00:20] <imbrandon> looks like your meta stuff at the bottom isnt tho, but i'll cheeck that in a bit
[00:29] <burnbrighter> my dnsmasq is fairly standard - it only sets static IPs for the given mac addr, and sets the domain to localdomain
[00:33] <imbrandon> oh now THAT is nice
[00:34] <imbrandon> first chrome app worth something , a fill working native ssh client
[00:34] <imbrandon> in a tab
[00:34] <imbrandon> even draws things correctly
[00:35] <imbrandon> https://chrome.google.com/webstore/detail/pnhechapfaindjhompbnflcldabbghjo/related
[00:36] <m_3> imbrandon: wow
[00:37] <imbrandon> yea you can even bookmark the server
[00:37] <imbrandon> once logged in
[00:37] <imbrandon> and its made by the chromium devs
[00:37] <imbrandon> ( intended for chromebooks but i have it open on osx and it works fine here )
[00:37] <imbrandon> works great actually
[00:38] <imbrandon> even irssi and byobu hotkeys work
[00:39] <m_3> imbrandon: have to play with it... wonder if you can pass args through the url
[00:39] <m_3> great for classroom stuff if you could
[00:39] <imbrandon> wow and inspecting element on the page, its normal html output but realtime
[00:39] <imbrandon> thats why it looks so nice
[00:39] <m_3> cool
[00:39] <imbrandon> and yea you can it loks like
[00:39] <imbrandon> looksing at the bookmark
[00:40] <imbrandon> chrome-extension://pnhechapfaindjhompbnflcldabbghjo/html/nassh.html#root@15.185.101.99:22
[00:41] <m_3> omg
[00:41] <m_3> when did you start having to sign in to add extensions
[00:41] <imbrandon> :)
[00:41] <m_3> wow
[00:41] <imbrandon> umm since forever
[00:41] <m_3> no way
[00:41] <imbrandon> yea, iirc its always been like that
[00:41] <m_3> there were several extensions I've installed without having to sign in to my google acct
[00:42] <imbrandon> cuz it follows ya profile to other computers
[00:42] <imbrandon> how do you run chrome at all without signing in ?
[00:42] <imbrandon> mine nags to sign into the BROWSER
[00:42] <m_3> 've got like 6 different profiels
[00:42] <imbrandon> :)
[00:42] <imbrandon> yea i use 3
[00:42] <m_3> one is signed in for gmail... the others aren't
[00:43] <imbrandon> gonna make a special one jusy for this
[00:43] <imbrandon> this rocks
[00:43] <m_3> right
[00:43] <imbrandon> and you could easily short url that i think,dunno but definatly a href= link it
[00:44] <imbrandon> i cant get over just how much it is like a term and not like a JS rendition of a term
[00:44] <imbrandon> heh
[00:45] <imbrandon> and things like CTL+a baksp work
[00:45] <imbrandon> as expected etc
[00:46] <imbrandon> <embed style="position: absolute; height: 0px; " src="../plugin/ssh_client.nmf" type="application/x-nacl">
[00:46] <imbrandon> i'ma have to look into these native client apps, man
[00:46] <m_3> imbrandon: ah, only _some_ extensions require this
[00:46] <imbrandon> ahh
[00:47] <m_3> prob all ones after a certain date or something
[00:47] <imbrandon> yes
[00:47] <imbrandon> i bet
[00:47] <burnbrighter> if anyone has any ideas, I am seeing this...
[00:47] <burnbrighter> ituser@maas01:~$ juju -v status
[00:47] <burnbrighter> 2012-06-29 00:46:10,105 DEBUG Initializing juju status runtime
[00:47] <burnbrighter> 2012-06-29 00:46:10,114 INFO Connecting to environment...
[00:47] <burnbrighter> 2012-06-29 00:46:10,213 DEBUG Connecting to environment using maas03...
[00:47] <burnbrighter> 2012-06-29 00:46:10,213 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="maas03" remote_port="2181" local_port="54681".
[00:47] <burnbrighter> 2012-06-29 00:46:13,223 ERROR SSH forwarding error: ssh: connect to host maas03 port 22: No route to host
[00:47] <burnbrighter> that must be cached info from somewhere?
[00:48] <m_3> burnbrighter: once you've bootstrapped, yes the bootstrap nodes' info is cached for all subsequent commands to know where to route to
[00:48] <m_3> burnbrighter: but that should be destroyed on a `destroy-environment`
[00:49] <burnbrighter> but it always ends up going to the same node - maas03
[00:49] <m_3> burnbrighter: the initial bootstrap is handed a machine from the provider (maas in this case)... I'd expect that maas makes the decision of which machine is the bootstrap node
[00:49] <imbrandon> then the chooseing alg could be the same
[00:49] <burnbrighter> even after destroying things and deleting the cache directory
[00:49] <m_3> so that's possible cached in maas, or at a lower level in dnsmasq
[00:49] <imbrandon> its maas choosing not juju
[00:50] <imbrandon> i dont think juju COULD choose if it wanted to
[00:50] <burnbrighter> ok ok, you guys win :)
[00:51] <m_3> imbrandon: there're constraints for juju to choose, but I don't think that's implemented in the maas provider (or maas itself) yet
[00:51] <imbrandon> right but even then they cant say i want the node with this mac
[00:52] <imbrandon> they just say i want the one that has a quad proc
[00:52] <imbrandon> or soemthing
[00:52] <m_3> imbrandon: similar to 'juju deploy --constraints="instance-type=m1.large" ...'
[00:52] <imbrandon> sure but even then you could get a diff m1
[00:52] <imbrandon> every time
[00:52] <imbrandon> juju cant garentee it would be the same one
[00:53] <m_3> imbrandon: there were specs for '--constraint="tagged-with=junk"'... but dunno what'll come out of it
[00:53] <imbrandon> yea now that could
[00:53] <imbrandon> and that would rock
[00:53] <m_3> (we need that for rack-locality in openstack)
[00:54] <imbrandon> yea we need access to alot of the lower stuff, maybe not needed for every charm etc
[00:54] <imbrandon> but we cant not care about it
[00:54] <m_3> need to start pushing for tag constraints in ec2 too
[00:54] <imbrandon> else we'll have to have another provisoning agent
[00:54] <imbrandon> between us and the provider to do it
[00:54] <imbrandon> us = juju
[00:54] <m_3> yup
[00:55] <imbrandon> but as long as juju must provision then we must have access to configure the bare metal if needed , sure abstract it 99% of the time
[00:55] <imbrandon> but the 1% will make it 100% unuseable
[00:55]  * imbrandon preachin to the quior
[00:56] <m_3> I do see the value of pushing the abstraction... but yes, the tool should support the corners as well... we can push the abstrction socially with examples
[00:56] <imbrandon> ohhhhhhh i havent tried my new hpc config yet ....... /me does that
[00:57] <imbrandon> m_3: exactly
[00:57] <m_3> i.e., it really is a totally new way of approaching most problems
[00:57] <imbrandon> yup
[00:57] <m_3> especially when you start looking at maas as using "ephemeral" instances
[00:57] <imbrandon> i mean its very very simple to give us EVERYTHING , all in one swoop, i've already got it figured out
[00:57] <m_3> gotta balance the paradign shift with just outright saying "no" all the time
[00:58] <imbrandon> its like 25 loc + tests
[00:58] <m_3> everything wrt what?
[00:58] <imbrandon> anything below juju we may need
[00:58] <m_3> more coffee brb
[00:58] <imbrandon> kk
[00:59] <imbrandon> all we need is the ability to pass in one string ( a https url ) to a user script that gets appeneded to cloud-init like the other scripts and settings juju does
[01:00] <imbrandon> this bypasses the 16kb limit on size and the script can then be in bootstrap at clout init just like juju and do whatever it needs
[01:00] <imbrandon> and pass info etc etc , basicly it would be a custom juju plugin or equivilant as there would be not a juju api to use
[01:01] <imbrandon> but your loading in initramfs at that point
[01:01] <m_3> hmmm
[01:01] <m_3> dunno
[01:01] <imbrandon> and thats all the code it took, the hard work was laid out by the cloud init team
[01:01] <imbrandon> you seen that you can run puppet and chaef and
[01:01] <imbrandon> all kinda stuff directyl from clout-init
[01:02] <imbrandon> native
[01:02] <m_3> best way to communicate about it is a combo of jistu and charm-tools branches that implement
[01:02] <imbrandon> yup, already on it :)
[01:02] <m_3> rockin
[01:03] <imbrandon> got it so far decided i did not know node well enough so i started a new design doc and am going with something i know .... not phpp
[01:03] <imbrandon> heh
[01:03] <imbrandon> ruby :)
[01:03] <imbrandon> well probably as i know it the 2nd best
[01:03] <imbrandon> and i dont want to be learning node AND pulling some coool hacks
[01:03] <imbrandon> :)
[01:04] <imbrandon> sides i can take advantage of cloud-inits capistrano client then too :)
[01:08] <imbrandon> m_3 / SpamapS / jcastro : http://bholtsclaw.github.com/html5slides/templates/ubuntu/
[01:08] <imbrandon> last slide tells how to dl the template , i'm gonna make a slight variation for juju specific too
[01:09] <imbrandon> ( plus looks great on an ipad and iphone for postign online after the talk too, as well as when ya give it :P )
[01:10] <imbrandon> sugestions welcome :) but that gives the team a consistan look and feel for the charm school slides and stuff
[01:11] <m_3> imbrandon: nice
[01:11] <m_3> thanks!
[01:11] <imbrandon> yw :)
[01:12] <imbrandon> bah i goofed the link on the last page
[01:12] <imbrandon> it has to be https:// to work fixing now but if you already loaded it you need to refresh
[01:13] <imbrandon> or add https://
[01:13] <imbrandon> to get the downloadable index.html
[01:13] <imbrandon> ( rest of the assest load remotely from the one JS call in the top
[01:13] <imbrandon> )
[01:15] <imbrandon> fixed :)
[01:15] <imbrandon> https://raw.github.com/bholtsclaw/html5slides/gh-pages/templates/ubuntu/index.html
[01:15] <imbrandon> is the raw
[01:16] <imbrandon> jcastro: new docs are LIVE!
[01:18] <m_3> imbrandon: and here I was all excited about tpp
[01:18] <imbrandon> hehe :)
[01:20] <imbrandon> i think i can embed EVERYTHING too, into data uri's and put it at the bottom, ( the css and js and logo images )
[01:21] <imbrandon> then it would be truely just one file
[01:21] <imbrandon> firefox, safari, chrome and ie8+ would all be fine
[01:22] <imbrandon> dunno if i care about ie7 enough to let it stop me
[01:22] <imbrandon> :)
[01:23] <imbrandon> whats tpp ?
[01:27]  * imbrandon hugs his avatar http://bholtsclaw.wpengine.netdna-cdn.com/wp-content/uploads/brandon-penguin.png
[01:29] <m_3> imbrandon: apt-cache show tpp
[01:30] <imbrandon> oh nice :)
[01:30] <m_3> ncurses slides... they're fun let's do you stuff like http://paste.ubuntu.com/1065310/
[01:31] <imbrandon> nice
[01:31] <m_3> depends totally on the crowd... but it works if you're already in a tmux session on a shared ajaxterm doing a demo
[01:32] <imbrandon> hrm but with mine you can put a whole ssh term into the iframe of a slide :)
[01:32] <imbrandon> hehe
[01:32] <m_3> and since _tmux_ lets you control everybody's screen that they're looking at... :)
[01:32] <m_3> ha yes
[01:32] <m_3> exactly inverted
[01:32] <m_3> nice
[01:32] <imbrandon> :)
[01:32] <m_3> that rocks
[01:33] <imbrandon> that is pretty slick tho
[01:33] <imbrandon> i'ma have to check it out
[01:34] <imbrandon> more of the sleep movie
[01:34] <imbrandon> yo dawg i herd u liked ssh so we put some ssh into your slides that have some slides in their ssh
[01:42] <lifeless> SpamapS: I replied fwiw
[03:34] <negronjl> hazmat: you still around ?
[03:53] <negronjl> flame on
[03:54] <negronjl> ... and with that ..... I call it a night ... later all
[10:25] <jml> tee hee: https://juju.ubuntu.com/docs/write-formula.html
[10:42] <m_3> jml: doh!
[10:45] <jml> I want to fetch some branches in my charm. They require authentication (username, ssh key) to get. What do I do?
[13:44] <hazmat> jml, service config
[13:50] <sidnei> hazmat, is it safe now though? i remember there was some discussion about it being publicly accessible from zk
[13:51] <hazmat> sidnei, zookeeper isn't encrypted or acl'd, a zk client can discover information yes, that's not a permanent scenario though
[13:52] <SpamapS> jml: is there any reason you're not just embedding the branches in your charm btw?
[13:52] <SpamapS> hazmat: IMO we have to remove all of the data from ZK and only use it for structure
[13:52] <jml> SpamapS: Canonical Webops deploy to production from config-manager branches that are kept private
[13:53] <jml> SpamapS: I want to re-use as much of their deployment chain as possible
[13:53] <SpamapS> hazmat: config settings should go directly to units, and on add-unit, the settings should be sent peer to peer. Same with relation data. It terrifies me that ZK has all of the usernames/passwords for the entire environment.
[13:54] <SpamapS> jml: ah interesting
[13:54] <jml> currently, my branch uses a public fork of that config-manager config.
[13:58] <hazmat> SpamapS, then it should terrify for you any config management system, because they all have it centrally
[13:58] <hazmat> they do a better job of protecting the kitty
[13:58] <hazmat> and if i can nail this libzk issue, we can haz some acls
[13:59] <hazmat> although perhaps that will get last minute veto'd too
[14:01] <jml> SpamapS: also, that config-manager branch fetches other branches -- the project itself and some of its dependencies. I don't want to embed them in the charm. That would be getting the cart before the horse.
[14:02] <hazmat> jml, service config is the mechanism for this
[14:03] <jml> hazmat: `juju set libdep-service launchpad-private-key-file=~/.ssh/id_rsa`?
[14:03] <hazmat> jml, contents of the key
[14:03] <jml> hmm, no, because it wouldn't be able to access it.
[14:03] <jml> right.
[14:03] <jml> juju set libdep-service launchpad-private-key-file="$(cat ~/.ssh/id_rsa)"
[14:04] <jml> s/-file//
[14:04] <hazmat> yup
[14:04] <jml> well, except presumably the decrypted version
[14:05] <hazmat> jml, right no password on the key since their is no user agent on the remote sys, but that already applied i assumed
[14:05] <jml> I'm sure the other developers won't mind sending their private ssh keys in the clear
[14:06] <hazmat> jml, ? why not create a separate user in the lp group for this
[14:06] <hazmat> ie a deployment user
[14:06] <hazmat> or are you doing this not from group owned branches
[14:07] <jml> no, they're all owned from groups. we could do that.
[14:07] <jml> it's a bit annoying that the deployment user would have write access.
[14:07] <jml> but that's LP's problem.
[14:07] <hazmat> jml, that's an lp issue
[14:09] <hazmat> SpamapS, re p2p rels via zeromq.. its interesting and definitely has merit imo.. but i don't see it happening without some advocacy to juju-dev and the core team.
[14:19] <sidnei> jml, one alternative i've considered is packing all the branches into a 'dumb' package, putting into a private ppa.
[14:20] <sidnei> jml, effectively, just running the build step that triggers the config-manager bits and throw that into a .deb.
[14:22] <_mup_> Bug #1019294 was filed: a charm publisher instance should handle the same charm being uploaded twice  <juju:New> < https://launchpad.net/bugs/1019294 >
[14:41] <negronjl> 'morning all
[14:47] <negronjl> hazmat: lp:~hazmat/juju-jitsu/deploy-to is empty. ??
[15:18] <sidnei> SpamapS, hazmat: know about the status of #993034? seems like it should be resolved, but i just upgraded to the ppa version (was running a version before the fix) and it doesn't seem to have fixed the issue?
[15:18] <_mup_> Bug #993034: lxc deployed units don't support https APT repositories <verification-needed> <juju:Fix Released by davidpbritton> <juju (Ubuntu):Fix Released> <juju (Ubuntu Precise):Fix Committed> < https://launchpad.net/bugs/993034 >
[15:21] <hazmat> sidnei, that should be fixed
[15:21] <hazmat> sidnei, pls comment on the bug if you have a reproducible case for it
[15:21] <sidnei> maybe i need to juju bootstrap again or something (after apt-get upgrade juju)?
[15:22] <hazmat> negronjl, it should be there
[15:22]  * sidnei checks what the actual fix is
[15:22] <negronjl> hazmat: It's empty ... forgot to push maybe ?
[15:23] <negronjl> hazmat:  I reviewed the code from the other webapp ( codereview .... )
[15:23] <hazmat> No new revisions or tags to push.
[15:24] <negronjl> hazmat:  What do you see when you check this page: http://bazaar.launchpad.net/~hazmat/juju-jitsu/deploy-to/files
[15:25] <hazmat> negronjl, oops
[15:26] <sidnei> hazmat, i think the lxc template needs to be refreshed after upgrading, a destroy-service/deploy combo still has the old version of /etc/apt/apt.conf.d/02juju-apt-proxy, even though i confirmed that /usr/share/pyshared/juju/lib/lxc/data/juju-create has the fix
[15:26] <hazmat> sidnei, its only cleand out if the env is destroyed
[15:26] <hazmat> sidnei, each env has a template container with customization thats cloned for units
[15:27] <sidnei> hazmat, as suspected. thanks!
[15:27] <negronjl> hazmat: can you merge it into jitsu ?  I approved your MP already but, can't get to your branch
[15:29] <hazmat> negronjl, i'm waiting for the last sparks to fly
[15:29]  * negronjl nods
[15:34] <hazmat> ec2-east down again
[15:34] <hazmat> i find it odd that jujucharms has managed to survive all the recent ec2-east outages
[15:34] <hazmat> not doing enough 'real' work i guess
[15:35] <sidnei> survival of the weakest, that's how the cloud rolls *wink*
[15:36] <negronjl> hazmat:  dont jinx it :)
[17:39] <jcastro> negronjl: SpamapS uhhh wow. The queue has _2_ items in it.
[17:39] <jcastro> did you guys do a massive sprint or something?
[17:48] <hazmat> i should remove those
[18:32] <negronjl> jcastro:  check again ... nothing on the queue :)
[18:33] <jcastro> <3
[19:33] <bkerensa> jcastro: is uber list live yet?
[19:33] <jcastro> uberlist?
[19:33] <bkerensa> jcastro: for HP Cloud
[19:34] <jcastro> hey we demoed subway live at velocity
[19:34] <jcastro> nope, unfortunately we are still waiting on them
[19:34] <jcastro> I've asked for a status report this week already
[22:02] <sidnei> is there anything in charm-tools for 'give me the public address of this unit'? i saw some charms using hostname -f but i guess that doesn't generally cut it
[22:07] <SpamapS> sidnei: get-unit-info in juju-jitsu has stuff for that I think
[22:21] <sidnei> SpamapS, uhm, i guess i need to be more specific. i need the external address for exporting the hostname for the http interface
[22:21] <sidnei> SpamapS, eg, haproxy's charm website-relation-joined has "relation-set port=80 hostname=`hostname -f`"
[22:22] <sidnei> SpamapS, but running local with the lxc provider i got 'localhost' out of 'hostname -f'
[22:22] <SpamapS> sidnei: haproxy should have `unit-get private-address` not hostname -f
[22:23] <sidnei> SpamapS, awesome, that's the one i was looking for. thanks!
[22:23] <sidnei> (also, will send a MP for fixing that if no one beats me to it)
[22:26] <SpamapS> haproxy's charm needs a lot of work