#juju 2012-04-30
<imbrandon> s3
<imbrandon> yea
<imbrandon> hazmat: s3, gonna switch to akamia ( rackspace cloudfiles ) real soon ( probably have the update pushed by uds ) was just talking to Joey and marcoceppi earlier about it
<imbrandon> real cdn, faster, same price
<imbrandon> lots of JS optim comming too
<imbrandon> now that the server side is manageable
<hazmat> imbrandon, cool, although frankly just having more points of presence then s3 eu would be a big win (ie any cdn would be a big improv)
<lifeless> hazmat: how many pops does s3 eu have ?
<hazmat> lifeless, doesn't really matter when i'm not in the eu ;-)
<imbrandon> heh
<imbrandon> lifeless: not sure but s3 is only served from the one its stored in
<imbrandon> unless you use cloudfiles service
<hazmat> or cloudfront
<imbrandon> then its more like a cdn , origin pull that uses s3 as origin
<imbrandon> err yea cloudfront
<imbrandon> bah
<imbrandon> names all so close :)
<hazmat> imbrandon, mix and match clouds is a confusing biz ;-)
<imbrandon> heh yea
<imbrandon> i think thats how it may be with omg tho untill we grow
<imbrandon> OSAPI supprt
<imbrandon> rack for cdn aws for deploy + s3 db dump backups
<imbrandon> leaste thats the tentive plan i came up with today
<imbrandon> gotta sell it to the others
<imbrandon> but it seems like the right thing for themoment
<imbrandon> then when juju can move so can we, ver very easy
<imbrandon> but yea we've squeesed pretty much what we're gona get out of pure httpd enhancements out of it, maybe a bit more, but the rest will mostly be code and front end, right now 80% of the page req 0 to done is front end rendering anyhow
<imbrandon> thus we need to work on the JS badly
<imbrandon> and thats another place where newrelic shines , man i love that company
<imbrandon> i'm almost as much a newrelic fanboy as i am apple and github HAHHAHA
<imbrandon> monitor.us sup has gotten much better and closer to the newrelic level of service herer reciently too but not had a chance to try it myself yet
<lifeless> "Unlimited Application Insight at Light Speed!" wtf
<imbrandon> oh and if you ever consider exceptionhub for a project, dont, not even worth the $9 a quarter it costs
<lifeless> imbrandon: have you used tracelytics.com ?
<imbrandon> its so bad i actually started a self hosted opensource version and have it 80% complete, just to spite them
<imbrandon> lifeless: nah, not heard of them
<imbrandon> getexceptional and exceptinohub
<lifeless> imbrandon: js exceptions - I need that glued into LP OOPS someday
<imbrandon> are the only two that i found quickly that had php api's and js apis
<lifeless> Just haven't gotten around to it
<lifeless> already have analysis console of course ;)
<imbrandon> lifeless: i can get ya the glue, its very easy
<imbrandon> i am not great on the py part for lp you smooth the edge on that and i'll snag my bits out and givem to ya, its very simple idea these places do
<imbrandon> once its caputured its just jsond and compressed then posted to server
<imbrandon> server does all the work
<lifeless> so, basically I need a dict sent to a web service
<imbrandon> yup
<lifeless> http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops/trunk/view/head:/oops/config.py#L54
<lifeless> describes the keys we use today
<imbrandon> kk
<lifeless> they are all optional but the more the better
<imbrandon> oh thats not many
<imbrandon> i was expecting 54
<imbrandon> lol
<imbrandon> :)
<lifeless> we use bson for the rabbitmq glue / disk store -  (but json would be fine too, obviously can't do binary in that case)
<imbrandon> yea, well there might be a lib but it would add weight to the thing
<imbrandon> not sure if the diff is worth it
<lifeless> I'd use json to start with
<lifeless> lingua franca of the open web
<imbrandon> wouldent be hard to try / untry once in plkace anyhow
<imbrandon> right
<lifeless> ok, time to put on the hacking music and put my head down for a bit.
<imbrandon> yea every place i seen just gzip encodes a json req, no matter how the lang glue captures the exceptions
<imbrandon> then posts it, server gunzip's ties to an accounts sent with the api key
<imbrandon> and stuffed into a db for analytics later
<lifeless> right
<lifeless> so id is a guid or other random thing
 * imbrandon really needs to bytes the bullet and get comfy with python, i mean i know the basics , honestly more than some novices i know but still .... mid-newyears resolution ? heh
<lifeless> reporter should be configurable, e.g. LP would use 'Launchpad-js-prod'
<imbrandon> right
<lifeless> topic would probably be also configurable (e.g. LP might supply the topic in the page body, for correlation purposes)
<lifeless> ditto branch_nick and revno, LP would inject that
<imbrandon> https://github.com/bholtsclaw/exceptional-php/blob/master/exceptional/remote.php
<imbrandon> is the send bits i would convert to yer need
<imbrandon> to give ya an idea
<lifeless> ok, well I have one other thing I *have* to get done today
<imbrandon> kk
<lifeless> I might whip up the web service end of this after that, can't promise it tho. we'll see.
<imbrandon> yea i'll much with this inbetween my charms , i never speed too much at one moment , task flip
<imbrandon> sure thing
<imbrandon> spend*
<imbrandon> it is very very nice once its even half way in place tho
<imbrandon> its like, man why did i never do this 5 years ago
<lifeless> yeah
<lifeless> the zope and django versions are invaluable, key tools in LP problem diagnosis
<imbrandon> hrm
<imbrandon> zope /me runnnnnnnnnns
<imbrandon> lol jk
<lifeless> https://errors.ubuntu.com/ uses a common substrate
<imbrandon> isnt LP based on zope heavily, or was to begin with ?
<lifeless> yes, LP was one of the first zope3 things built
<imbrandon> ohhhh nice
<imbrandon> ( the ui )
<lifeless> I wouldn't advise folk to get into zope3 tho
<lifeless> it meets a very niche set of requirements
<imbrandon> heh nah, that enews i just converted , well reimplmented was zope something, bnever looked at the code only the business req , into drupal
<imbrandon> fun fun
<imbrandon> was solid and working for 10+ years tho
<imbrandon> prior to them contracting me to do that
<lifeless> prob zope2 then
<lifeless> different beast
<imbrandon> if you can tell from output its http://enews.penton.com
<lifeless> many things inherited from, but many different and no necessarily better :P)
<imbrandon> mine is http://enewspro.penton.com ;)
<lifeless>   Server: Zope/(Zope 2.7.4-0, python 2.3.5, linux2) ZServer/1.1
<imbrandon> :)
<lifeless> the pro one wants a pasword :>
<imbrandon> yea i never even had to open the code on that one, year long project with 6 guys under me full time
<imbrandon> still never touched it
<imbrandon> only the brd
<imbrandon> i was happy
<imbrandon> oh yea , prod i dont have a pass for
<imbrandon> you could hit http://dev.enews-pro.gotpantheon.com
<imbrandon> and use "admin" and "admin1"
<imbrandon> :) super secure
<imbrandon> dev server
<lifeless> Content Encoding Error
<lifeless>       
<lifeless>       
<lifeless>       
<lifeless>       
<lifeless>       
<lifeless>         
<lifeless>         
<lifeless>           The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
<imbrandon> and no i dident pick the pink and blue, it was handed to me, i only was tech engagement lead , e.g. head coder with ass on line
<lifeless> lololol
<imbrandon> NIce
<imbrandon> what browser ?
<lifeless> ff
<imbrandon> just a norm one ?
<lifeless> Accept-Encoding:gzip, deflate
<imbrandon> hrm
<lifeless> yeah, normal
<imbrandon> wow
<imbrandon> strange
<lifeless> Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
<imbrandon> never had that from anyone else but the dev is on totaly diff hardware / software than stage and prod too
<lifeless> Content-Encoding:gzipContent-Length:2522
<imbrandon> dev == some funky outsourced nginx from india with mongodb cache
<imbrandon> heh
<lifeless> ctrl-shift-refresh fixed it
<imbrandon> stage and prod was in house over there
<imbrandon> ahh prob tried to send gz headers without telling ya
<imbrandon> first time
<imbrandon> or somethn
<imbrandon> anyhow its a pretty simple app, build out newsletters that go out daily for 100+ subcompanies
<imbrandon> something like 1.3 mil email a month from that thing
<imbrandon> and its really justa wysiwyg editor for a farm of F5's blasting constantly
<imbrandon> well only prod, dev wont actually send anything
<imbrandon> legs cut out from it on back end
<imbrandon> it thinks it does tho :)
<imbrandon> but yea all UI choices on that were not me at all
<imbrandon> i mean i put theme there but was handed them
<imbrandon> and not input on changing them
<imbrandon> none
<imbrandon> grrr
<imbrandon> but yea pretty much all functional code there i either wrote or designed and hand picked the dev to complete it
<imbrandon> then did the review for merge
<imbrandon> along with anothre trusted senior dev
<imbrandon> to check me own arse
<imbrandon> considering how much that thing sends tho, and then archives forever ( in an archive db but same ui)
<imbrandon> is impressive to me even having done it
<imbrandon> the real ones probably been in production full blast since mid january and i bet arround 5 to 8 mill nodes already are in the archives
<imbrandon> but i finished the proj and opted to find another late feb
<imbrandon> so not 100% on that one
<imbrandon> dev is on my farmed out server btw, your not hackin the gibson :)
<imbrandon> i need to take the code down really
<imbrandon> yea so if you ever get an "Industry" news letter of some type , like trucker magazine or Win SQLPro
<imbrandon> look at the bottom for "Penton Media" its those freaks
<imbrandon> they own like every industry mag possible and are borderline spammers, legit but only barely thus me choosing to move on once the projcet was in a state i did not mind handing it off
<imbrandon> mmmm i do like that ui alot ( not meaning the standard ubuntu branding parts, altho those are bad ) but what chart widge/lib/whatever is thaty
<imbrandon> is it open ? or avail at least ?
<imbrandon> would be kinda nice to grab some of the new relic info and snaitize it then use that to represent it via their api
<imbrandon> instead of the embed charts the giv
<imbrandon> was gonna use google charts but that looks much slicker and dont make my cpu fan kick on
<imbrandon> lol
<lifeless> imbrandon: yes, all open
<imbrandon> nice i'll have to add that to my note pad to check out later then
 * imbrandon keeps a oldschool pen and paper otherise shiney would overule work
<imbrandon> for todo's later in the week
<lifeless> SpamapS: land your patch
<lifeless> SpamapS: for txaws
<imbrandon> wow wait a min, LP is fully open now ?
<imbrandon> wow i really need to get out of my little hole in the sand and look around a bit
<lifeless> LP has been fully open for a few years
<imbrandon> SpamapS: is awsome even deployable, i cant find any actual code or instuctions to piece existing code togather if i wanted to use it
<imbrandon> lifeless: yea, just now noticing, how dumb of me
<imbrandon> heh
 * imbrandon rembers when some ppl would sign nda's to help with it prior 
<imbrandon> infact william grant, isnt he on the LP team now
<imbrandon> bah, JS code
<lifeless> yes
<lifeless> he is
<imbrandon> cool yea he was an execlent contrib when we used to be on the same bits of ubuntu working
<imbrandon> glad for him
<imbrandon> very young too iirc ( well then , likely a full man now )
<imbrandon> lifeless: ohh this is much easier than i thought it would be
<imbrandon> i _might_ have this ready in just a few
<imbrandon> def not long tho
<imbrandon> $json_ret = $u->url_get_contents($apiurl);
<imbrandon> bah
<imbrandon> lifeless: i got to run for a bit, promised someone id help them IRL for a few , ive got a good chunk of this ripped out , its pretty isolated to begin with as i builts it from 2 or 3 others ideas i had evaluated, anyhow i'll jot ya an email if your not around when i get back
<imbrandon> probably only an hour or so
<SpamapS> lifeless: I thought I did
<SpamapS> lifeless: I don't see any pending reviews for txaws anyway
<bkerensa> SpamapS: can you have a look at https://code.launchpad.net/~bkerensa/charms/precise/locker/trunk
<bkerensa> I have a bug open for it
<SpamapS> bkerensa: you might not have noticed this, but precise's nodejs is only one patch level behind upstream
<bkerensa> SpamapS: oh
<SpamapS> bkerensa: I bet you can use the stock nodejs/npm from precise
<bkerensa> SpamapS: Yeah I will go ahead and fix that
<SpamapS> bkerensa: also you open port 8042 twice. The one after 'start' is far more appropriate :)
<bkerensa> :D
<SpamapS> bkerensa: other than that it looks pretty clean. :) You may want to explain in the README that scaling out is not possible.
<SpamapS> anyway, about to pass out.. so tired
<lifeless> SpamapS: the indicators one ?
<lifeless> SpamapS: if so, cool
<SpamapS> lifeless: yeah, in trunk aws-status is an indicator now :)
<SpamapS> https://bugs.launchpad.net/charms/+bug/991980
<SpamapS> doh
<_mup_> Bug #991980: Oneiric official branches are all locked <Juju Charms Collection:New> < https://launchpad.net/bugs/991980 >
<senior7515> SpamapS: did you guys, for lack of better word, push the precise charms to the correct repo?
<senior7515> with m_3
<m_3> senior7515: yes, the lp:charms/hadoop is in the right place... and no, we haven't deprecated lp:charms/hadoop-{master,slave,mapreduce} yet
<m_3> senior7515: those were the ones you were interested in right?  I recommend using lp:charms/hadoop on precise
<m_3> senior7515: that combo passed basic tests this morning
<senior7515> m_3: thanks a lot.
<senior7515> yeah
<senior7515> about to do some testing on that.
<senior7515> thanks
<m_3> senior7515: cool... lemme know how it goes.  love to know more about your project sometime too if it's not proprietary
<senior7515> m_3: basically just trying to compute averages of a large mongo collection on the fly..
<senior7515> averages per day, hour, month, year, graphs, etc.
<m_3> senior7515: oh cool... are you planning to fork the lp:charms/hadoop to work with mongo?  it's pure hdfs atm
<senior7515> well, not sure how this works yet.. :) But basically there is this mongo-hadoop lib
<senior7515> you drop it in the jar directory of hadoop
<m_3> senior7515: shouldn't be too much work... just thinking offhand... mongo's pretty easy to work with in general, and the mongo charm manages replsets pretty well
<senior7515> and it gives you a streaming api
<m_3> awesome!... yeah, then that shouldn't be hard to change the charm to do then
<senior7515> ohh i see, is a charm some sort of config file ?
<m_3> senior7515: it might even make sense to make that a config option in the primary hadoop charm... have to think about it
<senior7515> true
<senior7515> m_3: any idea why juju ssh doesn't work ?
<m_3> senior7515: yeah, poke around in the charm... the key places to look are the hook/install and hook/datanode-relation-changed
<m_3> no clue... there are several situations where 'juju ssh' can be broken depending on your provider
<m_3> this is more a problem with the bare metal or openstack providers
<senior7515> i'm on ec2
<m_3> ec2 and lxc providers shouldn't have that problem
<m_3> ah, then you should be good
<senior7515> it doesn't work though :)
<m_3> make sure your client version is up to date and matches what your environments.yaml says for 'juju-origin'
<m_3> i.e., both should be 'distro' or both should be 'ppa'
<senior7515> ohh k cheking
<senior7515> m_3: sooo question what does it mean that the client matches juju-origin. I mean I only have one env set up 'prod' and it has juju-origin:distro
<senior7515> what else should be there ?
<senior7515> i just did an update on the system and didn't update jujuâ¦ so I assumed is up to date
<m_3> ah, so on your client machine you can install juju from the universe archives (just apt-get install juju)
<m_3> or from a ppa (a more recent version of juju)
<senior7515> I didâ¦ my client is a server on ec2 cuz the mac juju is broken .. I reported the bug
<senior7515> but besides the point
<senior7515> yeah
<senior7515> is updated from the ppa
<senior7515> the client machine is 10.04.4 LTS soo I had to use the ppa
<m_3> ah, ok... then if you're client machine is installed from the ppa, then your environment.yaml file should have 'juju-origin: ppa'
<m_3> this makes sure that the version on your client matches the version installed on the instances
<m_3> shouldn't matter too much, but that might explain an ssh breakage
<m_3> oh...hmmm
<m_3> if your client is on ec2, then I recommend precise
<m_3> 10.04 is pretty old for juju
<senior7515> hmm i see...
<m_3> safer route to take... especially if you spun it up just for this... definitely use precise
<senior7515> ok got you.. soo basically spawn up precise new instance. install juju thereâ¦
<senior7515> will it reattach to the hadoop-master/0
<senior7515> if I do juju bootstrap ?
<senior7515> k so changing to ppa didn't work, spawning new instance for juju
<senior7515> so basically  juju is a client, and it also spawns a server on ec2 or whatevâ¦ with juju software installed. so the client sends commands to the juju server that it spawns and then it does the dirty work of installing and configuring instances etc ?
<m_3> senior7515: safest, if you can do it, is just drop it all... then spin up a precise client... then bring up a new stack of services based on the lp:charms/hadoop charm.. and test from there
<senior7515> ok...
<senior7515> will do. then...
<m_3> senior7515: yes, great description
<senior7515> ok off to killing and spawning
<m_3> that's totally my life lately... waiting on ec2 :)
<senior7515> m_3: soo ok I finally terminated everything and i'm up and running with juju server and client installed on precise
<senior7515> do I just do juju deploy hadoop-master ?
<senior7515> or I have to clone the charms repo
<senior7515> and install from a local dir ?
<m_3> senior7515: sorry.. in a meeting atm... clone lp:charms/hadoop, not hadoop-master
<m_3> the one hadoop charm itself is the one to use
<m_3> the README file in lp:charms/hadoop has some great walkthroughts
 * m_3 finding link
<m_3> https://code.launchpad.net/~charmers/charms/precise/hadoop/trunk
<m_3> senior7515: ^^
<m_3> senior7515: and http://jujucharms.com/charms/precise/hadoop
<m_3> the last link shows the README with the examples
 * m_3 gotta run
<senior7515> m_3: thanks a lot!
<jcastro> arosales: https://blueprints.launchpad.net/sprints/uds-q?searchtext=juju
<jcastro> arosales: ok so I made all the juju sessions people wanted
<jcastro> but then I realized that I have super launchpad powers so they become autoapproved.
<m_3> jcastro: thanks man!
<jcastro> arosales: what's supposed to happen is you need to approve the ones under servercloud-q-juju
 * arosales is looking
<jcastro> so I think to make up for that you can just tell me which juju ones you think you'd like to see consolidated, etc.
<jcastro> or if you think they're good to go
<jcastro> the only one I'm confused about is this intelligent brain thing
<arosales> 17 for servercloud track . . .
<jcastro> m_3: ^^^ more PhD  research? :)
<arosales> jcastro: does that fit into the schedule ok?
<jcastro> yep, it does
<m_3> jcastro: can you kill the first versions "/juju" of the two blueprints that were already there?
<jcastro> I think I'd rather overbook a little bit because we can always say "we don't need this, remove it." on the fly
<arosales> jcastro: if it fits into the schedule ok, its ok with me.
<jcastro> whereas "oh no we need to find room for 5 more sessions this week" would be tough
<m_3> jcastro: that stuff's just about autoscaling tools
<m_3> we can bump it to next series if you want
<m_3> people have been asking for it
<arosales> m_3: and SpamapS probably have a better pulse on things that can consolidated though
<jcastro> m_3: done
<m_3> danke
<jcastro> m_3: ok I can fix the description so that's more obvious
<m_3> by all means
<arosales> are these dups?
<arosales> https://blueprints.launchpad.net/juju/+spec/servercloud-q-juju-intelligent-infrastructure
<arosales> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-intelligent-infrastructure
<jcastro> the first one is for the wrong project, I just declined it
<jcastro> so we're good
<arosales> jcastro: same with https://blueprints.launchpad.net/juju/+spec/servercloud-q-juju-integration
<m_3> arosales: yeah, I'd mistakenly put them under /juju instead of /ubuntu
<arosales> and https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-integration
<jcastro> yep, killed that one too
<arosales> ah ok
<jcastro> I just refiled them under ubuntu that's why they're there, though I wonder why LP doesn't drop them from the list
<arosales> jcastro: thanks for documenting those blueprints
<m_3> hulk should be happier now
<jcastro> pro tip for you guys:
<jcastro> always schedule early, even if the bp is empty.
<m_3> he's totally gotta be watching for that name now :)
<jcastro> because when the slots fill you are doomed
<jcastro> so I like to claim my space early
<m_3> jcastro: good to know
<jcastro> then go back and fill it with content, agenda, etc.
<arosales> jcastro: thanks for the info, that makes sense
<jcastro> m_3: when these schedule in about 15 minutes, what you'll want to do
<jcastro> is go into each session from the schedule
<jcastro> and like, layout an agenda and stuff
<arosales> jcastro: if we need to we can shorten the mysql ultils session to just one hour.
<jcastro> m_3: that way you can just walk into the session and know what to do, as I always forget and UDS is a brain shuffling spaz fest, so I put my notes in the etherpad before I get on the plane.
<arosales> jcastro: if servercloud spots become crampe
<m_3> jcastro: you're critical in a couple of those too
<jcastro> yeah
<jcastro> i've criticalled you guys on some of mine as well
<jcastro> arosales: http://summit.ubuntu.com/uds-q/2012-05-07/display
<jcastro> looks like only about 1/3 of the rooms have been booked per hour
<jcastro> so we should be good
<arosales> jcastro: ok, thanks.
<jcastro> arosales: I'm going to try to make Thursday as juju empty as I can so we can have time for contest/demo planning, etc.
<m_3> yeah, we totally have a lot of overlap
<jcastro> I'm just waiting an hour for the schedule to settle, then I'll make ours nice and smooth
<m_3> charm release process -vs- charmstore maintenance
<m_3> juju best practices -vs- charm workflow
<m_3> cool
<jcastro> I want workflow to be more about fixing the 10 step process
<jcastro> than the actual best practices for authors
 * m_3 just wants to go to desktop icon sessions all week
<arosales> jcastro: cool, thanks.
<arosales> jcastro: also it looks like http://summit.ubuntu.com/uds-q/meeting/20357/servercloud-q-cloud-imgages/
<arosales> is having some issues
<arosales> I think utlemming filed a bug
<arosales> its linking to the wrong blueprints, and thus not scheduling with the correct folks who have limited availabilit
<arosales> availability
<jcastro> I think the misspelling threw it off at first, I'll check
<arosales> jcastro: thanks for taking a look.
<arosales> jcastro: if need be, can we manually move it to monday or tuesday
<jcastro> k
<arosales> jcastro:  thanks for all help, and documenting the juju blueprints
<jcastro> arosales: tuesday, 16:15
<arosales> I think that works, I'll confirm with utlemming in ubuntu-server
<m_3> jcastro: there were two on charm testing... James had a charm-testing in general
<m_3> in addition to the unit-tests
<jcastro> m_3: oh those I combined, you need them seperate?
<m_3> no, combined is fine with me
<m_3> also juju-upstart-integration was william's...
<m_3> don't know if James added himself on that or you did
<m_3> jcastro: Barton's asking for you
<jcastro> ok, hopping on
<m_3> you need the #?
<flepied> how can we customize the installed packages on all systems ? to use a configuration engine like puppet or chef, I need it pre-installed on all system...
<m_3> flepied: it's easy to add to the top of the install hook... there're discussions of adding some packages to metadata, but it's easy to do in the install hook
<m_3> flepied: you can add ppas or other package sources there too.. it's just shell script
<flepied> m_3, I don't want to do apt-get in the install hook, I want to use puppet for example...
<m_3> flepied: right, I'm saying you can bootstrap puppet in the install hook
<m_3> that's easy with puppet... chef's a little more work, but it's easy to add too
<adam_g> jimbaker: i saw something in my scrollback re that relation-get bug i hit last week. has that landed yet?
<flepied> m_3, in which install hook ?
<m_3> flepied: actually, that might make a great subordinate charm...
<m_3> that can be deployed alongside of any charm
<m_3> flepied: but note that juju does the "service orchestration" or coordination... best integration so far is puppet in masterless or chef in solo mode
<m_3> flepied: this is a topic for the ubuntu developer summit next week
<m_3> flepied: (juju integration in general)
<m_3> capistrano's in there too
<jimbaker> adam_g, not yet
<jimbaker> however, you can try out that branch and see that it works for you or not - i just need to add appropriate testing before it can land
<adam_g> jimbaker: ah, ok. sounds good
<jimbaker> adam_g, you can try out a version of the change in lp:~jimbaker/juju/debug-relation-hook-context, just set juju-origin as usual
<flepied> m_3, I don't think it will work to use a subordinate as it will be too late to be able to use puppet to install what is needed
<m_3> flepied: we have charms that apply puppet manifests from within hooks
<m_3> that works great
<m_3> especially with templates
<m_3> "install" hooks are called before "started" hooks
<m_3> so you can make sure anything you need is in there
<flepied> m_3, yes but if you want to use puppet to have system independence then you don't want to install it via apt-get as it'll break this independence
<m_3> flepied: sorry, not sure I understand
<m_3> flepied: install hooks can install stuff from other gems or even directly from github for that matter
<m_3> flepied: jenkins is a good example where the install source is a config parameter for the charm
<m_3> flepied: something similar can be done with the puppet install itself
<flepied> m_3, I have an example here: https://code.launchpad.net/~flepied/charms/precise/mongodb/puppet
<m_3> flepied: yeah, I see
<m_3> certainly putting something in the metadata that's a pre-dep of the charm would be a nice feature for this
<m_3> but you could certainly install puppet and deps at the top of the install hook
<m_3> packages or from a frozen repo
<m_3> there's some way to do a preseed for the cloud images too
<m_3> (that's used in MaaS)
<m_3> but that depends on your provider... I've been thinking in this conversation we've been talking about ec2
<flepied> m_3, yes but I would like to have the charm independent from the system to ease the adoption of juju from other systems than apt based ones
<adam_g> support for user-definied cloud-init /w juju would be great here :)
<m_3> adam_g: yup
<flepied> adam_g, yes that's what I would like
<m_3> flepied: until then, I'm thinking the install hook installs from other than apt packages
<m_3> but add a bug request for it unless it's already there
<adam_g> flepied: this is obviously a chicken and the egg scenario.  if you don't have control over your machine to provider to have that installed pre-juju, you'll need to install it manually in the install hook
<flepied> adam_g, I could be cool  to find a way to add a script to be run at provision time imho
<m_3> flepied: oh, one other option
<adam_g> flepied: and if you're really running this on multiple distros, that would be the only distro-specific bit in any of your hooks (if puppet is used everywhere else). a  simple shell switch statement would be easy to install using the correct package manager
<m_3> you can specify ami... so that can be custom if you want... not a good answer, but...
<adam_g> flepied: is this EC2 or ?
<flepied> adam_g, no just a general question about juju
<m_3> again, jenkins is a good example of that config
<flepied> m_3, jenkins install hook uses apt-get so I don't get where it solve the indepence issue
<m_3> flepied: one of its options is installing directly from upstream
<m_3> we have ones that use tarballs even
<m_3> but it's an easy switch
<m_3> that's configurable in config.yaml
<m_3> (first entry in jenkins config.yaml iirc)
<flepied> m_3, I don't see it but I think it'll not solve the issue for system independence as we need to bootstrap the configuration engine from what is already installed
<flepied> and it'll not always be possible
<adam_g> flepied: forgetting about juju, how do you usually ensure puppet is installed pre-first boot?  i've always used cloud-init
<flepied> adam_g, yes and I think we need the same thing in juju
<flepied> specified at the environment level
<adam_g> flepied: so (on ec2) either a custom AMI with puppet pre-installed, or a way to add that package to what gets installed via the cloud-init Juju generates?
<flepied> adam_g, yes that would be cool for all the providers
<_mup_> Bug #992153 was filed: juju deploy stuck on Starting container... <juju:New> < https://launchpad.net/bugs/992153 >
<senior7515> m_3: are you around ?
<senior7515> m_3: sorry had to fix a bug in prod :) back to devops.
<senior7515> m_3: soo this line doesn't work any ideas.. I can post my juju status if that helps but the machines deployed correctly is just the names that dont' work juju add-relation hadoop-master:namenode hadoop-slavecluster:datanode
<senior7515> actually the last thing could be answered by anyone, posting my statusâ¦ 2 secs
<senior7515> http://paste.ubuntu.com/958429/
<senior7515> i deleted the dns names but other than that
<senior7515> I'm not sure why associating the nodes don't work.
<senior7515> perhaps spamaps knows :)
<m_3> senior7515: it looks like you're still trying to deploy using the hadoop-master charm
<m_3> senior7515: you need a single charm for hadoop... lp:charms/hadoop... nothing else
<m_3> senior7515: you deploy it according to instructions in the README for that charm
<senior7515> hmmm yeah
<m_3> the "hadoop-master" that it references is just the service _name_, not the charm
<senior7515> ohhh lol
<senior7515> k
<senior7515> you are right
<m_3> it's still just deployed from the lp:charms/hadoop
<m_3> there's a big difference between the two
<senior7515> sweet thanks. err.. that was silly of me.
<m_3> senior7515: cool!
<m_3> senior7515: np.. it's confusing... we need to figure out the best way to deprecate charms
 * m_3 note to self to try to really prevent charm renaming :)
<senior7515> hehe soo this command is awesome juju destroy-environment
<m_3> totally
<senior7515> hmm wished amazon was faster
<senior7515> m_3: ok soo that was easier.. all I had to do was copy and paste the commands and add ârepositry ~/charms â¦ sweet. soo when I expose it
<senior7515> do I just expose the master ? right
<senior7515> or I need to expose all of them
<nathwill> hey all, having a bit of a problem with juju becoming confused when trying to process config values of either "YES" or "NO" (puts them out as "True","False", then chokes), no matter what i set the config key type as "string", "boolean", even tried regex, with validator 'YES|NO'
<nathwill> is this something worth reporting a bug about? or is this expected behavior?
<nathwill> i.e. here's the charm that works fine on its own, http://bazaar.launchpad.net/~nathwill/charms/precise/vsftpd/trunk/files, and here's a config override that makes juju blow up: http://pastebin.ubuntu.com/958460/
<m_3> senior7515: only expose master yes
<senior7515> ohh ok how to unexpose.. :)
<senior7515> i exposed all
<m_3> nathwill: yes, it's expected behavior, and yes perhaps it's something to report a bug about
<m_3> senior7515: actually, I have no idea
<m_3> senior7515: i'd have to look... one sec
<nathwill> m_3, ok. i'll send in a bug report...
<senior7515> just that
<senior7515> juju unexpose
<senior7515> i think
<senior7515> i just looked at the help
<senior7515> but will it be able to communicate between master and slaves
<senior7515> without exposed ports ?
<senior7515> that's cool
<m_3> nathwill: I find it quite annoying myself
<m_3> nathwill: strict type checking for no real reason
<m_3> senior7515: expose is just to the outside world... within ec2 they can talk to each other
<senior7515> ohh coolâ¦ soo i basically never have to expose
<senior7515> anything if all my stuff runs on ec2
<senior7515> except 80 or whatev I need cool good to know
<senior7515> thanks
<senior7515> unexposing
<_mup_> Bug #992237 was filed: juju fails to override charm config correctly when values are "YES" or "NO", treats as boolean even when setting type as string <juju:New> < https://launchpad.net/bugs/992237 >
<senior7515> how does one install more than one pakcage in a host
<senior7515> say I deploy package x
<senior7515> then I also want package/charm y on the same host that x deployed ?
<chmac> Can I use juju to install a handful of applications, users, etc on a standalone dedicated server? Like puppet / chef?
<chmac> Ok, not yet according to my reading of the FAQ
<senior7515> errâ¦ after reading faq.. only one service per machine
<m_3> senior7515: you can deploy some services subordinate to others on the same machine, but not two primary services
<m_3> senior7515: it's for things like loggers, monitors, storage clients, etc
<senior7515> m_3: ahh how come ? just haven't gotten around or something purposely not included ? perhaps dependency management is a pain.. dunno.
<m_3> senior7515: subordinate services just landed a couple of weeks ago
<m_3> senior7515: lots of stuff that we have planned for development
<senior7515> m_3: is it possible to deploy hadoop on one computer for dev only ?
<senior7515> with juju ?
<senior7515> the instructions add up a bunch of nodes
<senior7515> not sure if possible
#juju 2012-05-01
<m_3> senior7515: juju works against a local lxc provider for development
<senior7515> ohhh awesomeâ¦ sooo how does it work when you say -n 3
<senior7515> for example
<senior7515>  ?
<senior7515> virtual instances over some virtual engine or ?
<senior7515> disregards ?
<senior7515> or ?
<chefnewbie> a newbie's question, and I appreciate if anyone give me a quick answer: can I say Juju does exactly what Chef wants to achieve? Or can someone give me an intro to Juju and Chef's different goal?
<m_3> senior7515: well, it depends on your local resources... perhaps I'd try it with a small stack of services first (it creates lxc VMs on a single box)
<m_3> senior7515: if you have a large machine available... or pay for a large instance in ec2, then you can run a larger set of service in your local lxc cloud
<m_3> chefnewbie: chef's a great tool... it's for configuration mgmt.  Where chef is lacking atm is in "coordination" or what we're calling "service orchestration".  That's what juju's solving.. it's an eventing/coordination layer.  You could coordinate services using juju where each machine was configured with chef or puppet
<m_3> chefnewbie: the way that would work would be to have juju charms that call puppet manifests or chef cookbooks... a charm is just a set of hook scripts that get called by juju at the right time.
<imbrandon> SpamapS: ping , wanna prom this ? https://github.com/websitedevops/charms-newrelic-php
<chefnewbie> so Chef cookbook is responsible for individual machine configuration (i.e., "setup a machine as MySQL server"); where juju is responsible for a group of machine collaborating with each others ("Apache Server A talks to App Server B, B talks to MySQL server C"
<chefnewbie> is this a correct 101 understanding?
<m_3> chefnewbie: it _could_ work that way, but it really depends on the service
<_mup_> juju/unit-rel-lifecycle-start-invoker r533 committed by jim.baker@canonical.com
<_mup_> Ensure that invoker.start is called to get relation hook caching for lifecycles
<m_3> chefnewbie: a lot of services are pretty simple installations and don't need manifests or cookbooks to configure them
<senior7515> m_3: thanksâ¦ testing this mongodb-hadoop api is becoming a pain.. meh.. still wishing I had a devops guy hehe
<m_3> chefnewbie: browse through the "install" hooks on a couple of charms in jujucharms.com and you'll see some simple examples
<chefnewbie> Thanks, m_3. I am thinking of this long-term goal in my company....
<m_3> chefnewbie: more complex things like rails apps or django apps might warrant using other tools for the configuration of each charm
<m_3> chefnewbie: sure...  happy to discuss.
<m_3> senior7515: cool
 * m_3 gotta run to dinner... catch y'all later
<chefnewbie> We are a small Python shop, right now we are planning to  use OpenStack / Swift as our backend -- so, this is pretty much a python shop from infrastructure layer to application layer
<chefnewbie> if we introduce Chef, we are introducing Ruby prettey much as I understand.
<chefnewbie> We want to avoid such scenario as much as possible.
<chefnewbie> any suggestion?
<m_3> chefnewbie: after you've looked at a couple of charms like wordpress or node.js, take a peek at mysql (the hooks there are done in python)
<m_3> chefnewbie: juju hooks can be written in any language (with an ubuntu runtime)
 * imbrandon even does some in php
<senior7515> is it customary for a person to take a charm, modify the confi of the charm and then deploy or the other way around. Say you need other services etc.
<chefnewbie> we are trying to avoid Ruby as much as possbile, that's what I am trying to say :-), and that's why I am asking if Juju can serve as a complete Cloud Management stack
<imbrandon> chefnewbie: certainly
<imbrandon> its able to use pupet or others if you wish but certainly dont need them
<chefnewbie> I know people saying Juju can work with Chef, but my motivation is to have python programmers take care of the Management Stack as well (i.e., the Devops job)
<imbrandon> chefnewbie: many hooks are in python in juju
<imbrandon> infact i'd say about 50% its by far the most comon choice
<imbrandon> and those that arent are simple bash scripts
<chefnewbie> thanks, I think I roughly got what I wanted from this chat :-)
<chefnewbie> and the supportive chat room just gave me another reason to explore Juju...
<imbrandon> :)
<chefnewbie> another question: how would other OS vendors treat Juju? --I know Ubuntu will support this effort as long term commitment, but how about centos?
<imbrandon> hrm one of the juju core dev probably would be better to awsner that but IMHO its a blessing it dont, gives you a excuse to kill that abomina^W centoos with fire
<imbrandon> really with services orchstration tho service should not matter, e.g thats one rewason to use a something like this is you care about the app, not the reast of below the app
<imbrandon> the os and software running the app then becomes a commodity , not a asset, and can be started/stoped/moved thrown out etc at will
<imbrandon> and the app is fine
<imbrandon> e.g. stuff like i dont care how many mysql cluster heads or if its just one, i care that my app has a db to connect to
<imbrandon> let juju care if there are 3 heas or 3 and making them work
<imbrandon> once your to that point the os is really just a name on paper
<imbrandon> 3 heads* or 30*
<chefnewbie> well, this goal is what Chef claim to serves (i.e a layer to hide the specific OS systems), here I'd like to see how well juju has done this job.
<chefnewbie> For example, Ubuntu's /etc/networking/... controls network stuff, but that may be different in Redhad (or other vendors)
<imbrandon> chefnewbie: not sure exactly what your meaning , but real example with omgubuntu.co.uk , when it was release day a few days ago, we had it running on 1 webhead and 1 db, needed mroe capacity so i said "juju add-unit omgubutu-wp -n4"
<imbrandon> and i then had 5 webheads and plenty of room for traffic
<imbrandon> i juju took care of spinning up 4 more nodes, installing nginx, configing it
<imbrandon> making it talk to the db
<chefnewbie> imbrandon: here is my question....
<imbrandon> rsyncing the current wp relase adn code
<imbrandon> etc
<marcoceppi> chefnewbie: Charms are written currently with Ubuntu in mind since Juju is such a recent release, as the Juju core is Python it should be relatively easy to port Juju to most any other Linux based system. The charms are less portable, so you'd have to tailor each charm to its intended platform
<marcoceppi> While this might change in the future the primary goal is to build the charms in the Ubuntu ecosystem then I'd imagine branch out. Unless someone wanted to work on an RPM port of the project, etc
<chefnewbie> marcoceppi: charm is the hook (i.e., the one defining the inidvidual node's configuration)?
<marcoceppi> charms define the service to be deployed
<marcoceppi> chefnewbie: these are all charms; http://jujucharms.com/charms
<marcoceppi> rather, these are all services that have been charmed
<imbrandon> chefnewbie: think of a hook as a init.d script, they are juju scripts that fire at the right times
<imbrandon> on the node
<imbrandon> so like when juju adds more of the "webserver" service , the units all fire "config-changed" hook so that they can add ip's and whatever else they may need to their own configs etc
<imbrandon> whatever is in the config-changed hook, a bash or python or whatever script , is what gets done
<chefnewbie> imbrandon: your comparison of "think of a hook as a init.d script" made understand hook crystal-clear (for now for this 101 discussion, at least), can you further talk about charm? -- can you give a metaphor for that?
<marcoceppi> charms are just a collection of hooks
<marcoceppi> that comprise to build a service
<imbrandon> hrm heh , well it would just bee the system that kicks those off
<imbrandon> yea
<marcoceppi> chefnewbie: you can browse what hooks make a charm at any of the charms here:  http://jujucharms.com/charms
<imbrandon> and keeps info about all the nodes
<chefnewbie> so charm basically is a collection of "Cookbooks", but it does a little more ---it defines how each cooked machine should talk to each other?
<imbrandon> chefnewbie: yea marcoceppi said it perfect "charms are all the hooks it takes to build , configure, and maintain a server, wrapped into one place a.k.a a charm"
<imbrandon> and keeps track of weach service and its state
<chefnewbie> thanks, I think I should be looking at Juju doc more.
<chefnewbie> You guys are really supportive, many thanks
<chefnewbie> what is the juju's license term?
<imbrandon> yea thats one good thin, even as quick as juju is moveing the docs stay pretty upto date
<imbrandon> they are great about that
<chefnewbie> AGPL 3.0? what does that mean?
<imbrandon> gpl 3 iirc, for the program its self, chamrs are lic on their own
<imbrandon> charms*
<imbrandon> afro gpl v3
<chefnewbie> yep, it is agpl v3.
<imbrandon> but yea charms are lic individually they arent derivitive works
<imbrandon> of juju at leaste
<marcoceppi> All official charms in the charm store must be at least GPLv3 license to be included, though you can license your charms to whatever you'd like, if you want it in the store it needs to follow that and a few other criteria
<imbrandon> marcoceppi: really ? shit mine is gpl v2 and that means drupal will never be in the cs
<marcoceppi> s/must be at least GPLv3/must be under a free license: http:\/\/www.opensource.org\/licenses\//
<imbrandon> ahhh ok
<imbrandon> good god
<imbrandon> :)
<marcoceppi> Yes, I escape my chat regex lines.
<imbrandon> ahahah
<marcoceppi> GPLv3 is just recommended
<imbrandon> yea i about craped my pants there, i really dislike v3 and use v2 mostly or a simplified BSD but drupal is v3 incompatable too
<chefnewbie> AGPL v3 is stricter than GPL v3?
<imbrandon> chefnewbie: it covers webservice stuff
<imbrandon> iirc
<chefnewbie> imbrandon: what does this mean ("covers webservice stuff")?
<chefnewbie> if someone use juju to provide a service like RightScale, it needs to pay license fee?
<imbrandon> chefnewbie: think of it like this ... gpl , website dont have to give out src, its not distrubuted,   website in agpl , website must also give out src due to lic provisions specificly for that
<imbrandon> chefnewbie: and no
<imbrandon> chefnewbie: only the src to juju, unless your modify juju to actually provide the web ui
<imbrandon> if its a tools calleed on the backend
<imbrandon> then no
<imbrandon> you can write a webui and be 100% closed and still "call out" to juju
<imbrandon> as a back end program as you would with say ummm ssh or somehting
<chefnewbie> hmm, then please give me a scenario that I need to give out src, please.
<imbrandon> chefnewbie: think about it this way makes it easy, about you said the word "use" , any case where that is true then no src is needed, when you say "modify juju to do ....blah"
<chefnewbie> thanks, this is simple and easy to understand (for now, for my 101 understanding)
<imbrandon> then src and webservice would be needed to be handed out IF JUJU IS PART OF THE ACTUAL WEBSERVICE CODE , not just another tool of many it may use under da hooh
<imbrandon> basicly if you dont madify juju your golden
<imbrandon> and charms dont cound as part of juju
<imbrandon> count*
<imbrandon> okies, dinner time
<imbrandon> afk a bit fellas
<chefnewbie> many thanks, imbrandon
<imbrandon> np
<_mup_> Bug #992329 was filed: Ensure Invoker.start is called from UnitRelationLifecycle usage. <juju:In Progress by jimbaker> < https://launchpad.net/bugs/992329 >
<chefnewbie> thanks to marcoceppi, too.
<imbrandon> btw , the internet meme applies IANAL :)
<jimbaker> adam_g, lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker now contains the fix (this also adds unit testing of the fix vs the debug version i pointed to you earlier, otherwise should be about identical)
<imbrandon> ( i am not a lawyer )
<imbrandon> chefnewbie: ^^
<jimbaker> (the only other change was to make it slightly more verbose on logging the caching of the relation hook contexts)
<chefnewbie> yeah, layers make big bucks for good reason :-)
<imbrandon> yup yup , just wanted to make sure, when it comes down to it , get real advice, but thats the general gist of it
<chefnewbie> yeah, just get a ballpark of what I should pay attention to when thinking of choosing a technology for our small shop...
<imbrandon> yup, you  should be perfectly fine imho
<chefnewbie> will ask 201 questions once I get another depth of understanding...
<imbrandon> :)
<chefnewbie> after that, layers get consulting checks :-)
<imbrandon> heh
<chefnewbie> thanks again, you have a good dinner time...
<imbrandon> most of the time you can get clarification on the fsf site as they have spelled out 99% of common cases as lawyers
<imbrandon> but if not you know :)
<_mup_> juju/unit-rel-lifecycle-start-invoker r534 committed by jim.baker@canonical.com
<_mup_> Fixed tests that saw augmented log changes
<SpamapS> imbrandon: git is great, but the charm store lives in launchpad. can you push to a launchpad branch please?
<imbrandon> SpamapS: sure but jcastro told me to force yall yo learn the other workflow since its documented that github is a valid src too
<imbrandon> but yea in the intrest of time right now i will :)
<SpamapS> who?
<SpamapS> who decided that?
<SpamapS> imbrandon: I'm supportive of those who would shun git
<SpamapS> but we have a distribution built on bzr
<SpamapS> err
<SpamapS> I'm supportive of those who would *use* git
<SpamapS> Until Launchpad supports git, or the charm store supports pulling from github, new charms for the official charm store need to be on launchpad
<SpamapS> imbrandon: where is it documented btw?
<SpamapS> imbrandon: also btw, the AGPL's only difference from GPL is that *if* the service has a method for downloading the source over any network ports it opens, you cannot disable it.
<SpamapS> juju has no such method
<SpamapS> so it is effectively GPLv3
<nathwill> SpamapS: https://juju.ubuntu.com/Charms
<nathwill> in answer to your github question
<SpamapS> yeah, thats confusing
<SpamapS> since we've never discussed that as a group
<SpamapS> nor have I ever looked at the github pull requests to see if there are new charms there
<imbrandon> :)
<SpamapS> nathwill: thanks tho
<nathwill> fer sure.
<imbrandon> SpamapS: iirc m_3 is writing some glue so LP wont need to support git
<imbrandon> for the cs
<imbrandon> using bzr-git-ng
<imbrandon> least thats how jcastro splained it to me
<imbrandon> anyhow i pushed the latests newrelic-php to LP and fixed up the bug
<imbrandon> its ready for your worst
<imbrandon> i got some more commits for drupal before i'm happy but working on them now
<imbrandon> just had to stop for a omg hiccup
<SpamapS> awesome
<imbrandon> but back at it , i am
<SpamapS> It would be really awesome if somebody would actually tell *me* that so I don't feel like an idiot telling you something else. ;)
<imbrandon> hahah np
<imbrandon> i totaly understand
<imbrandon> i think thats one reason he was like, yea do it that way, so we're forced to learn the workflow
<imbrandon> like almost exact words :)
<SpamapS> man
<SpamapS> I hate that idea
<SpamapS> lets have one workflow
<SpamapS> choices lead to mistakes
<imbrandon> heh
<imbrandon> we're talking ppl that should be devs
<SpamapS> its already new and crazy and weird enough to be writing charms.. to have 2 workflows to choose from and maintain and monitor... ugh
<imbrandon> dont cut the wheels off, it should be embraced or your gonna see alot more of like what i put in the comments
<SpamapS> Its an efficiency blunder
<SpamapS> Debian has that ethos
<imbrandon> nah
<SpamapS> "choice is the almighty"
<imbrandon> just make the tools work
<imbrandon> like the glue to import from github :)
<SpamapS> And while I'm proud to wear my new Debian Developer badge (granted this weekend) I hate that part about Debian. Just pick one way and get stuff done.
<imbrandon> see i like the midground
<imbrandon> not too man but dont cut my fingers off
<imbrandon> many*
<SpamapS> If its as superior as people seem to think..
<SpamapS> then it will win out with users anyway
<imbrandon> it has
<imbrandon> thst the problem :)
<SpamapS> But it *has* to be on launchpad.
<nathwill> oh snap
<SpamapS> *has to be*
<imbrandon> your statements just contradictoed
<imbrandon> themselfs
<nathwill> SpamapS, doesn't launchpad already have mechanisms for registering upstreams and importing from various VCS systems?
<nathwill> automagically?
<SpamapS> Unless you know of another system which groups many branches by series and allows bug tracking across those branches (i.e., packages in distro, and charms in our case)
<imbrandon> nathwill: yea for projects nothing else
<nathwill> hrm
<nathwill> bet that functionality could be leveraged pretty easily
<SpamapS> nathwill: yes, launchpad can import from github
<SpamapS> we can do that
<SpamapS> But we lose linked branches
<SpamapS> and linked merge proposals
<imbrandon> SpamapS: the way your doing it in LP , github, the unicorn you describe no where without hacks like NEEDING /precise in my url or branch names for that matter like /trunk
<imbrandon> :)
<imbrandon> imho its LP thats broke tho not the cs or github, it should be easy to support both
<imbrandon> i see your grip as its not now
<imbrandon> but thats the problem , not that users wanna use something else
<SpamapS> OpenStack has proved that you can successfully have LP for bugs and git for all else.
<imbrandon> ok then let us do it
<SpamapS> But, thats at the project level. We're building a distro with potentially thousands of branches.
<imbrandon> exxactly a LP peroblem
<imbrandon> SpamapS: whats 1k;s of branches got to do with it, branches are cheap
<SpamapS> imbrandon: the management of them, is not.
<nathwill> SpamapS: ah, i see what you're saying about losing merge proposals/links
<imbrandon> the management of them is automated either way or should be
<SpamapS> no, bugs cannot be automated
<SpamapS> else we'd have entered the singularity and be fighting off skeletal robots
<imbrandon> and also why can i not link a branch to my repo on github, that should be renamed to something else reflicting that it only works with bzr and LP hosted code
<SpamapS> I'm honestly ignorant of any other bug system that allows bug tracking across concerns the way LP does.
<imbrandon> SpamapS: bah, this is better high bandwidth, but i promis you it all comes down to LP "bugs"
 * nathwill nods i think it's a killer feature
<imbrandon> SpamapS: inho that a useability nightmre and should be removed with fire
<SpamapS> were it me, I'd suggest that people just use the git-bzr thing that just pushes into a bzr branch but does git locally. Is that too hard?
<imbrandon> yes
<imbrandon> make 10000000 ppl change or fix the tool ? hrm
<SpamapS> imbrandon: so, just list out the packages that a bug affects in the comments, or have 10 bugs that duplicate the same error and how it affects each package?
<imbrandon> or fix lp to relate to github bugs and branches as well
<imbrandon> or twoway mirror git
<imbrandon> or both
<SpamapS> linking to an external bug tracker is not really what I"m talking about
<imbrandon> it accomplishes the same thing by linking bugs, we handel it all the time in drupal issue tracking, diffrent upstreams, projects, codepbases but some the same
<imbrandon> etc
<SpamapS> I'm saying, when we change charm store policy to not allow anything to have default passwords, we should have *one* bug to track all 20 charms that have violated it across the 2 series we have.
<imbrandon> yea its not the one ring but still works great
<SpamapS> If all the charms are on github, we can just paste links to the fixed branches, thats not even that much of a concern.
<imbrandon> huh ? still a bug in LP if you NEED that function and it only support LP 1 of 2 things are gonna happen, users will NOT use LP to track bugs at all and you fail or whole projects will not use the cs and you fail
<imbrandon> either way as much as we want it to be it CANNOT be absolutely tied to LP or any ONE place
<imbrandon> even github
<imbrandon> so to fix it, we make LP the easiest way, and supopiort the other ways without hacks
<SpamapS> err
<SpamapS> somehow ubuntu succeeds where this will fail?
<imbrandon> ubuntu did only because it already had critical mass
<imbrandon> it took years
<imbrandon> and juju dont have that mass
<SpamapS> I come at it from a different angle
<SpamapS> The tools are of some slight concern
<nathwill> that maas
<SpamapS> but as long as I know *how* to contribute
<SpamapS> I don't care that its not my favorite method
<SpamapS> If there are 49 islands out there with charms on them
<SpamapS> how do I pick one?
<SpamapS> paradox of choice
<imbrandon> i come at it from sf.net has been THE place for floss since it came out in 96ish, github toppled them in one year, ONE , the best way to fight that is not with force but embrace it and make your shit better
<imbrandon> if they are forced to choose they WILL choose github
<SpamapS> So, VCS is all on LP, or its all somewhere else.
<imbrandon> and make their own
<imbrandon> why
<imbrandon> why not support both
<SpamapS> github is great, but this is still different
<SpamapS> in fact
<imbrandon> vcs is distributed for a rewason
<imbrandon> it shoud not matter where it is
<SpamapS> the fracturing that github encourages which is why its so awesome for rapid dev of new things, is a detriment to the integration that we need w/ charms
<nathwill> imbrandon, i don't think developers choose to get involved with a project because of the vcs it uses... but because they like the project
<imbrandon> no
<imbrandon> omg no
<imbrandon> nathwill: your right but they choose to contrib to it or not based on that
<imbrandon> and the frequency of their conriubs
<imbrandon> SpamapS: your missing my point entirely tho
<imbrandon> and its hard for me on irc to articulate it
<SpamapS> imbrandon: the strong tie between the charms in each release is there for a reason. Throwing the charms' VCS out to the wolves means having to use some other meta-storage to bind them together to create a cohesive release.
<imbrandon> and now i'm irritated cuz i know via other convos we've had you would agree if i can figure out how to put it
<imbrandon> SpamapS: thats an infrastructure problem for the store, should not be a user issue in any way
<imbrandon> transparent
<SpamapS> well realistically the juju team seems to think thats important too, but I think they're going to run into the wall because VCS matters and they're halfway to a new VCS already
<imbrandon> SpamapS: see t5hough i'm of the firm thinking that "plan and do how it should be, if the tools, and that means ANYTHING from asm code on up to the keys on my remote to the tv dont supoort that, then fix it or change it, no compromise because of tools"
<imbrandon> in this case LP dont support git or remote bug association and a few other key things that wouold make all this moot
<SpamapS> Yeah, and my plan is, have the same VCS for all charms, bind them together in a single place, and track bugs in a single place.
<SpamapS> note, bzr, lp, not mentioned
<imbrandon> SpamapS: hehe
<imbrandon> sure tho
<imbrandon> and i fully suport that
<imbrandon> but then drop down on step
<imbrandon> thats at the store level no one else care
<lifeless> mmm skeletal robots
<imbrandon> so at the next meta step down in distrib vcs
<imbrandon> they are all over the place
<SpamapS> dvcs is fine
<imbrandon> so make some glue to brong em togtaher and your both happy
<SpamapS> but the *official* charms need a single place to tie them together
<SpamapS> there needs to be *a mainline*
<imbrandon> they are in the storwe with a vcs
<SpamapS> I know, git blasphemy
<imbrandon> no
<imbrandon> no
<imbrandon> absolutely not
<imbrandon> ok
<imbrandon> every app in itunes is in one place
<SpamapS> imbrandon: I don't have to make that glue. LP exists, and does this, now.
<imbrandon> every dev has crap everywhere
<imbrandon> SpamapS: LP is fucking broken if it wont support that then
<SpamapS> and bzr is not limiting in any way other than politics.
<imbrandon> there is no glue
<imbrandon> bullshit
<imbrandon> it fucked up the omg merges 3 or 4 times last month where git worked perfect
<SpamapS> this is editor wars. ;)
<SpamapS> imbrandon: perhaps because it was git users trying to use bzr the wrong way? :)
<imbrandon> ok look, itunes, apps all in one place, all reviews by apple, all done in diffrent palces
<imbrandon> why do i care that apple wants to keep them all in an NFS share on win3.1
<imbrandon> i dont
<SpamapS> and perhaps that is enough of a reason to step back and say "git users:bzr users seems to be about 1000:1, so perhaps we should use git"
<imbrandon> once they take it to review i dont care at all
<imbrandon> that dont fix tthe probme
<imbrandon> gaqd i hate irc
<SpamapS> imbrandon: app store apps are not integrated with one another
<imbrandon> it lets the issue get away
<SpamapS> they are, in fact, an island unto themselves.
<imbrandon> SpamapS: they certainly are
<imbrandon> no
<imbrandon> in store purchaes , receipts
<imbrandon> all kinda intergrations
<imbrandon> but that dont matter either
<imbrandon> wtf
<imbrandon> ugh
<imbrandon> you totally side steped it
<SpamapS> Its pretty rare, right?
<SpamapS> Like, *every* charm that is worth anything will have multiple integration points/interfaces which need to be tested as working on each target release of Ubuntu.
<imbrandon> it dont matter , why do i as an apple dev care what the hell apple does with my app once its in their store, awnser is i dont , so why should i be forced to care about the charm store ?
<SpamapS> Because you need your charm to work w/ mysql/memcached/etc.
<imbrandon> it can sorrte my stuff in sabdfl's pinto i dont care, but you make me care if i need to load up the pinto
<imbrandon> hplly shit
<imbrandon> SpamapS:
<imbrandon> common man
<imbrandon> i'm not even on that subject
<imbrandon> that has to do with zk and juju when running
<imbrandon> wtf does it have to do with the store
<imbrandon> then the vcs the store uses
<SpamapS> well if that subject is off the table, and we are not going to care about integration, then yes, we can make all the branches live wherever we want and just punt this to a text file that maps charm namespace <-> branch URL
<SpamapS> of course
<SpamapS> there's no trust relationship with those URLs
<imbrandon> umm thats how it shouldbe , maybe a db ya know ,21k centry and all
<SpamapS> ~charmers is a trusted party, like ubuntu-core-dev
<imbrandon> and ?
<SpamapS> so right now we own all the branches and review all changes made to them
<imbrandon> your bikesheding , it dont matter because the cs dont work directly off ~charmers it still needs to be pulled into the store repo
<imbrandon> or at minimum into the charmers repo
<imbrandon> on approval
<SpamapS> cs *does* in fact work directly off ~charmers  (well, lp:charms, same diff as its owned by ~charmers) for cs:series/charmname
<imbrandon> that is done by hand as well as trust verify
<imbrandon> ok my point still stands sans the first part
<imbrandon> ( and wow really? ewwww )
<SpamapS> Ok, so we can make that work w/o LP and bzr too, as we can have automated pulls that we review from all the branch URLs
<imbrandon> or we could fix LPO to do it too
<imbrandon> and everyone benefits
<SpamapS> imbrandon: cs:~user/series/charmname can be any LP user
<imbrandon> SpamapS: i know but that dont mean the cs
<imbrandon> well whatever
<imbrandon> thats just routing like in a django app
<imbrandon> could be anything
<imbrandon> semantics
<SpamapS> so, my point is still that this glue you speak of, that I acknowledge can be used and written, is not written, and does not exist
<imbrandon> brew install jujutools/juju is the same as ~/jujutools/Forumla/juju.rb tooo
<SpamapS> and furthermore, the process, while not super desirable, is single threaded and easy to follow right now
<imbrandon> for that matter, its all routing
<SpamapS> so until the glue exists
<imbrandon> SpamapS: yes but then it needs to be , we shouldent do something the wrong way because of it
<SpamapS> I do not want to pollute the contribution process, as flawed as it may be, with more VCS's
<imbrandon> so until it exists it should be manual
<SpamapS> there is already some work inside juju to hide these details as well
<imbrandon> right
<imbrandon> as it should
<SpamapS> there should be a 'juju publish' command that will push your local charm up to the charmstore w/o you caring about LP
<imbrandon> cool but how would it verify me then
<SpamapS> (but this gets into where now they are playing a weird game w/ VCS because of that revision file..)
<imbrandon> oh wait
<SpamapS> imbrandon: same way LP does, ssh key
<imbrandon> i would have to care and put a ssh key
<imbrandon> :)
<SpamapS> or perhaps OAuth
<nathwill> imbrandon, you do for github as well...
<imbrandon> nathwill: sure but i care for github
<imbrandon> :)
<imbrandon> i was playing devils advocate as in yes charmers will still need to care and strust lp
<imbrandon> but users wont
<imbrandon> but thats minor
<SpamapS> users are implicitly trusting ~charmers if they deploy charms unqualified w/ username
<imbrandon> jup
<imbrandon> sure
<imbrandon> and ?
<SpamapS> well its really a trust transfer
<SpamapS> since they get juju from Ubuntu or a PPA, they are already trusting those entities
<SpamapS> or brew.. :)
<imbrandon> see the whole thing here is you are working with tools that exist only, instead of how the ideal situation is an going there
<SpamapS> idealism is the quickest path to failurre
<imbrandon> not with release eaarly and often
<SpamapS> "My goal is perfection." ... you have just failed.
<imbrandon> iteration is the quickest path to success
<SpamapS> yeah, we're going to iterrate
<SpamapS> a LOT
<imbrandon> ok so in the meantime that means some things are a bit un fun or suck like manually pulling github , untill its iterated that lp can pull shiut in like it should
<SpamapS> But I'd like to keep that iterration focused on things that clarify the picture for new contributors, not muddy the waters.
<imbrandon> ios my WHOLE point
<imbrandon> SpamapS: all the more reason to leave it that way then as it will work someday
<SpamapS> so basically "please bend over backward for me because I don't have time to write a tool as powerful as LP with my preferred VCS available?"
<imbrandon> and not change it then go back and say oh but now its ok
<SpamapS> I'm down with that. :)
<SpamapS> <-- seriously will bend over backward for anybody who writes a charm
<imbrandon> SpamapS: no
<imbrandon> fuck man
<SpamapS> I'm serious. :)
<imbrandon> i hate that, what does that have to do with it=
<SpamapS> (^)  I will look like that
<imbrandon> yea but you just threw awaay when i thought you finaly understood
<SpamapS> well pulling git branches manually is bending over backward
<SpamapS> and I'm willing to do it.
<imbrandon> the bug tracking and awesomness of lp KEEP, force bzr dont
<imbrandon> if it pains you that you cannot pull git into your store
<imbrandon> fix the store
<SpamapS> I'm just not willing to do it forever.
<imbrandon> right but why muddy the waters
<imbrandon> and make a policy change then to stop it
<imbrandon> and then start it or say "but now its ok"
<imbrandon> later ?
<imbrandon> or leave as is, and as you put it take one
<imbrandon> till its fixed
<SpamapS> Adding things slowly, as you understand their impact better, is a good method of iterration.
<imbrandon> it can be
<SpamapS> It will be very hard to convince me that the "how to submit a charm" page should have more than one method.
<SpamapS> I hope when juju grows a 'publish' command, that we can just ditch the BZR instructions entirely
<imbrandon> damnit man, screw all this lets do it over beer as its not gonna change this week , and prom my newrelic
<imbrandon> :)
<SpamapS> We *SHOULD* say "if you want to use git, do x, y, z, to get your git branch in front of us."
<imbrandon> agreed on the publish
<imbrandon> nah
<imbrandon> it should only take a gpg signed tarbal, quit thinking of lone devlopers, on their side 5 ppl might need to sign off on the release before sumitting to the itunes^W store
<SpamapS> Right now that bit is "push your git branch to a bzr branch, then follow all these other steps like bzr users do"
<imbrandon> rember this has all been done before and will all be done again, juju is NOT the first to havetheese problems, amazon, apple, google, and COUNTLESS others
<SpamapS> imbrandon: I have definitely considered the team story a lot. We suggest in the policy that if a team wants to own a branch we're willing to share ownership of it.
<imbrandon> SpamapS: right, imho any form os submition that is not under lock and https key via a single signed archie
<imbrandon> like ohhhh hte deb build servers
<imbrandon> is wrong
<SpamapS> ~charmers is as secure as ubuntu-core-dev in theory.
<imbrandon> thats how you solve the trust issue,i sign the package for relewase with gpg or whatever
<imbrandon> publish on that not if i';its in a certain vcs
<SpamapS> in practice, I have not reviewed the cs: code to see if it actually does https verification
<imbrandon> zomg
<SpamapS> I just now got EC2 doing that
<imbrandon> wtf does that have to do with it
<imbrandon> ~chamers dont let me upload
<SpamapS> yes it does!
<imbrandon> it dont take tarbalss
<imbrandon> it dont take zips
<imbrandon> iot dont verify gpog
<SpamapS> ~charmers takes bzr push which is as good as an upload
<imbrandon> nope
<SpamapS> SSH keys are the exact same crypto as GPG
<imbrandon> only if you use bzr it is
<imbrandon> then again your forcing somehting on the submistions that effect code
<SpamapS> the publish code will just talk to the cs: daemon and verify that you have write access via cryptographic means, then publish whatever you ask it to. This will have to make use of public key crypto in some form, either local client SSL certs, or gpg keys, or SSH keys
<imbrandon> right that verifies ME
<imbrandon> what verifies my code
<SpamapS> I do think we should be signing our commits
<imbrandon> therre ya go
<imbrandon> NOW
<imbrandon> with what bzr ?
<SpamapS> but there's nothing in there to verify those sigs
<imbrandon> fail
<imbrandon> sign a tarbal
<imbrandon> SpamapS: so
<SpamapS> <sigh> ... so much code you're suggesting we write
<imbrandon> SpamapS: fix it, dont not do it cuz there is nothing to veruify
<imbrandon> make something to verify
<SpamapS> which should we do first?
<imbrandon> SpamapS: sure
<SpamapS> glue for github?
<SpamapS> gpg signing of commits?
<imbrandon> SpamapS: something of this magnatude IS alot of code
<imbrandon> and alot of man hours etc
<SpamapS> you see now why I don't want to f*** with the way LP+BZR are used, even though I know it must change.
<SpamapS> I'm hoping its hidden from users
<SpamapS> Also hoping ZK is hidden from the client
<imbrandon> :)
<SpamapS> imbrandon: you have brought up an important bug in my mind though, and I think we have to get this done sooner rather than later.
<SpamapS> We have to start signing the code commits.
 * imbrandon writes some git hooks to checkin and push bzr on push
<SpamapS> I know you're saying tarballs, but for now, bzr supports this.
<imbrandon> right i get ya
<imbrandon> babysteps
<SpamapS> We have a closed authentication loop..
<SpamapS> but not a tamper proof repository
 * SpamapS prepares a bug report
<imbrandon> really imho as much as it is diffrent it also is the same as packaging
<imbrandon> e.g all brit or soyuz
<SpamapS> imbrandon: yeah its integration, not development
<imbrandon> etc steps
<imbrandon> not the finished
<imbrandon> product
<imbrandon> i mean the charms
<imbrandon> and how they are p[ublished
<imbrandon> packaging not using a deb
<imbrandon> your right charmer != kde dev, charmer == motu
<imbrandon> security and steps should be similar to be published, anyone can make their own repo, to be in cs its some work]
<SpamapS> imbrandon: yeah. The vision I have for this is that we have a single place for interested parties in a given service can collaborate on the best way to scale it, secure it, etc. etc.
<imbrandon> me too, but just rember there can be lots of middleware
<imbrandon> :)
<SpamapS> imbrandon: so let the forks roll, but I'd prefer that the forks stay close to the cs: charm ... which probably means we need to have cs: charms pull from github or risk having forks go off the reservation. ;)
<imbrandon> bah the place dont matter
<imbrandon> if your tool dont support tracking them
<imbrandon> SpamapS: see thats what i HATE about drupal, frak worring about if the charms go too far from the cs: make and trying to controll everything and pre think of everything
<imbrandon> just make the cs: and the workflow that should be best
<imbrandon> the easiest
<imbrandon> and the most solid
<imbrandon> then screw the rest, let em stray way the hell off
<imbrandon> it will police it self eventually and then it wont happen
<imbrandon> if its true
<imbrandon> then we dont have to "over think shit"
<imbrandon> we make a great store
<imbrandon> and a great juju
<imbrandon> and thats all
<SpamapS> imbrandon: yeah, I don't want to control.. I want to enable actually.
<SpamapS> imbrandon: I just want to maintain influence over the forks if I can.
<imbrandon> right but there is a fine line
<imbrandon> nag
<imbrandon> nah
<imbrandon> thats control , not enablement
<SpamapS> like, if somebody just fundamentally does something that is awesome to some, but anathema to the cs policy.. I'm fine w/ that.. just keep the merges between us flowing.
<SpamapS> imbrandon: influence means you maintain a voice, control means you squelch other voices.
<SpamapS> I'll give up control gladly.. if they go away.. fine, we lose influence too.
<imbrandon> well even thats against some of your coworkers, i was explained that every person should have their own local forks
<imbrandon> thats what was wnanted
<SpamapS> *bwahahahahaha*
<SpamapS> yeah
<SpamapS> Thats going to be *AWESOME*
<SpamapS> right?
<imbrandon> i think so, everyone has their own cookbooks
<imbrandon> *chef*
<SpamapS> so
<SpamapS> why not just use chef?
<SpamapS> its more mature
<imbrandon> zomg
<imbrandon> ok _everytolls_ has their own local configs
<imbrandon> tool*
<imbrandon> irc , missing , point, context sucks, ugh
<SpamapS> I'm hoping we can shake that kind of B.S. out of ops thinking
<SpamapS> no I get what you mean :)
<SpamapS> I was a busy op once upon a time
<SpamapS> and I didn't have time to contribute back either
<imbrandon> no you dont, you want ever site to be configured exactly the same on the internet ? yea THATS gonna work
<SpamapS> I'd just apt-get source.. change something, build it, install it, and forget about it
<imbrandon> no charms will always need local mods
<imbrandon> SpamapS: excactly
<SpamapS> long term, I'd like for juju to give users a single cmdline opportunity to turn that into a merge proposal against the charm you just forked.
<imbrandon> SpamapS: but that is absolutely needed
<imbrandon> juju will FAIL if not
<imbrandon> rember the php talk we had
<SpamapS> yeah I'll enable that
<imbrandon> you NEED to be abloe to do it
<SpamapS> I'll enable forking and forgetting
<SpamapS> I want to also enable forking and feeding back
<imbrandon> fast and not give two craps
<imbrandon> SpamapS: exactly
<imbrandon> but enable dont hunder
<imbrandon> hinder
<SpamapS> because the next time we update the charm w/ awesomeness
<imbrandon> your mixing the two
<SpamapS> and they can't use said awesomeness because they have to merge w/ us
<imbrandon> they will learn
<imbrandon> exactly
<SpamapS> I want it to be obvious how to say "crap, I don't want to maintain my awesomeness anymore"
<imbrandon> thats bullshit
<imbrandon> thats the same kinda of billshit that is "dont hack core" of drupal
<SpamapS> and if that is just 'juju propose-merge cs:~myuser/precise/foo'
<imbrandon> we make software like this to enable ops and dev
<SpamapS> and it just creates a bug, proposes the merge, and moves on with life.. *zang*
<imbrandon> not to make them do it our way
<SpamapS> we win
<imbrandon> bah
<imbrandon> thats ignorant and arrogant
<SpamapS> what would you propose differently?
<imbrandon> we need to make the tools good, so good there is no question about the process, NOT make them do shit the way we think it should be
<imbrandon> at all
<SpamapS> uhm.. ok?
<SpamapS> I just said that??
<imbrandon> no, you said how it would be ideal now if they was so incliuned
<imbrandon> and not have their own agenda
<imbrandon> not how the best tool would make that not even matter
<SpamapS> Yeah I guess I'm failing to see where we got disconnected.
<imbrandon> yea, i cant get enough speed out of my keyboard to get my full point accross
<SpamapS> I'm saying, they're off in their own world and it gets harder and harder to maintain that long term... we should make it easy for them to get back on the mainline by submitting their stuff for inclusion.
<imbrandon> or even a good chunk of it
<imbrandon> SpamapS: ok stop
<imbrandon> read
<imbrandon> that again
<imbrandon> what you just said
<imbrandon> ok see, thats where
<imbrandon> we fix the problem of it becominng harder and harder, not just make another damn tool that enforces that to be the hardwr way
<SpamapS> go through the scenario, only the way you'd see it working, instead of my arrogance :)
<imbrandon> not all stuff is or will be suitable for includsion
<imbrandon> nor will they goive two damns if it is
<imbrandon> even if its easy
<imbrandon> so we need to make it easy for them to stay inline IF we even want to at all
<imbrandon> without any
<imbrandon> expectations of them
<imbrandon> none
<SpamapS> how?
<imbrandon> that needs to be worked out by us group of smart ppl, isnt that why we're here
<SpamapS> code changes, forks beget merges.. this is a constant that I cannot see being factored out
<imbrandon> or are we just making something else thats already out there with another companies name on it
<imbrandon> the only thing constant in the universe is c
<SpamapS> we can minimize it, sure. we can have more declarative, simple to merge stuff in charms. I've proposed that for charm helpers already.
<imbrandon> 5 years ago we would have got laughed at for a tool like juju as its not needed for those kids playing in the cloud
<imbrandon> shit chnages fast
<imbrandon> then lets work to minimising it, and then again and again, and seriously not worry about the voice
<SpamapS> but if we both change the same bit of a charm, for good reasons.. thats not going to resolve itself.
<imbrandon> it will be there if we do that
<imbrandon> SpamapS: gawd man you get tied up in the technical bits like they cant be changed
<imbrandon> then lets fix ist or find another route etc
<SpamapS> I don't think a realistic goal of juju is "solve the problem of merging forks"
<imbrandon> then it cant enable forking
<SpamapS> you may need some sleep or something.
<imbrandon> mqybe not from day one, maybe not by me and you but it needs to
<imbrandon> no
<SpamapS> We're already aiming at the stars w/ juju. :)
<imbrandon> :)'
<imbrandon> and i just woke up damn you
<imbrandon> lol
<imbrandon> i'm just really set on not letting ppl think that old way
<imbrandon> in anything software eng, not just juju
<imbrandon> its too wrong and 15 years old
<SpamapS> What old way?
<imbrandon> the way i cant get you to seem to even notice i've been talking about a diffrent one for an hour
<imbrandon> heh
<SpamapS> is this "have a trunk" vs "there is no trunk" ?
<imbrandon> lol no, its if you have a blue button in the website and a user cant click his mouse on the button cuz he is color blind , what do you do, fix the button  ? i say make it able to preform the command via voice
<imbrandon> ( example is not practical but the idea of night and day )
<SpamapS> so, we should make juju impervious to color blind users (aka, Solaris admins?)
<imbrandon> i want new software to fix the real problems , not fix the ones they can and try and control the ones they cant
<imbrandon> LOL
<SpamapS> I think I get that
<SpamapS> You do realize that juju is pushing *REALLY* hard to be disruptive, and change the way people think about services/machines/etc., right? Its not like we picked the tiniest problem and went to tackle that first.
<imbrandon> hahah
<imbrandon> right
<imbrandon> another reason i'm so adament about it
<SpamapS> So there's also such a thing as focus
<imbrandon> and why we cant force things, that we need to embracce they way it flows and enable THAT way to be bets
<imbrandon> even if we dont think it is
<imbrandon> we make it the best it could be , and then encpourage others
<imbrandon> not say "no" and encourage other
<imbrandon> SpamapS: sure focus, but we need to also grow fast, imho every canonical employee and then some could be on this and it would not be enough just yet
<imbrandon> like you said to be distruptive takes alot fo work ( to get right )
<imbrandon> one way to do that is enable EVERYONE even the stuff we dont like
<SpamapS> The nice thing about being disruptive though is that you can bet on others saying your idea is worthless for a while. :)
<imbrandon> once we have critical mass then start making things more ideal
<imbrandon> heh
<SpamapS> imbrandon: shotgun approach is not really my cup of tea. I'd like to win over the influencers first.
<SpamapS> imbrandon: I welcome all with open arms, but I seek out a few key types.
<imbrandon> sure those key types will be quick to bury you too tho
<SpamapS> indeed, I want their raw unadulterated feedback
<imbrandon> look at the mass exodus over the last 2 years at google
<imbrandon> and the rewasons for it
<imbrandon> they are all the same
<SpamapS> yeah, it created a nice sucking void that pulled Canonical people into it. ;)
<imbrandon> google was king
<imbrandon> LOL
<SpamapS> oh now you're going to tell me google is dead
<imbrandon> no not dead
<SpamapS> "was king"
<imbrandon> but that they have left room for compatition
<SpamapS> so has microsoft
<imbrandon> as in the king got marriwd and has tons of inlaws
<imbrandon> so maybe the prince wont be the next king, maybe his new nephew in law will
<imbrandon> :)
<imbrandon> google is too worried about facbook , and forced g+ on employees, a company that used to foster inovation , now forces their innovators into a single stream of g+ or its shit
<imbrandon> thus the innovators left, quickly
<imbrandon> and made it very clear as to why
<imbrandon> http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx
<imbrandon> not even quote a month ago
<imbrandon> SpamapS: ^^ gogo read that whole post
<SpamapS> meh I've read enough of the same type of arguments
<SpamapS> and I think they're wrong frankly
<imbrandon> no this is from an exac
<SpamapS> being at war means making hard decisions
<imbrandon> and exec and its personal
<imbrandon> Publishers willing to put the Facebook brand before their own. Exhibit A: www.facebook.com/nike, a company with the power and clout of Nike putting their own brand after Facebookâs? No company has ever done that for Google and Google took it personally.
<SpamapS> google was at peace for a long time.. going to war is going to chase off some peace loving folk
<imbrandon> SpamapS: ok sure, i'll buy into that, but their culture was those ppl
<imbrandon> if they leave its not google
<SpamapS> and clinging to that would probably mean death
<imbrandon> nah, its made them a billion dollar company, trying to force somehting will be theior daeth,. they need to embrace the change
<imbrandon> like they would have 10 years ago
<SpamapS> Taking it personally seems a bit silly.. but.. I get it. "Oops, we f'd up and thought nobody would abuse power because we wouldn't abuse our power"
<SpamapS> I think this is just their way of embracing change.
<SpamapS> but I could be very wrong
<SpamapS> I am poorly informed, and DEFINITELY bike shedding now
<imbrandon> pretty sure your wrong on this one
<imbrandon> hehe
 * SpamapS holds up mirror to imbrandon
<imbrandon> heheh
<imbrandon> well he stuff is visable
<SpamapS> see anybody else bike shedding back there? ;)
<imbrandon> like all the programs that got cut
<imbrandon> Suddenly, 20% meant half-assed. Google Labs was shut down. App Engine fees were raised. APIs that had been free for years were deprecated or provided for a fee. As the trappings of entrepreneurship were dismantled, derisive talk of the âold Googleâ and its feeble attempts at competing with Facebook surfaced to justify a ânew Googleâ that promised âmore wood behind fewer arrows.â
<imbrandon> dont tell me they needed the money
<imbrandon> or investors cared,
<imbrandon> :)
<imbrandon> so no google is not dead, far from it, but its about to be a very very diffrent google, and in that respect control is bad
<SpamapS> seems to me its more about positioning than money
<imbrandon> oh and the funny thing
<imbrandon> this "exec" that left here a month ago and wrote this
<imbrandon> he was the exec over the initial dev and launch of G+
<imbrandon> heh
<SpamapS> G+ is interesting
<SpamapS> I'd *rather* all my friends were on there instead of FB
<SpamapS> but they're not
<SpamapS> and might never be :-P
<imbrandon> heh and if they were all the crap would come too
<SpamapS> so I toil away w/ 4 social networks (twitter, facebook, google, and linkedin)
<imbrandon> seee here is one line that i DONT want to see happen with juju "The days of old Google hiring smart people and empowering them to invent the future was gone. The new Google knew beyond doubt what the future should look like. "
<imbrandon> we need to attract those key ppl like you say, but not think we know how it should look when they are done
<imbrandon> just enable them along the way to de what they want, only the best way
<imbrandon> maybe not our way
<imbrandon> did you promstrangulate me ?
<imbrandon> man i just need to get some good voice software that i could code with
<imbrandon> that would be fantastic
<imbrandon> but whats out there i cant even chat with let alone code with
<imbrandon> mmmm pure java implmentation of php 5.4
<imbrandon> sexy
<imbrandon> and faster than the official runtime :)
<SpamapS> imbrandon: lol that is almost comedy
<SpamapS> Java whips crappy C code's butt. Film at 11
<imbrandon> heh, why is that ?
<imbrandon> LOL
<imbrandon> there is jython and jruby too :)
<imbrandon> but yea
<imbrandon> i wonder what php would be like if re-written
<imbrandon> and without 100000 functions to do everythiong, but more like python with 74
<imbrandon> but still keep the same syntax , runtime idiums etc
<SpamapS> Isn't that hiphop?
<imbrandon> nah hiphop == php to c converter
<imbrandon> then you can compiler the c with g++
<imbrandon> it just now grew a jit compiler
<imbrandon> but its buggy
<imbrandon> it would look more like django with php syntax
<imbrandon> infact i what i'm thinking of is exactly that
<imbrandon> django with only in php syntax
<imbrandon> not php current runtime a whole new one
<imbrandon> but same token parser
<imbrandon> hrm
<imbrandon> that might actually be cool
<imbrandon> and i bet with llvm compilers its pissible now a days witout a bajillion man hours
<imbrandon> mmmm python with a php tokenizer runtime, that sounds sexy
<_mup_> Bug #992454 was filed: Charms are not sufficiently tamper proof <juju:New> < https://launchpad.net/bugs/992454 >
<SpamapS> alright
<imbrandon> i mean the java php project shows it can be done in very little time
<SpamapS> I've filed my bug for the night
<imbrandon> :)
<imbrandon> func init() { http.HandleFunc("/", handler)
<imbrandon> }
<SpamapS> alright, sleep time
<imbrandon> how fast you think we could make the dev_appengine.py sticking nginx and sdy infront ?
<imbrandon> gnight man
<imbrandon> i just woke up like 3 hours ago so i'll be up till noon
<imbrandon> or more
<imbrandon> see ya in a few
<imbrandon> ohh before ya go
<imbrandon> where is that test charm
<imbrandon> for spdy, i wanna play with it a bit
 * imbrandon looks on SpamapS lp branches and hopes
<senior7515> hey m_3: soo I restarted my cluster of hadoop on ec2, but yesterday i simply shut themed down via the aws console, not juju andâ¦ I can't juju ssh into any machine today even though bootstrap and status work just fine.
<senior7515> any tips ?
<SpamapS> senior7515: can you ssh directly to them?
<senior7515> wellâ¦ not sure how. juju does not associate any keypar with them on install
<senior7515> i suppose I can try the debug thing
<senior7515> lets see
<senior7515> nope it detects the machine
<senior7515> it says
<senior7515> connecting to machine <public dns name>
<senior7515> then hangs
<senior7515> soo I suppose status does work, cuz otherwise how would it pick up the dns name
<senior7515> connection time out
<senior7515> debug_hooks finished successfully
<senior7515> that's what it says
<SpamapS> senior7515: it associates your ssh key to the machines
<SpamapS> senior7515: are you sure status sees the correct DNS name?
<SpamapS> senior7515: like, in the AWS console, are the DNS names the same?
<senior7515> hmm checking.
<senior7515> probablyâ¦ where would it make up the names ?
<senior7515> let me check
<senior7515> ohh good pointâ¦
<senior7515> why did the juju bootstrap
<senior7515> picked up the wrong dns name      dunno
<senior7515> I mean I dont know how else to do it ?
<senior7515> shouldn't the bootstrap detect that ?
<senior7515> based on like private ips
<senior7515> or smth more permanent than the public DNS which is dynamic
<SpamapS> senior7515: it doesn't poll amazon
<SpamapS> senior7515: shutting down instances like that is not something juju fully supports
<SpamapS> senior7515: you can reboot them, but shutting them down is still going to cause issues unfortunately
<senior7515> ohhh so how does one shut down the instances but keep the configs
<senior7515> like I need to install some jars on haddop and stuff. compile git repos
<senior7515> etc.
<senior7515> soo that takes some time
<senior7515> I don't necessarily want to shutdown
<senior7515> errr...
<senior7515> reboot
<senior7515> not destroy the environment
<senior7515> I just want to shutdown while I go home
<senior7515> and resume in the morning
<SpamapS> senior7515: we've been talking about that lately
<SpamapS> senior7515: I think shutdowns should be supported somehow
<SpamapS> senior7515: perhaps with a "refresh-provider" command or something that goes and re-pulls all the addresses from the provider
<senior7515> the easiest way would be to install some sort of coordination software
<senior7515> exactly
<senior7515> welll on amazon
<senior7515> i knprivate IP's are not supposed to change for the life of that instance
<senior7515> so store that instead of the public dns
<senior7515> and it would work as is for now..
<senior7515> okâ¦ sooo solution is to terminate and then install again ?
<SpamapS> senior7515: but how would you ssh to the private IP? ;)
<SpamapS> senior7515: and FYI, I don't believe that private address guarantee extends to shutdown instances
<senior7515> ohhh ok
<senior7515> just thinking out loud, should have confirmed before.
<senior7515> I guess I was thinking private ip is fine within amazon
<senior7515> i can definitely ssh to 10.*
<senior7515> from my other machine
<SpamapS> the reason I say that is that I'm pretty sure when I shutdown bootstrap, it changes both addresses
<senior7515> not sure how they segment their networkâ¦ I guess it has worked for me in the past because I use all of the instances on est coast
<senior7515> ohh got you
<SpamapS> which is why you cannot shutdown node 0 :)
<SpamapS> we should actually have some way to fix that
<senior7515> oh so that's the main problem then hahaâ¦ I shut all of the services down when I go home
<senior7515> ok
<SpamapS> though perhaps the best way would be to make bootstrap HA and make sure the 'leader' corrects the addresses when it is time.
<senior7515> hmmm terminating.. instances
<SpamapS> senior7515: one thing you  might consider is pre-handling most of that stuff and dropping a big tarball in the charm w/ all the stuff
<SpamapS> senior7515: this is actually why I encourage use of packages/PPA's because you can do that fairly easily
<senior7515> got youâ¦ sometimes is more than packages is port numbers, configs, custom software, firewall rules, etc.
<senior7515> packages in ubuntu is a breeze with apt-get\
<SpamapS> that stuff should all be saved in juju config options
<SpamapS> you can save them off with 'juju get'
<SpamapS> actually I wonder if juju get will save the whole of them in the proper yaml format
<SpamapS> if not, it should
<senior7515> juju is great so far for 'deploy'
<imbrandon> SpamapS: and json :)
<SpamapS> imbrandon: json would not wor
<SpamapS> k
<imbrandon> :(
<SpamapS> because juju set only takes yaml
<SpamapS> imbrandon: patches accepted
<SpamapS> :)
<imbrandon> oh right , $whatever app could conert it back i guess
<imbrandon> hehe
<imbrandon> speaking of , you know any good php <--> zk bridges ?
 * imbrandon is thinkin of a ui on the bootstrap node
<imbrandon> would be kinda cool to do add-unit / remove unit from the web
<imbrandon> and see some nice bar graphs :)
<phschwartz> does open-port open the local firewall on a node or update the security group to allow for outside access to the port?
<imbrandon> the aws security grp firewall
<imbrandon> iirc
<imbrandon> no idea on anything else
<phschwartz> imbrandon: ok, so doesn't touch iptables. TY
<imbrandon> SpamapS: how can i "force" juju to update its ip info in zk
<imbrandon> phschwartz: as far as i know thats correct, least thats how its been working on my deploys
<imbrandon> i KNOW it does the aws security grps, not sure if it does the ufw in addition or nor
<imbrandon> not*
<SpamapS> imbrandon: what you're describing is best done via a REST API.. https://launchpad.net/jrapi
<imbrandon> SpamapS: yea i figured i'd have to write one tbh
<imbrandon> thus started lower
<imbrandon> :)
<imbrandon> doh twistd
<imbrandon> bah
<imbrandon> SpamapS: btw is zk really needed on the client, would be nice to drop some deps on the osx build
<SpamapS> imbrandon: absolutely
<SpamapS> its *the only thing* the client does
<imbrandon> k thiought maybe only bootstrap needed it
<SpamapS> client changes ZK
<SpamapS> agents make ZK true
<SpamapS> or report errors
<imbrandon> right but it dont workj like sql where there is only the "server" running remote on the bootstrap
<imbrandon> and i only need bindings local ?
<imbrandon> total zk newb so .... yea
<imbrandon> mmm this reset interface looks like it could be functional
<imbrandon> not a fan of twistd but i could use it untill i got a "roundtuwit" and did it in node or php
<imbrandon> hrm
<SpamapS> imbrandon: well the problem is the C library is included w/ ZK proper
<SpamapS> imbrandon: don't be silly
<SpamapS> imbrandon: the REST API will be built into juju. Save your precious time.
<SpamapS> imbrandon: the twistd jrapi is there as a stop-gap until the real one lands.
<imbrandon> really, why complicate it, least a seperate go module i hope
 * imbrandon graps the jrapi and to see if it still is working with current juju'
<imbrandon> oh wait
<imbrandon> its only a few days
<imbrandon> old
<imbrandon> nice
<SpamapS> imbrandon: the client will be using the REST API when it is done
<imbrandon> sweet
<imbrandon> ok
 * imbrandon hugs SpamapS 
<SpamapS> so yeah, don't make a 3rd one
<SpamapS> :)
<imbrandon> well i still may just fo that
<imbrandon> lol
<imbrandon> j/k
 * imbrandon fires up Zend Studio, too much bash, time for some php
<imbrandon>     def to_yaml( self ):
<imbrandon>         try:
<imbrandon>             return( yaml.safe_dump( self.to_dict() ) )
<imbrandon>         except yaml.YAMLError:
<imbrandon>             return( None )
<imbrandon>     def to_json( self, pretty = True ):
<imbrandon>         args = dict( skipkeys = True )
<imbrandon>         if pretty:
<imbrandon>             args["sort_keys"] = True
<imbrandon>             args["indent"] = 4
<imbrandon>         return( json.dumps( self.to_dict(), **args ) )
<imbrandon> HAH!
<imbrandon> wow this code isnt half bad
<imbrandon> maybe its django i dont like ... /me hushes before he has to eat a few words
<imbrandon> ok back to my problem tho, SpamapS how can i inform the juju got to refresh its info about the ips of the member nodes
<imbrandon> e.g. i got a webhead or 3 that have changed IP's and juju still thinks they are on the old ones
<imbrandon> preferably without invoking any hooks
<SpamapS> imbrandon: it doesn't have any routines to do that. as I was suggesting, we need something like 'refresh-provider'
<imbrandon> ahh ok
<imbrandon> dident catch that
<imbrandon> musta been typing too much
<SpamapS> and in theory, you would also need to invoke all hooks around that service, and any connected to it
<SpamapS> because they may have consumed private/public address
<imbrandon> yea, i just manyualy fixed where it filled in the wrong ip
<imbrandon> figured id spin a new env up sometime
<imbrandon> but trying to put it off as long as possible
<imbrandon> and atm if i add/remove anythign then the hooks fire and refill in the wrong ips
<imbrandon> :)
<imbrandon> i could make the configs read only i guess :)
<imbrandon> lol
<imbrandon> ohh got me a shiney new email ( just got activated ) you.should.hire@me.com heh
 * imbrandon orders some business cards
<tooth> well done
<imbrandon> :)
<ihashacks> niemeyer: you mentioned here "http://irclogs.ubuntu.com/2012/01/20/%23juju.txt" that juju won't survive a reboot with local/LXC
<ihashacks> Is that still the case? (seems like it is)
<SpamapS> ihashacks: it is
<SpamapS> ihashacks: a few of the daemons don't get started properly on reboot
<ihashacks> Is manually starting up the containers sufficient or still best to destroy-environment and bootstrap again?
<SpamapS> ihashacks: I believe zookeeper also won't start back up properly
<SpamapS> ihashacks: though you might be able to get it started
<ihashacks> crap, it was here: https://juju.ubuntu.com/docs/provider-configuration-local.html
<ihashacks> I need to RTFM better next time. Thanks.
<jimbaker> adam_g, were you able to verify that one of the 2 branches (debug or what's in review, otherwise no functional diff) worked for you in terms of working with relation ids?
<mapu> I am wondering - performing a 'juju deploy mysql' - my resulting juju status shows "state: start_error"
<mapu> if I connect directly to the system- I find myql is running
<adam_g> jimbaker: i haven't had a chance to test yet, sorry
<jimbaker> adam_g, no worries, just want to make sure this isn't blocking
<jimbaker> from what i could tell, it now works fine in debug-hooks however
<adam_g> jimbaker: i can try now, where is the branch ?
<jimbaker> adam_g, lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker
<adam_g> thanks
<jimbaker> adam_g, you might also find the new jitsu run-as-hook command useful for triggering relation hooks
<adam_g> jimbaker: am i wrong in assuming something like this should work: http://paste.ubuntu.com/960962/
<jimbaker> adam_g, yes
<adam_g> i'd like to have a relation service A -> B.  When a relation is added from B -> C, I'd like to be able to inspect relation data between A and B
<adam_g> specifically the private-address of A
<jimbaker> adam_g, you need to specify the remote unit as part of the relation-get
<adam_g> ok
<jimbaker> since it's different than what the relation hook would imply - and that's on a different relation
<jimbaker> so pretty easy
<adam_g> jimbaker: is there a way to resolve the JUJU_REMOTE_UNIT of a relation id?
<jimbaker> adam_g, you could use relation-list -r relation_id
<adam_g> jimbaker: ah! exactly what i need. thanks
<jimbaker> adam_g, i suspect that it might be a nice feature if JUJU_REMOTE_UNIT was simply set that way
<jimbaker> when specifying -r... could definitely change that behavior
<adam_g> jimbaker: cool, that branch seems to do everything i need.
<adam_g> from debug-hooks at least
<jimbaker> adam_g, cool!
<adam_g> thanks for the quick fix
<jimbaker> np, please tell how it works in practice and what edges we can smooth
<adam_g> definitely
<nathwill> i'm trying to get the remote unit ip in a relation-joined hook, but i'm getting an empty string... i'm using: UNIT_IP=$(relation-get ip), is that the right way to be doing this?
<bkerensa> imbrandon: this is going to be my new laptop http://www.slashgear.com/samsung-series-7-gamer-busts-out-ivy-bridge-01225472/
<bkerensa> :D
<bkerensa> It will start shipping to stores for consumers in the last quarter of this year ^ but I get one when I get back from UDS :D
<mars> Hi guys, I think I just found a bug where the machine-agent.log consumes all the harddrive space after reboot.  Has anyone seen that yet?
<mars> 2012-05-01 17:24:46,172:1198(0x7f2743605700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [192.168.122.1:54477] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
<mars> ^ my system was just killed with a 45GB logfile containing what was likely the above message.
<mars> Actually, that explains why my laptop has been mysteriously shutting down every night...
<mars> FWIW, I'm using juju from the PPA.
<m_3> mars: yeah, that's a problem!  please file a bug on it
<mars> m_3, yep, doing so now
<m_3> thanks
<jimbaker> re the machine log, there was a recent fix for that, but it has not been merged to trunk yet: bug 958312
<_mup_> Bug #958312: Change zk logging configuration <juju:Fix Released by hazmat> < https://launchpad.net/bugs/958312 >
<jimbaker> however marked fix released as above, so really needs to be merged
<jimbaker> mars, ^^^
<_mup_> Bug #992887 was filed: machine-agent.log grows after boot until all disk space is used <juju:New> < https://launchpad.net/bugs/992887 >
<mars> jimbaker, thanks
<mars> m_3, filed: bug 992887
<_mup_> Bug #992887: machine-agent.log grows after boot until all disk space is used <juju:New> < https://launchpad.net/bugs/992887 >
<m_3> mars: cool
<mars> jimbaker, looks to be the same.  Someone should confirm and dupe the bug I just filed.
<SpamapS> nathwill: "ip" is not always present, it would need to be set by the other side
<SpamapS> nathwill: only 'private-address' and 'public-address' are always present in relations
<nathwill> hrm
<nathwill> SpamapS: sounds like i should use one of those then
<nathwill> SpamapS: will can private-address be used for internode comms?
<nathwill> s/will can/can/
<SpamapS> nathwill: the distinction is purely up to the provider, but usually you would want to use private-address for inter-node communication, and public-address only when you need to send an external party to that service
<nathwill> perfect. ty :)
<SpamapS> nathwill: you might see some older charms doing weird things to get the IP because those values were added later
 * SpamapS thinks we should probably go back through the older charms and do some spring cleaning.
<nathwill> SpamapS: aha. that would explain the confusion...
<hazmat> ugh
<_mup_> juju/trunk r533 committed by kapil.thangavelu@canonical.com
<_mup_> [merge][trivial] minimize zk logging, workaround local provider problems with restart, ie. filling disks [r=jimbaker][f=958312]
<hazmat> jimbaker, yeah.. i totally got on a plane before i committed.. done now
<SpamapS> hazmat: I figured as much. :)
<nathwill> anyone have time to review bug 991897 ? my first charm attempt...
<_mup_> Bug #991897: new-charm: vsftpd <new-charm> <Juju Charms Collection:New> < https://launchpad.net/bugs/991897 >
<SpamapS> nathwill: I'll be reviewing charms later today or early tomorrow
<jimbaker> hazmat, if you have a chance to take a look at  lp:~jimbaker/juju/unit-rel-lifecycle-start-invoker, that would be great. adam_g was able to use it to fix the problem he saw with using relation ids - just a one-line fix, everything else is just testing to ensure Invoker.start is actually yielded upon
<nathwill> SpamapS: cool,thankee
<jimbaker> so i would call it a trivial
<hazmat> jimbaker, saw it, it looked good, just haven't had a time to examine it carefully
<hazmat> jimbaker, i'll do it this evening after we wrap up the sprint
<jimbaker> hazmat, np
<bkerensa> jcastro: I was just going to ask out of curiosity why you choose dell laptops instead of zareason or system76?
<SpamapS> bkerensa: perhaps the dell laptops chose jcastro, not the other way around ;)
#juju 2012-05-02
<SpamapS> FYI, there's a new charm-tools in the PPA now
<SpamapS> includes 'unpromulgate'
<SpamapS> imbrandon: did you get your newrelic-php charm to deploy?
<SpamapS> imbrandon: the metadata is a bit confusing
<SpamapS> imbrandon: no interface: juju-info ..
<imbrandon> SpamapS: i was about to try in in just a few minutes
<imbrandon> no i did it blind so far
<imbrandon> untill a few ago no to deploy it
<SpamapS> imbrandon: I think you need interface: juju-info
<imbrandon> i thought i put it
 * imbrandon looks
<imbrandon> SpamapS: i can give you a valid key
<imbrandon> if you wanna try it too
<imbrandon> the one i use for brandonholtsclaw.com so the numbers dont matter if a little skewed
<imbrandon> etc
<SpamapS> well I'd think juju would just refuse
<lifeless> newrelic have a free account for low traffic sites IIRC, so you can get a key easy.
<SpamapS> yeah that should go in the README of the charm :)
<imbrandon> lifeless: yea for the system monitor only
<imbrandon> lifeless: not the lang ones like php
<imbrandon> this is a php one
<lifeless> imbrandon: wait, what ?
<lifeless> that sucks
<SpamapS> imbrandon: copyright: This charm is not endorsed or affiliated with the Locker project and the Locker source is the respective work of its author.
<imbrandon> yea the free only does like cpu memory and disk and like that
<lifeless> $pointless
<imbrandon> SpamapS: whoop
<imbrandon> SpamapS: sounds like an old push
<imbrandon> SpamapS: let me make sure bzr is uptodate
<SpamapS> bzrhater
<imbrandon> subordinate: true
<imbrandon> requires:
<imbrandon>   juju-info:
<imbrandon>     scope: container
<imbrandon> provides:
<imbrandon>   logging:
<imbrandon>    interface: newrelic-php
<imbrandon> is that not right ?
<SpamapS> nope
<SpamapS> at the same level as scope: container, you need 'interface: juju-info'
<SpamapS> at least, thats how I read the docs
<imbrandon> ok and leave the other too
<imbrandon> so two juju-infos
<imbrandon> ?
<SpamapS> same level as scope
<SpamapS> requires:
<SpamapS>   juju-info:
<imbrandon> right but do i leave the other
<SpamapS>     interface: juju-info
<imbrandon> ok
<SpamapS>     scope: container
<imbrandon> kk yea thats what i was asking if i left both
 * imbrandon fixes
<SpamapS> no files dir either
<imbrandon> lifeless: yea "system" monitoring is free for unlimited servers, "application" monitoring is now
<imbrandon> not*
<imbrandon> yea bzr was out dates
<imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ bzr add .
<imbrandon> adding files
<imbrandon> adding files/548C16BF.gpg
<imbrandon> doh
 * SpamapS suspends review
<lifeless> imbrandon: I think you are wrong
<imbrandon> 3 seconds and i'll have it pushed
<lifeless> http://newrelic.com/pricing/details
<lifeless> lite
<lifeless> free
<imbrandon> right but thats for the newrelic-sysmon
<lifeless> includes basic db and app monitoring
<lifeless> anyhow
<imbrandon> ahh yea
<imbrandon> when theysay basic they mean BASIC
<lifeless> oops gathers more data :)
<imbrandon> as in is it running
<lifeless> and is always free
<imbrandon> but yea
 * imbrandon will add a bit about that in the readme
<SpamapS> imbrandon: you need a start/stop hook
<SpamapS> contrary to popular belief, having an init.d installed in runlevel 2 is not enough
<imbrandon> SpamapS: k
<SpamapS> eventually juju will use stop/start to support migrating services, and possibly snapshotting.
<imbrandon> SpamapS: also if you do grab a lite key while i push this, and the "deploy" it to test the charm, they count that as a depooy and will send ya a data-nerd t-shirt :_
<SpamapS> I am starting to think more and more that we should take the debhelper 7 approach and try to get this all down to one hook file that just calls out to various helpers
<imbrandon> heh
<SpamapS> 99% of charms are doing the same things
<SpamapS> No revisions or tags to pull.
<imbrandon> push
<imbrandon> ed
<imbrandon> should be rev 3
<imbrandon> on bzr
<imbrandon> SpamapS: PM with key if you wanna try without hassle of signing up, just a convience
<imbrandon> just added a line in the readme too about getting a ( free ) newrelic account
<imbrandon> ty lifeless , i mis-understood
<SpamapS> oh nice , I get a data nerd shirt
<imbrandon> yup yup, i got two from them , nice shirts actually
<imbrandon> and i got a book "The Lean Startup" hard cover they was giviing away a few weeks ago
<imbrandon> they are always giving some kinda swag out to twitter followers
<SpamapS> Ok I'm going to point it at my thinkup instance
<imbrandon> kk
<imbrandon> i'm after testing and prom etc i'm gonna deploy it to omg instead of how its done by hand now
<imbrandon> omg is using cloudflare now too
<imbrandon> :)
<SpamapS> 2012-05-01 17:43:44,651 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/install: line 13: syntax error near unexpected token `else'
<imbrandon> crap
 * imbrandon looks
<SpamapS> forgot ; after ]
<imbrandon> damn i was gonna say this is like the simplest chamr
<imbrandon> lol
<imbrandon> pushed
<SpamapS> yeah I just haxored it in and I'm rerunning the install hook now
<imbrandon> kk
<imbrandon> :)
 * SpamapS hugs juju resolved --retry
<SpamapS> I think we should just alias that to 'juju retry'
<SpamapS> I almost always want --retry anyway
<SpamapS> 2012-05-01 17:46:09,907 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/install: line 10: md5: command not found
<SpamapS> ha-ha
<SpamapS> md5sum
<SpamapS> imbrandon: man u suck at this! ;-)
 * SpamapS hides
<imbrandon> i am so gonna make the error and info functions in juju to be "ohai = info " "ohnoe = warn" "ohpoo = error"
<imbrandon> wow
<lifeless> imbrandon: misunderstood what ?
<imbrandon> lifeless: the free leel
<imbrandon> level
<imbrandon> SpamapS: no md5sum on base install ?
<imbrandon> frak
<SpamapS> no *md5*
<SpamapS> md5sum is there
<SpamapS> well, it might be
<SpamapS> not entirely sure actually
<imbrandon> ph, frakin osx thin
<imbrandon> there is here
<imbrandon> not sure on linux
<lifeless> imbrandon: ah, so it does do more than you thought ?
<imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ md5 -q files/548C16BF.gpg
<imbrandon> be9704aa1e7001d855a60c4c05d7598b
<imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$
<SpamapS> md5sum is in coreutils
<imbrandon> lifeless: yup, not a lot , i'd still pay,. but yea
<SpamapS> imbrandon: realistically, that check doesn't add any security. If a bad actor could change that, it could change install
<imbrandon> true
 * imbrandon just drops it
<SpamapS> 2012-05-01 17:49:21,939 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/config-changed: line 12: /ect/newrelic.cfg: No such file or directory
<imbrandon> jesus i am bad
<SpamapS> imbrandon: I am your debugger
<SpamapS> imbrandon: perhaps consider variables rather than repetitive hard coding as a strategy to mitigate mt. dew induced type-o impact
<SpamapS> imbrandon: or maybe Mavis Beacon? :)
 * SpamapS will stop going all alpha-dog on imbrandon now :)
<imbrandon> all pushed
<imbrandon> heheh
<imbrandon> np
<imbrandon> i deserve it most of the time :)
<imbrandon> including now
<SpamapS> 2012-05-01 17:51:24,404 unit:newrelic-php/0: hook.output INFO: Starting New Relic Proxy Daemon: newrelic-daemon
<SpamapS> 2012-05-01 17:51:25,412 unit:newrelic-php/0: hook.output INFO:  FAILED
<imbrandon> no lic key
<imbrandon> likely
<SpamapS> I did set one, I think
<SpamapS> perhaps not in the confusion
<bkerensa> SpamapS: Would you like to share some examples of your ninja variables work in a charm? :D
<bkerensa> examples accepted
<SpamapS> A=speling
<imbrandon> lol
<SpamapS> echo "I suck at $A even when I'm competing in a $A bee"
<SpamapS> Starting New Relic Proxy Daemon: newrelic-daemon OK
<imbrandon> shaweet
<SpamapS> imbrandon: one weakness..
<SpamapS> imbrandon: it doesn't restart apache
<imbrandon> yea i thought about that
<SpamapS> imbrandon: seems like you could just restart any that are running.
<imbrandon> i would need tro know any way php could be installed and start apache nginx php-fom
<imbrandon> etc
<SpamapS> imbrandon: thats what the scope: container relationships are for
<imbrandon> ?
<imbrandon> it stil dont help me to know the type i need to restart
<SpamapS> imbrandon: you can have one interface: php-app-server ... and then the charms that implement it can feed back things like what service to restart
<imbrandon> oh yea
<imbrandon> that way
<imbrandon> yea that was the "comming soon" thing we mentioned
<imbrandon> btw you should be able to refresh the page once or twice and it start feeding data
<imbrandon> its almost realtime
<SpamapS> I don't see any data yet
<SpamapS> but, it appears to be working basically
<imbrandon> make sure your on the apps tab
<imbrandon> and not the system one
<imbrandon> at the top left
<SpamapS> imbrandon: thats pretty impressive
<imbrandon> :) the sysmon one will fill in the system tab
<imbrandon> etc
<imbrandon> then ruby and python
<imbrandon> et al
<SpamapS> imbrandon: I wonder if we shouldn't just make a "newrelic" subordinate and have each different app type installable via relation or config
<imbrandon> well i thought about that for the apps but figured it would be configin
<imbrandon> confusing*
<SpamapS> the reason I like doing it that way is that you can have one place for your key.. one place to upgrade
<SpamapS> oh also, I'd recommend calling the config option just 'key'
<imbrandon> stil all uses /etc/newrelic.cfg
<imbrandon> or whatever
<imbrandon> kk
<SpamapS> no reason to prefix it when it is already namespaced into the charm
<imbrandon> k
<imbrandon> so in theory
<imbrandon> then as long as i do them all the same
<imbrandon> if you installed the python one now
<imbrandon> you would not need to mess with the key
<imbrandon> since i put it in the if/else
<imbrandon> on config-change only
<SpamapS> right
<imbrandon> so kinda the same just not said expliositly
<imbrandon> bah
<SpamapS> Interesting, it seems like it held off feeding back the massive spike that my siege created until I let the load drop
<imbrandon> its a little behind
<imbrandon> not 1000% realtime
<imbrandon> but almost
<SpamapS> damn tho
<SpamapS> drilling down now
<SpamapS> We'd have been able to fire 3 people at my last place w/ this
<imbrandon> :)
<SpamapS> not because they wouldn't have work to do
<imbrandon> yea dude it rocks, and thats just the default settings
<SpamapS> but we'd finally be able to prove that their code was causing all the suck
<imbrandon> if you get into the api you can set some treally cooll stuff
<imbrandon> https://newrelic.com/docs/php/the-php-api
<SpamapS> wow
<SpamapS> what a PoS thinkup is
<imbrandon> https://newrelic.com/docs/php/php-agent-phpini-settings#inivar-tt-top100
<SpamapS> every hit to index.php does show tables like '?'
<imbrandon> heh nice
<SpamapS> this app wouldn't even work on mysql 5.0 .. it takes a table lock (briefly) to do that
<imbrandon> good thing for mysql query cache
<imbrandon> lol
<SpamapS> bunch of lazy load insanity here
<imbrandon> newrelic.framework = ""
<imbrandon> Scope: PERDIR
<imbrandon> Type: String
<imbrandon> New Relic tries hard to automatically detect the frameworks it supports, but it can get it wrong if you are using experimental new versions or you have customized the framework. This setting can be used to manually set the framework if the auto-detection fails. This must be one of "cakephp", "codeigniter", "drupal", "joomla", "kohana", "magento", "mediawiki", "symfony", "wordpress", "yii", "zend" or "no_framework" to force no framework even if one was detec
<imbrandon> ^^ very nice
<SpamapS> imbrandon: the mysql QCache is also a problem.. though they've finally got it working ok by splitting it up into multiple mutexes
<imbrandon> SpamapS: yea an ppl often make it huge thinking it will help
<imbrandon> and iit  burries them
<SpamapS> yeah, I went through the thrashing up and down for a while at my last place before I realized turning it *OFF* actually made things better :)
<imbrandon> and yea in like a day or so you'll get an email from $sales saying "we sent ya a tshirt, enjoy" but then takes like 2 weeks to show :)
<imbrandon> just fyi
<SpamapS> I didn't give them an address yet
<SpamapS> but thats cool
<imbrandon> ahh ok
<SpamapS> I'll gladly wear it, this is cool stuff
<imbrandon> :)
<SpamapS> SET time_zone = '?'
<imbrandon> HAHAHA
<SpamapS> theres one that just runs into concurrency problems
<SpamapS> 1,483 ms
<imbrandon> wow
<SpamapS> imbrandon: here's one thought. What about just restarting apache2 and php5-fpm .. those two would cover 99.9% of the cases where a daemon is serving PHP
<imbrandon> good call
<imbrandon> untill something better
<imbrandon> is done
 * imbrandon adds it
<imbrandon> is the service apache or aoache2 ( /me dont have it installed )
<SpamapS> apache2
<imbrandon> k
<SpamapS> and use the service command
<SpamapS> that way it works even if we move it to upstart
<imbrandon> yea i do
<SpamapS> actually, /etc/init.d/apache2 works that way too.. so.. :-P
<imbrandon> cuz php5-fpm will restart its self that way
<SpamapS> but, service > /etc/init.d/oldcrap
<imbrandon> yea i like upstart works liek god
<imbrandon> god == the bomb tho
<SpamapS> imbrandon: ok, so thats my review. Change the name of the config option to 'key' and restart the services. Everything else can stay as a TODO for the future. Well done. :)
<imbrandon> ty ty and i'm pushing herer in a 30 seconds
<SpamapS> also what do you think about calling it newrelic
<imbrandon> nah, its the php one , there is another that will be just newrelic
<SpamapS> Ok
<imbrandon> this installs the newrelic.so
<imbrandon> sysmon will be just newrelic
<SpamapS> We need to grow 'replaces' and 'provides' like capabilities for charms so when we consolidate those or rename something users can get it on an upgrade-charm
<imbrandon> as i needs absolutely nothing else
<SpamapS> heh, 'juju dist-upgrade'
<imbrandon> lol
 * SpamapS is not sure he likes the implications there
<SpamapS> Ok time to go
<SpamapS> imbrandon: will promulgate later tonight
<imbrandon> brew upgrade all
<SpamapS> family is home
<imbrandon> SpamapS: ty ty
<imbrandon> kk
<imbrandon> SpamapS: ok pushed, for when you do get back round
 * imbrandon grabs some late dinner
<nathwill> is there a no-cache option to forcibly reload a charm from the repository?
<nathwill> when doing a deployment ^
<imbrandon> hrm not sure, i think it just looks at the revision
<nathwill> ok. too bad, that would be handy
<imbrandon> SpamapS: how far behind is the go client, as in is it useable _at all_ now and not upto feature parady or ...
<imbrandon> SpamapS: zomg sexy .... love; why cant this be unity .... me want .... https://plus.google.com/u/0/100530892038948253747/posts
<SpamapS> imbrandon: as I understand it, a week or two ago the go client was able to spin up ec2 instances
<SpamapS> imbrandon: and some details about how the bootstrap will differ from the python client are being worked out
<SpamapS> imbrandon: so, its still quite far behind, but the foundations are laid
<SpamapS> imbrandon: FYI, there is a --upgrade option to deploy that satisfies what nathwill was asking earlier
<imbrandon> ahh
<imbrandon> SpamapS: kk, i was thinkning about compiling the go here local and trying to kick the tires a bit , nothing serious really just see what works and dont
<SpamapS> I tried that about 2 months ago and there was nothing, but I'm told there is at least something to play with now
<SpamapS> imbrandon: you can also start up your own charm store ;)
<imbrandon> oh ?>\
<imbrandon> with go or ?
<imbrandon> just in general ?
<SpamapS> imbrandon: the charm store backend is written in go
<SpamapS> and is in lp:juju/go/store
<SpamapS> imbrandon: still have that bit about Locker in the copyright
<SpamapS> oh wait no
<SpamapS> it says newrelic now, never mind :)
<imbrandon> :)
<SpamapS> imbrandon: so, the provides ..
<SpamapS> that needs to go
<SpamapS> unless you're going to add a hook, or explain who will require: that
<imbrandon> ... um i wantthat later
<SpamapS> is it going to be purely for private-address/public-address ?
<imbrandon> probably
<imbrandon> and unit names
<SpamapS> imbrandon: so you don't actually have to do anything on the newrelic side of things?
<imbrandon> and the ability to have other svc change its configs
<imbrandon> huh ?
<SpamapS> imbrandon: I'm asking if its possible w/o hooks
<imbrandon> if what is
<imbrandon> your not clear at all
<SpamapS> imbrandon: that relation
<imbrandon> i'm still very lost
<SpamapS> You have a relation
<SpamapS> with no hooks
<imbrandon> yes
<SpamapS> I'm questioning the value of such a thing
<imbrandon> its for later so names and other config bits can easily be set
<imbrandon> from peers
<SpamapS> There is an *implied* juju-info relation in all charms. https://juju.ubuntu.com/docs/implicit-relations.html
<SpamapS> imbrandon: until you have actual hooks, just use that.
<imbrandon> right but it wont always be juju-info that was a hack till i get php-app in all others
<imbrandon> no then i got to go back and change it yet again
<imbrandon> why
<SpamapS> step back, this is the provides, not the requires
<imbrandon> yes , it proviodes a php logging interfae
<imbrandon> it does
<SpamapS> so, the only way an interface: can be defined is by an implementation (currently). I'm hesitant to have an interface w/o an implementation.
<SpamapS> Oh, does it like, listen on a port or something?
<imbrandon> what does it hurt, and it helps by making things very clear
<imbrandon> yes
<imbrandon> the daemon does
<SpamapS> this is uncharted territory
<SpamapS> so tell me to F off all you want. :)
<imbrandon> right
<SpamapS> I'll take it well
<imbrandon> heheh well i'm looking at it more like i'll probably use it so good to have it from the get go and it dont hurt
<SpamapS> So at this point, interface: newrelic-php , listens on a given port on the private-address.
<imbrandon> instead of doing like juju-info and then changing later
<imbrandon> right, well right now its 127.0.0.1/unix/sockt
<SpamapS> *doh*
<imbrandon> but i will have it just use one daemon and a tcp port
<imbrandon> when ther is more than one
<imbrandon> i'm still missing what why its bad to have
<imbrandon> and i see it as good even witout a implmntation as it makes it very clear
<imbrandon> even in the status
<SpamapS> It still sounds like its a broken interface at this point.
<SpamapS> no documentation for it..
<SpamapS> no partner implementation
<SpamapS> Not saying "NO"
<SpamapS> just asking for a good reason to keep it
<imbrandon> and i'm asking for a good reason to ditch it
<SpamapS> when it sounds like you'll have to change things in the charm to make it actually work anyway
<SpamapS> cause its broken
<imbrandon> no it works fine
<imbrandon> in telling me that via the meta info its a logging php infterface
<SpamapS> there's nothing that can relate to it
<imbrandon> that cant be the *only* reason for the meta info otherise why have it
<imbrandon> and just go on whatever interfaces ahve implentations
<SpamapS> It is *definitely* the only reason
<imbrandon> then just enumerate the implmented interfaces
<imbrandon> and ditch all the meta info
<SpamapS> Otherwise somebody goes off and writes themselves a thing that wants to log to newrelic-php
<SpamapS> and then they get really annoyed that it won't work
<SpamapS> and they have no example to follow from the author
<imbrandon> if if exposes no info for them to do so
<imbrandon> then they wont
<imbrandon> and i linked the docs in the readme
<SpamapS> So, it doesn't say 'will-provide' logging, it says 'provides' logging. And yet, it listens on no ports.
<imbrandon> logging dosent have to mean it provieds to all
<imbrandon> or on a port
<imbrandon> it does to the app
<imbrandon> and only the app
<imbrandon> but it still does
<imbrandon> and its still an interface
<SpamapS> thats scope: container then
<imbrandon> its in container
<SpamapS> Yeah, so thats not relatable over the network
<SpamapS> so add scope: container
<imbrandon> omg
<imbrandon> yes it is and no
<imbrandon> it is not setup that way
<imbrandon> there is not a config opetion
<imbrandon> so it is not there
<imbrandon> for public use
<imbrandon> but it IS there
<SpamapS> Well since you can't show me how its setup, because you haven't implemented it, I stand by my -1, if for no other reaosn than primal fear of the unknown. :)
<imbrandon> look in the only config
<SpamapS> thats not -1 as in, NACK for cs:
<SpamapS> just, -1
<SpamapS> you're good to go for cs:
<imbrandon> ... >.<
<SpamapS> though I'm going to open a bug in the charm as a reminder to fix it or drop it. :)
<imbrandon> ok then i'm truely missing something
<imbrandon> and i'll mark as wontfix unless you can tell me what the hell you mean
<SpamapS> relations define *network* service relationships. There is no logging network interface exposed by the installed/configured software.
<SpamapS> so it is effectively broken
<imbrandon> that is not explisit
<imbrandon> and if its 100% then we need a local relations speeled out too
<imbrandon> more than container
<SpamapS> container == local
<imbrandon> right this is both
<imbrandon> now what ?
<SpamapS> that would be two relations
<imbrandon> ...
<imbrandon> really?
<SpamapS> one for relating via the socket
<imbrandon> thats broken
<SpamapS> one for relating over the network
<imbrandon> no only one is active
<imbrandon> at a time
<imbrandon> or can be
<SpamapS> Thats fundamental to the way subordinates work.
<SpamapS> Think it through
<imbrandon> no or the thing would not work now
<imbrandon> if that was the case
<imbrandon> it DOES work like the way i did it
<imbrandon> and does imply the way it is
<imbrandon> but if i put two
<imbrandon> one will always be wrong
<SpamapS> if its "both", how do you direct juju to install the charm subordinate to any given service *and* let other things log to that particular daemon? you can't because the scope defines where the charm ends up running.
<imbrandon> because it installs both a php nrerelic.so that talks to a running daemon
<imbrandon> that so can be on any machine
<imbrandon> one one daemon is needed
<imbrandon> but aman can be runniung
<imbrandon> right now its made where many are
<imbrandon> weach has their own
<imbrandon> thats how its both
<SpamapS> that all makes sense
<SpamapS> but for juju, you can't have one relation that is both container scope, and not container scope
<imbrandon> i do right now :)
<imbrandon> or you mean i'm not intended to ?
<SpamapS> Could be the latter.
<imbrandon> hehe
<imbrandon> i do think thats wrong though, for other thingas like the LB
<imbrandon> that might have a webserver local and remote
<imbrandon> etc
<imbrandon> and more not on the top of my head
<imbrandon> container/not container should be a hint not restriction
<SpamapS> It should work, to relate the local one to the same service it is deployed on. Thats fine, I'd encourage that sort of thing. But you can't use the unix socket without doing backflips to figure out if you are local or not.
<imbrandon> brb more soda
<SpamapS> 8 min, I have to go :p
<imbrandon> okies
<imbrandon> ok so for real
<imbrandon> add container ? imho thats just crust
<imbrandon> but i will and then bitch later
<imbrandon> very not in line with DRY
<SpamapS> no actually I think you should just remove it still, until you can actually make it work across the network. :)
<imbrandon> well even if i dont i still want it there so its explisit in the metadata
<imbrandon> i dont think that metadat should only be for implmented services or then why have it
<imbrandon> s/servicecs/interfaces
<SpamapS> its explicitly lying about its capabilities. Stubs are generally kept private while they're being worked on.
<imbrandon> thats it its not a stuf
<imbrandon> stub
<imbrandon> bah
<SpamapS> Yeah I get it, you can force it to work by only relating it to services it is already deployed on top of
<SpamapS> But, you can see where I'd think that sounds a whole lot like a scope: container relationship, right?
<imbrandon> yea i do see that
<imbrandon> but then thats a real limitation
<imbrandon> where as if i leave it off  its not
<imbrandon> its only a "would be better" kinda thing that is debateable
<imbrandon> but i DO see your point
<SpamapS> I think eventually, I'd rather see this charm have 2 requires, and 1 provides...
<imbrandon> ugh i do gotta run a few and you'll likely be gone when i get back ( just a few minutes ) so catch ya in the morning man, openweek tomarrow with the OMG story :)
<imbrandon> hrm that might be ok
<SpamapS> the 2 requires are both scope container, one is the generic juju-info .. and the other is for services which implement the php-app interface.
<imbrandon> yea
<SpamapS> The provides is for network based logging into the daemon
<imbrandon> well then the top php need not be container
<imbrandon> but other than that yea
<SpamapS> it does, because you need a way to pass local aspects
<imbrandon> but i need a way to gather network ones too
<SpamapS> without haveing to pass the hostname, and compare it to your own, so you know you are local and not remote, and can do things like restart services.
<imbrandon> i was thinking about making all the service restarts config options anyhow
<imbrandon> and doing it in config-changes
<imbrandon> that would solve some othert issues as well
<SpamapS> The network ones would be via the provides interface. I assume what you want is to deploy the daemon to only one app server service, but then log to it from many other services.
<SpamapS> That would create issues though. The more config options that are needed to make the system work, the more one has to think about how to automate.
<imbrandon> defaults
<SpamapS> much better if it works well for 99% of use cases w/o configs
<imbrandon> sure sane defaults
<imbrandon> it would be more like protected class vars
<SpamapS> does newrelic have any other interesting local-only data that it needs to know about your app?
<imbrandon> is how it would be used
<imbrandon> hrm yea
<imbrandon> well
<SpamapS> I assume most of it can be gleaned from the PHP modules, so just knowing how to configure that is all you need
<imbrandon> hrm
<imbrandon> alot of it is set in the actualy app booptstrap code
<imbrandon> its self
<imbrandon> other than that it guesses or you can manualy overidse in the newrelic.ini
<imbrandon> really the main thing that NEEDS to be local is the app group anme and the app server uniq name
<imbrandon> so like onthe omg webheads all have   "OMG-ALL;OMG-1"   "OMG-ALL;OMG-2"
<imbrandon> etc
<imbrandon> where N is $JUJU_MACHINE_ID
<SpamapS> yeah
<SpamapS> juju has a nice logical model for that :)
<bkerensa> pah
<imbrandon> they all agrogate to one and each ahve their own
<imbrandon> in this i set it to JUJU-ALL;$JUJU_MACHINE_NAME
<imbrandon> i think
<imbrandon> but i wanna make that a config as well
<SpamapS> this is wher ethe juju-info relation would come in handy
<SpamapS> what you really want is OMG
<SpamapS> so add a hook that records $JUJU_REMOTE_UNIT
<SpamapS> since 'omg/0' is way more interesting than 'newrelic/0'
<imbrandon> hrm, good idea
<SpamapS> must be my lucky day :)
<imbrandon> hehehe
<imbrandon> yea i'll do thhat before i sack out, doing got a lot more left in me
<imbrandon> but ok so is it in the store now ?
<imbrandon> and ty ty btw
<imbrandon> and how do i do updates ? more bugs ?
<SpamapS> Yeah I'm pushing it now as-is
<imbrandon> sweet ty
<imbrandon> yea i'll make a few small changes to ngiht and also try to get the other newrelic ones ( minimum python and ruby )
<SpamapS> imbrandon: if you want to own it, I'd be good with that. We can create a team which has you + charmers in it. Or you can get some other ~charmers person to +1 you and start reviewing charms too.. :)
<imbrandon> thte latter is what i plan
<imbrandon> just everyone been busy with releases
<imbrandon> so i kinda held back
<SpamapS> well is this your first promulgate? I can't believe that
<imbrandon> drupal should ahve been many
<imbrandon> weeks ago
<imbrandon> but omg hit the fan
<imbrandon> :)
<imbrandon> and not that subs are out ( yea its been that long ) i wanna change it up some
<imbrandon> now*
<SpamapS> Yeah, subs are fun
<imbrandon> but yea i got nginx and mysql ndb
<imbrandon> local
<imbrandon> and on github
<imbrandon> but not ready
<imbrandon> drupal and these newrelic ones and the omg playground
<imbrandon> :)
<imbrandon> ok gonna run a few, youll ber gone so i'll catchg ya tom man
<imbrandon> ty ty
<imbrandon> gotta do openweek tom
<imbrandon> heheh
<imbrandon> makin a slick graphic for it now
<imbrandon> turning out much better than i had hoped
<SpamapS> cool!
<_mup_> Bug #993027 was filed: 'juju get' needs an option to produce the same yaml that 'juju set --config' will consume <juju:New> < https://launchpad.net/bugs/993027 >
<imbrandon> SpamapS:
<imbrandon> still round ?
<imbrandon> http://cl.ly/GIxf
<imbrandon> still needs work, but nice graffic to go along with Juju: the OMG!Ubuntu story :)
<SpamapS> sparklies
<imbrandon> lol
 * imbrandon hugs photoshop
<_mup_> Bug #993034 was filed: lxc deployed units don't support https APT repositories <juju:New> < https://launchpad.net/bugs/993034 >
<mrevell> i
<koolhead17> marcoceppi, ping
<mgz> is there some way in juju to make it ssh to the instance IP rather than the hostname?
<mgz> ...seems not, ProviderMachine takes dns_name and private_dns_name only
<m_3_> mgz: for some providers you might get away with adding .ssh/config that includes entries to a.) get to the bootstrap node, and b.) proxy through the bootstrap node for other instances
<mgz> m_3_: so, my immediate problem is canonistack doesn't seem to work unless I manually edit my .ssh/config with the details of the bootstrap node
<mgz> if that's the current expected state, I guess that's okay.
<m_3_> mgz: yeah, afaik that's the current state of affairs with openstack installs
<m_3_> mgz: or drive juju from "inside" the openstack cloud itself... provided you can route to the endpoint urls
<_mup_> Bug #993288 was filed: Provide an option to specify creation of a new instance upon deployment <juju:New> < https://launchpad.net/bugs/993288 >
<SpamapS> bbcmicrocomputer: Confirmed your bug, good idea. :)
<bbcmicrocomputer> SpamapS: ah cool :)
 * flepied is happy to have a working mongodb charm using his own configuration engine and having the change port test working
<SpamapS> bbcmicrocomputer: just finished a review of your solr charm. REALLY nice work. You can ping me in here as soon as you address the issues.
<SpamapS> flepied: Is this an evolution of the existing one, or a total rewrite?
<bbcmicrocomputer> SpamapS: ok thanks
<flepied> SpamapS, it's based on the mongodb one
<SpamapS> flepied: cool. :) If you want to propose it as a merge into the existing one we'll review that just like we review new charms.
 * SpamapS points in a circle at all the other ~charmers members *YOU* will all review it, right?! RIGHT
<flepied> SpamapS, I don't think it can be used by anyone else at this point as it uses my adminkit config engine and adminkit needs to be preloaded on the image before beeing used
<m_3_> SpamapS: right
<flepied> but if someone is curious, just look at https://code.launchpad.net/~flepied/charms/precise/mongodb/adminkit
<m_3_> argh... leaking security groups in autotesting
<m_3_> gonna start having to use eucatools and ec2 tools to avoid things like 'cross-fingers; destroy-environment; sleep 120; destroy-environment; pray'
<SpamapS> m_3_: something cares if there's already a group?
<SpamapS> m_3_: perhaps you need to bump the env name
<m_3_> yeah, that would work... but then I'd be leaking them longer-term
<m_3_> didn't think about tmp-envs tho... good idea
<m_3_> might be just lagging cleanup of sec grps
<SpamapS> m_3_: its probably worth adding an option to bootstrap like --nuke-from-orbit to make sure the old env is gone before bootstrapping
<jimbaker> m_3_, security group reuse along the lines of what was done in the go port is probably a good idea
<m_3_> SpamapS: yeah, I did that with local providers (mostly remove data_dir)
<m_3_> jimbaker: yeah, we've been informed that the current way we use groups will need to be limited in ec2
<m_3_> jimbaker: simply not enough available to really scale
<jimbaker> m_3_, right
<SpamapS> OH, does ec2 actually hvae a limit?
<m_3_> SpamapS: but I'll have to do something different to nuke envs in ec2/openstack... hence the ec2tools/eucatools... perhaps
<m_3_> SpamapS: longer quiet periods between tests don't seem to suffice
<SpamapS> m_3_: sounds like a job for jitsu :)
<m_3_> SpamapS: yup!
<m_3_> SpamapS: all this stuff's going into jitsu
<SpamapS> werd
<SpamapS> I need to finish getting the stable releases -> ppa automated
<lynxman> jcastro: ping
<_mup_> Bug #993372 was filed: terminate-machine should accept an option for --all-unused <juju:New> < https://launchpad.net/bugs/993372 >
<AlanBell> hi all, I am having a problem with juju bootstrap, I have rebooted, but I still get error: internal error Network is already in use by interface virbr0
<AlanBell> I do have virtualbox installed if that is relevant
<AlanBell> I just added myself to the libvirtd group and it worked \o/
<AlanBell> maybe it should do that automatically?
<koolhead17> AlanBell, file a bug if you think something is missing :)
<SpamapS> AlanBell: when you install libvirt-bin, all administrators are added to that group
<AlanBell> I am an administrator (single user default precise desktop installed yesterday)
<SpamapS> AlanBell: though it sounds like juju needs to explicitly check for that group membership.
<AlanBell> hmm, so running juju with no arguments should create ~/.juju/environment.yaml?
<AlanBell> it doesn't
<AlanBell> I set up the environment.yaml manually, it seems to run without error but very very fast and I don't think it is doing anything http://paste.ubuntu.com/962806/
<AlanBell> here is my environments.yaml http://paste.ubuntu.com/962809/
<SpamapS> AlanBell: it takes a long time to build the first container
<AlanBell> then again, it may have actually worked
<AlanBell> gosh, it did
<SpamapS> AlanBell: has to bootstrap mini-ubuntu .. and then install juju on top of that
<AlanBell> I installed an SSD yesterday, not used to the speed and silence, didn't realise it was doing stuff!
<AlanBell> I appear to have a working wordpress install
<SpamapS> Yeah SSD's suddenly rob you of the scratchy sound of "I'm Busy"
<SpamapS> AlanBell: woot
<AlanBell> so where are these virtual machines it created? they are not in ~/.juju or the environment working directory ~/Projects/juju
<AlanBell> there is stuff in there, but only 264k
<SpamapS> /var/lib/lxc
<AlanBell> 2GB of stuff there, that sounds about right
<SpamapS> yeah, I think its about 600MB per container usually
<jcastro> SpamapS: can you review and promulgate something? We're 1 away from 70. :)
<_mup_> Bug #993492 was filed: Wrong error message when calling remove-relation with a subordinate charm <juju:New> < https://launchpad.net/bugs/993492 >
<SpamapS> jcastro: I'm reviewing dokuwiki right now actually
<SpamapS> jcastro: and solr is very close :)
 * SpamapS rings the bell
<SpamapS> dokuwiki promulgated
<SpamapS> jcastro: ^^
<marcoceppi> I thought we had a glouster charm?
<SpamapS> I think somebody was messing with that
<SpamapS> It really needed subs
<SpamapS> Same w/ ceph really. I need to write a ceph-client sub
<SpamapS> we should probably start slow w/ an NFS-client sub
<SpamapS> I really just want to sit and rewrite half the old charms I wrote to be way more awesomer w/ subs.
<marcoceppi> SpamapS: that's kind of what I need now
<marcoceppi> a Glouster like sub
<marcoceppi> I guess it's about time it gets written
<marcoceppi> SpamapS: can subs open ports yet?
<SpamapS> marcoceppi: no :(
<marcoceppi> SpamapS: it's too bad, Glouster would be really easy to charm if I could just open those ports
<marcoceppi> I wonder why it doesn't actually work
<SpamapS> marcoceppi: wait, why do you need to open ports?
<SpamapS> marcoceppi: thats only for *external* access
<marcoceppi> DUH
 * marcoceppi is so silly
<SpamapS> marcoceppi: for a client.. you don't need anybody accessing their local gluster daemons :)
<marcoceppi> So, next question, if a charm is a sub, and I juju add-unit to the parent of the sub, will the sub be re-deployed on the new unit (I assume yes) and if so will the peer relation be fired?
<SpamapS> marcoceppi: yes
<SpamapS> marcoceppi: do you believe in magic? :)
<marcoceppi> SpamapS: http://i.imgur.com/f2qPJ.jpg
 * SpamapS lols, like, literally
<marcoceppi> I think I'm going to end up writing three charms just to author this one charm
<SpamapS> marcoceppi: awww yeah thats how the sexy charmers do it, http://on.mtv.com/IYDYWJ
<marcoceppi> awwww yeah
<nathwill> i... this falls under the category of "can't unsee"
 * nathwill shudders
<SpamapS> :-D
<SpamapS> nathwill: awwwwwwwwwyeah
<_mup_> Bug #993552 was filed: Charm store should automatically close any bugs marked using '--fixes' when charm is published. <juju:New> < https://launchpad.net/bugs/993552 >
<_mup_> Bug #993557 was filed: Charm store should delete charms that have been removed. <juju:New> < https://launchpad.net/bugs/993557 >
<gmb> Hi folks. juju deploy is telling me that a charm doesn't exist in a local repository. AFAICT, it does - and juju was working before an update & reboot. How can I debug this problem?
<gmb> s/and juju/this juju deploy command/
<SpamapS> gmb: pastebin?
<gmb> SpamapS, http://pastebin.ubuntu.com/963475/
<SpamapS> gmb: and I assume under /home/graham/launchpad/workspace/juju-charms/precise , you have a dir named 'launchpad-clinic' ?
<SpamapS> gmb: whose metadata.yaml also has name: launchpad-clinic ?
<gmb> Oh, big hairy arse.
<gmb> SpamapS, I forgot I'd renamed the charm but not updated metadata.yaml. Thanks :)
<SpamapS> that name: bit will bite you ever time. I just added a charm proof rule to warn people
<gmb> Awesome, ta.
<_mup_> Bug #993616 was filed: We should ship a boilerplate environments.yaml. <juju:New> < https://launchpad.net/bugs/993616 >
<SpamapS> marcoceppi: hey, been reading a few of your reviews. start/stop are not just for the here and now of charms. They're separate hooks from install because they are meant to be run when units are migrated between hosts or rebooted.
<SpamapS> marcoceppi: at the moment, they're not used, but I'd like to see new charms implement them as their own, independent entities that can be run at any time.
#juju 2012-05-03
<SpamapS> Ding ding
<SpamapS> another charm promulgated
<SpamapS> Kusabax
<bkerensa> yay
<bkerensa> SpamapS: I fixed the locker charm and pushed again
<bkerensa> :P
<SpamapS> bkerensa: I might just review that now so that I can add you to ~charmers and you can start doing reviews.
<SpamapS> The queue, I suspect, will get long, fairly quickly. :)
<bkerensa> SpamapS: yes then I will help review stuff and make things easier
<bkerensa> :D
<bkerensa> SpamapS: is the level of frostiness acceptable?
<marcoceppi> SpamapS: thanks for the info, I'll keep that in mind
<jamespage> jcastro, this looks largely unmaintained - https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoW1nhI7IMt3dFRvSFdkZmNqQ0t3RjZ2QTR2Z19teWc&hl=en_US#gid=0
<jamespage> and is linked from https://juju.ubuntu.com/Charms
<jamespage> worried it might be creating a bit of confusion about who's working on what charm - new folk don't seem to be looking at bugs in launchpad....
<yolanda> hi jamespage, saw your email
<yolanda> to see the juju code there, you need to have access to that team, do you want me to put in a public url?
<jamespage> yolanda, yes - but we really need to resolve the issue about multiple charms targeting the same service deployment.
<yolanda> jamespage, it's ok for me. I still have to deal with details of openerp module, to push it to Debian & Ubuntu. But if the charm can be configured to do one thing or another depending on version, that can be good
<yolanda> what is Patrick Hetu nick, to talk with him?
<jamespage> yolanda, not sure - check launchpad - it should tell you
<yolanda> avoine, but is not there, i'll send an email
<jkyle> so, if I'm understanding juju correclty. It can't be used as a standalone deployment tool. Only with a cloud like EC2 or MaaS?
<avoine> jkyle: there is a local deployment option but it's more for testing
<jkyle> right, so no way to deploy to a target. and I also bumped into a blurb that it's being rewritten in Go?
<avoine> jkyle: no right now you can deploy to an existing server
<avoine> jkyle: I'm not sure about Go, I think they want to test it
<jkyle> I hope not
<avoine> or make a proof of concept
<avoine> sorry you cannot deploy to a remote existing server
<jkyle> proof fo concept is fine. seems moving to go would alienate a lot of potential contributors
<avoine> only local or via ec2 or Maas
<jkyle> blurb in question: http://tinyurl.com/79nm8ej
<jkyle> yeah, I may have to revisit maas my next deployment. was unable to get it (or cobbler) to work well this round
<avoine> it can be tricky yeah
<jkyle> I think it was just too early in 12.04's release cycle
<avoine> it was moving fast in the last months
<jkyle> yeah, the nail for me was when the source outpaced the hosted ephemeral disks and they wouldn't boot :P
<avoine> jkyle: so juju is mainly in python
<jkyle> avoine: right, that was one of the things that first drew my attention
<jkyle> seems a natural choice for workign with openstack
<avoine> yeah
<jkyle> I'm working here and there to get a macport of juju written
<jcastro> m_3_: ping
<FunnyLookinHat> Is there an appropriate place to 'stake a claim' to a specific charm so that people don't double up?  Is it that google doc spreadsheet I see floating around?  Because that seemed a bit out of date.
<marcoceppi> FunnyLookinHat: if you're going to start something and there's a bug for it, just claim the bug report for that charm, otherwise create a bug report and assign it to yourself
<jcastro> FunnyLookinHat: yeah just claim the bug in launchpad by assigning it to yourself.
<m_3_> jcastro: hey... bout to call you
<jcastro> join #juju
<jcastro> and then call me in 2 minutes.
<jcastro> I will fill you in
<jcastro> oh, this is #juju
<jcastro> ok call me
<koolhead17> jcastro, i have assigned one using that google doc, is that okey
<marcoceppi> koolhead17: that google doc is out of date
<koolhead17> gosh
<koolhead17> why is it there/mentioned then/
<_mup_> Bug #994116 was filed: juju local environment doesn't survive reboots <juju:New> < https://launchpad.net/bugs/994116 >
<SpamapS> koolhead17: I don't know. We should burn the google doc unless it updates automatically from launchpad
<dpb_> Hi all -- Is there a right way to copy files between services, when relations are joined.
<SpamapS> dpb_: scp would be the simplest way. Can you give an example of what you want to copy?
<dpb_> SpamapS: it's a server cert actually (self signed)
<koolhead17> SpamapS, exactly. I don`t see information catered two places :)
<SpamapS> dpb_: two simple options. 1) setup SSH between the two hosts by passing along public keys for auth. 2) relation-set certcontent=`cat my.crt`
<dpb_> SpamapS: oh on 2.. not a bad idea.
<_mup_> Bug #994118 was filed: Update manager fails with an error <juju:New> < https://launchpad.net/bugs/994118 >
<dpb_> SpamapS: I guess it's small enough.  if I have a case of something larger, the ssh key approach would be workable as well.  thanks
<_mup_> juju/scale-test r534 committed by kapil.thangavelu@canonical.com
<_mup_> short circuit per machine security group management
<jcastro> marcoceppi: hey so I had to shuffle the plenaries, you're on monday now.
<marcoceppi> jcastro: http://i.imgur.com/i8YYs.gif
<marcoceppi> that's cool, I'll hunt you down on Sunday for a drink and quick dicussion about the plenary
<SpamapS> dpb_: the only trouble is that you have to trust ZK with the content of your cert
<SpamapS> dpb_: We already trust ZK with a lot of stuff, but its something to think about.
<dpb_> SpamapS: well, this particular charm is for development spin up, so trust is a non-issue.  good to know though.  BTW I just had to double quote the param to relation-set and it worked.  thanks!
<SpamapS> dpb_: woot
<jcastro> SpamapS: thomas has an incoming fix for the postgres charm
<jcastro> he says it was broken, but he fixed it. :)
<SpamapS> *sweet*
<SpamapS> I have had a proposed fix for the mysql charm open for over a month
 * SpamapS wishes somebody would review it
 * marcoceppi goes to review
 * SpamapS goes to get marcoceppi an IRC beer
<gmb> hazmat, Around?
<hazmat> gmb, yup
<gmb> hazmat, So, I'm back  to trying to get juju to bootstrap with a specific AMI. What should I make the ec2-uri point at in order to be able to use default-image-id?
<hazmat> gmb, the ec2 region url
<hazmat> ie. api access endpoint
<gmb> hazmat, So, ec2.us-west-1.amazonaws.com?
<gmb> (For e.g.)
<SpamapS> https://us-east-1.ec2.amazonaws.com
<SpamapS> I think
<gmb> Okay, lemme try that (the documentation is a bit ambiguous)
<gmb> SpamapS, Yep, that got it. Thanks.
<marcoceppi> SpamapS: shouldn't this be it? region: eu-west-1
<marcoceppi> it's what we use to bootstrap omg in the EU EC2 zone
<gmb> hazmat, SpamapS interestingly, if you get it wrong, the only indication that something's not right is a "400 Bad request" in the juju bootstrap output.
<SpamapS> marcoceppi: There's some specific logic in juju to prevent users from using default-image-id on EC2 (why, I'm not sure, as this seems like we're trying to be peoples' mommies)
<SpamapS> If somebody wants to ditch our sophisticated and awesome way of looking up image ids.. let 'em.
<marcoceppi> SpamapS: looks good to me, it too me a while to figure out why you were using md5sums, but makes sense now
<marcoceppi> merge away
<SpamapS> marcoceppi: Yeah its a little weird but I want to avoid restarting mysql if at all possible.
<marcoceppi> Right, makes snes
<SpamapS> marcoceppi: thanks for the review! :)
 * SpamapS pushes
<gmb> SpamapS, hazmat: Is the fact that multiple constraints need to be specified as separate --constraints="" parameters a known bug?
<SpamapS> gmb: I thought hey could be space separated
<SpamapS> I have not tried them enough to know though
<gmb> SpamapS, For me, it gets confused and thinks the second constraint is the charm name.
<gmb> I'll file a bug if one doesn't exist already.
<hazmat> gmb, you can space separate them
<SpamapS> hazmat: who admins _mup_ ? I want him to monitor merge proposals and bugs in charms too
<hazmat> SpamapS, dunno exactly, i just ask gustavo when i need something changed on it
<SpamapS> I also want promulgate to be able to notify _mup_
<gmb> hazmat: This is what I'm seeing; what am I doing wrong? http://pastebin.ubuntu.com/965372/
<marcoceppi> SpamapS: I just realized, for gluster you don't need to use subordinate charms, just regular relations will work
<marcoceppi> though it'd be "faster" charms can just use nfs mounts vs nagive gluster mounts
<SpamapS> marcoceppi: they will only work if you want to tie your charm to gluster specifically
<dpb_> How do I supply data to a install hook, or more preferrably to a relation?  I.e, I would like to supply a URL that is changeable at deploy time to retrieve data about the install.
<marcoceppi> I've been trying to figure out the workflow for gluster charm/sub The way I see it now, you have two options. Use gluster/gluster-client sub combo but then have the parent charm require gluster-client (to handshake *where* glusterfs mountpoint should be created) or just use gluster as a standalone and require nfs, resulting in a handshake of server details
<marcoceppi> http://paste.ubuntu.com/965392/
<hazmat> gmb, not sure... i'm able to do effectively the equivalent without issue http://pastebin.ubuntu.com/965396/
 * hazmat tries with the same constraints
<gmb> hazmat, Ah, wait
<gmb> I have found the problem.
<hazmat> that works
<gmb> Old copy of the juju wrapper lying around.
<hazmat> ah
<gmb> sitting in /usr/local/bin...
<hazmat> transparent wrapper is evil
 * gmb stabs it
<hazmat> thankfully gone
<gmb> Yep.
<gmb> Good-oh.
<dpb_> so like.  juju deploy --variable URL=http://foo/bar  or   juju deploy --relation-data my-relation:URL=http://foo/bar
<dpb_> I see the "--config" option on juju deploy, but I'm not sure what it can do.
<balloons> I'm trying to initialize a basic environment to start messing with juju charms.. I'm looking at this page: https://juju.ubuntu.com/Charms. The "charm update some/dir/precise" and "charm getall some/dir/precise" commands it's telling me to follow are failing :-(
<balloons> So in short, I got as far as installing juju and charm-tools on an up to date precise installation -- what do I do next?
<marcoceppi> balloons: what are the commands failing with?
<balloons> marcoceppi, the charm update and charm getall commands fail differently
<balloons> which should i do first?
<marcoceppi> balloons: pastebin both?
<balloons> sure.. one sec
<SpamapS> dpb_: there's supposed to be a --set option for deploy, but I think its been deferred a few times.
<dpb_> SpamapS: can I get something similar with --config?  I even thought about making a fake service. :)
<SpamapS> dpb_: you need to write out a yaml file with the options you want to set
<SpamapS> servicename: { URL: 'http://foo' }
<SpamapS> dpb_: anything you use 'config-get' for, btw, should go in config-changed, not install
<SpamapS> unless there's a really compelling reason not to let people change the variable later
<balloons> marcoceppi, here's charm update: http://paste.ubuntu.com/965430/
<dpb_> SpamapS: ok.  config-changed is a hook by itself?  like install or start or stop?
<SpamapS> dpb_: right, it runs after install
<dpb_> ok.
<SpamapS> dpb_: and any time any config options are changed
<dpb_> cool.
<dpb_> SpamapS: let me play with that a bit, thx
<marcoceppi> balloons: mkdir -p projects/charms/precise
<marcoceppi> then run the command again
<SpamapS> Hm, with the store now..
<SpamapS> I wonder if we should deprecate 'charm getall'
<SpamapS> its really slow
<SpamapS> and does things in a wonky way
<SpamapS> 'charm get xxx' seems better
<balloons> marcoceppi, I get the same error as you see in the paste
 * SpamapS removes the suggestion from https://juju.ubuntu.com/Charms
<balloons> if you scroll down you see I create the directory and try again
<balloons> I'm not sure if it worked or not, but stuff does go into the directory, along with the errors
<marcoceppi> balloons: that's odd
<balloons> you can see the listing in the paste
<marcoceppi> balloons: can you cd into that precise folder, and run charm get mysql (just as a test)
<balloons> running now
<balloons> Permission denied (publickey).
<balloons> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<balloons> Permission denied (publickey).
<balloons> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<marcoceppi> balloons: did you install from the archives or ppa?
<balloons> I installed from the archives
<balloons> I have an up to date precise install.. running 64-bit
<balloons> a random side note, but lxc failed to install for me also giving a dpkg subprocess error.. that's really baffling https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/994192
<_mup_> Bug #994192: package lxc 0.7.5-3ubuntu52 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 <amd64> <apport-package> <need-duplicate-check> <precise> <lxc (Ubuntu):New> < https://launchpad.net/bugs/994192 >
<balloons> so charm update and then charm get XXX should work then?
<marcoceppi> balloons: charm get mysql works fine for me, it's odd that it throws BZR errors for you
<SpamapS> balloons: you don't actually need charm update anymore
<SpamapS> balloons: its only for charm getall. So you can just do 'charm get mysql'
<bkerensa> SpamapS: how did the charm look?
<SpamapS> bkerensa: sorry which one?
<balloons> SpamapS, so.. I'm a bit confused then.. I see you updated the page, so I just need to grab a charm then.. what charm might be a good one to have a look at if I'm trying to learn about charms and juju?
<SpamapS> balloons: wordpress, mysql, subway, appflower .. those are all good ones
<jcastro> balloons: I'm in the cloud room if you want me to fix your juju
<SpamapS> balloons: do you have any services in mind that you might want to charm?
<balloons> jcastro, SpamapS sounds like jcastro  is willing to fix my issue
<balloons> SpamapS, yes, I do have something in mind..
<balloons> it's a tomcat app.. but it isn't straightforward to setup or deploy with tomcat
<balloons> it also requires google refine, jena, mysql and apache
<marcoceppi> balloons: there's a tomcat charm you could use as a base http://jujucharms.com/charms/precise/tomcat7
<balloons> ohh and optionally joseki.. so it's a good mix of stuff
<balloons> is there a tomcat6 charm?
<SpamapS> balloons: sounds interesting. :)
<SpamapS> balloons: yes there is
<balloons> i hoping my install script I typically use for deploying can be converted easily.. I'm curious to see :-)
<balloons> SpamapS, great.. I'll start with tomcat6 then as a base
<marcoceppi> balloons: I'm sure it will, most of the stuff I've charmed I just used my huge install script and just tweaked it into the Juju charm structure
<balloons> cool
<marcoceppi> s/most/some/
<SpamapS> s/some/one time at bandcamp/
<marcoceppi> good times
<SpamapS> balloons: You might be able to just write your app as a "subordinate" app to tomcat6. The benefit there is you don't have to fork tomcat6
<bkerensa> SpamapS: https://bugs.launchpad.net/charms/+bug/898714
<_mup_> Bug #898714: Charm Needed: The Locker Project <Juju Charms Collection:Fix Committed by bkerensa> < https://launchpad.net/bugs/898714 >
<SpamapS> bkerensa: ahh, I haven't gotten to it yet. UDS prep has been sucking all my time away ;)
<bkerensa> indeed
<bkerensa> :D
 * SpamapS is doing SRU approvals for the first time in 10 days right now
<SpamapS> bad.. bad SpamapS
<balloons> SpamapS, marcoceppi turns out my ssh key for this machine is not in my launchpad profile
<balloons> that's what was causing the error.. I'm adding the key, and I'm guessing it will work.. had I not had an lp-login, I'm guessing it would have also worked :-)
<SpamapS> balloons: ahh!
<jcastro> SpamapS: should I add that to the charm instructions?
<SpamapS> jcastro: yeah, good idea
<m_3_> SpamapS: do you know the current way to specify the explicit ami in ec2
<m_3_> SpamapS: docs say it's turned off for ec2... only works on "private clouds"
<m_3_> bootstrap won't respect my deprecated default-image-id
<SpamapS> m_3_: if you explicitly set ec2-uri to https://$region.ec2.amazonaws.com/ then it will let you use default-image-id
<m_3_> ah, thanks!
<jcastro> SpamapS: ok weird
<jcastro> do "charm get tomcat6"
<jcastro> and it gets tomcat6
<jcastro> question ... look on the charm store, we don't have an official tomcat6
<jcastro> there are two personal tomcat6'es, so which one did it snag?
<SpamapS> hah
<SpamapS> the one pointed to by lp:charms/tomcat6
<m_3_> jcastro: look at .bzr/branches/branch.conf
<SpamapS> Which is actually owned by me
<SpamapS> doh
<jcastro> right. :)
<SpamapS> jcastro: its named 'precise'
<SpamapS> my guess is it was forked for precise
<SpamapS> m_3_: perhaps your rename script missed one?
<m_3_> SpamapS: dunno... I have notes on the ones it barfed on
<m_3_> there were only a couple
<SpamapS> ok well I think we just need to promulgate a ~charmers owned tomcat6
<SpamapS> m_3_: I think it was this one, because I owned it rather than ~charmers
<m_3_> oh, yeah, we only dealt with ~charmers explicitly I think
 * SpamapS fixes
<balloons> you can blame me
<balloons> :-)
<SpamapS> jcastro: thanks for pointing that out. We should now have an official tomcat6 in precise.
<balloons> ohh really?
 * SpamapS notes the charmstore tkaes a bit to update
<balloons> SpamapS, since I'm crazy while we're at it..
<balloons> I show jcastro this:
<balloons> balloons@awesomesauce:~/projects/charms/precise$ charm update
<balloons> usage: update charm_directory [ --fix ]
<balloons> balloons@awesomesauce:~/projects/charms/precise$ charm update --fix
<balloons> getopt: unrecognized option '--fix'
<SpamapS> balloons: its a little bit confusing, I know. but you forogt to put in a dirname
<SpamapS> balloons: charm update is going away
<SpamapS> balloons: it was just a stop-gap until we had store.juju.ubuntu.com
<balloons> SpamapS, yes, jcastro told me..
<balloons> I'm trying to not point out the other weirdness I'm finding
<balloons> keeping my head down..  can't help but notice/find these things
<SpamapS> balloons: noooooo.. point it out
<SpamapS> set it all on fire if you have to
<balloons> is charm update capable of updating all of my charms or ?
<balloons> is tomcat6 gonna show up eventually on this page? http://jujucharms.com/charms
<SpamapS> balloons: tomcat6 will show up there yes
<SpamapS> balloons: charm list already shows it
<SpamapS> balloons: 'charm update' just pulls all the official charms into a '.mrconfig' which you can then use to bzr branch every charm...
<SpamapS> balloons: that was a good idea when we had 20. Now we have over 70.
<balloons> ok, so let's say the offical tomcat6 charm is updated
<balloons> how do I know it got updated / and how would I get the update?
<SpamapS> balloons: well as a charm dev, 'bzr pull'
<SpamapS> balloons: for your services, 'juju upgrade-charm servicename'
<balloons> hmm.. ok, but no way for me to know there are pending updates?
<balloons> for your sake.. i'm trying to relate this to how apt works
<balloons> aka what is the equivalant for apt-get update, apt-get dis-upgrade?
<SpamapS> balloons: there's no "upgrade all of my services"
<SpamapS> balloons: upgrade-charm will pull a new version of the charm if one exists
<balloons> Ok, can I know there is a new version before running?
<SpamapS> no, that seems like a useful feature
<SpamapS> I bet we can hack that up in juju-jitsu
<SpamapS> just parse status and compare charm revisions to the repo
<balloons> :-)
 * SpamapS just submitted perhaps his most interesting new-charm yet.. "ubuntu"
<FunnyLookinHat> err - am I reading correctly... no nginx charm ?
<FunnyLookinHat> http://jujucharms.com/charms/precise
<SpamapS> FunnyLookinHat: we have charms that use nginx in development
<SpamapS> FunnyLookinHat: the thing is, nginx by itself isn't very interesting
<FunnyLookinHat> Is there a process for referencing "in development" charms...  I want to create a charm that relies on it -and rather than build it into my install script I'd rather just require it and configure it in install
<FunnyLookinHat> Right
<FunnyLookinHat> But having a charm published would allow me to do requires: http: nginx
<FunnyLookinHat> or something like that, right?
<SpamapS> sort of
<SpamapS> FunnyLookinHat: most of the intelligence for nginx that is generic is already in the package
<FunnyLookinHat> Ah ok
<SpamapS> FunnyLookinHat: so, just 'apt-get install nginx' gets you all the generic tools
<FunnyLookinHat> slick
<FunnyLookinHat> I had some poor assumption that charms should leverage the latest stable source rather than packages
<SpamapS> FunnyLookinHat: we *have* discussed having an nginx charm that would then have subordinate app charms attached to it..
<FunnyLookinHat> But that's clearly backwards.
<SpamapS> FunnyLookinHat: some charms do
<SpamapS> But only when they absolutely need to
<FunnyLookinHat> SpamapS, ah ok cool.
<FunnyLookinHat> Will you be at UDS ?
<FunnyLookinHat> err - ARE you at UDS?
<SpamapS> Tuesday and Thursday
<FunnyLookinHat> Oh you're in the bay area ?
<SpamapS> No, I'm in LA
<FunnyLookinHat> ah
<SpamapS> flying up for day trips Tue and Thu
<SpamapS> I'd come all week, but wife is 8 months pregnant
<SpamapS> she wants me home at night, just in case :)
<FunnyLookinHat> Well - swing by the System76 booth and introduce yourself on Tuesday...
<FunnyLookinHat> Ah yes.
<FunnyLookinHat> Good priority.  :)
<SpamapS> I will for sure. :)
<FunnyLookinHat> ok - so quick question... what good is the requires: db: mysql for then if it's coming from packages?
<balloons> SpamapS, more questions :-) is there an apache charm?
<FunnyLookinHat> Or is it requiring mysql on a charm-level - i.e. distributed and whatnot
<balloons> and depending -- how can I setup a charm for a webservice that runs on apache/tomcat?
<FunnyLookinHat> balloons, doesn't look like it.
<bkerensa> FunnyLookinHat: system76 will have a booth at UDS?
<bkerensa> :D
<SpamapS> balloons: just like nginx.. all the generic stuff is already in the packages. The charms need to configure apache/nginx/etc. for the specific app
<FunnyLookinHat> bkerensa, heck yes - we'll have some really awesome ( and some new I believe ) hardware to show off
<SpamapS> balloons: Though we might have a generic "high performance PHP nginx" that can plug into PHP apps via subordinates.
<bkerensa> FunnyLookinHat: cool stuff :) I have a Dell atm
<balloons> SpamapS, hmm.. I suppose your right.. I wonder if I'd use tomcat6 charm or just the package
<balloons> I might have some more ah-duh questions as I walk thru this
<SpamapS> balloons: well the charm is sort of a framework
<FunnyLookinHat> bbl
<SpamapS> balloons: in fact, for tomcat6, IIRC, it takes a URL to fetch a WAR from.
<balloons> right right.. and I won't have that
<balloons> better for me to install it as part of charm i'd guess
<balloons> cool.
<balloons> wheels are turning
 * SpamapS hears journey
<SpamapS> THE WHEELS IN THE SKY KEEP ON TUUUURRNNNIIINNN
 * balloons sings don't stop believin.... streetlights, people... ooo ahhh oooo
<Sydney> hi everybody, does someone know why the rabbitmq charm for precise throws out error whilst trying to deploy?
<SpamapS> Sydney: make sure you use 'rabbitmq-server'
<Sydney> yes i do, but still..
<SpamapS> ok
<Sydney> just error: nothing else..
<SpamapS> Sydney: is that coming from the debug-log ?
<Sydney> anyhow.. pulled the branch, seems to work locally
<Sydney> no..
<Sydney> stdout..
<Sydney> weird..
<Sydney> whoops..
<SpamapS> Sydney: stdout of your machine?
<SpamapS> like you type 'juju deploy rabbitmq-server' and it prints 'error:' and exits?
<Sydney> exactly.. he's connecting, throws out error, exits..
<Sydney> http://irclogs.ubuntu.com/2012/04/20/%23juju.html somebody mentioned that the charm name wouldn't match the metadata..
<SpamapS> hm
<SpamapS> bkerensa: https://bugs.launchpad.net/charms/+bugs?field.tag=new-charm .. I don't see your locker charm.
<bkerensa> SpamapS: I have to file a new bug for a charm thats already wishlisted?
<bkerensa> there I added the new-charm tag to the existing bug
<bkerensa> https://bugs.launchpad.net/charms/+bug/898714
<_mup_> Bug #898714: Charm Needed: The Locker Project <new-charm> <Juju Charms Collection:Fix Committed by bkerensa> < https://launchpad.net/bugs/898714 >
<bkerensa> the branch is linked to the bug report
<SpamapS> bkerensa: right, thats why it didn't get reviewed. :)
<bkerensa> ahh
<bkerensa> >.<
<dpb_> How do I change the series of a deployment at the command line when I'm launching?  like --series lucid or something?
<SpamapS> dpb_: juju deploy cs:precise/foo or juju deploy local:precise/foo
<dpb_> ok, derived from the name... got it.
<dpb_> SpamapS: thx again!
<SpamapS> namespace.. but yes :)
<dpb_> :)
<SpamapS> Sydney: ahh, ok, I'm fixing it
<SpamapS> Sydney: things were very broken there.. we had a bit of a rough patch with the move from oneiric -> precise
<Sydney> please, what?
<Sydney> that fast?
<dpb_> SpamapS: do lucid lxc images work?  Do you configure your environment differently to support them?
<dpb_> s/images/containers/
<SpamapS> Sydney: very confusing, but I think I have it figured out.
<Sydney> take your time..
<SpamapS> adam_g: question about rabbitmq charms
<SpamapS> adam_g: would you say lp:~openstack-ubuntu-testing/charms/precise/rabbitmq-server/trunk is the "best" charm to have in precise?
<SpamapS> m_3_: I think I finally figured out the rabbitmq mess
<m_3_> SpamapS: awesome... thanks!
<m_3_> did you unpromulgate lp:charms/rabbit
<SpamapS> m_3_: promulgate looks at meatdata.yaml to choose a charm name
<SpamapS> m_3_: the charms have name: rabbitmq
<SpamapS> meatdata
<SpamapS> hehe
<SpamapS> or rather, had
<SpamapS> m_3_: yes!
<SpamapS> fixed
<SpamapS> finally
<SpamapS> m_3_: lp:charms/rabbitmq-server now points at https://code.launchpad.net/~charmers/charms/precise/rabbitmq-server/trunk
<SpamapS> m_3_: and there is no lp:charms/rabbitmq
<SpamapS> Sydney: if you want to make sure I got a working charm, you can do 'charm get rabbitmq-server' and then deploy it using local:rabbitmq-server
<SpamapS> thats now *3* charms we need deleted from the charm store.
<m_3_> SpamapS: awesome
<Sydney> well, i will give it a try as i do testing anyways.. had pulled it via bazar for now.. but i'll give it a shot.. thanks anyways..
<SpamapS> Sydney: right, so just 'bzr branch lp:charms/rabbitmq-server'
<Sydney> exactly...
<Sydney> but how do i pull a charm with "charm get rabbitmq-server"?
<SpamapS> Sydney: thats just an alias for 'bzr branch lp:charms/$1'
<Sydney> all right.. i'm pretty new to juju, beginner's class :)
<SpamapS> Sydney: welcome!
<bkerensa> ;p
<Sydney> Thanks, Man.. nice to know..
<balloons> SpamapS, alright.. i'm in knee deep now :-) So I have a few questions on my first charm here
<balloons> my app in question needs a specific user and table created as part of the setup in mysql
<SpamapS> balloons: why a specific user?
<SpamapS> balloons: it can't just use the user you tell it to use?
<SpamapS> balloons: most apps just want to own a single database all to themselves
<SpamapS> balloons: if yours is special and more complex, you can use the other interfaces in the mysql charm.. mysql-shared or mysql-root
<balloons> SpamapS, well, yes, it wants it's own db.. but I need to get that value back.. if the user is randomly named
<balloons> I need to tell the app what the setup info is
<SpamapS> balloons: right, thats how all charms work
<balloons> right ;-)
<SpamapS> balloons: you need a something-relation-changed hook, attached to an 'interface: mysql' relation
<balloons> ahh.. I was missing the relation bit
<SpamapS> balloons: that hook will use 'relation-get user' to find out the user (and password, database, host, etc)
<balloons> right
<balloons> i was trying that in my install hook
<balloons> ahh-ha
<SpamapS> nooo install is for things that only ever happen one time
<SpamapS> relations are important :)
<balloons> lol - yes, I got the idea better now..
 * balloons is off to add some new hooks!
<SpamapS> ok, my brain is officially fried
#juju 2012-05-04
 * SpamapS EOD's
<adam_g> SpamapS: re: rabbitmq. no, none of those ~openstack-ubuntu-testing charms are relevant to anything outside of that jenkins lab
<_mup_> juju/unit-rel-lifecycle-start-invoker r535 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<_mup_> juju/unit-rel-lifecycle-start-invoker r536 committed by jim.baker@canonical.com
<_mup_> Addressed review points
<jimbaker> adam_g, i just committed the fix for working with relation ids from relation hooks to trunk. SpamapS, this is a trivial one-liner and imho should be included asap in the juju distro
<jimbaker> along the lines of other recent fixes we have had
<adam_g> jimbaker: cool. if theres an SRU bug somewhere, i can verify. or let me know, and ill file one
<imbrandon> SpamapS: i think rs is gonna be the way to go for sites similar to OMG, or ones setup to scale the same way
<imbrandon> mainly because of their small servers that have 265mb ram but 4x2.2ghx proc and can sustain high cpu task
<imbrandon> so bootstrap on a tiny
<imbrandon> mysql on a something not considered here but seperate as is now
<imbrandon> cluster or not etc
<imbrandon> and each webhead ona  tiny but lots of them
<imbrandon> cuz right now the OMG webheads are maxing the cpu's but use very little other resources
<imbrandon> so scaleing them out to many of these ultra tiny webheads that have lots of cpu makes sense
<imbrandon> ( just thinking out loud here, as i prep the same charms to deploy websitedevops.com )
<imbrandon> oh and the tiny's are 0.01c hr , vs 0.08 for mediums on aws
<imbrandon> so couple that with some rrdns and the lb setup we adopted
<imbrandon> = win
<imbrandon> SpamapS: http://cl.ly/GNEY  <--- thats pretty avg accross the 3 current webheads , 15 to 25 Mb/s traffic, 30ish % of the 1.6 G ram used and 1.0 sys load
<imbrandon> kinda strange to me, past experince has always been the ram not cpu on webheads
<imbrandon> heh
<marcoceppi> bkerensa: Are you working on the OpenPhoto charm?
<SpamapS> imbrandon: the reason the RAM isn't running out is because of the heavy caching, you don't need many active processes
<bkerensa> marcoceppi: yes
<marcoceppi> bkerensa: ah, wasn't sure
 * SpamapS wishes mediagoblin was easier to package, he'd finish it and get it promulgated
<SpamapS> actually what I really wish is that pip installs used https
<marcoceppi> Time for a patch?
<SpamapS> no, pypi doesn't have https
<SpamapS> Though we *could* mirror pypi into a launchpad project.....
<SpamapS> but, no, thats silly. Packaging isn't actually that hard, I just need to finish it
<imbrandon> SpamapS: yea, just thought it was unique
<marcoceppi> bkerensa: I read your G+ post about openphoto and I was like "YES THEY HAVE A REPO" and then I saw the install script they made, which is like 90% charm ready
<marcoceppi> s/G+/planet/
<SpamapS> imbrandon: its actually really encouraging. :)
<SpamapS> imbrandon: leaves RAM for VFS cache and stuff. The webheads are doing the cache of files, right?
<bkerensa> marcoceppi: yep and I have it partially done and hope to have it fully done by the deadline... I might pick your brain to make it more frosty but right now I have to go pack :D
<marcoceppi> I should probably pack soon too. I have too many social engagements leading up to my departure Sunday morning
<m_3_> SpamapS: oh, btw, the new version of rubygems checks https certs... saw the release notes at conference
 * m_3_ has to check that against the version we have in precise
<imbrandon> SpamapS: yup
<marcoceppi> Can a relation hook both set and get relational data?
<m_3_> marcoceppi: yup
<marcoceppi> spectacular
<SpamapS> m_3_: sweet
<m_3_> marcoceppi: the conversation keeps firing as long as either hook keeps _set_ting relation data
<SpamapS> marcoceppi: there are a few, like mysql replication, that do several rounds of back and forth relation get/sets
<marcoceppi> I think that's what I want do to for gluster
<marcoceppi> instead of just having one giant shared fs, each charm should have it's own brick so the gluster client and gluster server need to keep up communication
<m_3_> marcoceppi: the coolest part of gluster is that we now have subordinates!
<marcoceppi> m_3_: I know! That's why I've started working on proper subordinate gluster-server/client charm pair
<m_3_> marcoceppi: that's the hard part... specifying the striping config you want from the clients
<marcoceppi> m_3_: I figured just config value for each gluster-client
<marcoceppi> there's only 4 different types of stripes
<marcoceppi> unfortunately this is only a segue charm pair so I can get back to work on my main charm of interest
<m_3_> marcoceppi: yeah, the client should get the makeup of the entire volume its currently using as config... not easy though
<m_3_> marcoceppi: maybe the stack startup script would specify the volume composition, then pass that into the config for the client... dunno how to discover that dynamically though.  maybe see what clint did on ceph
 * imbrandon gigles a little inside at seening his newest charm have "#!/usr/bin/env php" at the top of hooks
<imbrandon> SpamapS: is it nessesary to have a requires in the metadata ?
<bkerensa> imbrandon: we still have no solid time/day for cloudflare?
<bkerensa> :(
<imbrandon> bkerensa: no worries, it will work out
<imbrandon> and if not there is always next time
<bkerensa> imbrandon: Im sure they will be there pretty much 9 to 5
<bkerensa> :D
<bkerensa> so long as a I ping @eastdakota half hour before we head out they can prepare
<imbrandon> bkerensa: my goal is to be out on the left coast by this time next year anyhow :)
<imbrandon> :)
<bkerensa> for work/living?
<imbrandon> yea
<bkerensa> is that what were known as in the red states?
<bkerensa> The left coast?
<imbrandon> hahaha
<imbrandon> pretty much
<tooth> also matters what continent.
<bkerensa> for good reason probably
<bkerensa> :D
<imbrandon> brb afk
<marcoceppi> Will `relation-list` in a peer relation list the current unit?
<imbrandon> marcoceppi: i dont think so, thats why the 127 in the omg
<imbrandon> lb relation
<marcoceppi> Gluster seems like it's this huge thing, but so far it looks really straight forward to setup
<jcastro> I see your incoming charm
<jcastro> Yeah I set it up, it was dead easy
<bkerensa> anyone want to review locker charm? :)
<SpamapS> marcoceppi: the question is, how to get charms to mount gluster
<marcoceppi> SpamapS: that's what I'm trying to figure out in an elegant fashion
<marcoceppi> Charms will have to expect gluster current
<SpamapS> marcoceppi: or, perhaps, charms should just have a 'scope: container' relationship where they ask for a place to put their data
<SpamapS> marcoceppi: interface: mount
<SpamapS> marcoceppi: then gluster, nfs, and ceph, all have subordinates which speak that interface, and tell them "put it here..." and mount the data there
<marcoceppi> In fact, the way I have the gluster-client currently setup, it expects two relations, juju-info and a shared-fs relation where the charm tells gluster where the mount point should be
<SpamapS> marcoceppi: \o/
<marcoceppi> yeah, figured that was the best way for now
<SpamapS> thats perfect
<SpamapS> we should do NFS too... just for the "never do this" case. :)
<marcoceppi> SpamapS: already did that too :)
<marcoceppi> gluster-server charm has a direct NFS relation
<SpamapS> marcoceppi: I'm going to give jcastro some cash so he can buy you beers all the nights I'm not there next week ;)
<marcoceppi> so you can use the gluster-client, or just add-relation to the nfs interface on the main charm
<SpamapS> marcoceppi: the NFS interface isn't as fault-tolerant though.. is it?
<marcoceppi> and not as robust
<SpamapS> so.. IMO.. leave it out
<SpamapS> its for non Linux clients
<marcoceppi> SpamapS: http://i.imgur.com/hZf6H.jpg
<imbrandon> ugh
<imbrandon> getting a little confused
<imbrandon> http://paste.ubuntu.com/967228/
<imbrandon> SpamapS marcoceppi ^^
<bbcmicrocomputer> Have a Q.. when you have a one to many relation between say service A, B and C, e.g. A->C , A->B, when C breaks its relation with A, A's relation-broken hook doesn't appear to have a means of telling whether it's relation with B or C is being broken, so it seems impossible to make the hook idempotent, anyone know any answers?
<jcastro> SpamapS: get in line.
<SpamapS> bbcmicrocomputer: there is a way, its just not obvious
<SpamapS> bbcmicrocomputer: and many charms don't make use of it, because it only landed in recent juju versions
<SpamapS> bbcmicrocomputer: $JUJU_RELATION_ID
<SpamapS> bbcmicrocomputer: you can enumerate the relations with the relation-ids command
<bbcmicrocomputer> SpamapS: ah cool, will investigate
<SpamapS> imbrandon: that looks good. assuming then that its just for serving static content?
<imbrandon> yea i want the websites to determine the
<imbrandon> dynaic part
<imbrandon> but not sure how to handel that yet
<imbrandon> e.g if they want to use uwsgi or php or whatever
<SpamapS> imbrandon: in addition to 'webroot' perhaps have an interface 'fcgi-socket' ?
<imbrandon> hrm
<imbrandon> would that be an interface or just a config
<SpamapS> imbrandon: youc an feed back 3 things .. fcgi-socket, static-wwebroot (for the "if it exists just serve from there"), and 'cache-url-patterns' for the thing to define where to look for cached pages.
<imbrandon> as it is right now , i want this to be the base charm, not sub, and provide a nginx that is both a content on 8080 and 80 like the omg
<SpamapS> imbrandon: interface definitely
<imbrandon> and then yea have "sites" as subcharms
<imbrandon> even frameworks and then sites
<SpamapS> imbrandon: right, so nginx is primary, opens ports, etc. Then you have 'omg-wp' as a subordinate that drops its files in, and tells nginx how to serve it'
<imbrandon> yea
<imbrandon> exactyly
<SpamapS> you can relate subs to other subs btw
<imbrandon> yea , i was thinking this as the base and then sub be wp, then sub of that be omg-wp
<imbrandon> was my plan
<imbrandon> but also support like marcoceppi gluster etc
<SpamapS> so while it will be a bit wonky, you can have 3 tiers of relations on a box.. like...  nginx->php-fcgi->wordpress (and then get crazy, ->omg-themes)
<imbrandon> thus the other optional bits
<imbrandon> SpamapS: yea ,e xactly
<imbrandon> well omg-something as it would be themes+plugins
<imbrandon> but yea
<SpamapS> imbrandon: perhaps I will write an Apache 2.4 charm w/ the same interfaces, and we can have a shootout. :)
<imbrandon> :) rockin
<imbrandon> lll
<imbrandon> i rally want so seperate it too at some point
<imbrandon> but not in time for the contest
<SpamapS> imbrandon: one thing I want to do is enhance the http interface with an 'endpoint-host' that can be set by either side. I'm not sure which one should take precedence though.. upstream or downstream.
<imbrandon> as in seperate the nginx lb+cache and the 80
<imbrandon> so apache could be the content serving
<balloons> allo, mes amis.. So I'm looking at this page now: https://juju.ubuntu.com/docs/getting-started.html#configuring-your-environment. It says to run juju without arguements to generate an example enviroments.yaml.. That doesn't seem to work.
<imbrandon> SpamapS: yea i had that question too, just wasent sure how to articualte it yet
<balloons> Juju just responds with the argument list
<SpamapS> balloons: did you look at ~/.juju/environments.yaml ?
<balloons> SpamapS, right.. there's no folder created
<balloons> that *should* work then yes
<balloons> ?
<SpamapS> balloons: interesting, I think we must have broken that
<imbrandon> thats used to work
<SpamapS> balloons: try 'juju bootstrap', does it create it then?
<SpamapS> I think we made it so it only creates it if you try to do something now
<SpamapS> since typing 'juju --help' was creating it
<balloons> juju: error: too few arguments, and gives arg list
<imbrandon> ahh
<SpamapS> so docs probably need fixing
<balloons> k, trying juju bootstrap
<balloons> awesome: error: No environments configured. Please edit: /home/balloons/.juju/environments.yaml
<balloons> so yea.. just needs updated I guess
<SpamapS> balloons: if you're feeling adventurous.. 'bzr branch lp:juju/docs' .. and fix it. :) I'll merge it :)
<SpamapS> balloons: otherwise file a bug here https://launchpad.net/juju/+filebug and we'll get to it right away
<imbrandon> SpamapS: btw here in a few hours when i get frustrated enough with the nginx charm to switch gears i got some small updates to the newrelic one if you wouldent mind pushing, mostly stuff you sugested the other day
<balloons> SpamapS, yea I had planned on branching and merging
<balloons> I'll add it to the list of changes :-)
<SpamapS> Also there's another way to setup a new environments.yaml.. 'jitsu setup-environment' ... a little more user friendly :)
 * SpamapS adds ssl-hostname-verification to that
<SpamapS> imbrandon: sweeeeet .. yeah just bug me. I'll be out on the road for a couple hours starting at 1200 my time tho.
<imbrandon> kk
 * imbrandon has to pack sometime today
<imbrandon> btw i'm thinjking more downstrea,
<imbrandon> as in the "lowest" sub should be able to overide anything its layerd on
<SpamapS> imbrandon: I was thinking there will be times where it may be useful to define it at the upstream point, for instance if you want to host two apps under one proxy.
<FunnyLookinHat> Is there an etiquette for assigning a charm request bug to yourself if someone else owns it?  It looks like there has been no movement on it:
<FunnyLookinHat> https://bugs.launchpad.net/charms/+bug/931835
<_mup_> Bug #931835: Charm needed: Gitlab <Juju Charms Collection:New for antono> < https://launchpad.net/bugs/931835 >
<SpamapS> which is quite likely for big multi-layerd apps
<SpamapS> but.. those should really not be doing Host: inspection
<imbrandon> yea
<SpamapS> still sometimes you need to know what the Host is. :p
<imbrandon> and would likely have
<imbrandon> well
<imbrandon> hrm
<marcoceppi> FunnyLookinHat: I'm actually working on that atm
<FunnyLookinHat> marcoceppi, Ah - glad I asked.
<marcoceppi> yeah, I didn't claim it yet, becaues I was trying to get a hold of the author
<FunnyLookinHat> Same here - but I was trying to do it through the ticket
<imbrandon> mmm i forgot to file an nginx one, supose i should do that
<SpamapS> So, IMO, Antono claimed it almost 2 months ago
<FunnyLookinHat> marcoceppi, you can take it though  :D
<marcoceppi> If you wanted to take a stab feel free, I'm trying to do a gluster, gitolite, gitlab combo to make a scalable github-esque setup
<SpamapS> and has then gone dark
<FunnyLookinHat> marcoceppi, oh geez... I just wanted a simple charm to deploy a gitlab setup so that people could easily either run git or sparkleshare types of stuff on their client
<SpamapS> How does everybody feel about making the policy that you can only "claim" a new charm bug for 30 days before it goes back to available?
<FunnyLookinHat> SpamapS, good idea.
<SpamapS> Debian has recently done the same with ITP bugs for intent to package.
<marcoceppi> SpamapS: +1
<imbrandon> SpamapS: +1
<SpamapS> m_3_: ^^
<SpamapS> Ok, the motion carries.
<FunnyLookinHat> w00t.
<SpamapS> I will record that at https://juju.ubuntu.com/Charms
<SpamapS> marcoceppi: are you definitely ready to work on it now, or do you want to give it to FunnyLookinHat ?
<FunnyLookinHat> So if I need ruby 1.9.2 and only 1.9.1 is available in the repositories, should I make my charm download/build 1.9.2 or should I try to reference another charm somehow?  I know one is in dev here: https://bugs.launchpad.net/charms/+bug/799879
<_mup_> Bug #799879: Charm needed: rails (framework) <developers> <Juju Charms Collection:In Progress by mark-mims> < https://launchpad.net/bugs/799879 >
<m_3_> SpamapS: yeah, that sounds good
<marcoceppi> SpamapS: I plan to have it done for UDS, I'm kind of doing gluster, gitolite, then gitlab in that order, so FunnyLookinHat if you want to take the gitlab charm feel free
<FunnyLookinHat> I'm going to try to throw it together for UDS - figured it'd be a decent entry for the competition
<FunnyLookinHat> LOL
<FunnyLookinHat> marcoceppi, You take it
<FunnyLookinHat> I have others to do
<FunnyLookinHat> magento is one that a lot of people seem to want
<SpamapS> marcoceppi: please assign it to yourself
<m_3_> FunnyLookinHat: note that the package 1.9.1 is actually a newer version of ruby
<FunnyLookinHat> m_3_, newer than 1.9.2 ?
<m_3_> 1.9.3p0
<FunnyLookinHat> How does that work?
<FunnyLookinHat> Ooooh
<m_3_> it's just the package _name_ was chosen poorly imo
<FunnyLookinHat> Should be ruby-current
<m_3_> FunnyLookinHat: also note that rvm is packaged now too
<FunnyLookinHat> Or just ruby
<FunnyLookinHat> Oh awesome
<m_3_> that makes it easier
<FunnyLookinHat> much
<SpamapS> FunnyLookinHat: the reason 1.9.1 was used was that it was wildly incompatible with 1.9.0
<SpamapS> FunnyLookinHat: so anything that depended on ruby1.9 wouldn't necessarily work with ruby1.9.1
<m_3_> FunnyLookinHat: feel free to run with rails for the charm contest.  the one in there is mine, but it's pretty naive and I really only use it for example hooks... it definitely needs some love across the board.  should be split from apache/passenger so nginx, unicorn, thin, etc could be used.  perhaps as a subordinate charm even
<SpamapS> this unfortunately put the package maintainers in a bad position when 1.9.2 and 1.9.3 arrived, because they *are* compatible with 1.9.1
<m_3_> yikes... really?
<SpamapS> yep
<SpamapS> its really ruby's fault
<SpamapS> should have been 1.10, not 1.9.1
<m_3_> no surprise, but still quite ugly
<imbrandon> or 1.9.1.1
<imbrandon> heh
<FunnyLookinHat> m_3_, this would be my FIRST charm... so I think I'll write the magento one first ( seems the easiest to deploy ) and then I might try my hand at something more complex.
<SpamapS> I think ruby1.9.1 was the wrong choice
<m_3_> FunnyLookinHat: awesome!
<SpamapS> But it was right before freeze for squeeze IIRC
<tobin> Is there a concept of server vs. client when writing charms? IE only the server has specific configs, and the client another set.
<SpamapS> Can you guys look at https://juju.ubuntu.com/Charms and make sure I specified that correctly? Specifically search for '30 days' and see the footnote
<SpamapS> tobin: charms provide, and require things
<SpamapS> tobin: typically servers provide, and clients require
<tobin> Okay somewhat like dpkg. Got it. thank you SpamapS.
<marcoceppi> SpamapS: should there be an exception if there's a repository attached to the bug but no activity in 30 days?
<balloons> alright -- juju bootstrap worked.. I see a small instance deployed
<balloons> a few questions :-) can I control the instance size / type it creates when I bootstrap?
<balloons> sorry I should say.. I bootstrapped to ec2
<imbrandon> balloons: yea with constraints
<m_3_> SpamapS: https://juju.ubuntu.com/Charms sounds good
<balloons> imbrandon, thanks.. I see the docs on constraints.. looks simple
<m_3_> marcoceppi: hmmm... yeah, we sort of have to account for charms people write that attach to a bug but they might not wanna publish it into the store
<m_3_> not sure
<balloons> so I issued the 'juju debug-log' command in one window, and a juju deploy mysql in another.. I don't seem to be getting any messages in the tailing log window though :-( Is there a log level I can set perhaps?
<m_3_> I guess the bugs are for the charms we're wanting in the store... so no, they'd still be fair game
<marcoceppi> cool
<marcoceppi> makes sense
<balloons> nvm.. things are cranking in the log now :-)
<SpamapS> marcoceppi: I don't think so, no. Though anybody else who takes it on would be a bit silly to not at least use that as a starting point.
<m_3_> balloons: "provider-delay" let's call it :)
<balloons> that took a long time after I issued the commands and they returned successful.. interesting
<marcoceppi> SpamapS: makes sense
<balloons> m_3_, yes makes sense..
<balloons> gotta spin up the machines, etc
<SpamapS> marcoceppi: I'd like to favor the person interested *now*. :)
<marcoceppi> Not a bad idea
<m_3_> agree
<SpamapS> The reason for the bug assignment bit is that we want to reduce duplication of effort.
<m_3_> ok, so "super last-minute drop everything" project isn't happening right now, so back to charm testing...
<SpamapS> BTW, I saw no response to my maintainer: thread on juju.. so I'm going to start assigning maintainers soon.
<m_3_> BTW, we're rolling up test results to jenkins.qa.ubuntu.com
<jcastro> SpamapS: hey so, I'm thinking, kill the spreadsheet for charms
<m_3_> still working to get other provider tests to show too
<jcastro> and move to all bug reports.
<m_3_> jcastro: yes, please
<SpamapS> m_3_: woot. Where is the main charmtester branch? I want to add explicit tests soon
<SpamapS> jcastro: yes please
<imbrandon> jcastro: spreadsheets are evil
<SpamapS> m_3_: JINX!
<SpamapS> oh wait
<SpamapS> I said your name.. so.. yo're already free
<m_3_> lp:~mark-mims/charmers/charms/precise/charmtester/trunk
<m_3_> ha!
<SpamapS> stupid IRC killing a children's game
<imbrandon> lol
<SpamapS> m_3_: you mean /charms/precise right, not /charmers/charms
<m_3_> surely we can remember others... /me digs around in there
<m_3_> crap... yeah
<imbrandon> SpamapS: when can i use #!/usr/bin/php on install hook kthxbia!
<m_3_> lp:~mark-mims/charms/precise/charmtester/trunk
<m_3_> was reading other things while typing...
<marcoceppi> imbrandon: almost never :)
<m_3_> imbrandon: +1 for adding dep packages in metadata
<imbrandon> :)
<SpamapS> imbrandon: when the sun rises in the west and sets in the east
<imbrandon> my install hook for nginx is seriously "apt-get update && apt-get install nginx php5-cli && php ./includes/install"
<imbrandon> heh
<marcoceppi> imbrandon: nothing wrong with that
<imbrandon> oh i know, just kinda pointless
<imbrandon> and the rest all use #!/usr/bin/php :)
<m_3_> imbrandon: that's really pretty close to sourcing the php interpreter to consume the rest of the hook :)
<marcoceppi> Â¯\(o_o)/Â¯
<m_3_> we should put a snippet together to do that :)
<imbrandon> :)
<m_3_> s/php/anything else/ of course :)
<imbrandon> would work for ruby or anything
<imbrandon> yea
<m_3_> yup
<m_3_> fairly obscene tho
<imbrandon> lol yea
<imbrandon> i see SpamapS cringing now
<m_3_> SpamapS: I just realized I haven't updated that branch in a while... git-bzr barfed on me a while ago and I haven't done the workaround... updating now
<imbrandon> m_3_: speaking of yea the one you use is the one i do as well
<imbrandon> git bzr ng
<SpamapS> <sigh>
<imbrandon> git bzr clone lp:blah
<imbrandon> etc
<SpamapS> so sad that you guys can't just play nice w/ bzr. :)
<imbrandon> heh it hates me
<imbrandon> and i dont like the forks are called branches
<imbrandon> :)
<SpamapS> I don't like that git calls update revert, and revert merge, and merge .. wtf I am lost already :)
<SpamapS> but I still use git when I am working on projects that use git
<imbrandon> heh
<imbrandon> thats it tho my projects are in git, not bzr, i just must use it to get reviewed :)
 * imbrandon stops
 * imbrandon hugs SpamapS :)
 * m_3_ actually thinks there're more similarities than differences... 
 * SpamapS hugs err'body
<imbrandon> yea there are quite a few, but i see bzr is more akin to hg, infact its damn near identical
<imbrandon> just slower
<SpamapS> There may come a day where we can have charms in git in the store
<balloons> SpamapS, I think I did the docs merge properly (hope) https://code.launchpad.net/~nskaggs/juju/juju-bootstrap-fix/+merge/104781
<SpamapS> that day is not today
<marcoceppi> relation-list spits out service/unit correct?
<SpamapS> marcoceppi: yeah
<imbrandon> really my main main gripe is split between bzr merges seem dumb compared to gits ( as do pretty much any other vcs compared to git, there is a reason hg as a config option of [merge] git=true to use git for merging ) and the fact that bzr branches are actualy forks and not "in-place" like git branches with hardlinks, i REALLY like that feature
<SpamapS> imbrandon: actually there's been recent work to have in place branches in bzr
<SpamapS> as everybody seems to like that
<imbrandon> dude, if that lands i'll convert
<FunnyLookinHat> So question - I feel as though I'm creating a bad charm if all it does it download code, create a user, extract code and assign rights, and then setup a VirtualHost - am I missing something?
<SpamapS> Heh, but what about rebase, and fastforward.. and the 3x speed difference? :)
<FunnyLookinHat> i.e. is there some magic sauce where I'm supposed to make sure it can be duplicated or something ?
<imbrandon> heh i can take one for the team
<imbrandon> :)
<SpamapS> imbrandon: talk to niemeyer, he wrote a plugin to do it
<SpamapS> imbrandon: its called 'cobzr' you can probably find it
<imbrandon> kk yea i'll check it out soonish
<m_3_> FunnyLookinHat: there's all sorts of stuff you can do to expand on charms... but the basics are pretty basic... on purpose
<SpamapS> FunnyLookinHat: thats a great charm!
<FunnyLookinHat> Ok awesome- just making sure I'm not submitting work that's worthless and has to be redone  :D
<SpamapS> FunnyLookinHat: if the charm stores user data locally.. you may want to find a way to store that in a shared place (like a database, or a shared filesystem), but that is where things get complicated and we all huddle together to scale-out a service.
<m_3_> SpamapS: great description
<SpamapS> I really think if I spend a week on ways to scale-out w/ mysql I will be able to make mysql's 'add-unit' extremely useful.
<imbrandon> SpamapS: yea i wanna get with you at uds too about a ndb mysql charm
<SpamapS> Like, make it a replication ring, or maybe use galera to do sync-replication.. or screw it lets just make everything NDB cluster.
<SpamapS> imbrandon: NDB's problem is network bandwidth
<imbrandon> ahahaha
<SpamapS> you need a ridiculous amount of it
<imbrandon> right but its so sexy
<SpamapS> imbrandon: sure, its sexy on infiniband. I doubt it performs on EC2
<m_3_> FunnyLookinHat: we try to make suggestions for how to handle scaling, upgrades, external relations, etc in review too
<FunnyLookinHat> m_3_, oh ok cool
<imbrandon> SpamapS: i can see a whole env juju'd with ndb charms , then have your "web" farm in another juju env
<imbrandon> just dunno how to make them talk yet
<imbrandon> :)
<imbrandon> external relations
<imbrandon> mmmm
<imbrandon> so i can upgrade or blow away my web farm but not my shared storage farm or my memcache farm or my sql farm
<imbrandon> mmmm dreams
<imbrandon> kinda like meta suboranates ? heh
<m_3_> imbrandon: take a peek at the mongodb charm's config.yaml file... note that the replicaset_master can be specified by host/port explicitly.  It's pretty manual, but it's a way of bridging between two juju envs
<imbrandon> nice, i was sure i wasnt the first to think of it
<m_3_> imbrandon: so the charm needs to be written to handle both "kinds" of relations
<imbrandon> right
<imbrandon> small price
<m_3_> imbrandon: but it's what we have atm
<imbrandon> yea, better than full on manual
<SpamapS> imbrandon: also subordinates can easily be used to proxy between two envs
<m_3_> in all sorts of interesting ways
<imbrandon> SpamapS: ahh hadent thought of that
<SpamapS> especially now that we have out-of-hook relation-set capability
<m_3_> ha!
<m_3_> yes
<imbrandon> hrmm, intresting times we now live in
<SpamapS> just need dynamic relation capability and we can have a juju-proxy charm
 * imbrandon just needs to get a job where he can write charms all day 
<SpamapS> m_3_: watch your back!
<bkerensa> SpamapS: if you move a merge proposal to "merged" will launchpad merge it?
<SpamapS> ;)
<m_3_> ha!
<SpamapS> bkerensa: not sure, that would be cool though
<bkerensa> lol
<m_3_> imbrandon: yeah, you end up doing all sorts of other stuff too :)
<imbrandon> :)
<bkerensa> SpamapS: ok well for some reason I have review privileges on a branch
<bkerensa> >.<
<bkerensa> and I reviewed some code and it looks fine
<bkerensa> :P
<SpamapS> bkerensa: lp:juju/docs is owned by ~charm-contributors
<SpamapS> Basically anybody who asks real nice can update the documentation. :)
<m_3_> bkerensa: yeah, we've got a bit of disconnect between charms and our charm process and launchpad atm
<bkerensa> LOL
<bkerensa> m_3_: your not a bot?
<bkerensa> :D
<SpamapS> bkerensa: no, change it back to Approved, launchpad did not merge it ;)
<SpamapS> as cool as that would be
<bkerensa> SpamapS: yeah I saw it
<m_3_> SpamapS: found my notes from series upgrade btw... there's still a couple of danglers
<bkerensa> its moved back
<m_3_> bkerensa: ha!.. nope, not a bot
<m_3_> bkerensa: all my names start with 'm'... and you _don't_ wanna turn on irc highlighting for 'mmm' :)
<imbrandon> lol
<m_3_> SpamapS: but now we have unpromulgate... thanks!
<SpamapS> oh that reminds me
<SpamapS> I pushed adams crazy juju testing lab as the official rabbitmq-server branch
<m_3_> SpamapS: btw, if you wanna see _exactly_ what the lp script did on series upgrade, lp:charms/nova-compute is still in a pristinely screwed up state (i.e., we haven't tried to fix it yet)
<SpamapS> adam_g: is there any reason not to include your special testing lab fork in the main charm store? I'd rather there only be one place that is generally consumed.
<m_3_> basically, compare lp:charms/nova-compute ( -> lp:~charmers/charms/precise/nova-compute/precise ) with lp:~charmers/charms/precise/nova-compute/trunk
<SpamapS> bkerensa: you can go ahead and push that fix into the branch btw
<bkerensa> SpamapS: How do I push it in?
<bkerensa> =/
 * bkerensa has never merged 
<bkerensa> do tell
<balloons> :-) more doc changes..  juju is yelling at me for having a revision info in my metadata.yaml file.. looks like there is a revision file now.. the docs should be updated
<m_3_> when lp:charms/nova-compute was updated from ...oneiric.. there was another branch on lp:~charmers/charms/precise/nova-compute/trunk, so the lp script renamed it to lp:~charmers/charms/precise/nova-compute/precise and aliased accordingly
<SpamapS> bkerensa: there's a first time for everything! :)
<bkerensa> SpamapS: do tell how
<SpamapS> bkerensa: simplest way, 'bzr branch <<the branch you want to merge in>>'
<balloons> I'll do my best to edit that also
<bkerensa> then bzr merge?
<SpamapS> bkerensa: then if there is only one commit, just 'bzr push lp:juju/docs'
<bkerensa> ahh
<bkerensa> k
<m_3_> SpamapS: so the net is the aliased branch is old... needs to be unpromulgated and then the lp:~charmers/charms/precise/nova-compute/trunk branch needs to be promulgated in its place
<SpamapS> bkerensa: if there are like, 10 crazy commits, you just want one in the mainline changelog, so you 'bzr branch lp:juju/docs', cd into that dor, and 'bzr merge ../whatever' and then commit as one thing.. 'Merging doc fix...'
<m_3_> SpamapS: that's what happened with rabbitmq-server, but there was lots of manual "intervention" to try to fix this without an unpromulgate :(
<SpamapS> Yeah
<SpamapS> I think you named a brnch FML or something
<m_3_> well... yes
<m_3_> I should write this down for next release upgrade so we know exactly what we're gonna try to prevent
<SpamapS> m_3_: I assume this is the one we want: lp:~charmers/charms/precise/nova-compute/trunk
<m_3_> SpamapS: I think that's correct... looking at the history
<balloons> can someone confirm the revision file is automatically created now, or is this something I should create and update?
<SpamapS> m_3_: I'm pretty sure all we need to do is rename the trunk -> series name *and* get the charm store to ignore the branch name for official branches
<m_3_> SpamapS: hmmm
<SpamapS> balloons: you'll have to create it and update it whenever you want users to see the new charm.
<balloons> SpamapS, hmm.. I don't remember making one.. but there is a file now called revision with a '1' in it
<balloons> in my charm
<SpamapS> m_3_: Ok so the fix is this: bzr branch lp:charms/nova-compute ; cd nova-compute ; charm unpromulgate ; cd .. ; mv nova-compute nova-compute-busted ; bzr branch lp:~charmers/charms/precise/nova-compute/trunk nova-compute ; cd nova-compute ; bzr push :parent ; charm promulgate
<jcastro> woo, lots of charm activity lately!
<imbrandon> offer shiney toys and that happens :)
<SpamapS> jcastro: at least 60 commits per day since Feb 12.
<m_3_> SpamapS: right, that sounds perfect... did you already do it, or shall I?
<SpamapS> m_3_: I want you to do it, so I can confirm there's nothing special on my machine :)
<m_3_> SpamapS: will do
<SpamapS> m_3_: I'm also interested in seeing what happens when I 'bzr pull' from the aliased branch
<jcastro> hazmat: speaking of, we might want to fix the charts ^^^^
<SpamapS> m_3_: so let me know when you're done
<m_3_> SpamapS: also my notes say it barfed on zookeeper, statusnet, nova-compute, nova-cloud-controller, rabbitmq-server
<m_3_> I'll do nova-compute now... one sec
<bkerensa> SpamapS: ok balloons stuff is up
<SpamapS> bkerensa: woot!
<bkerensa> I thought there was much more to all that
<bkerensa> =/
<SpamapS> I think the website refreshes every 15 min or maybe 60 min, not sure
<m_3_> SpamapS: http://paste.ubuntu.com/967444/ I use this machine for bzr/lp all the time, so it has my lp id / keys
<SpamapS> m_3_: are you ssh'd to it? that breaks
<SpamapS> I don't know why
<m_3_> probably... lemme see if I can turn that off
<SpamapS> but launchpadlib won't work if you ssh into a machine that also has your lpcreds in gnome keyring
<m_3_> oh... I see
<m_3_> yeah, other desk one sec
<SpamapS> yeah, its dumb
<SpamapS> I'm sure there's a way to get it to ignore the gnome keyring creds, but I don't know what it is
<imbrandon> works fine if osx keyring has them heh
<imbrandon> i;m sure it dont look in the osx keyring on osx tho
<SpamapS> imbrandon: does lplib work on os x?
<imbrandon> yup
<imbrandon> use it all the time
<imbrandon> its how bzr knows who i am when pushing and such
<imbrandon> like i said pretty sure it ignores the osx keyring tho
<balloons> hmm.. ok, how do I undeploy a charm if you will?
<SpamapS> balloons: juju destroy-service foo
<SpamapS> balloons: note that the machines are not terminated
<balloons> right, is destory enviroment the only way to kill a machine?
<balloons> or can i selectively kill off a machine?
<balloons> as far as I can tell, I don't see destroy-service mentioned in the docs anywhere
<m_3_> SpamapS: ok, so I keep gettings can't determine launchpad location from bzr branch
<marcoceppi> -relation-departed the $JUJU_REMOTE_UNIT is the unit which "departed", correct?
<SpamapS> m_3_: you might have forgotten the 'bzr push' step?
<SpamapS> marcoceppi: correct
<SpamapS> balloons: terminate-machine to terminate a specific machine
<m_3_> nope, this was during unpromulgate... editing the .bzr/branch/branch.conf manually worked though
<SpamapS> m_3_: OOOHHH right, I forgot a step .. ;)
<SpamapS> m_3_: bzr push :parent
<m_3_> SpamapS: yeah, did that
<m_3_> but the branch it put there didn't let me unpromulgate
<SpamapS> m_3_: promulgate just looks at the push branch , so if bzr info shows something else, thats what is wrong
<m_3_> had to manually change it to the one I wanted
<SpamapS> m_3_: you can tack on '--remember' to change it
<SpamapS> oh
<SpamapS> you know that makes sense
<SpamapS> m_3_: right you have to push to the explicit name
<SpamapS> didn't think about that
<m_3_> I can get the url if you want... it was +branch/..../
<m_3_> either way... that's working... lemme promulgate the other branch
<SpamapS> m_3_: we should also look at the charm store and see if it is listing our new ones in a while
<SpamapS> m_3_: we might have to bump the revision file
<SpamapS> though actually it probably doesn't seem them cause their name is 'precise'
<SpamapS> so the new one named 'trunk' will show up
 * SpamapS facepalms
<SpamapS> ETOOMANYVARIABLES
<balloons> when you deploy a charm, does it pull from bzr or your local files? I made changes but they aren't reflecting in my deploy.. seems like perhaps bzr plays a part here
<balloons> in short, if I make a change to my charm, what do I have to do before doing another test deploy from my local repo?
<adam_g> SpamapS: those testing charms are full of little hacks that are specific to our deployment and environment
<m_3_> SpamapS: ok, that worked... lp:charms/nova-compute points to the right place... yeah, we might have to invalidate the store cache entry
<adam_g> SpamapS: things like wget'ing stuff from a local webserver, granting ubuntu user permission to stuff it shouldn't have, etc
<adam_g> SpamapS: im curious, why is hte rabbit charm causing problems but hte other stacked ones are not?
<m_3_> adam_g: they are :)
<SpamapS> aye
<SpamapS> adam_g: all the ones that we had versions of in precise before the branch-distro script got run caused issues
<m_3_> adam_g: I'll send you an email with a detailed description of what happened...
<SpamapS> balloons: depends on how you deployed it
<balloons> SpamapS, haha..
<SpamapS> balloons: if you used local: .. then the local dir is scanned for a revision file, and if it is different from the one you already have in your environment, the new charm is deployed, otherwise the one already in the env is deployed
<balloons> ah-ha!
<m_3_> adam_g: just the lp tool we used does some special things for pre-existing target branches
<balloons> that pesky revision file!
<SpamapS> balloons: there is a switch for deploy -u, which will force the revision file to be bumped up by 1
<m_3_> adam_g: nothing about your charms/branches at all
<balloons> so everytime I make a change I have to bump that file?
<SpamapS> balloons: also you can use the 'upgrade-charm' command to bump the rev and upload the new version for an existing deployment
<balloons> hmm.. I think I'll like this deploy -u
<balloons> I'm just trying to test and debug the charm I have
<balloons> so iteratively deploying, changing, deploying
<balloons> I'll try the deploy -u and see if that solves my issue.. it's interesting nonetheless
<SpamapS> balloons: one thing I do is to make the 'upgrade-charm' hook do 'stop;install;config-changed;start' so that I can just iterate with 'ugprade-charm'
<SpamapS> actually I think that order is wrong though.. I need to change it to stop;install;start;config-changed
<SpamapS> (or perhaps juju should just do that for me.. since it makes the most sense. ;)
<balloons> SpamapS, hmm.. I'd be happy to take up your best practice on this
<balloons> let me know :-)
<m_3_> SpamapS: ok, so that looks good... I'll go ahead and catch the rest of the upgrade errors
<SpamapS> m_3_: ok, I think we can avoid this at branch-distro time by renaming any 'trunk' branches in quantal to 'quantal', then running the branch-distro.. then do the mass rename from quantal->trunk
<SpamapS> we're also going to have to look at the problem that branch-distro *locks* all existing branches
<m_3_> SpamapS: ah... yeah... so just rearrange the order... good idea
<SpamapS> since the charm store won't let us push anything except 'trunk'.. that means we can't have like, a -updates branch that we then change the pointer to
<m_3_> SpamapS: I'm writing up the whole process so we don't forget... send it to the list
<SpamapS> I think we have to fix the charm store
<SpamapS> it should blindly publish anything that has an official pointer
<m_3_> dunno... it should ignore feature branches though and only display trunk huh?
<imbrandon> or master
 * SpamapS gets the hose
<imbrandon> hahahahaha
<m_3_> ha!
 * imbrandon about choked on my mt dew
<m_3_> imbrandon: actually the difference between "trunk" and "master" names has saved me many times in git-bzr-ng screwups
<m_3_> but yes... not your point
<imbrandon> hahah same here on hg <--> git
<imbrandon> at penton
<SpamapS> imbrandon: http://bit.ly/IOdIgm
<m_3_> great pic
<m_3_> clarise
<m_3_> or rather clarisssssssse
<imbrandon> hahha
<SpamapS> m_3_: the trunk name should totally be the name it uses for publish/notpublish per-user branches. But there's no reason to apply that same rule to official branches
<SpamapS> The other option though, is to unlock those branches for updates
<SpamapS> which I'd actually be in support of for Ubuntu as well.
<SpamapS> Because having different branches for different pockets is confusing and does not work well.
 * imbrandon like the lp:~imbrandon/charms/nginx/trunk for devel , /charms/nginx/precise for precise and /charms/nginx/oneiric for oneiric
<imbrandon> personaly, thats how i do other non charm projects
 * m_3_ still trying to figure out what a pocket is on lp
<imbrandon> trunk or master or whatever is the main devel branch, then named branches for stage or prod etc
<imbrandon> in this case releases
<SpamapS> imbrandon: lp:~imbrandon/charms/precise/nginx/trunk ...
<SpamapS> m_3_: pocket is release, security, updates, proposed
<imbrandon> i realize that but thats reversed
<SpamapS> m_3_: release is the pocket assumed in the absence of a pocket ;)
<SpamapS> imbrandon: the reason we want them to be this way, is that its not just your charm. You are well integrated with all the other charms.
<balloons> hmm.. juju debug-log seems to have some crazy lag on it when using it in connection with wget
<imbrandon> sure thats what the /charms/ name space does
<SpamapS> Making them their own little islands will fail at the de-duplication of effort that we're striving for.
<SpamapS> imbrandon: but we want each release to work well as a whole
<imbrandon> no no your mising a part there
<imbrandon> sure
<balloons> any idea why that might be? 2012-05-04 11:59:35,646 unit:vivo/4: hook.output ERROR: ..... .......... ....
<balloons> 2012-05-04 11:59:35,647 unit:vivo/4: hook.output ERROR: ...... .......... 38% 22.7M 7s
<SpamapS> as the OS moves on, we want the charms to move, as a whole, with the OS.
<imbrandon> the release loosk for the $release banch
<SpamapS> what I don't want is a bunch of "if release == oldnbusted: else ...
<imbrandon> um no
<balloons> the file downloaded minutes ago, but the debug log is still slowly scrolling through lines that look like that, giving download status updates
<imbrandon> not at all
<imbrandon> where do you get that ?>
<SpamapS> imbrandon: thats what will happen if we leave the release out of the url. And if we put it at the end, its purely psychological.. they won't be seen as a whole "precise" set of charms or "quantal" set of charms.
<imbrandon> e.g my drupal modules ( as well as thousands of others ) are that way, and in no way have "if release -- blah"
<SpamapS> its entirely psychological
<imbrandon> no no
<imbrandon> wow no
<imbrandon> what it comes down to is shared code
<imbrandon> notthing more
<imbrandon> your way causes fragmentation
<SpamapS> precise/nginx means precise's nginx. nginx/precise means the nginx that works on precise..
<imbrandon> the other allows hsared
<imbrandon> right
<imbrandon> exactly, and thats what it is
<SpamapS> and lp:charms/nginx means "where you do dev now"
<imbrandon> no thats where sotre releases are
<imbrandon> no one devs there
<SpamapS> its actually not, the store releases lp:charms/precise/nginx
<SpamapS> and lp:charms/oneiric/nginx
<imbrandon> still no chared code , forces forking, is bad
<imbrandon> shared*
<SpamapS> imbrandon: we have a session scheduled for this actually
<imbrandon> thus the way drupal has done it now for years just for this very reason
<SpamapS> I'm not sure what code you want to share tho?
<imbrandon> i seriously say we take a book from them
<imbrandon> all of it
<SpamapS> drupal is a single project though
<imbrandon> not much is gonna chage
<imbrandon> SpamapS: no its not
<SpamapS> I don't know if a distribution of things loosely coupled works like a project
<imbrandon> its 10000's of smaller ones
<SpamapS> ah ok
<imbrandon> no i mean drupal as in every module included on drupal.org
<imbrandon> like 6k+
<imbrandon> they all follow one rule
<imbrandon> dev is done in ~/projectname/master ( its git blah , trunk here ) and then
<imbrandon> ~/prijectname/7.x branch for
<imbrandon> drupal 7
<imbrandon> and 6.x branch for 6
<imbrandon> etc
<imbrandon> that way its not forked
<imbrandon> its the same git repo
<SpamapS> imbrandon: btw, I forwarded your newrelic-php charm to the newrelic sales guy who contacted me. He forwarded it along to their dev/products teams.
<imbrandon> just a branch, so when 8.x comes out, git branch 8.x from the current dev and get to work
<SpamapS> imbrandon: ah I think thats semantics. We're really just branching the same mainline.. lp:charms/charmname, and then we can easily merge backward to all previous releases.
<imbrandon> and merge back into each other as its applicable
<imbrandon> SpamapS: SWEET
<imbrandon> i have the others ready just about too
<imbrandon> as in python , ruby and sysmon
<imbrandon> more than that is gonna wait post uds
<SpamapS> imbrandon: in fact our session that we have scheduled is about discussing whether we should automate that process by saying if the tests pass, it gets auto-pushed back to non-diverged branches
<imbrandon> sysmon being the "main" newrelic namespace
<imbrandon> SpamapS: yea and see its much easier to track that way
<imbrandon> if its in the same branch named space
<SpamapS> imbrandon: totally. I'd rather have releases improve constantly and only make it manual when we actually break stuff.
<imbrandon> SpamapS: drupals automated testbot does it
<imbrandon> right
<SpamapS> sounds like we're already headed in the same direction then
<SpamapS> ok crap time got away from me
<SpamapS> time to hit the road
<SpamapS> bbl
<imbrandon> l8tr
<flepied> what are the pre-requesites to run ec2 instances ?
<hazmat> jcastro, re charts? commit activity?
<imbrandon> flepied: just a amazon acount iirc ( with attached cc info )
<m_3_> SpamapS: whats the name of the tool that lp originally ran?
<m_3_> bump-series?
<flepied> imbrandon, I saw you need an S3 bucket at least
<SpamapS> m_3_: branch-distro
 * SpamapS is gone
<jcastro> hazmat: yeah, commit activity, remember you said it was wrong?
<hazmat> jcastro, yeah.. it only captures 10 commits per charm
<hazmat> i'll take a look at fixing it up this weekend, at conference at the moment (mongo)
<flepied> I have the following error: ERROR SSH forwarding error: bind: Cannot assign requested address
<flepied> after bootstrapping an ec2 environment
<flepied> all commands report this error...
<tobin> Can someone help me understand what 'interface: monitor' means within a metadata.yaml file. I believe I understand how requires and provides somewhat works, but unsure what monitor means.
<nathwill> query: is $JUJU_RELATION_ID specific to a service unit, or is that generic to the relationship between the services?
<tobin> For instance, the ganglia charm has a relation name of "ganglia-node" with a interface set to monitor. Why is this needed?
<bkerensa> imbrandon: thoughts on Cloudfront costs?
<victorp> I am trying to boostrap an ec2 environment, juju boostrap command finishes ok but juju status gives me an invalid SSH error
<victorp> help?
<victorp> jcastro, ^^
<flepied> victorp, same error here
<victorp> flepied, did you manage to fix it?
<flepied> no
<victorp> oh well
<victorp> I cant get it to work
<victorp> maybe daviey can help
<flepied> got it to work
<flepied> oops already gone
<imbrandon> bkerensa: more expensive than compeditors but same as s3, so if your just serviing alteady out of s3 kinda nuts not to
<bkerensa> imbrandon: ahh I was one it for a few because maxcdn got blocked by my host
<bkerensa> :D
<bkerensa> but now its sorted... their VP had people call my host and get their ranges white listed
<bkerensa> and then told me how much he is enjoyinh 12.04
<bkerensa> :D
<imbrandon> maxcdn = shoddy and a pita to use IMHO
<bkerensa> imbrandon: NetDNA/MaxCDN has sponsored me for three years
<bkerensa> ;)
<bkerensa> and I get unlimited terabytes at no cost ;p
<imbrandon> cool, still a PITA to use
<imbrandon> ;)
 * imbrandon dont like origin pull 
<bkerensa> you like push zones?
<bkerensa> =/
<imbrandon> and automation, yes, then i'm in control
<imbrandon> or tranparent like cloudfront or cloudflare
<bkerensa> :P
<bkerensa> I think at the end of the year Im going to ask NetDNA to end my MaxCDN sponsorship and transition me to CloudCache
<bkerensa> :D
<imbrandon> really i'm more of a fan of abstraction tho, provider transparent
<imbrandon> thus when juju grows cdn wings i'll be happy
<marcoceppi> Making upstreams put their downloads behind SSL: https://twitter.com/#!/marcoceppi/status/198139725402488833 https://twitter.com/#!/johnmark/status/198509648603656194
<imbrandon> marcoceppi: nice
<victorp> flepied, hey - got it working
<_mup_> Bug #994855 was filed: Error messages are logged twice in the command line <juju:New> < https://launchpad.net/bugs/994855 >
<_mup_> Bug #994863 was filed: juju needs ssh keys in launchpad but we don't tell the user that. <juju:New> < https://launchpad.net/bugs/994863 >
#juju 2012-05-05
<hazmat> hey folks if anyone is looking for something to charm. postgres-xc would rock
<m_3_> hazmat: ping
 * SpamapS rings the bell
<SpamapS> charm promulgated: 'ubuntu' ..
<SpamapS> deploys.... you guessed it.. ubuntu!
<flepied> why don't you use libcloud to be able to access all the available clouds in Juju ?
<hazmat> flepied, twisted
<SpamapS> hazmat: isn't there a way to wrap pretty much any library in twisted, its just not ideal?
<SpamapS> hazmat: like, deferToThread or something?
<hazmat> SpamapS, indeed there is
<hazmat> SpamapS, and yes we could try that
<SpamapS> hazmat: its kind of attractive to have http://libcloud.apache.org/apidocs/0.6.0-beta1/libcloud.drivers.html available. ;)
<SpamapS> but, at this point, I wouldn't say that twisted is the reason libcloud isn't available. Its really that we're feature frozen while go gets done. :)
<hazmat> SpamapS, the abstractions aren't quite strong enough, ie we could have a number of libcloud based providers, but a single libcloud provider wouldn't be able to use against multiple backends
<hazmat> SpamapS, true
<SpamapS> hazmat: perhaps. If we embraced the new 'Deploy' methods though, we could supplant cloud-init for a post-boot ssh :)
<SpamapS> hazmat: so I think it might be stronger now than it was in the past
<SpamapS> hazmat: s3-like storage is also abstracted to a level where we could probably just de-couple the two
<hazmat> SpamapS, what days are you at UDS for?
<SpamapS> hazmat: are you in Oakland for the weekend?
<hazmat> SpamapS, i am
<SpamapS> hazmat: Just Tuesday and Thursday
<SpamapS> hazmat: isn't it nice up there? Shouldn't you be like, photographing parrots or something? :)
<hazmat> SpamapS, was going to try get into some hacking and catch a showing of avengers
<hazmat> SpamapS, i wandered into sf yesterday and checked out mongosf
<SpamapS> oh fun
<hazmat> its a beautiful day, gotta figure out some laundry
<SpamapS> hazmat: I'm usually happy just wandering down by pier39/fishermans wharf and then having tea somewhere on russian hill.
<SpamapS> Always gives me hope for America.. that we're not all going to be fat and ugly :)
<SpamapS> (russian hill does that.. fisherman's wharf is where I get depressed because of all the morbidly obese wearing american flag t-shirts wandering around ;)
<hazmat> ostack conf was basically next door to the wharf.. twas nice
<SpamapS> yeah thats a great hotel
<SpamapS> I heard from a few people that Oakland has become more "hip" lately
<SpamapS> that there is a cool part
<SpamapS> but.. nobody could tell me where it is :)
<hazmat> SpamapS, lots of nice restaurants around here, twas very smokey walking the streets last night though
<imbrandon> mmmm good mornfternoon
<imbrandon> yall know if the Bart runs to ( or close nuff ) the hotel ?
<hazmat> imbrandon, the bart drops off within sight of the hotel get off on the 11th st side
<imbrandon> hazmat: rockin, yea its been a few 5 years since i have been out there so wasent sure
<m_3_> was just wlking around a bit
<m_3_> suffering from a distict lack of MMA-related attire
<imbrandon> heya m_3_
<hazmat> imbrandon, no worries, really no way to know unless till you know or ask
<hazmat> m_3_, yeah.. that has been a bit odd
<imbrandon> i should be in early tomarrow, flight is a redeye out of here
<m_3_> imbrandon: cool
<imbrandon> i think i land around 9am local
<imbrandon> would need to check to be sure tho
<imbrandon> but somewhere near that
<imbrandon> was trying to get in this afternoon so i could go see jono's gig
<imbrandon> but not this time :)
<imbrandon> m_3_: does your git-bzr "binary" start with this header ?
<imbrandon> #!/usr/bin/env python
<imbrandon> # git-cl -- a git-command for integrating reviews on Rietveld
<imbrandon> # Copyright (C) 2008 Evan Martin <martine@danga.com>
<imbrandon> # Copyright (C) 2010 Andy Smith <andy@term.ie>
<imbrandon> ?
<m_3_> imbrandon: lemme look
<m_3_> imbrandon: yup... got it from termie's github acct
<imbrandon> thats mine, main reason i'm still curious  is its not barfed on me yet
<imbrandon> heh
<imbrandon> yup
<m_3_> imbrandon: I can almost reproduce it on queue now
<imbrandon> from termie, rackspace dude i think
<imbrandon> oh nice, that means maybe fixable
<m_3_> imbrandon: usually ok if I push after every commit... usually barfs if I don't
<imbrandon> ahh see my normal "workflow" for using it is very cut and dry tooo
<imbrandon> i only
<imbrandon> git bzr clonew lp:blah
<imbrandon> then do a ton of git stuff over a few days
<imbrandon> pushing to github etc etc
<imbrandon> then once i'm back to a git status thats "clean"
<imbrandon> i git bzr push
<imbrandon> back to lp
<imbrandon> and restart the process
<imbrandon> nothing else really
<m_3_> imbrandon: wow... I'd love for that to work consistently
<imbrandon> even got to use it on an older format bzr repo yesterday and it worked
<m_3_> imbrandon: wanna get your bzr, bzr-fastimport, and git versions
<imbrandon> of lp:kubuntu-website
<m_3_> nice
<imbrandon> m_3_: sure thing
<imbrandon> m_3_: also i have not tried it on linuz either
<imbrandon> this is always on osx
<imbrandon> fwiw
<imbrandon> linux*
<imbrandon> how can i get the fast import verions ?
<imbrandon> m_3_: https://gist.github.com/2606357
<imbrandon> m_3_: i did git twice ( at the top ) as i normally also have git aliased to defunct's "hub" command  ( ruby gem )
<imbrandon> not sure if/why that would make it more stable either but added it too just incase it plays a part
<imbrandon> oh and git + bzr are both from homebrew/brew , fastimport is from easy_install and hub is from rubygems i think ( whatever the instructions says on defuncts website )
 * SpamapS waves hi
<imbrandon> heya SpamapS
<SpamapS> imbrandon: how's the drupal charm going?
<imbrandon> SpamapS: i dont htink i'm gonna be done with this nginx in time for the contest deadline, i mean i _could_ be but the perfectionest in me is not allowing it, so i think i'm gonna just enter the newrelic charm(s) and the drupal ( all-in-one , e.g. no subborainate support yet )
<imbrandon> SpamapS: well i have it cleaned up
<imbrandon> and working well as a all-in-one like omg is
<imbrandon> but not the ideal way
<imbrandon> like with nginx and LB seperate etc etc
<imbrandon> so before UDS is over i should have like 5ish rockin charms, but only 1 or 1.5 by monday morning :)
<imbrandon> see my delima :)
<SpamapS> Wed. is the deadline
<imbrandon> but its ok, i'd rather have a charm done "right": and easy to support/maintain later than laptop, although it would be killer, i got plenty of computers heh
<imbrandon> ohhhh
<imbrandon> wed ?
<SpamapS> You will be faced w/ "Drink, or win shiny"
<imbrandon> i thought it was Monday
<SpamapS> Two week contest for charm authors, starting on 25 April 12 and closing out on 09 May 12 at 1700. Here's a list of current charms: http://jujucharms.com/charms
<imbrandon> i'm good with that choice
<SpamapS> imbrandon: you can opt for "Drink *and* win shiny"
<imbrandon> ohh nice
<imbrandon> SpamapS: yea i'll likely just "drink light" monday , then
<imbrandon> and tue
<imbrandon> then fully join in the fun :)
<imbrandon> lol
<SpamapS> Find the kernel team, bring beer and a laptop.. you will have all kinds of good ideas :)
<imbrandon> actually, i'm more a social drinker anyhow, i try not to get smashed, uds or not :)
<imbrandon> dont always work that way tho
<imbrandon> lol
<SpamapS> Yeah I haven't gotten smashed at a UDS.. but I've certainly mixed the wrong things a few times.
<imbrandon> one night i always end up smashed
<imbrandon> normally the last night
<imbrandon> after the grp dinner etc
<SpamapS> Friday night I usually end up pretty fershnockered, but I just dance like a maniac until I sweat it out. :)
<imbrandon> heh
<imbrandon> <-- dont dance
 * SpamapS is sad he'll be missing the friday festivities
<imbrandon> or if i do, i'm way way tooo drunk
<SpamapS> I'm a karaoke whore and a closet crumper
<imbrandon> i got 3 left feet
<imbrandon> crumper ?
<imbrandon> yea i like to sing,i do it local here all the time
<imbrandon> and play alot of pool, i'm the guy in the back either shooting for $$ or has a table full of girls "teaching" them :)
<imbrandon> one of the few geeks that has all the computers and tech UPSTAIRS at home, and the mancave is full of pooltable and wetbar ( that i use like 1 time a year :( )
<imbrandon> been on my todo to "tech-up" the mancave in some cool ways
<imbrandon> but that budget always gets spent elsewhere before i do it
<imbrandon> this last time spent bailing out my little ( still a grown ass man over 30 ) of jail
#juju 2012-05-06
<imbrandon> on a promis of repayment but i knew going in it was a gift
<imbrandon> :)
<imbrandon> little brother*
<imbrandon> SpamapS: so i got to thinking ,since there is ALOT tweaks that go with the fcgi interface processor of choice, and looking at the way rightscale and some chef cookbooks etc all seem to split it up
<_mup_> juju/increase-session-timeout r451 committed by kapil.thangavelu@canonical.com
<_mup_> pep8
<imbrandon> its more common to have more than one nginx bases on the fcgi used, but i think its cleaner to do it the way we talked about ( but a larger charm that must encapsulate the knowhow of both php and ruby and python fcgi tweaks )
<SpamapS> Ok maybe not a crumper ;)
<imbrandon> heh
<_mup_> juju/scale-test r535 committed by kapil.thangavelu@canonical.com
<_mup_> log agent connections
<imbrandon> crumper ? like crunk ?
<_mup_> juju/scale-test r536 committed by kapil.thangavelu@canonical.com
<_mup_> merge increase session timeout
<imbrandon> SpamapS: sad part is i love karaoke, and not half bad , but even though i listen to EVERYTHING, but mostly rock/r&b/rap(selective) I sing country
<imbrandon> lol
<imbrandon> shhh
<SpamapS> hah
<SpamapS> its ok, I sing Neil Diamond and Billy Joel
<imbrandon> :)
<SpamapS> or NiN
<SpamapS> but only when I'm pissed off
<imbrandon> :)
<imbrandon> i wish i could sing Hurt
<imbrandon> but i would tear it up and thats an awsome song
<imbrandon> in fact /me switches itunes to Hurt ( Cash Version )
<SpamapS> I like Only
<SpamapS> THERE IS NO YOU!
<imbrandon> heh
<SpamapS> alright, Goldeneye is over, time to go get dinner
<imbrandon> said brother from above named his oldest boy Trent, after NiN
<SpamapS> imbrandon: travel safe
<imbrandon> SpamapS: ty , see ya
<SpamapS> hah, thats a one-way ticket to the psychiatrist office. "Hi, I'm named after an angry, dark, brooding master of electronic instruments.:
<imbrandon> lol
<SpamapS> ok, out
<imbrandon> :)
<_mup_> juju/scale-test r537 committed by kapil.thangavelu@canonical.com
<_mup_> increase connect timeout to 8m
<txwikinger> Has anyone ever used juju with trystack.org?
<SpamapS> txwikinger: I have not, but if it has full S3 capabilities then it should work
<bkerensa> =o
<imbrandon-web> ugh
 * imbrandon-web twiddles thumbs
<marcoceppi> imbrandon: come to the second floor
<m_3_> marcoceppi: imbrandon here yet?
<m_3_> marcoceppi: please intro
<marcoceppi> m_3_: he's here, I think he's waiting for a room
<zirpu> hey, it's till sunday here. don't mess with me. :-)
#juju 2013-04-29
<marcoceppi> jamespage mgz what would it take to get charm-tools in backports?
<jamespage> marcoceppi, just a bit of testing in older releases and a backport request
<jamespage> its quite lightweight
<jamespage> marcoceppi, 'requestbackport' is the tool
<marcoceppi> jamespage: awesome, thanks
<jamespage> marcoceppi, best thing todo would be to get it in a good state in saucy and then request backport to 12.04->13.04
<jamespage> marcoceppi, https://wiki.ubuntu.com/UbuntuBackports
<jamespage> documents the process
<jcastro> scuttlemonkey: http://www.jorgecastro.org/2013/04/29/13-reasons-to-deploy-with-ubuntu-server/
<jcastro> scuttlemonkey: does that earn me a RT since I mention ceph? :)
<jcastro> hey gary_poster
<jcastro> We'd like to put the gui instructions on the getting started page so people can deploy it right away
<jcastro> any gotchas or should I just add what we put in the charm's README there?
<gary_poster> jcastro, on call but the README should work *except* for jitsu deploy-to.  juju core version does not support deploying to machine 0 ATM, but I think they will open that up
<scuttlemonkey> jcastro: haha, fosho :)
<jcastro> gary_poster: I'm not even going to mention the jitsu part.
<gary_poster> jcastro, cool!  go for it.  thanks
<andreas__> jcastro: do you have a recording of last friday's charm school?
<jcastro> it's not last friday
<jcastro> it's this friday
<andreas__> jcastro: ah, ok
<jcastro> it will be recorded
<jcastro> and I will announce that
<andreas__> hm, juju-core question. Is juju set <service> key=value supposed to work on units that are in an error state?
<andreas__> specifically, mine failed in the install hook, and juju set would fix it
<andreas__> hm, maybe a set followed by retry
<ahasenack> yep, works
<sidnei> ahasenack: set + retry should work
<rshade98> anyone know why this would start happening
<rshade98> ERROR state: TLS handshake failed: x509: certificate signed by unknown authority
<benji> I'm a bit surprised to get this error message:
<benji> 2013-04-29 12:58:45,726 ERROR Bad 'instance-type' constraint 'hs1.8xlarge': unknown instance type
<benji> is this a known issue?
<marcoceppi> benji: what provider?
<benji> marcoceppi: ec2
<rshade98> ok two problems I ran into with an ec2 environment.
<rshade98> I need a way to only bootstrap the certs, without getting the environment already setup error. And now that I have the certs my handshake fails. Any ideas?
<jcastro> marcoceppi: arosales just got a text from Mims
<jcastro> he's found a "good example stack on rack"
<jcastro> (he's at railsconf)
<arosales> jcastro, good to hear :-)
<arosales> keep rock'in it m_3
<jcastro> I envision him going like booth to booth or something. "excuse me sir, can you look at my charm?"
<arosales> jcastro, its reverse people are stopping by where they they here they here the doctor is at asking to see his charm.
<mwhudson> hi
<mwhudson> i have wordpress deployed
<mwhudson> but i'm accessing it via ssh port forwarding
<mwhudson> and wordpress is generating links without the port so css etc doesn't work
<mwhudson> is there something simple i can do about this, or is wp just dumb?
<sarnold> mwhudson: on a first guess, it sounds to me like you may have chosen a poor replacement for an http proxy :)
<mwhudson> heh well
<mwhudson> generating urls with a hostname in when you don't have too is kinda daft too
<sarnold> mwhudson: okay, that bit makes sense.
<marcoceppi> mwhudson: yeah, wordpress is being pretty dumb
<mwhudson> you'd think such a high profile piece of softwa...
<mwhudson> oh never mind
<marcoceppi> We actually had this problem early on when re-working the WordPress charm. Instead of using the URL of the  "primary" peer, all the URLs were re-written to be nginx-backend:8080
<marcoceppi> which breaks quite a few things
<mwhudson> ha
<marcoceppi> As a stop-gap we wrote a plugin that basically utlized the pre-render hook to rewrite all URLs on the page
<marcoceppi> That's not needed anymore, thankfully, I can't actually remember how we fixed it
<marcoceppi> So, you could write a plugin that basically just rewrites all the URLs to be relative
<mwhudson> given i only have wordpress installed because it's the "hello world" of juju
<mwhudson> i'll pass i think
<marcoceppi> mwhudson: sounds like a wise decision
<marcoceppi> but! Sounds like your deployment worked out pretty well
<mwhudson> yeah
<mwhudson> it was a fight on several levels but it seems to be working now
<mwhudson> (with pyju, goju isn't quite there on arm it seems)
<mwhudson> the last bit of fun was that cloud-init really really wants the fqdn to have a dot in
<mwhudson> so i had to make it so that $hostname.localdomain resolved in dnsmasq
#juju 2013-04-30
<pmitros> Is there good text on debugging juju anywhere? I've gone through the Hello World example a few times (wordpress+mysql), and it's never worked. On one machine, it would break while apt was installing packages (specifically, the postfix package was waiting for user input). On my home maschine, I get a bad gateway error from nginx. Some kind of high-level roadmap would be very helpful ("Here are where log files live," "Here's how you downloa
<marcoceppi> jcastro: can you delete this? https://code.launchpad.net/~jorge/charms/precise/docs/trunk It breaks `charm list`
<jcastro> done
<rshade98> I am still having a problem with TLS failure. Any ideas?
<hazmat> marcoceppi, see jitsu search
<hazmat> rshade98, pastebin?
<hazmat> pmitros, which version?
<hazmat> pmitros, ie. juju-core or pyjuju
<marcoceppi> hazmat: I see there's a search, but no "list" function, any way to list "reviewed" charms outside of charm list?
<marcoceppi> Trying to replace `charm list | grep lp:charms`
<hazmat> marcoceppi, search -h
<hazmat> marcoceppi, owner:~charmers is cheeky but should hit the majority
<hazmat> er. owners:charmers
<marcoceppi> hazmat: http://paste.ubuntu.com/5619558/ ;)
<hazmat> marcoceppi, ugh.. the help in jitsu is broken.. try jitsu help search
<marcoceppi> hazmat: Ah, thanks that works much better
<hazmat> marcoceppi, its going to break in a week or two when jujucharms.com gets switch over to its new backend, easy enough to fix though
<marcoceppi> hazmat: ack
<rshade98> hazmat
<rshade98> http://paste.ubuntu.com/5619673/
<hazmat> rshade98, it looks like you have a cert mismatch, the ca is cached on the client in ~/.juju but the ca cert on the client doesn't match up with the bootstrap'd state server
<rshade98> Is there a way to only bootstrap the certs
<hazmat> rshade98, not without a destroy-environment and rebootstrap
<rshade98> I get a failure with multiple boxes, saying the environment is already bootstraps
<hazmat> rshade98, did you switch machines?
<hazmat> rshade98, which ever machine you did the original bootstrap on. you have to copy the whole ~/.juju over
<rshade98> oh, so it is gone
<hazmat> the ca cert file that works, is in the one that bootstrapped
<rshade98> I need to destroy the whole environment huh
<hazmat> rshade98, in that case destroy && bootstrap is the simplest option
<rshade98> is that just deleting the bucket in ec2?
<hazmat> alternatively manually creating a new ca, new cert, and installing it onto the bootstrap server
<rshade98> I mean s3/ec2
<hazmat> rshade98, destroy-environment kills all the machines in the env
<rshade98> ok, so that just deletes the bucket etc.
<rshade98> now it won't dial the mongos should upload the certs, kill the machine, add the juju groups to it, and start it
<arosales> marcoceppi, https://jenkins.qa.ubuntu.com/view/Precise/view/Precise%20Charms/ looking a lot better. Thanks for getting beating that into shape :-)
<arosales> s/getting/
<hazmat> marcoceppi, you coming out to oakland?
<marcoceppi> hazmat: yes
<hazmat> cool
<hazmat> marcoceppi, it looks like failures generate false success in some cases
<marcoceppi> hazmat: have an example?
<hazmat> marcoceppi, i thought i did.. but explicitly navigating to the last build looks okay.. i was looking at the wordpress graph test
<hazmat> which still fails with memcached.. but the test is passing
<hazmat> but the it does look significantly better
<marcoceppi> hazmat: yeah, there's still a few broken tests out there. Some corner cases like juju environment not getting set up properly cause the test to pass
<sarnold> ooh, I like that jenkins overview of charms :) ec2 and local, very neat
<hazmat> marcoceppi, the new juju-deployer version is pretty robust and helpful about doing the proper wait for success with streaming change output (jcore only though)
<hazmat> might be able to feed it the test plans, or massage the test plans into a compatible form
<marcoceppi> hazmat: juju-developer? You mean the API stuff?
<hazmat> marcoceppi, its a tool for deploying complex environments from a yaml/json description.. with inheritance, file value substitution, etc.
<hazmat> lp:juju-deployer
<hazmat> we use it quite a bit for openstack
<marcoceppi> hazmat: that sounds super sexy. Shouldn't be difficult at all to format the test plans to feed that in
<rshade98> is juju a per s3 folder environment?
<rshade98> it seems to alway have conflicts when they share.
<rshade98> and if so, any idea what the best way to randomize the uuid is
<_mup_> Bug #1174905 was filed: Not possible to deploy local charms <juju:New> <https://launchpad.net/bugs/1174905>
<mwhudson> mramm: hey
<mramm> hey
<mwhudson> mramm: <generic armhf juju ping goes here>
<mramm> I've filed a ticket to get the go 1.1 beta into the archive so that we can start building official images with it
<mramm> if you want help trying to compile yourself davecheney (dfc) can help (I CCed him on our last e-mail exchange)
<mwhudson> ok
<mwhudson> compile go myself or compile juju?
<rshade98> is there any way to make the juju commands super verbose
<sidnei> rshade98: as in -vvv?
<sidnei> rshade98: though you might be actually looking for juju debug-log which tails the services' logs
#juju 2013-05-01
<jcastro> davecheney: wrt. the image numbers
<jcastro> I don't want to promise "just this once"
<jcastro> but ... just this once.
 * jcastro quickly hides to escape responsibility
<freeflying> http://paste.ubuntu.com/5622314/ trying to bootstrap within maas by using kvm, got this error, any clues? dns resolved successfully
<marcoceppi> freeflying: What's your "maas-server" set to?
<marcoceppi> in your configuration
<freeflying> marcoceppi: set to the vm I have maas installed
<marcoceppi> Right, I mean I think that error is because that address isn't formatted properly. Wanted to see what you had there
<freeflying> marcoceppi: http://192.168.124.2/MAAS
<marcoceppi> freeflying: Yeah, you need to include the port in the address. Try: http://192.168.124.2:80/MAAS
<freeflying> marcoceppi: thanks, will give it try, but the same configuration worked before, its on precise with latest update, using ppa version of juju + maas
<marcoceppi> freeflying: hum, things may have changed. I know when I tried MAAS + Juju about a year ago the port missing from the address blocked everything up
<freeflying> marcoceppi: right :)
<jcastro> marcoceppi: whoa, _6_ new juju questions from yesterday
<jcastro> that's a record
<marcoceppi> AskUbuntu Y U NO POST IN HERE
<jcastro> http://askubuntu.com/questions/tagged/juju?sort=newest&pagesize=50
<jcastro> I'll edit through them in a bit
<marcoceppi> Stupid irc bot thing
<marcoceppi> hazmat: any reason why this was changed? http://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/revision/65
<hazmat> marcoceppi, because its on port 80?
<marcoceppi> hazmat: the loadbalancer is, but each unit actually runs on 8080
<marcoceppi> the "automagic peer loadbalancer"
<hazmat> marcoceppi, the load balancer is a peer.. i was using an external load balancer
<hazmat> and its misrepresenting its port
<hazmat> marcoceppi, the only port exposed is 80.
<hazmat> try connecting a varnish or haproxy charm to it..
<marcoceppi> hazmat: Right, but 8080 is the port it should be hitting since the peer relation is a lb that pushes back on to 8080, if you're adding a lb relation you shoulnd't need that port exposed for it to work
<marcoceppi> If that is the case though, 8080 should be exposed as opposed to using 80 for the relation, otherwise you're just adding one more hop on to the lb -> wp relation
<hazmat> marcoceppi, fair enough
<hazmat> hmm
<marcoceppi> I'm just about done fixing the memcached relation, I'll check out varnish and haproxy to make sure they work properly in addition to memcached
<hazmat> marcoceppi, its only listening on localhost:8080
<hazmat> ?
<marcoceppi> each unit should be listening on 80 and 8080, 80 being the lb that re-routes to a peer on 8080
<hazmat> the automagic loadbalancer is a bit confusing, is that adding value?
<hazmat> allows for just  multiple dns entries for the service without an exnternal lb?
<hazmat> marcoceppi, cool re memcached
<marcoceppi> At this point I'm not sure. It was a nice feature, have peer loadbalanced units without needing an extra layer. Hit any node and it'll just "automagic" distribute the load in a dumb way
<hazmat> marcoceppi, actually the haproxy issue turned out to be a compatibility issue/bug in juju-core
<hazmat> doesn't support -r rel_id to relation-list atm
<marcoceppi> hazmat: ah
<hazmat> marcoceppi, i can revert/or feel free to
<marcoceppi> hazmat: I'm already working in the branch, I'll just revert it. nbd
<hazmat> marcoceppi, thanks
<rshade98> if my keys are right in aws what might cause this: 2013/05/01 15:27:46 ERROR command failed: cannot query old bootstrap state: Access Denied
<rshade98> I figured it out
<jcastro> arosales: ok I'm going to fire up the hangout early so we can spread the URL.
<jcastro> https://plus.google.com/hangouts/_/c90e71c6c9f5031e7b771639e8c0ea793a645663?authuser=0&hl=en
<jcastro> if anyone wants to pop in early for the meeting
<arosales> jcastro, ok, thanks. I am wrapping up a few items here so won't join to closer to the top of the hour.
<jamespage> OK _ so how do I bootstrap a MAAS managed environment using juju-core?
<jamespage> I just get a message about tools not being found right now
<jamespage> http://paste.ubuntu.com/5623032/
<jamespage> evilnickveitch, mgz: ^^ any pointers?
<evilnickveitch> jamespage, hmmm, i haven't tested that yet
<mgz> looking
<mgz> you may need --upload-tools for now, or to manually upload to storage and specify that in config
<jamespage> mgz, where do I get my tools:-)
<mgz> jamespage: does `juju sync-tools` possibily with --all or --public help?
<jcastro> Juju Charm meeting going on now: https://plus.google.com/hangouts/_/c90e71c6c9f5031e7b771639e8c0ea793a645663?authuser=0&hl=en
<jamespage> mgz, "error: environment has no access-key or secret-key"
<jcastro> for anyone who wants to join!
<jamespage> jcastro, many attendees this week?  do want to bulk it out to much
<jcastro> only 4 so far
<jamespage> jcastro, OK - I'll come keep you all company!
<mgz> jamespage: set them to anything, it's a design issue with the s3 client code
<mgz> so, AWS_BLAH envvars set to summat
<marcoceppi> http://pad.ubuntu.com/7mf2jvKXNa
<jamespage> mgz, gah - no s3 access
<mgz> there was some kind of issue with that command, will see if I can dig up what it was from the log
<mgz> so, you can manually copy things from the s3 bucket and upload them to maas
<mgz> jamespage: get the series/arch you need from juju-dist.s3.amazonaws.com
<mgz> we have bug 1172973 on the silly creds thing
<_mup_> Bug #1172973: sync-tools requires aws credentials be set in the (shell) environment <juju-core:New> <https://launchpad.net/bugs/1172973>
<mgz> jamespage: suggests that sync-tools *should* work though if you do that...
<jamespage> mgz, yeah - I set the shell env variables
<jamespage> that got me past error 1
<jamespage> but the lab I'm working in has not outbound to s3
<mgz> ah, and the second issue was, right
<mgz> hadn't gathered that
<mgz> so, if you can get the tar in somehow we can work out how to upload it to maas
<jamespage> mgz, ok - hopping through another server now
<jamespage> mgz, OK - I have the tgz's locally
<mgz> jamespage: okay, so try `maas-cli maas files --help`
<jamespage> mgz, right
<mgz> should be able to add, with the right name, and then use that
<jamespage> mgz, the right name being: tools/mongo-2.2.0-precise-amd64.tgz or suchlike?
<mgz> just trying to see...
<jamespage> mgz, thanks for you help btw
<mgz> as far as I can see, it's all just the defaults, yes
<mgz> so, "tools/juju-" prefix
<mgz> ".tgz" suffix
<mgz> and version string in the middle
<jamespage> mgz, OK - so  "maas-cli maaslocal files add filename=tools/juju-1.10.0-precise-amd64.tgz file=juju-1.10.0-precise-amd64.tgz"
<mgz> looks good.
<jamespage> mgz, I'm missing something "File not supplied"
<mgz> hm...
<mgz> now sure how the cli wants file attachments spelt, which is what the server side code seems to expect
<mgz> looks web-form-ish, maybe you can do it via the web front end as well?
<jamespage> mgz, not that I can find
<mgz> have poked gavin in #maas as I can't figure it out from the code
<mgz> (and the login mechanism makes it annoying to try and step around with curl)
<mgz> is `maas-cli maas files add --help` any more specific about how it wants params?
<jamespage> mgz, http://paste.ubuntu.com/5623255/
<jamespage> mgz, "application/octet-stream" but I have no idea how to pass that on the CLI
<mgz> yeah, that's just the docstring, and I can't see from the code how to give a file upload either
<jamespage> mgz, OK _ i have to downtools for the day
<jamespage> I'll pick this up again tomorrow
<mgz> lets poke someone maasy tomorrow
<jcastro> marcoceppi: hmm, ok so.
<jcastro> a bunch of the incoming juju questions are still on pyju
<jcastro> that can't be right
<marcoceppi> jcastro: could be, if they downloaded it a while ago
<AskUbuntu> Juju and MAAS: ERROR No matching node is available | http://askubuntu.com/q/289226
#juju 2013-05-02
<TheChistoso> when i run "juju status" i get: "the authenticity of host '...' can't be established...are you sure you want to continue connecting? ..." i've run this once before and i assumed it added the host to known_hosts -- why is it prompting again? and what can i do to fix it?
<hazmat> TheChistoso, if its the same machine, it should get added to the host.. but if you create a new env, it its a new machine. juju isn't doing ssh cert fingerprint management. another option (with some risk) is to disable host fingerprint checking for some iprange corresponding to the cloud provider if posible.
<TheChistoso> how do i tell juju to use a particular machine?
<TheChistoso> hazmat: oddly enough, i just ran it again and the problem's gone
<hazmat> TheChistoso, cool.. but to answer the question, you either keep the env around,  or try one of the ssh workarounds. juju's philosophy is machines are  ephemeral.. and that services are whats important. its worth a bug report though
 * hazmat pokes around
<hazmat> its bug 892552
<_mup_> Bug #892552: juju does not extract system ssh fingerprints <juju:Confirmed> <juju-core:Confirmed> <https://launchpad.net/bugs/892552>
<TheChistoso> i understand the philosophy but i'm using it w/ maas and i only have a set # of machines
<hazmat> ah
<TheChistoso> so i'd like one machine to run multiple services
<hazmat> TheChistoso, with pyjuju jistu deploy-to or with juju-core deploy -force-machine achieve that goal
<hazmat> fwiw http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
<TheChistoso> couple questions...how do i cancel a pending deploy? and how do i add add'l machines if, let's say, a new server has arrived and i just racked it?
<TheChistoso> (using maas + juju)
<TheChistoso> okay figured out the first -- juju destroy-service
<TheChistoso> hazmat: tyvm, btw, b/c jitsu seems to be working
<TheChistoso> so i expected that exposing mysql would open up port 3306 but it didn't seem to
<TheChistoso> and when is juju 2.0 due?
<TheChistoso> anybody available to answer maas+juju questions?
<evilnickveitch> does keypair auth work for juju core on HP now?
<mgz> there's a branch to be landed shortly
<evilnickveitch> mgz, cool
<jair> I have been hearing a lot about juju but have one specific question, is it free software?
<jair> I can use and download ubuntu I know that but what about the juju instance?
<jair> just checking making sure this is not something like eucalipto something possible to use only if you pay to canonical?
<jair> I think this is the right channel
<marcoceppi> jair: Juju is free and open source software provided by Canonical
<jair> opensource is different than free software right?
<marcoceppi> jair: no, There's free software, then there's open source software. This happens to be both
<jair> marcoceppi: so if I install debian can I use juju in my environment? or will only work with ubuntu versions and ony latest version of Ubuntu correct?
<jair> marcoceppi: interesting
<jair> marcoceppi: I really appreciate your help and willingness to clarify my concerns
<marcoceppi> jair I believe there are only packages for ubuntu at the moment, but you can compile the source and use it on Debian, nothing's stoping you. It's my understanding we'll be supporting other platforms in the near future
<jair> marcoceppi: I see, thank you very much my friend!
<jair> I will be doing some testing at home
<marcoceppi> No problem :)
<jair> I have seen it a few times on the youtube presentations.
<jair> looks cool, also I am trying to learn bash and phyton so some of the charms are written on those languages.
<jair> which is very cool
<marcoceppi> jair: you can find the quick "getting started" guide on the homepage: https://juju.ubuntu.com/get-started/ and feel free to ask here or on the mailing list if you have any questions
<jair> sounds good
<jair> marcoceppi: I will definetely get my hands on it
<jair> thank you"
<jair> Thank you for all the information and the links to knowledge
<Marlinc> Is it possible to allow multiple architectures using a constraint? So my environment can have 32 bit and 64 bit machines?
<rbasak> all: Marlinc has been hit by bug 1064291, asked in #maas, and I directed him here. I think another solution might be to disable constraints entirely, but I'm not sure how to do that.
<_mup_> Bug #1064291: Default constraints make no sense on MAAS <arm> <juju:New> <Release Notes for Ubuntu:Invalid> <https://launchpad.net/bugs/1064291>
<Marlinc> Jup
<Marlinc> Why is it marked a invalid by the way
<marcoceppi> Marlinc: it was marked invalid for the ubuntu-release-notes project
<Marlinc> Ah okay I don't get the Launchpad issue tracker quite well yet
<Marlinc> Ah I see
<marcoceppi> Marlinc: So you can change the architecture at anytime either on a per-deploy basis or the defaults altogether with juju set-constraints. The defaults can only be changed /after/ a bootstrap though. So you'll still have to juju bootstrap --constraints arch=arm before being able  to do something like juju set-constraints "mem=256m arch=i386" or whatever you'd like to change
<marcoceppi> and the defaults only live on for that environment, they won't carry over between bootstraps or other environments
<Marlinc> So if I would use amd64 as default I would be able to use a i386 node inside that environment? At all
<marcoceppi> Marlinc: You can change the arch for any machine not yet deployed at anytime. Let me find the doc on machine constraints
<Marlinc> https://juju.ubuntu.com/docs/constraints.html ?
<marcoceppi> But you can do juju deploy mysql --constraints arch=i386; juju deploy wordpress --constraints arch=amd64; juju deploy nfs --constraints arch=arm and so long as the provider can provide those arch it'll work
<marcoceppi> Marlinc: yup, that's it
<marcoceppi> So you can have mixed arch (and even mixed series) machines in a deployment
<Marlinc> Okay
<Marlinc> Would be nice if it would allow it by default though
<Marlinc> Without having to specify a arch
<marcoceppi> Marlinc: Well, there's a split hairs scenario there. I see where you're coming from with maas. The majority of the people either don't care about the arch or want them to all be the same. It'd be tedious to have to specify it everytime (hence why I see where you're coming from)
<marcoceppi> Hopefully the dev team can come up with a decent solution to this problem
<marcoceppi> Marlinc: which version of Juju are you using?
<Marlinc> 0.7
<mgz> Marlinc: you can enable multiple arches trivially with `juju set-constraint arch=any` on your environment
<Marlinc> Ah
<mgz> arguably that should be the default, indeed
<Marlinc> Ah great thank you very mch
<Marlinc> Much
<Marlinc> I think that would be a great default too
<rbasak> mgz: is there also a way to do that with mem? I'd like to document the workaround in the bug.
<mgz> mem=0 is fine
<mgz> as it's really a gte
<rbasak> mgz: what's the argument during the bootstrap command, please?
<rbasak> Does --constraints arch=any,mem=0 work?
<rbasak> Or is there some other way of separating that?
<Marlinc> Deploy MySQL on a machine with at least 32GiB of RAM, and at least 8 ECU of CPU power (architecture will be inherited from the environment, or default to amd64):
<Marlinc> $ juju deploy --constraints "cpu=8 mem=32G" mysql
<mgz> it's "arch=any mem=0" genrally
<rbasak> Thanks!
<mgz> hm, thought this was already in the maas docs, but maybe it only made it to launchpad bugs/mass-devel list?
<marcoceppi> any, good to know
<rbasak> I'm not sure. I'm only aware of the bug.
<mgz> it's worth noting set-constraint on the environment, as otherwise you need to remember --constraints on every deploy
<mgz> +s
<rbasak> Doing it on bootstrap sets the default environment constraints, doesn't it?
<mgz> ah, maybe it does
<hazmat> it does
<jcastro> heya hazmat
<jcastro> looks like the docs aren't updating
<jcastro> I pushed an update like 2 weeks ago and the docs haven't generated
<jcastro> I thought that was a cron job?
<hazmat> jcastro, it should be cron'd, as for the location/result its in webops hands.
<jcastro> ok so I should just file a general RT you think?
<hazmat> jcastro, yup
<jcastro> any info I can put there, like what machine it's on or anything?
<hazmat> jcastro, sorry i don't have anything additional.. i've got a separate doc cron job running on jujucharms.com/docs but i handed over the domain, and its scheduled to be transitioned to a new backend/frontend in a week or two.
<hazmat> evilnickveitch, do you know anything re doc deploy?
<jcastro> yeah it looks like that isn't being regenerated either
<evilnickveitch> hazmat, for juju? no, but I know the maas one is broken
 * hazmat pokes around
<jcastro> hazmat: hah man
<jcastro>  Last Generated on Nov 22, 2012. Created using Sphinx 0.6.4.
<jcastro> stay classy juju docs
<jcastro> RT filed
<hazmat> jcastro, that's funny
<jcastro> want me to CC you on all this stuff or want me to just deal with it with IS?
<hazmat> jcastro, cc me pls
<hazmat> jcastro, we might have disabled because the makefile gets executed and has upload/commit rights from a large group
<hazmat> interesting
<hazmat> the repo changed locations
<hazmat> jcastro, we moved the repo from ~charm-contributors/juju/docs/ to  ~charmers/juju/docs
<jcastro> oh ok
<jcastro> so the cron is probably still there
<jcastro> we just moved the source out from under them
<Marlinc> My Juju is having a issue when using it with MAAS: provision:maas: juju.agents.provision ERROR: Cannot get machine list
<Marlinc> It also throws ProviderInteractionError: Unexpected TimeoutError interacting with provider: User timeout caused connection failure.
<Marlinc>  errors
<Marlinc> Anyone with something on the top of their head what this could be?
<hazmat> Marlinc, does the maas cli work?
<hazmat> Marlinc, just wanted to verify maas is up and responding to on its api
<Marlinc> Yep it is
<Marlinc> It is hazmat :)
<hazmat> hmm
<hazmat> Marlinc, could you save the last few hundred lines of the provisioning log, and pastebin it perhaps. next i'd try restarting the provisioning agent..  ls /etc/init for exact agent name..  i think its $ service juju-provisioning-agent restart
<Marlinc> Okay
<Marlinc> I'll take a look later the router stopped working...
<SpamapS> https://www.ohloh.net/p/juju/analyses/latest/languages_summary
<SpamapS> tis official, goju > juju
<hazmat> jcastro, docs.. http://jujucharms.com/docs/
<hazmat> updatd
<jcastro> hey guys:
<jcastro> "I just spun up juju on AWS and was pretty impressed with how damn easy it was (the toughest part was looking up my AWS keys). Now I'm really excited to play around with it and see how it interacts with Chef."
<TheChistoso> i'm using maas+juju. i added a new machine and it's shown as "ready" in the node list. when i try and deploy mysql, it never picks up the new machine
<TheChistoso> juju bootstrap worked fine, btw
<TheChistoso> i started the deploy last night and 10 hours later juju status is still showing it as "pending"
 * avoine is trying to find a way to handle multiple version of Django in the charm
<sinzui> hey. I want to update the mongodb charm to restore a db from a dump on install. I don't think this can be done on install though. I think config-changed needs to do this, and I know the restore should only happen during installs or upgrade-charm hooks?
<sinzui> Are there charms that have solved such a problem?
<marcoceppi> sinzui: You _can_ have the charm do it during the install hook, since config-get is available during install.
<marcoceppi> So you'd just have to amend the readme to say that it can be resotred using this config but only if the config options is seeded during deployment, that it won't work after unit installation
<avoine> sinzui: the postgresql charm have a dumpfile_location config variable
<marcoceppi> Not wether or not that's charmer kosher, it seems like a grey area to me, so others please correct me if I'm wrong
<sinzui> marcoceppi, understood.
<sinzui> avoine, thank you! I will look
<sinzui> marcoceppi, I think the "it won't work after unit installation" is good as the goal is to only do this before there is a database.
<sinzui> marcoceppi, I also imagine this should only happen if the charm was configured to the be master during deploy. Slaves don't need to restore.
<marcoceppi> sinzui: So, I'm going to say as long as you document that caveat in the readme it'll be okay. Typically configuration options shouldn't be "immutable" in a sense and should react with a config-changed hook, but that's not always possible
<sinzui> marcoceppi, yep. this immutable aspect is indeed my concern. I was worried that I need some persistent means to know that the db was restored and not to do it again.
<marcoceppi> sinzui: You could do that with a file marker, something like touch .db-restored and check if that file exists everytime the config-changed hook runs
<sinzui> marcoceppi, in the charm's dir, or in the location where the db restored too?
<marcoceppi> sinzui: in the charm's directory, since the hooks run with the root of the charm as it's cwd
<marcoceppi> well, anywhere really. I typically just let put it in the cwd
<sinzui> marcoceppi, does upgrade-charm overwrite or replace the unit's charm dir?
<marcoceppi> sinzui: that's a really good question
<sinzui> I can drop a file into one of my running units, then do an upgrade to see
<marcoceppi> I want to say it overwrites, but doesn't replace the entire directory, preserving files created outside ofthe charm.
<marcoceppi> sinzui: since I know a lot of charms store data in this fashion
 * marcoceppi hopes that's the case
<sinzui> I bet webops know since they add files to charms and upgrade all the time
 * thedac reads backscroll
<sinzui> thedac does upgrade-charm overwrite or replace the unit's charm dir?
<thedac> it overwrites and does not replace
<thedac> so items that were in the charm and have been removed may still be in the charm dir on an instance
<sinzui> okay, that is probable best since it allows for a rollback option
<sinzui> thanks thedac, marcoceppi, avoine.
<thedac> no problem
<marcoceppi> o/
<TheChistoso|2> anybody around that could help me diagnose a maas+juju issue please?
<hazmat> sinzui, in future it employs git locally for charms to yank dead files
<hazmat> sinzui, the local charm is still on disk in archive/zip form in either case
<sinzui> okay, thanks for the warning.
<hazmat> TheChistoso|2, could pastebin the send the provisioning agent log  /var/log/juju on the bootstrap node
<hazmat> s/the/or
<TheChistoso|2> hazmat: http://pastebin.com/TS4kJg7b
<TheChistoso|2> it helps to know where to look -- tyvm
<TheChistoso|2> ProviderInteractionError: Unexpected TimeoutError interacting with provider: User timeout caused connection failure.
<TheChistoso|2> and then: exceptions.TypeError: an integer is required
<marcoceppi> TheChistoso|2: What's "mass-server" set to in the environments.yaml?
<hazmat> TheChistoso|2, on the server what version of juju is being run.. ie. output of dpkg -s juju
<TheChistoso|2> hazmat: juju-0.7
<TheChistoso|2> marcoceppi: maas-server: http://10.53.0.102/MAAS/
<mwhudson> oh i know this one
<mwhudson> you need to either (1) put the port number in the url
<mwhudson> so
<mwhudson> maas-server: http://10.53.0.102:80/MAAS/
<mwhudson> or
<mwhudson> bootstrap on something newer than precise
<marcoceppi> TheChistoso|2: I believe the "exceptions.TypeError: an integer is required" error is because you're not explicitly stating the port. Try setting it to http://10.53.0.102:80/MAAS/
<mwhudson> TheChistoso|2: ^^
<TheChistoso|2> ah
<marcoceppi> mwhudson: :D
<hazmat> TheChistoso|2, you'll need to restart the provisioning agent as well
<TheChistoso|2> i was concerned about bootstrapping on anything later b/c i wasn't sure how compatible the various charms are on anything later
<TheChistoso|2> hazmat: what command would i use to restart the provisioning agent? not sure which one it is in my list of services
<hazmat> TheChistoso|2, upstart.. via sudo service juju-provisioning-agent restart.. you might need to double check the name from the available list in /etc/init
<mwhudson> TheChistoso|2: probably putting the port in is the sensible thing
<hazmat> the name of the upstart service that is
<TheChistoso|2> mwhudson: i added the port
<mwhudson> i didn't realize you could recover from this, i re-bootstrapped when this bit me...
<hazmat> mwhudson, i do remember that bug.. but it  seems strange though.. the fix for maas ports went in 2012-06 from the changelog.. unless this really isn't juju-0-7 but 0-5 from precise.
<TheChistoso|2> the name of the service doesn't seem obvious -- i should be doing this on the bootstrap node, correct?
<hazmat> TheChistoso|2, yes
<mwhudson> hazmat: it's a bug in juju isn't it?
<mwhudson> errrr
<mwhudson> hazmat: it's a bug in maas isn't it?
<mwhudson> bigjools will be super happy to discuss the maas sru
<mwhudson> i'm sure
<mwhudson> hm, maybe not, i dunno
<TheChistoso|2> i can't find the name of the job/service. perhaps i'll just reboot :/
<hazmat> mwhudson, the traceback is from juju.. the issue was in the maas provider in juju i thought
<mwhudson> yeah, just looking at the bug
<hazmat> TheChistoso|2, ls /etc/init  .. should be prefixed juju-provisioning..
<hazmat> TheChistoso|2, then $ service juju-provisioning-agent restart
<TheChistoso|2> hazmat: not seeing that -- there's nothing prefixed w/ juju
<TheChistoso|2> okay i finally guessed it: juju-provision-agent
<hazmat> TheChistoso|2, this should be on the juju bootstrap node
<hazmat>  /etc/init should definitely have juju upstart files..
<TheChistoso|2> hazmat: ya know what -- i wasn't paying close enough attention. i was looking in /etc/init.d/ (force of habit)
<hazmat> TheChistoso|2, cool.. now you'll need to change your client config re maas port and try another command.. juju deploy/add-unit etc.. which will force a sync
<hazmat> hmm.. i might have spec'd the wrong order there.. the restart should happen after the sync.. else the provisioning agent is just going to run into the old setting
<TheChistoso|2> hmm...doesn't seem to be taking. i changed it in my environments.yaml, restarted the provisioning agent, destroyed the service, deployed the service again (mysql), restarted the provisioning agent again for good measure and...and just as I was writing this I saw the node power on so I guess it's working :D
<TheChistoso|2> so my ultimate goal will be to deploy open stack (grizzly) through juju. wish me luck. (c:
<TheChistoso|2> according to the guide, it says 28 nodes would be required. i'm doing a PoC -- i have 16 machines available. hope that'll work...
<TheChistoso|2> i would have bootstrapped w/ raring, but maas didn't download any raring images -- is that a known issue?
<TheChistoso|2> oh and my apologies -- i didn't properly thank you guys...THANK YOU!
<hazmat> TheChistoso|2, 28 is for full HA setup.. you can use jitsu deploy-to for certain services (non-conflicting) to have them co-located on the same machine..
<hazmat> and good luck
<TheChistoso|2> i intend to do that -- and thank you
<TheChistoso|2> i was actually hoping someone had an existing set of charms for co-locating an intelligent set of openstack services
<TheChistoso|2> it recommends doing it atop precise -- should i instead use quantal or raring (when available)?
<TheChistoso|2> lol that question didn't sound right -- what i meant to ask is, "do you know of any particular problems choosing a more up-to-date release?"
<hazmat> TheChistoso|2, the charms install from the cloud archive, depending on the release version you choose, so the openstack bits are typically current
<sarnold> TheChistoso|2: check charmstore for charm availability, not all charms are on all releases
<hazmat> TheChistoso|2, er.. the openstack charms install packags from the cloud archives.. based on config.. i'd stay on precise
<TheChistoso|2> hazmat: alright -- will do.
<TheChistoso|2> should exposing mysql open port 3306?
<TheChistoso|2> juju status isn't showing port 3306 as an open port
<TheChistoso|2> i installed mysql and wordpress successfully
<TheChistoso|2> i then removed the relation b/t mysql and wordpress and it looked like it did the correct thing
<TheChistoso|2> then i ran juju destroy-service wordpress
<TheChistoso|2> site's still running
<TheChistoso|2> is that correct?
<TheChistoso|2> shouldn't it be off or stopped since there's no other service that'd be listening on the port?
<marcoceppi> TheChistoso|2: there's a big where the stop hook isn't executed on older versions of juju. if you want to remove the machine run terminate-machine with the machine number as a parameter
<marcoceppi> s/big/bug/
<TheChistoso|2> so newer versions of juju aren't in the precise images that maas downloads?
<TheChistoso|2> and newer versions aren't in the apt repos for precise?
<TheChistoso|2> i was surprised when you had me check the juju version and it was rather old (isn't the latest something like 1.10?)
<TheChistoso|2> (while I'm on this -- is there an expected release date for juju 2.0?)
<hazmat> TheChistoso, mysql charm doesn't expose port
<hazmat> TheChistoso|2, the new version of juju is a new implementation, its not yet available in the distro packages, but via ppa or download.
<TheChistoso|2> is it possible to use a newer version when maas is commissioning the nodes juju uses?
#juju 2013-05-03
<TheChistoso|2> is there an environment variable i can use to point to environments.yaml?
<TheChistoso|2> and for that matter, config.yaml?
<_mup_> Bug #1175958 was filed: New peer relations not created when upgrading charms <amd64> <apport-bug> <raring> <juju:New> <juju (Ubuntu):New> <https://launchpad.net/bugs/1175958>
<sidnei> jamespage: hi! replied to your review, the install hook actually adds the ppa and installs the dependencies.
<jamespage> sidnei, I'd missed that
<sidnei> yeah, might need to adjust the readme to mention so
<jamespage> sidnei, how do you guarantee that the versions of tools you are pulling from the ppa are the same ones that the charm was tested with
<jamespage> ?
<sidnei> thats tricky. and also the fact that a ppa is not frozen, so an update to the ppa could break the charm.
<sidnei> wedgwood_away created a stable and dev ppa, im using the stable one, which supposedly would only get updates if it doesn't break the charm.
<jamespage> sidnei, yeah - its tricky - we have exactly the same issue with the openstack charms
<jamespage> sidnei, which is why we actually embed the helper in the charm
<jamespage> (s)
<sidnei> 'static linking' ftw. ;)
<jamespage> that way there is no requirement for a PPA; and DC's where there is limited outbound network access don't break
<jamespage> sidnei, man - its the way to fly!
<jamespage> *(apparently)
<sidnei> jamespage: so what do you suggest? include a copy of the deps?
<jamespage> sidnei, yep
 * jamespage ducks behind his desk to avoid being shot
<jamespage> sidnei, its a compromise but its the only one that meets the objective that a charm should be installable by default from the main ubuntu archive
<sidnei> jamespage: the other one being getting charmsupport into the archive, which is a pain on itself.
<jamespage> sidnei, well its not that bad
<jamespage> we could package and drop it into saucy and then backport back through to precise
<jamespage> backports is an official part of the archive so does get mirrored
<sidnei> and then you get into SRUs :)
<sidnei> ah, backports
<jamespage> sidnei, yeah - which is why actually taking the static link method is good
<jamespage> sidnei, I know it goes against all our ingrained distro knowledge
<sidnei> ok, i'll go that route then. will make it so that 'make sourcedeps' can be used to automate the update of those copies, so that you can just run that and commit
<jamespage> sidnei, makes sense to me
<hazmat> jamespage, do you need a fix for that peer rel issue on upgrade?
<jamespage> hazmat, well other than myself I'm guessing that no-one has hit that issue right now
<jamespage> as the HA branches are still in final testing
<jamespage> but I think that any juju based openstack deploys out there right now would be blocked on taking advantage of these features as a result
<jamespage> hazmat, is it a huge amount of work?
<hazmat> jamespage, not really.. http://paste.ubuntu.com/5629022/
<hazmat> that's the diff for the fix
<jamespage> I see - not huge then
<jamespage> hazmat, in that case - yes please!
<jcastro> marcoceppi: ping me when you're around
<jamespage> jcastro, folks are already trying out the OpenStackHA stuff - had a direct email this morning
<jcastro> hah yeah
<jcastro> someone asked about it on AU and I put a link there too
<marcoceppi> jcastro: ping
<jcastro> marcoceppi: pong
<jcastro> marcoceppi: let me fire up reminders to our social networks
<jcastro> and then G+?
<jcastro> shoot for the top of the hour?
<marcoceppi> Sounds good, I'll be here
<marcoceppi> jcastro: ack
<jcastro> marcoceppi: G+ing you
<jcastro> hey
<jcastro> which account should I be inviting to G+ you?
<mthaddon> does anyone know if there's any issue with running goJuju and pyJuju on the same machine (currently using pyJuju on Openstack, want to test using goJuju without disrupting existing envs)?
<mgz> mthaddon: you may want to use seperate env files, otherwise no
<mgz> you do want to be on raring for the shiny packages
<mthaddon> mgz: this is a production env that's precise - are there backports of shiny, or if not, will there be at some stage?
<mgz> you can deploy on precise... you just want to use the clients from the latest distro packages
<mthaddon> mgz: do you mean use the raring packages?
<mgz> yeah
<mthaddon> mgz: any ideas how easy that'd be to backport to precise?
<mgz> pretty simple, the point is you want both juju 0.7 and juju-core 1.10.0 with the packaging changes to make them co-installable
<mgz> and the ppas don't currently have that
<mthaddon> mgz: ah, I see, so we need juju 0.7 to allow it to be co-installable with juju-core 1.10.0 - gotcha
<marcoceppi> Does juju-core work with local provider?
<mgz> marcoceppi: no local provider is implemented yet
<marcoceppi> mgz: just checking, thanks :)
<mthaddon> mgz: how about openstack provider? (sorry, I should know this)
<mgz> mthaddon: there is an openstack and a maas provider now, though some things are still not quite as polished as in 0.7 yet
<mthaddon> mgz: understood - so if we have 0.6 installed, but are using a custom branch in juju-origin for a specific env, all local commands (juju status, etc) are using 0.6, but the env itself is deployed with that custom branch, correct?
<mgz> mthaddon: that's right
<mgz> for co-installbility, only the local package matters, as environments aren't compatible anyway
<mthaddon> mgz: how do you mean, environments aren't compatible?
<sidnei> the environments.yaml have different keys and both complain about unknown keys iirc
<mthaddon> sidnei: they require different formats for environments.yaml?
<sidnei> not 'formats' just some keys within environments.yaml are different
<mthaddon> right
<mgz> and you can't bootstrap with pyjuju, then do status with gojuju
<mthaddon> was just about to ask that :)
<mthaddon> how safe is an upgrade of pyJuju from 0.6 to 0.7?
<mgz> safe.
<mgz> an existing environment will be using a set version on the machines anyway, so all you're changing is your local client
<mthaddon> cool, thx. And last question (I think). Can we upgrade juju in a running env, or is that a goJuju feature only?
<mgz> I think that's gojuju only, hazmat might correct me.
<hazmat> go juju only on that one
<hazmat> mthaddon, probably next month, but there will be some tooling in place to enable impl migration
<hazmat> mthaddon, its a topic for next week
<jcastro> mthaddon: backports of everything to precise are on the team's todo
<jcastro> Daviey was telling me a "few weeks"
<jcastro> but I don't know how accurate that is lately
<Daviey> hmm
<Daviey> That is still the plan.
<Daviey> it will go in via backports tho
<mthaddon> thx
<marcoceppi> hazmat: did the local provider fix for juju make it in to the backports?
<marcoceppi> (on raring)
<hazmat> marcoceppi, i believe it did.. mgz?
<hazmat> marcoceppi, i added it to trunk since it wasn't there, but the 0.7 for raring was marked fixed
<marcoceppi> hazmat: cool, I'll give it a shot. I saw it was fixed commited but the ppa appears to be behind what's in backports
<hazmat> the trunk ppa is behind backports?
<hazmat> odd
<marcoceppi> ppa:juju/pkgs is still the pyjuju ppa, correct?
<Youssefk> Hello, does anyone of you guys know if the reboot problem in juju has been fixed or not?
<Youssefk> Hello, does anyone of you guys know if the reboot problem in juju has been fixed or not?
<Youssefk> Hello, does anyone of you guys know if the reboot problem in juju has been fixed or not?
<utlemming> macroceppi: is there an issue with the mediawiki? When deployed in the GUI, setting the user/password for Admin makes it go straight to config error
<hazmat> marcoceppi, yes
<AskUbuntu> Can I use Juju/MAAS on VPSes? | http://askubuntu.com/q/290122
<jcastro> 45 minute warning on Juju Charm School!
<jcastro> 30 minutes until Charm School!
<mgz> jcastro: is there a link already, or should I look again on the hour?
<jcastro> mgz: ubuntuonair.com for the stream
<jcastro> I will post the hangout URL here if you want to join in the actual session
<jcastro> but this one is more for new users
<jcastro> getting started installing and configuring, etc.
<jcastro> since we're starting anew
<mgz> right, I think it's worth seeing what issues come up there, so was going to listen in
<jcastro> he's having some problems with instances coming up on AWS
<marcoceppi> mgz: http://paste.ubuntu.com/5629682/
<marcoceppi> Deployed two services, but they're not launching instances in AWS
<saras> so the ubuntu on air should be starting soon right
<marcoceppi> saras: it's already started
<saras> hum
<saras> is that why their big white spot on ubuntu on air page
<ahasenack> marcoceppi: where, ubuntuonair.com? I don't see the viedeo, just a white area where the video should be
<marcoceppi> saras: not sure, bad embed code maybe; Here's the stream:" http://www.youtube.com/watch?v=9h5hgfnZcBQ
<TheChistoso> if i lose my juju bootstrap node, can juju still function?
<ahasenack> marcoceppi: thanks
<TheChistoso> and if a node dies (power supply dies), can i still remove (terminate) it?
<saras> can i use salt stack with juju
<sarnold> saras: you may be able to create a salt subordinate charm, so that salt is available on all your nodes
<TheChistoso> and simply rebooting a node shouldn't cause anything to necessarily change w/ juju, correct? that is, after services have been deployed to a node, rebooting the machine would have no ill effect on juju (the availability and services that node was running is a different matter)?
<saras> what we can't talk about stack i will be using nginx | node.js | mondb
<marcoceppi> On air page fixed
<saras> at least their not using webex agrr 10gen
<saras> metoer.js on node.js that know to talk to mongo
<ahasenack> jcastro: you should mute, or else the focus switches to your screen everytime you make a noise :)
<ahasenack> unless you want to speak, of course
<jcastro> noted
<jcastro> we're taking questions in here if you have questions
<FunnyLookinHat> And remove the unity bar from the left...  works against the full-screen view because it's not snapping :)
<brejoc> shell was better ;)
<jcastro> he's going to switch to the browsers a bunch
<Ben___> did I miss the juju charm school?
<jcastro> http://youtu.be/9h5hgfnZcBQ
<jcastro> nope
<jcastro> in progress right now!
<FunnyLookinHat> Awesome - thx :)
<jcastro> feel free to ask qurestions
<FunnyLookinHat> weird...
<Ben___> Is there a hangout link?
<jcastro> https://plus.google.com/hangouts/_/5ce263e3acf52d2a8604ad61d7fa1b7ef01377e7?authuser=0&hl=en
<ahayzen> jcastro, hit F11 for fullscreen terminal?
<jcastro> marcoceppi: ^^
<Ben___> thanks!
<mattrae> jcastro: are you using the ppa version of juju?
<saras> should I write a charm for metoer.js
<Guest76074> I wrote a juju charm for a service called boundary, wondering about the process to submit it for inclusion.  It is a paid SaaS.
<mattrae> jcastro: cool thx
<mattrae> neat
<jcastro> aaronj____: https://juju.ubuntu.com/docs/charm-store.html
<jcastro> if you prefer to have it on github that's fine too, just plop the link in the bug report
<TheChistoso> i just realized you guys are doing a web cast :D -- did you happen to catch my questions from earlier?
<aaronj____> jcastro: thank you
<saras> should I write a charm for metoer.js? jcastro:
<jcastro> TheChistoso: nope, feel free to AskUbuntu
<jcastro> saras: oh yes, absolutely!
<jcastro> that would be nice
<jcastro> TheChistoso: I meant feel free to ask again
<TheChistoso> if i lose my juju bootstrap node, can juju still function? how would i re-bootstrap?
<aaronj____> is this console where juju bootstrap was run an EC2 instance or a local machine.
<paraglade> jcastro: our company has made a big investment in puppet and I know it is possible to have juju and puppet work hand in hand.  I would love to see a charm demonstration of this.
<aaronj____> paraglade: +1
<paraglade> jcastro: can one bootstrap node handle many environments?
<TheChistoso> i'm looking at using juju + maas to deploy openstack. how stable are the openstack charms for use with raring?
<saras> salt
<FunnyLookinHat> TheChistoso, I stepped out for a sec- did someone answer your question about losing the juju bootstrap node ?
<TheChistoso> FunnyLookinHat: yes
<FunnyLookinHat> TheChistoso, the [short] answer?
<TheChistoso> right now, it's a known issue. they're working on HA for bootstrap nodes.
<saras> lxc
<FunnyLookinHat> jcastro, Timeline on colocation ?  I know it's dependent upon the Go rewrite...
<FunnyLookinHat> thx :)
<FunnyLookinHat> TheChistoso, Ah ok good to know
<TheChistoso> jcastro: i had a question (up above)
<jcastro> TheChistoso: yep, I'll hit it up next
<TheChistoso> jcastro: (thanks! :D)
<TheChistoso> jcastro: is there a provisional release date for 2.0?
<jcastro> over the next month or so
<TheChistoso> i'm working on a PoC, is there a way to easily use an RC/beta version before the official release w/o having to setup an entire development environment?
<TheChistoso> i don't have 28+ nodes (the required # for use w/ juju) to deploy openstack
<TheChistoso> (openstack HA that is)
<TheChistoso> jcastro: tyvm
<jcastro> oh, I can help you there too, I'll get to that one next
<jcastro> https://wiki.ubuntu.com/ServerTeam/OpenStackHA
<jcastro> for those interested in HA Openstack
<paraglade> jcastro: in the pyjuju version what is the "open-tunnel" command used for?
<saras> jcastro: how can I till what the verison of sevices is in a charm as their are 3 mongodb charms
<TheChistoso> i've been following that -- i do intend to use ceph -- that page mentions using precise w/ the quantal kernel. how do i set that up? or is that a maas question?
<jcastro> http://jujucharms.com/charms/precise/mongodb
<jcastro> saras: I'll explain why there are three in a minute
<saras> thanks
<ahasenack> jcastro: highlight that it's just not a service up and running, but up and running in a scalable fashion
<ahasenack> jcastro: otherwise people could reach the same state with just a bunch of customized amis
<jcastro> sure
<arosales> ahasenack, good point. The scaling embedded with relations is a very nice feature.
<ahasenack> or even just using fabric
<TheChistoso> jcastro: what if i want to colocate multiple web apps. is that possible?
<FunnyLookinHat> Now every DDoS his haproxy to test!  :D
<FunnyLookinHat> TheChistoso, He talked about that - not currently possible... planned as a post 2.0 feature
<TheChistoso> okay, thanks funny!
<FunnyLookinHat> fo sho :)
<TheChistoso> jcastro: the openstack HA page mentions using precise w/ the quantal kernel in order to get kernel updates for ceph. how do i set that up? or is that a maas question?
<jcastro> I'm still looking up how to answer that.:)
<jcastro> I think that's more of a cloud image question than either juju or maas
<TheChistoso> jcastro: (thanks!)
<TheChistoso> jcastro: that would make sense
<FunnyLookinHat> Given that errors are produced occasionally by bugs, is there a way to ensure that a service will always work by specifying a particular charm version ( or set of versions ) ?
<mattrae> if services need to be related in a particular order, is there a way to tell a juju to automate a complecated rollout?
<TheChistoso> FunnyLookinHat: how i manage that is by checking out the source and using locally-available charms
<mattrae> cool
<FunnyLookinHat> yeah - having the source local is... not as clean. :)  But being able to define the version w/ the charm store is a solid fix
<FunnyLookinHat> Ah ok - so it'll cache the charm you've used
<paraglade> jcastro: I thought that was what the control bucket was for.  caching the charms
<jcastro> yeah
<jcastro> I think it dumps other stuff in there too
<TheChistoso> jcastro: hey so when are you gonna support windows in AWS? ;D
<paraglade> before you bail you should so what happens if you kill an instance in the AWS console. :)
<jcastro> good point
<paraglade> s/so/show/
<TheChistoso> lol j/k actually :D
<paraglade> vCD support would be awesome also.
<TheChistoso> does anybody actually do that? ubuntu on azure?
 * SpamapS hums the song from The Little Mermaid "Poor Unfortunate Souls"
<sarnold> TheChistoso: doubtless the azure images weren't done just for giggles :)
<arosales> to help clearify its Juju managing Ubuntu workloads in Azure, in the same way Juju manages Ubuntu workloads in AWS
<jcastro> yeah did I say Juju managing windows at first?
<jcastro> let me be clear that "juju deploy sqlserver" would be awesome, it's not anything we're working on.
<arosales> jcastro, I think your finaly statement got it correct, just wanted to throw out some additional info.
<TheChistoso> if i deploy mysql w/ juju on AWS -- is it using EBS to back its data? ephemeral mysql storage wouldn't seem to be a good idea
<aaronj___> that would be cool to see.
<TheChistoso> that would be fantastic
<saras> jcastro: could someone add rdbms interface to charm
<TheChistoso> jcastro: you play guitar? :D you pretty good?
<aaronj___> looking forward to it!
<FunnyLookinHat> jcastro, marcoceppi - Great presentation! thanks guys :D
<TheChistoso> yes -- thanks guys!
<mgz> thanks jcastro :)
<mattrae> jcastro: is there a schedule for this training?
<arosales> jcastro, marcoceppi thanks
<aaronj___> thank you
<jcastro> thanks guys!
<ahayzen> thanks guys :)
<saras> bye
<mattrae> thanks :)
<jcastro> http://juju.ubuntu.com/survey
<paraglade> jcastro: this would be huge to get this working: https://code.launchpad.net/~franciscosouza/juju/juju-vpc/+merge/134169
<jcastro> ^^ feel free to pass that one
<aaronj___> jcastro: you mentioned a robbie williamson video ... regarding openstack iirc.
<jcastro> yeh let me find you that link
<arosales> jcastro, marcoceppi for the "debug" charm you may want to note the juju version and environment details for reproduction next charm school.
<marcoceppi> saras: Do you mean like a connection to Amazon's RDS service?
<jcastro> https://www.openstack.org/summit/portland-2013/session-videos/presentation/openstack-in-production-the-good-the-bad-and-the-ugly
<jcastro> aaronj___: ^^^
<jcastro> that's how we roll with openstack in prod
<marcoceppi> For those wondering which bug I was talking about, https://bugs.launchpad.net/juju-core/+bug/1172895 it's this one and it's been committed already
<_mup_> Bug #1172895: relation-list incompatibility with pyjuju: -r <juju-core:Fix Committed by fwereade> <https://launchpad.net/bugs/1172895>
<saras> rdbms i think
<mattrae> jcastro: is the plan to have charm school every other week at the same time?
<saras> nice
<jcastro> mattrae: yep
<mattrae> jcastro: cool thx
<jcastro> I'm going to go make sure it's repeating on the calendar
<marcoceppi> saras: Well, rdbms is a general name for data storage solutions. So MySQL, Postgresql, Oracle, SQLite, etc are all RDBMS systems
<mattrae> ah cool
<jcastro> I will also send mail reminders to the list, etc.
<saras> DRBD
<saras> sorry to many letters running around lose in my head
<marcoceppi> saras: ah, the block device mirroring tool?
<saras> yes
<marcoceppi> So, we don't have a charm for that, I'm not familiar about it
<marcoceppi> it's implementation but it looks like it would be something the provider implements?
<jcastro> I think that would be a sub
<jcastro> you would plop it on a service
<jcastro> and it would just start replicating
<marcoceppi> saras: we do have similar charms like Ceph that can do large continuous filesystems that are HA
<saras> ceph can speak drbd
<saras> so interface that you could talk to ceph over
<jcastro> the ceph guy is usually in this room
<jcastro> I think the question would be how does the ceph charm use drdb
<marcoceppi> or if it uses it at all. I don't see an interface for it, but if you knew ceph and knew how drdb would work you could implement it in to the ceph charm and have it reviewed/merged in to the official one if you had other services that needed to talk to ceph via drdb
 * marcoceppi goes to read more about it
<jcastro> scuttlemonkey knows, he's not here right now though
<jcastro> chttp://ceph.com/dev-notes/deploying-ceph-with-juju/
<jcastro> as an FYI
<saras> jcastro: so till me if I nut or should i use the node.js as starting point for the meteor.js
<saras> then add the npm command to install is and setup the mongodb inface
<saras> interface
<TheChistoso> so i'd actually like to deploy ceph alongside nova compute nodes. somewhat like piston cloud's solution (if you're familiar w/ that)
<jcastro> saras: yeah for sure
<TheChistoso> is that possible?
<jcastro> man, meteor looks pretty awesome
<marcoceppi> saras: actually, meteror.js might "just work" with the nodejs charm
<TheChistoso> how i would structure things is putting keystone/horizon/rabbitmq/mysql in a few HA controller nodes and then putting ceph, nova compute, quantum, swift/glance (swift would just be ceph) on each compute node using locally attached storage
<TheChistoso> how easy would it be to configure the charms to enable that scenario?
<marcoceppi> saras: http://jujucharms.com/charms/precise/node-app it's designed to "just work" for deploying node.js apps that use mongodb backends
<saras> marcoceppi: i see that
<saras> marcoceppi: thanks
<marcoceppi> saras: though it might be good to just make it it's own charm
<jcastro> https://install.meteor.com/
<marcoceppi> since it's more of a standalone service than it is "a node app"
<jcastro> has their install stuff
<marcoceppi> that's entirely up to you
<jcastro> https://bugs.launchpad.net/charms/+bug/1035003
<_mup_> Bug #1035003: charm needed: meteor <Juju Charms Collection:New> <https://launchpad.net/bugs/1035003>
<jcastro> So I think it'd be like a node or rails charm
<jcastro> just for meteor apps though
<sarnold> why on earth would they only support amd64 and i386??
<sarnold> I thought it was javascript..
<marcoceppi> saras: jcastro looking at it, yeah I agree, I think this is probably  it's own charm. It would be awesome as a charm
<jcastro> yeah so a little yaml file pointing to my meteor app on github
<jcastro> and deploy
<marcoceppi> sarnold: some node.js modules are compiled C++, like native php extensions
<saras> think i would use npm
<saras> not githud
<saras> not github
<jcastro> yeah so from experience on the node charm
<jcastro> people like having a switch to grab from $wherever
<jcastro> at first we used a PPA
<sarnold> marcoceppi: ah, so you'd have to compile yourself for othe arches, and the hilarious curl url | sh thing is just for the Big Architectures... okay. :)
<jcastro> then some people are like, I want to use the one in the distro not some PPA, etc.
<jcastro> so having a switch the user can deploy, defaulting to the safe distro version seems to be the defacto best practice
<jcastro> saras: do you work on meteor or just use it?
<saras> jcastro: no going to be playing with alot soon
<jcastro> it looks neat
<saras> learning mongo now
<jcastro> on the next screencasts we will talk about platform charms
<saras> i love idea of use mongo on server and client
<jcastro> where instead of charming up every single app, we have a stack of platform charms people can use to deploy apps on those frameworks
<saras> jcastro: thanks
<jcastro> <-- off to lunch
<ColinR> Howdy. I've been looking at implementing juju where I work and had some questions I was wondering if anyone in here could answer. First, from what I've read, juju support for multiple "bootstrap" nodes (don't know the proper term for them), is on it's way. Is there anyway to join in beta testing that feature/possibly contribute, and if so, who should I talk to?
<bkerensa> juju generate-config -w
<bkerensa> does nothing?
<ColinR> Was that directed towards me bkerensa?
<bkerensa> no
<bkerensa> m_3 or jcastro
<bkerensa> :)
<ColinR> no worries, just joined the channel, so I wasn't sure.
<bkerensa> ahh k
<bkerensa> or marcoceppi even ^
<ColinR> My second question is regarding chef. Is there anyone here who has experience working with chef and juju? Currently, we use Noah (https://github.com/lusis/Noah), a Zookeeper alternative, for orchestrating node interaction and chef for node configuration, but juju looks very promising if we can tie in our existing chef cookbooks.
<jcastro> ColinR: for multiple bootstraps, we call that Juju HA
<jcastro> For that you'd want to check out the dev mailing list: juju-dev@lists.ubuntu.com
<jcastro> there's all so #juju-dev on freenode fore core stuff
<jcastro> for your second question
<jcastro> there are some people using it with chef solo
<jcastro> as far as I know so far though, no one's really published a "here's how we reused our chef stuff with juju" yet.
<bkerensa> jcastro: your juju doc for rackspace is no works :P
<bkerensa> https://juju.ubuntu.com/get-started/rackspace/
<bkerensa> what [] brackets?
<jcastro> read the top thing
<bkerensa> also the command you listed is depracated
<jcastro> "This doesn't work and is really an inprogress placeholder while we figure out how to make it work, Rackspace Cloud is still in private beta so this answer is probably useless to most people. "
<bkerensa> LOL
<jcastro> they haven't rolled out the stuff we need to work on it
<bkerensa> ah
<jcastro> TLDR it's not really vanilla openstack
<jcastro> they have committed to fix it
<bkerensa> hmm
<jcastro> they just haven't yet
<jcastro> so one day, it will Just Work
<jcastro> and from ODS I know it's pretty soon
<bkerensa> :(
<bkerensa> what to do with this $500 a month rackspace credit then?
<bkerensa> pftt
<jcastro> does it expire?
<bkerensa> in two years
<bkerensa> :D
<bkerensa> but I was going to deploy a wordpress instance for testing my framework
<bkerensa> and then put up a huge instance to do BOINC
<jcastro> http://www.rackspace.com/blog/ramping-up-our-openstack-investment-involvement/
<jcastro> towards the bottom
<jcastro> We also realize that the Rackspace public cloud has a number of implementation details that are out of step with common practice in the OpenStack community. Most of these were due to either our early lockdown on features to enable our 2012 launch â or decisions designed to keep in line with our first generation Cloud Servers offering. While  we believe some variation in implementations will be inevitable, we
<jcastro> do want to eliminate as many of these as possible to provide as much of a common OpenStack experience as we can. Along those lines, we are committed to take the following steps between now and the end of 2013. Hopefully, this will close most of the gaps that may currently exist:
<bkerensa> ah
<jcastro> someone had a boinc charm somewhere
<jcastro> I don't think it ever made it into the store
<jcastro> It'd be awesome though
<jcastro> build your new cloud, break it in with boinc for like a week
<hazmat> bkerensa, its not too hard to enable it re rack
<bkerensa> ah
<bkerensa> jcastro: also they are using the old ubuntu logo
<bkerensa> ;p
<bkerensa> send sladen after them
<saras> their is guide to setup local juju for test and dev right
<ColinR> Thanks for the answers, jcastro. Is juju-core still using Zookeeper? (I'm trying to dig through the source code now, but Go projects are a new experience for me)
<jcastro> ColinR: mongodb
<jcastro> saras: yeah, the only bummer right now is that the local provider only works with old juju and not new juju
<jcastro> so you need to do an update-alternatives to switch the client back and forth
<saras> hum
<jcastro> it's not an ideal situation but the local provider for goju isn't finished yet. :-/
<jcastro> but using pyju to use the local provider to write a charm should work just fine
<saras> will just got apport to say hi by installing ppa verison
<jcastro> since the version of core doesn't matter to the charm
<saras> why "go" any way
<jcastro> I think we have that on video, sec
<jcastro> http://youtu.be/kKQLhGZVN4A
<hazmat> ColinR, isn't noah single node and dead upstream?
<hazmat> ColinR, re existing chef cookbooks, if you can get them to run solo mode you can have juju pass config into ohai/chef as relation data comes in
<ColinR> yes. We've forked it and made some changes to support multiple nodes/newer redis versions, but it still needs some work
<ColinR> Thanks, hazmat; looks like the big thing holding us back from jumping to juju is the HA support. I know it's marked high priority in launchpad, fingers crossed it won't be long.
<hazmat> ColinR, i expect will be there this summer
<hazmat> ColinR,  what are you using for chef ha now?
<hazmat> s/we'll
<TheChistoso|2> how i would structure things is putting keystone/horizon/rabbitmq/mysql in a few HA controller nodes and then putting ceph, nova compute, quantum, swift/glance (swift would just be ceph) on each compute node using locally attached storage -- how easy would it be to configure the charms to enable that scenario?
<ColinR> Our setup doesn't rely on chef HA, though it'd be nice if it was. If we can ditch relying on chef-server and just use chef-solo (which with something like juju we could) even better.
<hazmat> TheChistoso|2, i'm not sure if the ha charms support that.. ie. colocation.. adam_g ?
<hazmat> ColinR, cool. incidentally zookeeper has an http api.
<TheChistoso|2> i'd like to use a more up-to-date version of juju. the one i have (in raring) is 0.7. can/how do i upgrade? i'm using this w/ maas and so is there an issue w/ the cloud image used by maas b/c the latest juju version isn't in backports?
<ColinR> yeah, we looked at zookeeper quite a bit, but liked the way noah handled watches more.
<adam_g> hazmat, TheChistoso|2 the colocation of principle  services might work okay since they're deploying unrelated services to the same machines, but when you start to add HA, i could imagine the hacluster subordinates stomping on each others cluster configurations.
<jcastro> TheChistoso|2: you can use the PPA
<jcastro> https://juju.ubuntu.com/get-started/
<adam_g> TBH, i've not tried collocating services to share the same underlying pacemaker/corosync cluster. it *might* work okay
<TheChistoso|2> adam_g: is this a limitation of the way the charms configure openstack or an inherent openstack limitation? (i think the former)
<jcastro> repo is the top line on the CLI instructions
<serch> hello
<jcastro> TheChistoso|2: we're working on backporting all that to raring and precise, it's just a WIP right now
<TheChistoso|2> jcastro: PPA will work w/ machines allocated from maas?
<adam_g> TheChistoso|2, like i said its not really an issue for the openstack services themselves (the principle services), but the underlying cluster infrastrucutre that gets setup as subordinates.
<jcastro> TheChistoso|2: that's a good question, let me check it out
<TheChistoso|2> adam_g: well i suppose it merits the question of -- does this setup i'm looking to do make sense?
<serch> hello someone can explain how to release the last vercion of ubuntu from the official website
<jcastro> TheChistoso|2: I think you would just use juju-origin:ppa in your environments yaml
<TheChistoso|2> jcastro: i imagine it would require modifying the cloud image. i haven't done that, but i imagine it's possible.
<jcastro> and maas will know what to do
<adam_g> TheChistoso|2, collocating glance and keystone isn't an issue, as theres no overlap in  config files or service ports. when you add the hacluster subordinate, a corosync/pacemaker cluster gets setup underneath. there would be overlap there, between twoh acluster subordinates on the same machine
<TheChistoso|2> jcastro: ah -- okay. i'll have to read up on the docs for that then. never done that before.
<jcastro> http://maas.ubuntu.com/docs/quantal/juju-quick-start.html
<jcastro> needs to be updated probably
<ColinR> Is there a way to seed a bootstrap node's db with data from another bootstrap node?
<TheChistoso|2> ColinR: i imagine once bootstrap HA is done, you wouldn't need to do that
<adam_g> TheChistoso|2, i think it makes sense for the purposes of conserving hardware.  quantum-gateway might need to be hosted on a machine other than compute, since there is potential  OVS overlap
<ColinR> TheChistoso|2, agreed. in the meantime though, I'll have a much easier time convincing the boss to use it if I can show we can recover our data from a db dump.
<TheChistoso|2> adam_g: let me explain my scenario a bit more. i'm constructing a small private cloud (~100 machines right now, likely to grow to ~300) for testing purposes. our tests are both CPU and write intensive. so, we'd like to use ceph but need as much of the data locally available as possible.
<TheChistoso|2> so we have a few core VM images (snapshots) that we replicate hundreds of times across compute nodes.
<TheChistoso|2> we plan on using gridcentric's virtual memory streaming product actually to run the VMs
<jcastro> oh, who was the guy saying they didn't have enough machines for openstack?
<TheChistoso|2> lol for my PoC i don't have enough machines :D
<jcastro> http://jujucharms.com/~virtual-maasers/precise/virtual-maas
<TheChistoso|2> and i'd like to dedicate as many machines to the core problem (testing) as possible
<TheChistoso|2> i have 16 machines i can use for the PoC
<TheChistoso|2> lots of HA-capable OpenStack implementations don't require 28+ to work
<TheChistoso|2> mirantis' fuel package can do it w/ 3-4 nodes for a small-medium size implementation
<TheChistoso|2> rackspace private cloud as well
<TheChistoso|2> piston cloud's solution has all openstack services running on all nodes
<saras> juju no like me
<TheChistoso|2> btw, is there an environment variable i can use to specify where the environments.yaml file is?
<adam_g> hazmat, does current service colocation (jitsu deploy-to) work with multiple unit services? eg, deploy rabbitmq and mysql to machine 1. add-unit rabbitmq. where does rabbitmq/1 end up?
<hazmat> adam_g, new machine
<adam_g> TheChistoso|2, interesting.  does collocating ceph storage nodes with compute nodes equate to locally available storage, though?
<TheChistoso|2> adam_g: not necessarily :D
<adam_g> hazmat, so, would it be possible to add-unit rabbimq, add-unit mysql and have both second units on the same machine?
<hazmat> adam_g, deploy-to and the integrated --force-machine in core.. only apply to the initial unit deployed.. when scaling up those services they go to new machines
<hazmat> adam_g, thats been discussed as part of a deploy --with=service
<TheChistoso|2> i'm actually rather new to ceph -- what i actually would like is to have certain snapshots automatically replicated to every compute node for fast VM creation
<saras> any one will help me troubshoot why juju install in going wrong
<hazmat> its not done though, but its where the force machine stuff is probably heading.. its likely spelled as a constraint
<TheChistoso|2> saras: what are you seeing?
<adam_g> TheChistoso|2, FWIW, when you boot an image/snapshot, its cached locally on the compute node the first time its booted. the second time, its booted from the local copy
<hazmat> saras, what's the problem?
<hazmat> and which version
<TheChistoso|2> saras: i've recently been through this myself
<TheChistoso|2> adam_g: in my case i'm going to have copies upon copies of the same VM -- not rebooting the same VM necessarily.
<adam_g> TheChistoso|2, there was talk at openstack summit a couple weeks back of moving from machine/image snapshots being  entire copies of images to differential snapshots
<TheChistoso|2> most our VMs run constantly, but when we update our core image, it needs to be replicated to all compute nodes and the VMs restarted from the new (snapshotted) image
<TheChistoso|2> adam_g: gridcentric's VMS product effectively does that now. but w/ memory as well. so you can snapshot a running VM and then stream it to compute nodes.
<saras> dpkg: error processing /var/cache/apt/archives/juju-core_1.10.0-1~1189~precise1_amd64.deb (--unpack):
<saras>  trying to overwrite '/usr/bin/juju', which is also in package juju 0.5+bzr531-0ubuntu1.3
<saras> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<TheChistoso|2> my issue w/ that is when we update our image, we'll have a barrage of requests for the new snapshot all at once. a "VM snapshot storm" if you will....
<jcastro> "dpkg -i --force-overwrite /var/cache/apt/archives/juju-core_1.10.0-1~1189~precise1_amd64.deb" should fix that, but please wait for someone to confirm that.
<TheChistoso|2> for starters, though, i'll just get a basic openstack cloud up and running :D i've done it a couple of times using the mirantis fuel and then the mirantis fuel-web package and then w/ rackspace private cloud as well. but i really, really want to use juju for this. :D
<saras> i think that worked thanks
<saras> i think that worked
<saras> that worked i think
<TheChistoso|2> jcastro: a small recommendation for http://maas.ubuntu.com/docs/quantal/juju-quick-start.html -- i ran into this issue myself...please add a note that when configuring the "maas-server" entry, that you'll want to include the port number in the URI. I know that's fixed these days, but w/ juju that comes OOTB and following just the quick start, it can be an issue.
<TheChistoso|2> (sorry -- that is, when configuring "maas-server" in environments.yaml)
<saras> how do i till juju to use local
<jcastro> TheChistoso|2: got it, I'll submit a fix
<TheChistoso|2> saras: do you mean to use local charms?
<saras> yes
<TheChistoso|2> there's a couple different ways. i prefer to set the JUJU_REPOSITORY env var to the directory where they reside.
<TheChistoso|2> then to deploy you'd say something like juju deploy local:<service>
<TheChistoso|2> jcastro: adam_g: i have the issue that my hardware is not homogeneous. so i have a preference for which machine might get peeled off from maas for use in deploying services. actually what i have is a preference on machine characteristics and not the machine itself.
<TheChistoso|2> i know i can instruct juju to use a specific machine. but i really don't care which machine -- i care which "class" of machine it is.
<saras> saras@saras-Bonobo-Performance:~$ juju deploy local:precise/node-app-6
<saras> error: environment has no access-key or secret-key
<saras> why is this not liking me
<TheChistoso|2> my thought was to use separate maas environments and then deploy using one or the other. the issue is that i'm not sure if juju knows about different environments and can make them work together (i doubt it).
<TheChistoso|2> saras: you just need to specify that value in your .juju/environments.yaml file
<saras> TheChistoso|2: how do i do that for local
<TheChistoso|2> are you using lxc containers?
<saras> sure how
<saras> sounds fun
<TheChistoso|2> :D what are you using juju with? AWS? OpenStack? MAAS?
<saras> local
<saras> i was hoping
<TheChistoso|2> just to be clear -- you have locally-defined charms and you're using lxc?
<saras> um hum
<saras> i would love to use lxc
<TheChistoso|2> i haven't setup lxc before so i'm not much help. but first, provide the contents of your ~/.juju/environments.yaml (pastebin it)
<TheChistoso|2> you said you're using 1.10 IIRC -- which release? precise? raring?
<sarnold> (be careful not to pastebin secrets from that file..)
<saras> i am so lost now
<saras> https://plus.google.com/hangouts/_/c3ccfdfd6addbbd723b6ac93fa6be15a236e1a07?authuser=0&hl=en
<saras> help
<saras> is their not a way to get feet wet with out cloud provider
<sarnold> saras: I used local provider with juju when I was getting started, and a bit when developing new charms. It seemed about the same complexity to me as the ec2 provider..
<saras> sarnold: what do i need in the envirment file to do that
<saras> as the getting start guide does not cover it
<saras> arrrrrrrrrrrrrrggg
<saras> Open `~/.juju/environments/yaml` in your text editor and uncomment out the sections you need for your cloud provider.
<saras> is what the getting started guide tell me
<saras> their should be way to setup local to test stuff before you play spend money on cloud guys
<saras> or am i crazy
<TheChistoso|2> that's what lxc and maas can do for you
<TheChistoso|2> (well maas or virtual-maas)
<saras> then why are they not in the getting started guide
<sarnold> saras: iirc, juju generate-config -w should create a template ~/.juju/environments.yaml file for you to edit
<saras> yes it is
<sarnold> saras: you don't -need- the template, but it is a bit helpful
<TheChistoso|2> saras: the getting started guide was a bit difficult, i found, to get started. :D for one, i installed raring and didn't realize it was an older version and juju generate-config didn't exist.
<saras> yes i had the same issue
<sarnold> older versions I htink just used juju bootstrap to make the config .. yo'ud run juju bootstrap twice, once to create your template, edit that, then run it again to create the headnode..
<sarnold> saras: http://pastebin.ubuntu.com/5630403/
<sarnold> saras: something like that in your ~/.juju/environment.yaml
<sarnold> jcastro: hey, many typos abound in "Take 5 minutes to get to know juju" https://juju.ubuntu.com/get-started/   --- there's a ~./juju (yes, ~./)  and the markdown `` don't appear to do anything :) and the ~/.juju/environments/yaml -- with extra /  :)
<jcastro> ok I can fix those
<TheChistoso|2> so i tried to run add-apt-repository (in raring) and the command wasn't available. so i sudo apt-get install python-software-properties and it still doesn't work. anybody know which package that lives in?
<jcastro> slow down :)
<sarnold> software-properties-common: /usr/bin/add-apt-repository
<sarnold> jcastro: thanks :)
<TheChistoso|2> i'm not getting juju 1.10 -- still on 0.7. I ran the following:
<TheChistoso|2> sudo apt-get install software-properties-common
<TheChistoso|2> sudo add-apt-repository -y ppa:juju/pkgs
<TheChistoso|2> sudo apt-get update && sudo apt-get install juju charm-tools
<jcastro> you need juju-devel as the ppa
<jcastro> and it's juju-core
<jcastro> that'll get  you 1.10
<sarnold> ooh juju-core is at 1.10? nice work :)
<jcastro> sarnold: man, that's like the third or fourth time I've used markdown on a HTML webpage
<sarnold> (that's a confident-sounding round number. :)
<sarnold> jcastro: I keep finding myself typing markdown in irc.
<saras> any willing to jump into hangout help me out
<TheChistoso|2> jcastro: tyvm -- that's much better :D
<jcastro> I need to step out for the weekend, I'll be back in a few hours though
<TheChistoso|2> now how about the agents on the maas-provided machines?
<jcastro> I just realized that made no sense
<TheChistoso|2> lol :D
<TheChistoso|2> few days?
<sarnold> jcastro: have fun for the weekend, for the few hours :)
<saras> i get some of the novacut guys in hangout so beat our heads on this one toughter
<saras> have fun
<TheChistoso|2> so i upgraded juju and ran juju status. i now get: error: no CA certificate in environment configuration. that's needed now-a-days?
<TheChistoso|2> hazmat: i'm seeing "error: no CA certificate in environment configuration" -- any thoughts?
<TheChistoso|2> juju bootstrap now gives me: error: no tools available
<sarnold> TheChistoso|2: do you still have the 0.7 pyjuju stuff installed alongside the 1.10 gojuju?
<TheChistoso|2> sarnold: i must have
<TheChistoso|2> i'm updating charm-tools right now
<TheChistoso|2> juju sync-tools isn't working either
<TheChistoso|2> $ juju sync-tools -v 2013/05/03 15:16:20 INFO environs/ec2: opening environment "juju-public" 2013/05/03 15:16:20 ERROR failed to initialize the official bucket environment 2013/05/03 15:16:20 ERROR command failed: environment has no access-key or secret-key error: environment has no access-key or secret-key
<TheChistoso|2> whoops, let me try that again...
<TheChistoso|2> $ juju sync-tools -v
<TheChistoso|2> 2013/05/03 15:16:20 INFO environs/ec2: opening environment "juju-public"
<TheChistoso|2> 2013/05/03 15:16:20 ERROR failed to initialize the official bucket environment
<TheChistoso|2> 2013/05/03 15:16:20 ERROR command failed: environment has no access-key or secret-key
<TheChistoso|2> error: environment has no access-key or secret-key
<TheChistoso|2> sarnold: any thoughts?
<sarnold> TheChistoso|2: you need some environment variables to declare how to connect to your EC2 instances..
<TheChistoso|2> i'm not running w/ EC2
<TheChistoso|2> and this is to bootstrap w/ maas
<sarnold> TheChistoso|2: I think maas may require the same EC2 env variables... see e.g. http://wiki.debian.org/euca2ools
<TheChistoso|2> sarnold: that doesn't sound right to me
<sarnold> TheChistoso|2: hrm, you're right, I see none of that mentioned here http://maas.ubuntu.com/docs/quantal/juju-quick-start.html
<TheChistoso|2> sarnold: i found this: https://bugs.launchpad.net/juju-core/+bug/1172973
<_mup_> Bug #1172973: sync-tools requires aws credentials be set in the (shell) environment <juju-core:Confirmed> <https://launchpad.net/bugs/1172973>
<TheChistoso|2> sarnold: however, i set those env vars, but apparently i don't have the right values b/c i get:
<TheChistoso|2> $ juju sync-tools -v
<TheChistoso|2> 2013/05/03 15:31:15 INFO environs/ec2: opening environment "juju-public"
<TheChistoso|2> listing the source bucket
<TheChistoso|2> 2013/05/03 15:31:15 ERROR command failed: The AWS Access Key Id you provided does not exist in our records.
<TheChistoso|2> error: The AWS Access Key Id you provided does not exist in our records.
<sarnold> TheChistoso|2: oof. :/
<TheChistoso|2> not sure what to do at this point
<sarnold> TheChistoso|2: perhaps try #juju-dev ? I think the go juju folks hang out there..
<TheChistoso|2> sarnold: thanks -- i just asked and i'll cross my fingers for an answer
<sarnold> TheChistoso|2: good luck :)
<TheChistoso|2> thanks :/
#juju 2013-05-04
<_mup_> Bug #1176281 was filed: Rackspace connection fails because of security groups <juju:New> <https://launchpad.net/bugs/1176281>
<AskUbuntu> Use existing ssh keypair in juju | http://askubuntu.com/q/290449
<hazmat> TheChistoso|2, juju-core for maas has received very light testing. most of the openstack work happens with pyjuju to date.. that's changing but for today, i'd go with pyjuju for openstack deploys.
<aaronj___> \quit
<lamalex> does juju work with rackspace yet?
#juju 2013-05-05
<thediexguy> hello?
<cutout> n
<cutout> o
<cutout> ||||||
<cutout> ||||
<My_Ass\> h
<sudo_apt-get_ins> bbbbbbbbbbbbbbbbbb\
<TheDiex_Guy> jl;khssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;f
<TheDiex_Guy> kjldshfiuve tby27865 v783q2 xpoi32ufcnoiqrub2844trc4875b4h6587q34c62/8426388748E7857NTS9 876O8P7,6874X712S6897 19683789N56719675156983BV423/5VB3Q25644565V46542/6/254Q3YFVTU4Y5TBV
<TheDiex_Guy> LHIBKJGDFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ.KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
<TheDiex_Guy> IM AN EATER
<AskUbuntu> Is Ubuntu MAAS broken on 12.04 LTS and 13.04? | http://askubuntu.com/q/291043
<m_3> ok, vacation over... back to work
<b1tbkt> any way to deploy across multiple machines simultaneously with jitsu? Want to deploy ceph on units that are already assigned other services.
#juju 2014-04-28
<jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/precise/glance/notification/+merge/216573 if you have time :-)
<gnuoy> sure
<gnuoy> jamespage, lgtm, do I need to throw any tests at the mp before giving it a +1 ?
<jamespage> gnuoy, I think rharper and coreycb tested pretty well last week
<jamespage> gnuoy, happy to wait for their +1 as well if you want to
<gnuoy> Its pretty trivial tbh
<jamespage> gnuoy, ta - merged into trusty and precise branches
<gnuoy> jamespage, ah, I'm not an openstack-charmers
<jamespage> gnuoy, fyi we have different branches for trusty and precise - but they are still the same context
<jamespage> gnuoy, you are a charmer right?
<jamespage> context/content
<gnuoy> jamespage, I was, maybet I was stripped of that when I left IS
<gnuoy> s/maybet/maybe/
<jamespage> gnuoy, I added you to that team
<gnuoy> ta
<jamespage> gnuoy, you have more that enough track record of charm and charm-helpers updates
<gnuoy> thanks :)
<X-warrior> Does juju update amazon security groups?
<allomov> hey, everyone.
<allomov> do you know what can cause this output https://gist.github.com/allomov/11373534 when running `juju deployer -c bundle.yml`
<allomov> ?
<hazmat> allomov, transient error on state server.. it should be auto retrying those.. you might have an old version of jujuclient
<hazmat> allomov, apt-cache show python-jujuclient
<allomov> thank you, hazmat. sounds like useful hint
<hazmat> allomov, this is on trusty? could you send the version string in the output of that apt-cache show cmd?
<allomov> hazmat, here is an output https://gist.github.com/allomov/11373534#file-apt-cache_show_python-jujuclient-log
<allomov> hazmat: yes, I'm on trusty
<allomov> hazmat: I will try to reinstall python-jujuclient
<hazmat> allomov, latest versions are in pypi i'd use virtualenv.. i think ahasenack also has a daily/trunk ppa but not sure it includes jujuclient
<hazmat> the daily ppa for deployer that is
<hazmat> allomov, are you  seeing it regularly?
<hazmat> allomov, or is this a first time?
<ahasenack> hazmat: there are two ppas, one for deployer and one for jujuclient, both dailies
<allomov> hazmat: I've already seen this issue. I guess it was solved by recreating vm, where I run juju.
<lsyoyom> Hi, guys, I have a quick question, is juju-local able to survive a host restart? I'm getting confusing google search results.
<lsyoyom> According to https://bugs.launchpad.net/ubuntu/+source/juju/+bug/955576/comments/7, this should be fix in juju-core, but my juju-local won't start after a restart.
<_mup_> Bug #955576: 'local:' services not started on reboot <production> <pyjuju:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/955576>
<lsyoyom> So I guess this is still not fixed, or the fix is still not merged yet?
<lsyoyom> How should I bring up the environment manually after a restart?
<allomov> hazmat: here is what worked for me https://gist.githubusercontent.com/allomov/11373534/raw/bd430c2c92116340f2fa5d124b769c555946609d/solution.sh
<allomov> hazmat: thank you for helping
<lsyoyom> Thanks! I will take a look right away!
<allomov> hey again.
<allomov> after updating juju to 1.19.1-trusty-amd64 version I can't ssh with juju command
<allomov> here are details: https://gist.github.com/allomov/11374976
<allomov> I am working with aws btw (ec2 environment type)
<allomov> The error message is -> ssh: Could not resolve hostname ip-172-31-21-242.us-west-2.compute.internal: Name or service not known
<allomov> I can't see bug report for this issue on launchpad, so will create one.
<hazmat> allomov, ick
<hazmat> allomov, please file a bug re ec2 ssh
<hazmat> allomov, if there's a chance you can stick the stable version (1.18.x) i'd recommend it
<allomov> hazmat: I've already created bug report : https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1313785
<_mup_> Bug #1313785: Can't SSH with "juju ssh" command to EC2 instance. <ssh> <juju (Ubuntu):New> <https://launchpad.net/bugs/1313785>
<allomov> hazmat: actually I can live with it
<qhartman> what's the command to ack an error state? In my case I have a relation hook that failed, will juju retry that when I issue the ack command?
<qhartman> aha
<qhartman> found it
<qhartman> "juju resolved"
<X-warrior> Does juju update amazon security groups?
<lazyPower> X-warrior: when you say update, in which sense?
<X-warrior> lazyPower: update security groups for port access. Or something like this, I have a machine where I manually opened a port on amazon console... and from time to time this configuration is lost... so I'm thinking if juju updates it
<lazyPower> X-warrior: unless the charm itself does an explicit open-port or close-port, it won't address the security groups unless that behavior has chanaged
<lazyPower> which i don't think it has
<lazyPower> X-warrior: and juju expose would be the magic key to actually open the ports to the world.
<X-warrior> lazyPower: yeap. I have the port 80 opened with open-port and expose... but I manually add port 443 on machine but this 443 port is being closed from time to time... so I was thinking if expose/open-port rewrite the security group, or recreate it... that could be the problem
<lazyPower> X-warrior: i'm not 100% positive, but it sounds reasonable. I'll ask between tracks and see if i cant get a definitive answer for you.
<X-warrior> lazyPower: thanks for the help anyway
<qhartman> I'm having trouble with the keystone charm when setting up relations. it seems to be trying to connect to localhost instead of the real IP or hostname of the keystone box, which is failing
<qhartman> Anyone know the right way to make sure that's configured correctly?
<X-warrior> lazyPower: I'm leaving for today if you find anything new about this, I will be around tomorrow. Have a great one :D
<marcoceppi> negronjl-afk: ping
<negronjl-afk> marcoceppi, hey
<marcoceppi> negronjl-afk: hey, can you explain what these # do? https://docs.google.com/spreadsheet/ccc?key=0AgF6NYIOVngmdGFNdjQ3dlFEb3c4VmNfY3hjeVYyT1E&usp=drive_web#gid=1
<marcoceppi> Crapppp
<marcoceppi> wrong ling
<marcoceppi> link
<marcoceppi> https://code.launchpad.net/~negronjl/charms/precise/rabbitmq-server/lp1312281/+merge/217085
<negronjl-afk> marcoceppi, they comment everything after them.. I am using it to show the part of code that is being ignored in case someone down the line figures out why they were put there originally
<negronjl-afk> marcoceppi, I assume that somebody put that extra call to the function ( probably with the intent of using it later but, forgot about it ).  This way they get to see it without really affecting the code
<marcoceppi> negronjl-afk: cool, thanks
<marcoceppi> I thought so, but wasn't sure if it was some crazy python thing
<axisys> anyone got ucky in starting hadoop charm on local environment?
<axisys> I am using ppa:juju/devel's juju and still showing pending
<axisys> 1.19.1-trusty-amd64
<axisys> Now it shows working after following this
<axisys> https://gist.githubusercontent.com/allomov/11373534/raw/bd430c2c92116340f2fa5d124b769c555946609d/solution.sh
<lazyPower> axisys: i'm not sure what those modifications are, but if its working it's probably worth noting you should ping the list with those details
#juju 2014-04-29
<cylee_> hi, does anyone encounter juju cannot bootstrap under MAAS environment?  The juju status show port 17070 connection refused
<caribou> I would need some guidance in fixing the nova-cloud-controller charm
<caribou> I need to pass the content of authorized_keys & known_hosts through a relation
<caribou> currently, the content is encoded in base64 but if the file is too big it fails
<caribou> I'm looking at passing each line of the file as a relation
<caribou> the problem I face is building indexed relations so the other side can rebuild the file correctly
<caribou> any suggestion/comment ?
<Guest74260> I have a cloud instance running on which I installed juju and juju-gui using local provider.   juju-gui deploys into an lxc container with a 10.x.x.x address.   If I remote desktop to the cloud instance I can start firefox & access juju-gui.   But what can be done to directly access it & login over the internet
<Guest74260> I  tried installing nginx on the host and redirect to the juju-gui container IP the login menu starts to appear but it just spins on "Connecting to the juju environment"
<chenxiongfei> æå¤§åå´½åï¼
<chenxiongfei> test
<qhartman> It looks like the nova-cloud-controller charm for Trusty doesn't actually install nova-network, even though it says it does in the description.
<qhartman> Here's the apparently relevant code: https://bazaar.launchpad.net/~openstack-charmers/charms/trusty/nova-cloud-controller/trunk/view/head:/hooks/nova_cc_utils.py#L52
<qhartman> Is this by design to push people to Neutron, or is it an oversight?
<lazyPower> Guest74260: sshuttle will give you a "vpn" over ssh to use.
<html> morning
<html> morning
<avoine> o/
<html> hi
<html> https://bugs.launchpad.net/juju-core/+bug/1289799 this is what i get when i do just that
<_mup_> Bug #1289799: Trying to bootstrap local provider as root breaks environment <bootstrap> <regression> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1289799>
<html> local install
<mhall119> what are the charm category options?
<mhall119> nvm, found it
<html> there is none, i am trying to install juju for the 30th time
<mhall119> html: trying ot install the command-line tools?
<mhall119> marcoceppi: I'm not grasping the difference between a relation and an interface...can you point me to some docs that might clear it up for me
<mhall119> ?
<html> idk what im really doing.
<html> i know that im trying to install juju to get the gui
<html> the set up some servivces
<mhall119> oh, the juju-gui is different, I think
<mhall119> I've only used the command-line tools myself, which is probably easier if you just have a few services to manage, not a full datacenter
<html6> mhall119,  well atm idk how i get it working. 20-30 time and fail. im tired of banging my head
<mhall119> html6: what instructions are you following?
<html6> just a min
<html6> mhall119,  i believe that was the default page for the instucktions
<mhall119> what "that"?
<jose> html6: if you're bootstrapping local it doesn't require sudo
<html6> i did both
<jose> html6: did you already try destroying the environment?
<jose> with sudo juju destroy-environment --force
<html6> i like to install the juju on my Ubuntu desktop then have a nodes at digaitalocean to be sping up
<jose> I can give you a hand with that
<html6> jose,  teamveiwer?
<jose> html6: I can guide you through on IRC
<html6> sure,
<jose> http://blog.dasroot.net/replacing-u1-with-owncloud-on-digital-ocean/ has some instructions on how to get owncloud running
<jose> I think you want to follow everything until Boostrapping our DO service
<jose> now the question is, do you want to deploy everything on a single node or have different nodes?
<jcastro> hey jose
<jose> hello, jcastro!
<jcastro> you can make that power video I put on ubuntuonair.com public now. :)
<jose> awesome, thanks for the heads up!
<jose> negronjl: for when you have some time, https://code.launchpad.net/~jose/charms/precise/seafile/readme-cache-departed/+merge/217170 is waiting for review
<jose> should be pretty simple
<html6> thats a good qestion jose
<jose> html6: do you have any plans about what you want to deploy?
<html6> i need a webserver  with storage
<html6> a vpn
<html6> bittornet seeeder
<html6> give back to linux ;)
<html6> owncloud + stoagre.  hopeing i can use the storage from home over the internet
<html6> i can hear you
<jose> html6: why don't you try that owncloud tutorial?
<jose> if that works for you we can go ahead and help you with some other stuff
<html6> jose,  i have try this 10= times
<jose> html6: bootstrapping in digitalocean?
<lazyPower> Hey thats my blog up there
<lazyPower> jose: right on.
<FunnyLookinHat> Anyone here a MAAS expert?  #ubuntu-maas isn't too popular
<sarnold> FunnyLookinHat: I think everyone is 'on sprint' this week, travelled somewhere and working feverishly in too-tiny and underventilated hotel conference rooms..
<FunnyLookinHat> sarnold, hehehe - fair enough :)
<marcoceppi> FunnyLookinHat: not an expert, and at a sprint, but I could help
<marcoceppi> FunnyLookinHat: also, did you try #maas ?
<FunnyLookinHat> marcoceppi, I'll give #maas a try  :)
<hobbit> Hello!
<hobbit> having this issue, can't google out anything simlar: have one maas, one compute, when deploying juju - log shows that there are attempts to establish ssh connection, tcpdump show that compute answers - but nothing happens
<hobbit> latest juju, 12.04.4 precise
<sarnold> hobbit: are you using the python juju (version 0.7 or so...) or the juju-core (1.17 or so?)
<hobbit> juju-core 1.18.1
<sarnold> hobbit: can you pastebin a juju status?
<hobbit> that's a thing - juju status complains that juju is not bootstrapped; but i can't bootstrap
<hobbit> yet i can ssh easily between maas and compute
<jose> hobbit: have you actually bootstrapped the environment?
<hobbit> that's what im trying to do - but bootstrap times-out after 10 minutes
<hobbit> i see that it tries to ssh towards compute during this time
<hobbit> i can manually run same command from console - and it works (though i see no prompt) but i can definitely interact
<jose> can you please pastebin the log of the bootstrap?
<jose> what's weird is that it usually destroys machines if the bootstrap is not successful
<hobbit> it's huge, but this line is seen repeatedly during bootstrap ->  2014-04-29 17:30:12 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/virtu/.juju/ssh/juju_id_rsa -i /home/virtu/.ssh/id_rsa ubuntu@10.0.0.100 /bin/bash
<hobbit> every 10 seconds
<jose> hmm, it's trying to bootstrap local?
<jose> because 10.0.0.100 looks like a local-range IP
<hobbit> well, it's two physical blades, one maas and one compute
<jose> oh, openstack
<jose> I thought it was EC2
<hobbit> yepp, openstack :)
<hobbit> so, if i try
<hobbit> ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/virtu/.juju/ssh/juju_id_rsa -i /home/virtu/.ssh/id_rsa ubuntu@10.0.0.100 /bin/bash
<hobbit> from console, it works, i.e. i can interact with 10.0.0.100
<hobbit> no prompt though
<hobbit> im sure that ssh connection is not dropped or anything
<hobbit> but i guess maybe juju should send some command to /bin/bash, ie what's the point to ssh to bash with no command...
<magicrobotmonkey> im trying to deploy openstack and keystone has failed on the identity-service-relation-changed hook
<magicrobotmonkey> with Service Unavailable: http 503
<mattgriffin> jcastro, ping
<jcastro> hi!
<mattgriffin> hi jcastro. you going to be in ATL in a few weeks?
<jcastro> I won't be there, but we'll have a bunch of people there.
<jcastro> whatever you need I can make sure someone comes talks to you
<mattgriffin> jcastro, cool. are there any plans for juju + trove atm?
<jcastro> trove?
<mattgriffin> for deploying DBs
<avoine> magicrobotmonkey: have you try juju resolve keystone/0 --retry ?
<jcastro> OH, openstack trove
<mattgriffin> hehe... yeah
<magicrobotmonkey> yea, avoine
<jcastro> I don' t know off hand, I'm at a sprint though, I'll ask around
<magicrobotmonkey> and Im debugging the hook and seeing the same thing
<mattgriffin> jcastro, ok
<magicrobotmonkey> should i not be doing this on trusty?
<avoine> magicrobotmonkey: hum I don't know
<jcastro> mattgriffin, I am being told that it's a goal for utopic.
<jcastro> mattgriffin, you'll want to link up with either zul or jamespage in atlanta
<mattgriffin> jcastro, excellent. thanks!
<jamespage> mattgriffin, trove will be a charm target for this cycle
<mattgriffin> jamespage, great
<jcastro> \o/
<jamespage> mattgriffin, I think it will be a core project for juno so it will end up in main as well i suspect
<mattgriffin> ack
#juju 2014-04-30
<chenxiongfei> juju
<_benoit_> Hi
<_benoit_> wanabee contributor question: I want to add support for an EC2 compatible provider to juju. Will the patches be wellcome ?
<avoine> _benoit_: which one? (note that I'm just curious and I'm not in the juju dev team)
<cargill> what to do when a charm in the store needs to be obsoleted?
<avoine> fill a bug I guess
<_benoit_> avoine: Outscale cloud
<_benoit_> avoine: there si two compagny Outscale INC and Outscale SAS who are providing a high performance cloud
<_benoit_> avoine: If you are looking for an european EC2 alternative Outscale is  a good option
<mister_zombie> Hi, does Juju have a REST api of some kind?
<mister_zombie> I found stuff in launchpad that suggest it does, but I didn't find any documentation about it. I did google words that I thought were appropriate, but the results were not what I was looking for.
<marcoceppi> mister_zombie: yes, it does
<marcoceppi> mister_zombie: not quite a RESTful API, but it's an API
<marcoceppi> mister_zombie: there's a package, jujuclient, in python for communicating with the bootstrap node
<mister_zombie> marcoceppi: Thanks, will look at that.
<mister_zombie> marcoceppi: It's using a websocket?
<marcoceppi> mister_zombie: yes
<mister_zombie> Oh, cool. I wanted to build some kind of client that could fire up/shut down instances of services from some web interface I'd build.
<mister_zombie> Which seems redundant to the web ui but yeah.
<marcoceppi> mister_zombie: cool, yeah, that's available to do
<magicrobotmonkey> can you make bootstrap leave the node up for debugging?
<marcoceppi> magicrobotmonkey: can you elaborate?
<magicrobotmonkey> well i ran juju bootstrap and it died on cannot resolve streams.canonical.com
<magicrobotmonkey> and then shut the node down
<magicrobotmonkey> befofe i could get on it and investigate dns
<magicrobotmonkey> (my nodes do not have internet access so things are running through proxies. hopefully)
<marcoceppi> magicrobotmonkey: ah, yes, if a bootstrap fails during bootstrap it does a clean up
<marcoceppi> magicrobotmonkey: I have no idea how to get around that though, possibly with the --debug flag during bootstrap
<magicrobotmonkey> is nova-volume called something different in trusty?
<whit> lazyPower, heyo
<lazyPower> whit: https://juju.ubuntu.com/docs/reference-reviewers.html
<lazyPower> o/
<whit> lazyPower, danke
<lazyPower> Ihr Willkommen
<lazyPower> jose: new version of owncloud has been released
<lazyPower> 0.6.3
<jose> lazyPower: ack, should be an easy fix, but can I get the other MP off the way?
<jose> that way I can test that it actually works with the SSL integration stuff once it's updated
<lazyPower> jose: ack. sprinting so you know the drill. Will get to it asap
<jose> yep, thanks!
<mhall119> jose: lp:~mhall119/+junk/go-pronto-charm has my start charm
 * jose checks
<mhall119> with a go-pronto binary for i386 in files/
<jose> so what theda c mentioned is that $CHARM_DIR/files/go-pronto would be the path to look for if you want to run the binary
<mhall119> or copy the binary somewhere else on install/upgrade-charm
<mhall119> which was what I was going to do
<jose> that could work, yes
<jose> it's going to be 'go get' if 64bits else binary?
<mhall119> I can probably just call it from the start hook and push it to a background process...but that seems hackish
<mhall119> no, I was going ot just ship the binary, no go-getting
<jose> then it needs to fail if the machine is 64bits
<mhall119> it could run the 32bit binary on amd64, couldn't it?
<mhall119> it'd just have to fail on arm
<jose> hmm, not sure
<jose> now, for the upstart job you can just copy what's in http://bazaar.launchpad.net/~jose/charms/precise/communitycast-server/trunk/files/head:/data/
<jose> http://bazaar.launchpad.net/~jose/charms/precise/communitycast-server/trunk/view/head:/data/communitycast-server.conf specifically
<mhall119> is that all there is to an upstart job?
<jose> mhall119: yep, at least I got it that way for communitycast-server
<jose> oh, and you need to copy that to...
<jose> /etc/init/job-name.conf
<jose> to start it's `start job-name` and to stop `stop job-name`
<mhall119> thanks jose
<jose> np :)
<jose> let me know if you need a hand with anything
<mhall119> will do
<magicrobotmonkey> im having trouble with my keystone charm because localhost requests are getting sent through my proxy
<magicrobotmonkey> the only place i see the proxy set is in /etc/apt/apt.conf.d/42-juju-proxy-settings
<magicrobotmonkey> is there any way to add excpetions or anything in there?
<lazyPower> magicrobotmonkey: http://askubuntu.com/questions/92764/disable-proxy-server-for-one-apt-repository
<mhall119> marcoceppi: jose: I'm getting a strange error from my go-pronto charm:
<mhall119> 2014-04-30 20:16:38 INFO juju-log Creating pronto settings in /etc/go-pronto/config
<mhall119> 2014-04-30 20:16:38 INFO config-changed + '[' '!' -d /etc/go-pronto ']'
<mhall119> 2014-04-30 20:16:38 INFO config-changed + cat
<mhall119> 2014-04-30 20:16:38 ERROR juju.worker.uniter.charm git.go:211 git command failed: exit status 128
<mhall119> path: /var/lib/juju/agents/unit-go-pronto-0/state/deployer/update-20140430-161638997305812
<mhall119> args: []string{"commit", "--allow-empty", "-m", "Imported charm \"local:trusty/go-pronto-7\"."}
<mhall119> my charm isn't calling git anywhere....so why is it failing due to git?
<lazyPower> mhall119: are you on 1.19.1 or on 1.18.x? the 1.18 series of juju still uses git as an internal versioning tool
<lazyPower> this was removed as of 1.19.1
<mhall119> $ juju --version
<mhall119> 1.18.1-trusty-i386
<mhall119> is 1.19.1 being backported?
<mhall119> woot! success!
<gdey> hello everyone.
<marcoceppi> gdey: o/
<marcoceppi> mhall119: 1.19 series is bascially the RC for 1.20
<marcoceppi> mhall119: 1.ODD are dev releases
<gdey> Anyone one have a small tutorial or any documentation on how to create a provider for juju in go?
<marcoceppi> gdey: you should ping mgz
<marcoceppi> gdey: there's an example provider in the code base, but not really any documentation outside of the doc
<gdey> marcoceppi: k
<gdey> marcoceppi: Just making sure, in the juju-core code base; correct.
<marcoceppi> gdey: correct, under providers I believe
<qhartman> I've gotten my openstack setup working with Juju, with only a little bit of manual tweaking
<qhartman> one thing I'm having to do is add config-flags to the nova-compute config options
<qhartman> I've applied them in the gui, and they've appeared in the running config on one of my compute nodes that I have going, but not the other
<qhartman> how long should it take to juju to propagate these changes to all node?
<tvansteenburgh> jose: ping
<jose> tvansteenburgh: quick-pong
<tvansteenburgh> jose: nevermind, i'll email you
<mbruzek> jose are you there
<mbruzek> I have a question about your owncloud charm.
<mgz> jcastro: <http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#Using_AddingDefaultLocalInstanceStorageToAMI>
<mgz> "For M3 instances, you must specify instance store volumes in the block device mapping for the instance. When you launch an M3 instance, we ignore any instance store volumes specified in the block device mapping for the AMI."
<mgz> so, *if* he was switched to m3 instances from m1 instances by the pricing drop, he may well no longer be getting instance store when our images previously included it
#juju 2014-05-01
<jose> tvansteenburgh: I actually forgot to do bzr add and lost the info, BUT had pastebinned it :)
<jose> (for the nyancat tests)
* lazyPower changed the topic of #juju to:  Welcome to Juju! || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP
<rharper> in an openstack environment, can I configure what ssh keys juju uses when deploying services?  I'd like to provide the keypair instead of juju generating one
<stokachu> rbasak: do you maintain python-websocket?
<jose> marcoceppi: ping, I'm having some problems with my tests
<jose> they seem to not pass anymore, not sure why... even though they *did* pass when I wrote them
<rbasak> stokachu: I did TIL
<rbasak> stokachu: what's up?
<stokachu> rbasak: we recently got python3 support in the main source tree
<stokachu> rbasak: should i open a bug to get python3 packages built?
<rbasak> stokachu: in the websocket-client source tree?
<stokachu> rbasak: yea
<rbasak> stokachu: ah OK. Yeah we probably need a bug to update to latest upstream then, and to add Python 3 packages.
<stokachu> ok ill file one this week for that
<rbasak> Looks like Debian need one too
<stokachu> ok ill follow up with the Debian maintainer as well
<rbasak> stokachu: thanks! Just noticed that https://pypi.python.org/pypi/websocket-client still says 2.7 only - I guess you want to fix that?
<stokachu> rbasak: yea ill ask the upstream guy to release a new version
<rbasak> Ah
<rbasak> Right - I see. 0.13.0 is latest release which we haven't updated either, and 0.14 has Python 3 and needs a release. I get it now :)
<stokachu> rbasak: looks like 0.14 will be release may 15th
<stokachu> so i can follow up with those bugs after that
<stokachu> once this is done then we could look at making the jujuclient python3
<stokachu> i think the websocket part was the only blocker
<rbasak> Sounds great!
<rbasak> Though I wonder if you still want to support 2, for other platforms that don't have 3 yet? Or do they all have 3 now?
 * rbasak only uses Ubuntu
<stokachu> rbasak: that's a hazmat question re: py2 support :)
<stokachu> i dont think any other distro support python3 websocket-client yet
<mhall119> jose: marcoceppi: is there a way for me to check the current relation value between 2 services?
<jose> mhall119: `relation-get value` will return it
<mhall119> jose: from my host, not the instance?
<jose> oh
<jose> hmm, I think not, maybe Marco will be able to help with that
<jose> but if you want to check a consistent value, `juju debug-hooks unit/#` and then `juju set servicename` will get you in a hook environment
<jose> actually, debug-hooks and then join the relation or destroy it
<jose> mhall119: I'm checking the README and just a few things:
<jose> we've moved to Markdown so that won't render properly
<jose> and `charm add readme` should give you the boilerplate README to just copy and paste that
<jose> also, Contact Information listed there is for upstream (which is good) but we also want people to be able to report bugs on the charm itself
<tvansteenburgh> jose: ack. thanks for all the contributions man, you're rockin' it
<jose> tvansteenburgh: oh, you have a min?
<jose> tests are not going well :(
<tvansteenburgh> jose: yep, i got time
<jose> well, I'm using *exactly* the same tests as before (which passed) but they're now giving a timeout error
<tvansteenburgh> hrm. if you pastebin the test i can try to help debug
<tvansteenburgh> or push the branch (if you haven't yet)
 * jose does
 * tvansteenburgh pulls branch
<jose> \o/
<tvansteenburgh> jose: had some vm issues, running test now
<jose> cool, thank you!
<jose> I'm really surprised - the rev queue is now short!
<mattrae_> hi guys, i'm using the openstack provider with juju 1.18.. i'm able to bootstrap after doing the metadata setup.. but i'm wondering if i'm doing it the recommended way if someone can review: http://pastebin.com/hERMpCiA
<tvansteenburgh> jose: still investigating
<jose> np, I have time :)
<tvansteenburgh> jose: changing conference rooms, i'll brb
<jose> ok!
<tvansteenburgh> jose: this is where things are failing for me: http://pastebin.ubuntu.com/7374048/
<jose> hmm, maybe you hit a server during downtime?
<tvansteenburgh> jose: when your test times out, what's the tail of ~/.juju/local/log/unit-nyancat-0.log ?
<jose> I use ec2 for testing :P
<tvansteenburgh> ah
<jose> local would literally take an hour
<jose> it does throw an error, though, let me try and run the test right now
<tvansteenburgh> yeah, or ssh to the ec2 instance and check the log there
<jose> before it dies
<jose> will do
<mhall119> just wasted over an hour trying to figure out why my hooks were failing....because I used /bin/sh instead of /bin/bash :(
<jose> tvansteenburgh: I think I now found the error
<jose> for some reason it's not opening the correct port
<jose> it installed correctly, so looks like that prob was on your side
<tvansteenburgh> ko
<tvansteenburgh> ok
<mhall119> jose: `charm add` says invalid subcommand
<jose> mhall119: charm add readme?
<jose> are you using an updated version of charm-tools?
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/summit/charms/trusty/go-pronto$ charm add readme
<mhall119> Error: add is not a valid subcommand
<jose> looks like charm-tools needs some updating
<mhall119> jose: charm-tools: Installed: 1.0.0-0ubuntu2 Candidate: 1.0.0-0ubuntu2
<jose> hmm, that's the one I'm using
<jose> mhall119: oh, can you try with `juju charm add readme`?
<jose> anyways, http://paste.ubuntu.com/7374204/ has the contents
<d3lxa> hello, during a juju bootstrap on azure, it does apt-get aptitude but it never returns, any idea please?
<jose> d3lxa: can you explain a little bit more, please?
<d3lxa> jose: we are using trusty, juju 1.18.2-trusty-amd64
<jose> d3lxa: I mean, about the error
<d3lxa> when I do a juju debootstrap -e azure, where azure was correctly configured
<jose> debootstrap?
<d3lxa> jose: there is no error, I looked at the bootstrap logs but nothing expect debug and regular noise
<d3lxa> sorry bootstrap*
<jose> does 'juju status' show a bootstrapped environment?
<tvansteenburgh> jose: nyancat config-changed hook isn't symlinked
<d3lxa> jose: yes, it is even usuable as if nothing was wrong
<jose> d3lxa: can you go a little bit more in detail about what the *exact* error is?
<jose> tvansteenburgh: let me check
<d3lxa> but it is hanging somewhere
<jose> d3lxa: can you post some logs?
<jose> tvansteenburgh: good catch! thanks a lot!
<tvansteenburgh> jose: you bet - we both missed the obvious :P
<d3lxa> jose: cloud init output on the remote vm http://sprunge.us/BDYU
<jose> tvansteenburgh: I'm sure I also missed that one when I forgot bzr adding
<jose> d3lxa: checking now
<tvansteenburgh> jose: ah, yeah that makes sense
<jose> d3lxa: let's be honest, I don't find any errors there
<jose> it looks like everything's running smoothly
<d3lxa> jose: that's what I'm saying, there is no error but juju bootstrap hang
<jose> oh
<d3lxa> it never returns after printing "apt-get update"
<jose> can you paste the log of the terminal where you ran the bootstrap, please?
<d3lxa> so what I've done to bypass, is: to kill juju hardly with -9 or to just put it into backgrond (^Z) and live with that
<d3lxa> (kill the juju bootstrap of course, not jujud)
<d3lxa> but it wasn't doing this in the old version, so I guess this is a regression
<jose> d3lxa: ^
<d3lxa> sorry, doing it right now
<jose> np :)
<d3lxa> jose: http://sprunge.us/hVSC
<d3lxa> it was upgrade, my bad
<jose> you know what, let me go ahead, get that free azure credit and test for you :)
<d3lxa> jose: you have one and you can test? would be great thx
<jose> d3lxa: I'll be using their free trial, I'll test as soon as I get it
<jose> I'll let you know if I find something
<d3lxa> jose: great thx, in that case, will have to report?
<jose> d3lxa: yeah, if it repeats here then we'll report a bug
<jose> d3lxa: if you give me a moment I'll go ahead and test
<jose> I'm finishing to set up
<jose> d3lxa: question, still around?
<d3lxa> jose: so it doesn't hang on yours?
<jose> d3lxa: no, I have a question
<d3lxa> yes?
<jose> what should I put in storage-account-name? a random value?
 * jose has never used azure before
<d3lxa> jose: there is a quick guide https://juju.ubuntu.com/docs/config-azure.html very easy
<jose> blargh, that happens to me for not checking the docs
<jose> thanks!
<d3lxa> :)
<mattrae_> hi, i exported abundle from juju-gui.. 'juju bundle proof openstack-bundle.yaml' errors with 'FATAL: Not a bundle'
<mattrae_> is that supposed to work?
<jose> mattrae_: can you please pastebin the contents of the bundle?
<jose> tvansteenburgh: around?
<mattrae_> jose: here's the bundle http://pastebin.com/ED30UJKg
<jose> mattrae_: oh, I think you didn't export a bundle, but exported the environment itself
<jose> not sure if it's the same thing
<bac> hi mattrae_, the export is jus the yaml file.  to be an actual bundle you've got to put it in a directory
<mattrae_> jose: hmm the juju button in juju-gui says "export bundle"
<jose> there you go :)
<mattrae_> bac: ahh cool
<bac> in that dir you have the yaml file named bundles.yaml and you need a README
<mattrae_> sweet, i'll give that a try
<bac> mattrae_: you can look at some existing bundles to see examples
<mattrae_> cool i'll check out some existing bundles. thanks jose and bac
<bac> mattrae_: also, you'll need to rename 'envExport' in the yaml file to be a real name
<jose> guys, I'm having a problem when bootstrapping with azure
<jose> http://paste.ubuntu.com/7374531/
<d3lxa> jose: tried?
<jose> d3lxa: I get ^ when bootstrapping
<sarnold> jose: it might be a good idea to file a bug on that one, I dunno what your configuration looked like but it'd be nice if the parser were extended to handle it better than that :) hehe
<jose> sarnold: you mean, for the error I got?
<jose> with all that LP stuff?
<sarnold> jose: yeah
<jose> will do now :)
<jose> thanks!
<jose> d3lxa: I also recommend you file a bug against that problem, and if anyone else is able to replicate it we'll confirm
<jose> sorry for not being able to help right now
<jose> sarnold: do you by chance know if destroy-relation == remove-relation?
<sarnold> jose: no idea, sorry
<jose> np
<jose> d3lxa: hey, I'm bootstrapping on azure right now, will see if it presents the same error
<jose> d3lxa: I think I reproduced it. congratulations, you found a bug
<mattrae_> hmm following the 'juju quickstart bundles.yaml' example from the docs gives error 'unrecognized command; juju quickstart'.. is there a suggested way to deploy bundles?
<mattrae_> aha appears there is a juju-bundle command
<magicrobotmonkey> whats it mean when my node doesn't reboot after cloud-init?
<d3lxa> jose: ok, so I'll need to report the bug?
<magicrobotmonkey> I'm having a problem with the cinder charm. My block device isn't in /dev
<jose> d3lxa: yep, just go ahead
<tvansteenburgh> jose: don
<tvansteenburgh> don
<tvansteenburgh> dammit
<tvansteenburgh> don't forget to push that config-changed symlink
<jose> tvansteenburgh: yeah, will do, but looks like it doesn't fix the problem
<tvansteenburgh> :(
<jose> I'm going to grab lunch and check what's going on after that
<tvansteenburgh> kk
<jose> should be something pretty easy to fix
<jose> tvansteenburgh: symlink pushed anyways
<stokachu> is the password in the configuration for juju-gui the password for actually logging into the site?
<stokachu> or is it for the api
<lazyPower> stokachu: do you mean the admin-secret: value in environments.yaml?
<stokachu> lazyPower: yea i believe so
<stokachu> in local.jenv its just password:
<lazyPower> stokachu: its the password for the GUI
<stokachu> lazyPower: ok cool thanks!
<lazyPower> np
<stokachu> hmm doesn't seem to like that
#juju 2014-05-02
<jose> tvansteenburgh1: nyancat is fully working now (including those tests!)
<tvansteenburgh> jose: thanks! just saw the email, reviewing now
<jose> awesome, thanks!
<tvansteenburgh> jose: i've got some random package update error when running the tests and i'm running out of time today, so i may not get this finished until tomorrow - just fyi
<jose> tvansteenburgh: no worries, take your time :)
<tvansteenburgh> cool
<jose> (though that error should be on your side, because I'm not getting it)
<tvansteenburgh> jose: yeah i'm sure it's on my side, just need a little time to figure it out
<jose> np :)
<stokachu> so when you deploy services at what point can we set config options via juju set ?
<stokachu> do the services have to be in a started state?
<sarnold> stokachu: iirc you can set them near immediately after asking them to deploy
<stokachu> ok
<stokachu> the only way ive been able to get horizon+keystone to update its admin password is after horizon+keystone+mysql are started
<stokachu> everything is deployed but in various states
<Tug_> I tried to set source and key options for mongodb charm (which use charm-helpers) to install 10gen's package but I get an error at install because add-apt-repository also adds a deb-src line
<Tug_> (not sure I'm very clear here)
<Tug_> here is the output http://pastebin.com/1PbhhA3a
<bloodearnest> is there an easy way to log to the juju log from a cron job on a unit?
<themonk> marcoceppi: hi man
<themonk> hello everybody :) i have a question, in relation-changed of requirer charm I generate a file (schema file) now i want to send it to provider charm is it possible? (this 2 charms are independent charm)
<avoine> themonk: you could make a base64 of it and ship it in a variable I guess
<themonk> avoine: i know that technique but that is for config-chaged
<themonk> avoine: can i set config variable inside relation-changed?
<avoine> no you would use the relation-set command
<avoine> themonk: ^
<themonk> avoine: if that, then being inside of requirer charm how can i access provider config?
<avoine> themonk: you must send it using relation-set also
<themonk> avoine: hmm relation-set + base64
<avoine> themonk: see https://juju.ubuntu.com/docs/authors-hook-environment.html
<mattrae_> does some kind of flow chart for hook execution lifecycle exist? like something to visualize install -> config-changed -> start -> ... -> stop
<dimitern> mattrae_, the hook execution workflow is documented in juju-core/doc/charms-in-action.txt
<dimitern> mattrae_, but there's no chart/visualization afaik
<mattrae_> dimitern: awesome! thankyou :)
<brian515> can you use juju "manual" to bootstrap on your own laptop?
<jose> brian515: you use juju local for that
<brian515> @jose I know that.  But I don't want lxc on the server I want to use
<jose> oh, hmm
<jose> maybe? can you try?
<brian515> @jose I want to log into that machine, install juju-core, set for manual and point the configuration to that server's IP
<jose> brian515: you would need to just set it as bootstrap node
<jose> and then do juju bootstrap, juju deploy [charmname] --to 0
<brian515> @jose but when I do this and then execute juju bootstrap it asks for a password and no matter what password I enter it doesn't accept it
<jose> bootstrap will install everything necessary
<jose> it should be the password for the machine you're ssh'ing into
<brian515> @jose... I know it should be that machines password... but juju bootstrap does not accept that password  and I know the password is good... I use it to login via ssh
<jose> erm
<brian515> @jose... I'm stumped too <g>
<brian515> @jose - on that server there are only 2 accts.  ubuntu/ubuntu and one other and neither password is accepted
<jose> ubuntu/ubuntu?
<jose> the account should be just ubuntu
<brian515> @jose the original server acct is the default login ubuntu and password ubuntu
<jose> oh, gotcha
<brian515> @jose but juju bootstrap on that server when prompts for password - ubuntu isn't accepted
#juju 2014-05-03
<jose> new charm submitted! \o/
<marcoceppi> jose: \o/ yay new charm
<lazypower-travel> charms! \o/
<brian71> trying to get juju manual bootstrap to work.  edited environments.yaml to add IP of remote server where I have sudo access and can ssh to it but on local machine I do juju switch manual, then juju deploy and it keeps prompting for password???   doesn't accept any password I have on either machine and I am the only acct on both.   Any ideas?  Does Manual bootstrap work?
#juju 2014-05-04
<weoiru_jo> Hello there! Simple question: when I try to branch rabbitmq from bazzar, like sudo bzr branch lp:charms/rabbitmq rabbitmq
<weoiru_jo> always get: bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/charms/rabbitmq": no supported schemes
<weoiru_jo> (
<rick_h_> weoiru_jo: you need the series in there. How about bzr branch lp:charms/precise/rabbitmq ?
<rick_h_> oops, not it either, sec
<rick_h_> weoiru_jo: bzr branch lp:~charmers/charms/precise/rabbitmq-server/trunk
<weoiru_jo> well, from this wonderful page https://help.ubuntu.com/community/UbuntuCloudInfrastructure  it clearly says that there is rabbitmq-server and there is rabbitmq like in separate step, so im confused
<rick_h_> yea that is confusing how it does it both ways. I'm not sure if that's a bug in the docs or if I just don't know the short way here.
<weoiru_jo> i c, thanks mil!
<weoiru_jo> what about adding relationship between nova-compute and rabbitmq - it alwasy fails for me complaining on ambiguousity of some sort
<weoiru_jo> this particular line: juju add-relation nova-compute rabbitmq-server
<rick_h_> weoiru_jo: looking, normally it's because they support multiple relations and you need to specify the interface as well
<rick_h_> looks like they both can do either amqp or nova-compute:nrpe-external-master - rabbitmq-server:nrpe-external-master
<rick_h_> so you have to specify the amqp bit in the command
<weoiru_jo> and pardon my newbe-ness, how can i do that?
<rick_h_> weoiru_jo: so try juju add-relation nova-compute:amqp rabbitmq-server
<rick_h_> I work on the GUI so I know how to drag the line and need a cli refresher :)
<weoiru_jo> a miracle, it works!!!
<weoiru_jo> thanks a lot rick!!
<weoiru_jo> (i spent couple of days now trying to figure things out)
<rick_h_> weoiru_jo: yea, don't bang your head on a wall that hard. We're happy to help.
<rick_h_> there's notes in https://juju.ubuntu.com/docs/charms-relations.html#creating-relations
<rick_h_> that demo taht use case with mediawiki:db to mysql
<weoiru_jo> i was blindly trusting ubnutucloudinfrastructure  web page, checked it was updated mid april - so i couldn't believe it contains wrong info, so it felt like maybe i do something wrong
<rick_h_> wendar: yea sorry, I'm not as familiar with that doc. I tend to use the juju docs
<rick_h_> oops
<rick_h_> sorry, bad tab complete. He left the room
<jose> happens to everyone!
#juju 2015-04-27
<bbaqar> Hi guys. Just started writing an amulet test for my charms. Can't seam tp figure out how to deploy charms in LXCs from amulet and to deploy them to the same node.
<bbaqar> Hi guys. Just started writing an amulet test for my charms. Can't seam tp figure out how to deploy charms in LXCs from amulet and to deploy them to the same node.
<bbaqar> ??
<braderhart> bbaqar: were you able to find an answer or assistance?
<natefinch> rick_h_: you around?
<bbaqar> braderhart: I wasnt
<braderhart> is there a log for this channel?
<braderhart> bbaqar: i'm not part of the juju team nor familiar with this channel, but if you were not able to find an answer then i'd suggest that you open a ticket or post in ask ubuntu. it's also possible someone will see your question and respond at a later time.
<bbaqar> I did post a question on askubuntu. waiting for answers.
<haces> http://sentimentalcorp.org/eyes_of_randy_prozac/mentally_murdered.html
#juju 2015-04-28
<rogpeppe2> jog: hiya
<jcastro_> marcoceppi, http://askubuntu.com/q/614067/235
<jcastro> https://askubuntu.com/questions/611564/how-does-juju-get-the-private-address-of-a-node
<jcastro> any help here would be appreciated!
<mwak> Hi, Is it possible to add node app charm for trusty?
<jrwren> mwak: yes. Also consider making a charm for your app. The ghost charm is a good example of a node app.
<anacapa> hi folks, get problems while bootstrap JUJU
<anacapa> the error msg is: WARNING juju.replicaset replicaset.go:93 Initiate: fetching replication status failed
<anacapa> JUJU version: 1.22.1-trusty-amd64
<anacapa> 2015-04-28 16:55:54 WARNING juju.replicaset replicaset.go:93 Initiate: fetching replication status failed: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)
<anacapa> any suggestions? thx a lot
<plars> Is the version of juju-deployer in ppa:juju/stable compatible with newer versions of juju? I'm hitting an error when I try to run juju-deployer: http://paste.ubuntu.com/10929342/
<plars> juju: 1.20.11-0ubuntu0.14.04.1
<plars> juju-deployer: 0.4.3-0ubuntu1~ubuntu14.04.1~ppa1
<rick_h_> plars: try to install the python-jujuclient first? v 0.50 is in the ppa
<rick_h_> plars: sudo apt-get install python-jujuclient and then try the deployer again?
<plars> rick_h_: at some point in the past, it all used to work from this machine. I have things deployed already, but it's not one I have total control over, so I think landscape may have upgraded some things underneath me
<plars> python-jujuclient: 0.17.5-0ubuntu2
<plars> rick_h_: ^
<plars> rick_h_: which also seems to be the newest
<rick_h_> plars: right, but https://launchpad.net/~juju/+archive/ubuntu/stable
<rick_h_> plars: oh hmm, what version are you on?
<rick_h_> plars: python-jujuclient 0.50.1-2
<rick_h_> plars: what distro version that is?
<plars> rick_h_: 14.04.2
<plars> rick_h_: at some point in the past, we needed a newer juju-deployer but wanted to stick to an older juju version (I thought we had 1.18, but unfortunately it may have been upgraded). I know things worked after that, but when I tried to update our deployment with a current copy of the yaml file, it gave me that pastebinned error
<rick_h_> plars: right, well what you're hitting is that you've got a deployer looking for the 0.50 jujuclient lib
<rick_h_> plars: nothing to do with juju version tbh
<plars> strange that it would now start looking for that?
<rick_h_> plars: well if the deployer upgraded but the python-jujuclient didn't it might cause that
<rick_h_> plars:  ~/bin/tmux_split_custom -v
<rick_h_> whoops
<rick_h_> plars: so curious if you can upgrade the python-jujuclient package on your system at all
<plars> I'm certain that it worked with this version of juju-deployer in the past, and I can't envision how jujuclient may have been downgraded
<plars> rick_h_: I can't personally, but I can ask for it
<rick_h_> plars: sorry, no idea about the history of it but just telling you the error in that traceback is the deployer python looking for the python-jujuclient python lib > 0.18 (which is the 0.50.1
<plars> rick_h_: ack, thanks!
<f2> does mramm hang out in #juju on occasion?
<f2> jamespage: congrats on your prompt shipping of 0.94.1 â I was thrilled to see it in 15.04
#juju 2015-04-29
<lazyPower> stub: http://bazaar.launchpad.net/~lazypower/charms/bundles/sentiment-analysis/bundle/view/head:/bundles.yaml
<jcastro_> tvansteenburgh, can we kick off tests for this? http://review.juju.solutions/review/1087
<jcastro_> I tried to click the button but it didn't do anything for me
<jcastro_> robert would like to test his latest pushes
<tvansteenburgh> jcastro: kicked
<jcastro_> bcsaller, https://askubuntu.com/questions/611564/how-does-juju-get-the-private-address-of-a-node
<mbruzek> jamespage Please send me a link to the actions document.
<Bardhi> Hello everyone. I am new with juju and maas and im trying to get that installed and running in our company. I managed to get installed maas and juju, but when i want to deploy a service with juju it gets stucked in "allocating units" and it doesnt advance from there. It remains yellow it doesnt become green. If someone could help me how to solve this i wold appreciate it. Thank you
<mwak> hi
<ludvigx> anyone got a sec to help me out ? Trying to deploy the latests trusty/ceph-36 via juju, and it returns a agent-state-info: 'hook failed: "mon-relation-changed"' every single time.
<ludvigx> or is this more just a ceph related question ? not sure :)
<lazyPower> cory_fu: another fyi re: sync-watch - i'm getting consistent errors when watching subordinates
<lazyPower> https://github.com/juju/plugins/issues/56
<Bardhi|2> ello i am trying to deploy some services with juju but it gets stucked on allocating units and services are not deployed. i just started using juju and i am not an expert in using it and i dont know very well how it all works but i
<g3naro> hello! is anyone here able to help noob
<g3naro> root@falcon:~/.juju# juju deploy apache
<g3naro> ERROR environment is not bootstrapped
<hazmat> lazyPower: any presentation deck you recommend for giving a presentation on juju?
<lazyPower> hazmat: i do, 1 sec
<lazyPower> do you want the raw deck, pdf, or speakerdeck link?
<lazyPower> hazmat: https://speakerdeck.com/chuckbutler/service-orchestration-with-juju
<hazmat> lazyPower: looking, thanks
<hazmat> lazyPower: that looks solid, thanks
<hazmat> i'm giving a presentation on juju in a few hrs, and my decks are moldy ;-)
<lazyPower> :) want the .odp file to make tweaks?
<hazmat> lazyPower: that would be great
<lazyPower> hazmat: the biggest change is juju is the modelling language, and not "the orchestrator" - we're enabling orchestration through the language model
<lazyPower> https://www.dropbox.com/s/cvh31c2vrjbsrgm/service-orchestration.odp?dl=0
<lazyPower> hazmat: ^
<hazmat> g3naro: you have to bootstrap an environment before deploying
<hazmat> lazyPower: that distinction seems subtle, so juju is not an orchestrator but a language runtime for orchestrator?
<lazyPower> yeah, basically its a universal language to describe your infra as SOA
<cory_fu> lazyPower: You and your damned subordinates.  ;)  Thanks for opening the issue
<lazyPower> :3
<cory_fu> marcoceppi: Where was that tool you showed for rendering a bundle svg?
<marcoceppi> cory_fu: svg.juju.solutions
<cory_fu> Hrm.  No form?  How do you post the bundle?
<lazyPower> (Û¶à« áµÌ ÐáµÌ)Û¶à«=ÍÍÍÍ â¨  GIVE US THE KNOWLEDGE MARCO
<marcoceppi> cory_fu: read the instructions?
<cory_fu> It says post, but there's no form to post
<cory_fu> What am I, a wizard?
<marcoceppi> yes, use HTTP to post to it
<marcoceppi> or http://svg.juju.solutions/?bundle-file=http://bazaar.launchpad.net/~bigdata-dev/charms/trusty/apache-analytics-sql-hue/trunk/download/head:/bundles.yaml-20150420030716-vycsb0pcenhst8wt-1/bundles.yaml
<marcoceppi> cory_fu: I thought you knew kung fu
<marcoceppi> cory_fu: or http://svg.juju.solutions/?bundle=cs:bundle/openstack-telemetry-31
<marcoceppi> https://github.com/marcoceppi/svg.juju.solutions
<marcoceppi> no instructions, sorry, forgot I didn't write them yet
<marcoceppi> still a WIP
<cory_fu> Fair enough
<marcoceppi> cory_fu: I'll be adding caching and faster processing (plus embedding SVG so it downloads more cleanly) soon
<rogpeppe> jam: hiya
<jam> rogpeppe: /wave
<rogpeppe> jam: just wanted to give you a head's up regarding some changes we intend to make to the juju/charm repo
<jam> sure, what's up?
<rogpeppe> jam: we've had some cyclic dependency issues between the charm repo and charmstore
<rogpeppe> jam: i made a little doc to explain things to ourselves: https://docs.google.com/document/d/10Ol5g2T688fih2wBTDk6ZO5h2I8dXjVI3hWTSpMaUew/edit
<rogpeppe> jam: after some discussion, we've decided that solution 3 is the best way forward
<rogpeppe> jam: YMMV so any feedback would be good
<rogpeppe> jam: essentially this means moving the charmrepo package into a new repository. for juju-core, the implication should just be a simple import path rewrite with no other code changes required
<jam> rogpeppe: what is "publicly depends on" vs "depends on" ?
<jam> (it has a public API that uses a type defined in the other repo?)
<rogpeppe> jam: yes
<rogpeppe> jam: you said it much more neatly than i was trying to :)
<rogpeppe> jam: this is also a possible precedent for a pattern that we might use more generally and eventually something that might be worthwhile for juju-core to use (so that juju Go clients don't have to incur all juju-core's dependencies)
<jam> rogpeppe: so I'd like to understand why cycles in tests is ok
<jam> because you have to set up the underlying objects to test against?
<rogpeppe> jam: because it's possible to make forward progress even when there are cycles in tests
<rogpeppe> jam: in the worst case, you might need to temporarily disable some tests
<rogpeppe> jam: whereas in the situation we were in (with cycles in exported APIs) we literally couldn't make forward progress without some really nasty hackery (including charm.v6 needing to import charm.v5 in tests)
<jam> rogpeppe: so its not *actually* possible to upgrade a version and have all the tests pass
<rogpeppe> jam: it should be in most cases
<rogpeppe> jam: you'll end up with the tests importing two versions of the package, but that is usually ok
<jam> So charmstore is the actual server internals code, csclient is a consumer of the public API, what is charmrepo ?
<jam> "charm" is the core data structure, right?
<rogpeppe> jam: charmrepo is the API that juju uses, that layers onto csclient
<rogpeppe> jam: yeah
<rogpeppe> jam: charmrepo implements local repository handling too
<jam> and params is shared implementation of types exported and imported between the server and clients?
<rogpeppe> jam: charmrepo already exists, BTW: http://godoc.org/gopkg.in/juju/charm.v5/charmrepo
<rogpeppe> jam: yes
<rogpeppe> jam: similar to juju-core's params package
<rogpeppe> jam: ha, this probably isn't the right channel for this discussion - i had intended #juju-dev
<philip_stoev> Hello, how does one deploy a charm using uncommitted changes in a local bzr repository?
<philip_stoev> I am using this command:
<philip_stoev>  juju deploy --repository=. --config galera.yaml local:trusty/galera-cluster
<philip_stoev> and the charm being deployed does not contain the local uncommitted changes
<rogpeppe> philip_stoev: AFAIK the juju deploy command doesn't know about the bzr repo at all
<rogpeppe> philip_stoev: so it should just see all the files as they are (including uncommitted changes)
<rogpeppe> philip_stoev: what does it do if you try to deploy the charm when there's no .bzr directory at all (for instance, move it out of the way or make a copy of the charm dir without it) ?
<rogpeppe> philip_stoev: it's possible that this is an existing bug with juju deploy with respect to local charms actually
<rogpeppe> philip_stoev: have you already previously deployed that charm to the environment?
<philip_stoev> I found out that it is safer to destroy the environment every time. Otherwise it seems I am always getting a cached version of the charm
<philip_stoev> Actually committing to the local repository did not help
<philip_stoev> so, with a fresh environment
<philip_stoev> I am still getting files from the Charm Store
<philip_stoev> Even though I provided  --repository=. local:trusty/galera-cluster to juju deploy
<philip_stoev> Does juju have some local cache that I need to purge?
<philip_stoev> I have no ~/.juju/charmcache on the local machine
<philip_stoev> --upgrade has been deprecated
<philip_stoev> so what is left apart from committing every revision to the charm store?
<rogpeppe> philip_stoev: i think the problem is the revision number of the local charm
<rogpeppe> philip_stoev: i encountered this problem with gocharm, and worked around it
<philip_stoev> I think I got what the problem is, for some reason I had multiple copies of the charm locally, so --repository=. was picking the wrong directory
<rogpeppe> philip_stoev: if you create a "revision" file and increase the revision number in it each time, it may fix your issue
<philip_stoev> thanks
<rogpeppe> philip_stoev: ah, that can also be a problem
<rogpeppe> philip_stoev: the local repository logic is weird
<rogpeppe> philip_stoev: it ignores the name of the directory and just looks at the charm name in the metadata.yaml
<rogpeppe> philip_stoev: and then takes the one with the highest revision, or the last alphabetically by directory name
<philip_stoev> I was able to make it pick up the right files ...
<philip_stoev> so I am good
<rogpeppe> philip_stoev: cool
<philip_stoev> thanks for the help
<philip_stoev> I have a more conceptual question regarding Juju
<philip_stoev> Assuming I have started a service, e.g. MySQL , is it a strict juju requirement for other services to connect to it only through juju relations and interfaces?
<philip_stoev> If not, then it seems it is difficult for the user to simply obtain the IP of the service and then use that IP as needed
<philip_stoev> juju status seems to be the easiest way
<philip_stoev> as it is difficult to have juju create a database and spit out the complete connection URL
<philip_stoev> unlesss relations are used
<lukasa_work> Is there any way I can force Juju to run a hook?
<lukasa_work> neutron-api seems to have rendered an incorrect neutron.conf, and I'd like it to re-render
<cory_fu> lukasa_work: Easiest way would be to change and reset a config value.  If you don't want to do that, you *might* be able to manually run the config-changed hook using `juju run`
<cory_fu> But I'm not at all certain that won't cause you more issues
<cory_fu> It depends heavily on how the charm is implemented.
<plars> So I got python-jujuclient upgraded and now juju-deployer tries to run at least, but I'm hitting this now. Any ideas?
<plars> https://www.irccloud.com/pastebin/VUvzEJIo
<g3naro> juju deploy apache
<g3naro> ERROR cannot resolve charm URL: "cs:apache"
<g3naro> any ideas?
<lukasa_work> The charm is called apache2. =)
<g3naro> ohhh
<g3naro> :D
<g3naro> what what!! first lxc-local deployed
<jcastro_> g3naro, \o/
<g3naro> but what is the defualt user/pass :(
<roadmr> g3naro: use juju authorised-keys to add an ssh key to your containers, then you can ssh into them, no need to use user/password
<roadmr> g3naro: https://jujucharms.com/docs/stable/howto-authorised-keys
<g3naro> roadmr, thanks! looking now
<g3naro> i found in .juju/environments/local.jenv
<g3naro> it has correct ssh key but still giving me denied
<roadmr> g3naro: how are you doing ssh into the container?
<g3naro> ssh -i ssh -i juju_id_rsa.pub juju@10.0.3.167
<g3naro> also without the juju@
<g3naro> anhd without .pub of course
<g3naro> ssh -i juju_id_rsa 10.0.3.167
<g3naro> ohh its ubuntu@
<g3naro> what hwat :D
<jrwren> juju ssh is your friend :)
<g3naro> juju ssh ?
<g3naro> oh leet
<g3naro> is anyone running juju for prod
<stub> tvansteenburgh: I will need to add Adam's actions in a separate branch, as it needs to be taught how to connect to a cluster with authentication enabled.
<tvansteenburgh> stub: ack
<Aligner> Hi, if I upgrade charms with juju upgrade-charm, do I need to redeploy everything for the upgraded version to take affect?  I am trying to upgrade some charms but I can't tell if the applications are newer version
#juju 2015-04-30
<tvansteenburgh> niedbalski: where's your repo for converting juju status to a bundle?
<tvansteenburgh> niedbalski: nevermind, i found it
<g3naro> yo yo yo
<lazyPower> g3naro: to answer your question re: is anyone running juju for prod - lots of people
<lazyPower> g3naro: anyone that stands up ubuntu openstack is using juju under the covers + there are lots of orgs that use juju to model their infra on top of our openstack, and public cloud integration (not to mention the ones that are hard to measure as they reside behind corp firewalls)
<bmoosefh> Hi, I have a setup question for a juju environment I'm working on. Is it ok to ask here?
<bmoosefh> Perhaps this isn't the right venue for user questions?
<bmoosefh> I'll just ask anyway, and if anyone could help I'd be very grateful
<bmoosefh> I've bootstrapped juju onto a multihomed server
<bmoosefh> in a maas environment
<bmoosefh> and I'm having trouble understanding how the master node is chosing the ip it advertises as the api end point
<bmoosefh> it's not chosen the one that was specified in the bootstrap
<bmoosefh> this has the effect of meaning I can't deploy LXC hosted services
<bmoosefh> as the LXC instances are only bridging on to the management network, which was also the network I'd accessed the master over during bootstrap
<bmoosefh> specifically the cloud-init rtask can't fetch the juju-tools tar as it's trying to connect on the wrong IP
<jrwren> bmoosefh: please post that question on askubuntu.com
<bmoosefh> ok
<jrwren> please include juju version and a bit more detail about the network configuration
<jrwren> oh, and the provider. looks like manual provider?
<bmoosefh> maas in this case
<bmoosefh> I'll write it up on askubuntu
<jrwren> you might also ask in #maas
<bmoosefh> thanks
#juju 2015-05-01
<bradm> what am I doing wrong here?  I've submitted https://code.launchpad.net/~brad-marshall/charms/trusty/nagios/add-livestatus-support/+merge/257992 over an hour ago, but its not showing up on http://charmproof.com/.
<aisrael> bradm: It may just be an ingestion delay. marcoceppi_ can give it a kick
<redelmann> Hi, where i can found more info about "juju user"?.
<bilalbaqar> How can I set a tag on a node with multiple nics in maas?
<bilalbaqar> Any one there?
#juju 2016-05-02
<pmatulis> NAME     OWNER        STATUS     LAST CONNECTION
<pmatulis> admin*   admin@local  available  2016-04-28
<pmatulis> default  admin@local  available  2016-04-28
<admcleod1> is it possible to get model and controller name from inside a unit?
<stub> tvansteenburgh: Others have seen that too. Looks like there is a race condition buried in there that I can't see. I'll need a set of logs to trawl through to track it down.
<rick_h_> admcleod1: no, you can from the client, but things like controller name are client defined and it's all UUIDs in the other end.
<bwallis> Hey, anyone noticing a massive slowdown on launchpad/most canonical hosted sites?
<bwallis> Messing around with a juju deployment, and grabbing the tools for the initial bootstrap is taking a crazy amount of time
<bwallis> Doing manual wgets is really slow too, 15-20KB/s
<blr_> bwallis: well, glad I'm not the only one. Looking into it.
<bwallis> yea I've been going nuts trying to figure this out all afternoon, never thought slow responses from the tools host was causing it
<bwallis> if there's a mirror somewhere let me know :), I don't think there is though
<blr_> bwallis: out of interest, what country are you in?
<bwallis> US
<bwallis> CA specifically
<bwallis> I got around apt issues by just using other mirrors, but as far as I know there's no mirror of streams.canonical.com or launchpad
<bwallis> Which sucks, bootstraps just sit here all day:
<bwallis> 2016-05-01 22:59:59 DEBUG juju.environs.simplestreams simplestreams.go:674 using default candidate for content id "com.ubuntu.juju:devel:tools" are {20160220 mirrors:1.0 content-download streams/v1/cpc-mirrors.sjson []}
<bwallis> Wow, something just happened?
<bwallis> A bootstrap completed
<jose> \o/ let us know if you need any more help
<bwallis> will do, still seems to be slow, but it sped up enough to deploy one machine
<bwallis> going to see how it goes with others
<bwallis> spoke too soon I think :( failed to download the agent tools
<Sharan> i have created one dummy charm and deployed but this charm is going in a error state
<Sharan> its showing "Waiting for agent initialization to finish"
<Sharan> model: default machines:   "0":     juju-status:       current: error       message: no matching tools available       since: 02 May 2016 11:41:21+05:30     instance-id: pending     machine-status:       current: pending       since: 02 May 2016 11:41:07+05:30     series: trusty services:   testcharm:     charm: local:trusty/testcharm-0     exposed: false     service-status:       current: unknown       message: Waiting for agent initia
<bwallis> is there a reason the juju "controller" doesn't appear as a machine to deploy services on in a MaaS deployment now?
<bwallis> this is with beta6
<sharan> juju1.25 version, we used to get the log files in the path "/var/log/juju/unit-testcharm-0.log", but in juju2.0 version where do we find these log files?
<magicaltrout> same place sharan
<sharan> i didn't get, i have only "/var/log" after that there is no "juju" folder instead i found "lxd" folder
<magicaltrout> dunno but all my charms log to the same place in v2 as v
<magicaltrout> 1
<sharan> ok i have installed juju2.0 on Z-machine
<sharan> so i was trying to find the log files
<sharan> if i get into the "/var/log/lxd/juju-a938c2eb-4141-4a2d-89b6-71a20fa0d296-machine-3" i will get "forkstart.log,  lxc.conf,  lxc.log" files
<icey> is it possible to get the postgresql charm to install postgres 9.5?
<marcoceppi> icey: it might be, stub would know
<marcoceppi> icey: if you deploy on xenial
<icey> marcoceppi: I was poking around with it, but it looks like it's explicitly setting supported as <= 9.4
<icey> and marcoceppi, I just raised a bug about it not deploying on xenial :)
<marcoceppi> oic
<shruthima> hi all, I have pushed the IBM-IM charm to the store, with a new charm publish commands, but how to attach the bug .....?!!!!
<shruthima> Before pushing in this new way i have pushed into lanchpad and raised a bug (https://bugs.launchpad.net/charms/+bug/1575746) and linked to trunk branch. Do i need to change it ?
<mup> Bug #1575746: New Charm: IBM Installation Manager <Juju Charms Collection:New> <https://launchpad.net/bugs/1575746>
<shruthima> yes 1575746 is the bug i have created for IBM-IM ,but that bug i have linked to trunk branch ..!!!do i need to link it to cs:~ibmcharmers/trusty/ibm-im-0...??
<shruthima> I have done some alignment changes to Readme to IBM-IM ...Now what is the process to merge this changes in to IBM-IM charm in charm store???
<shruthima> please can anyone suggest on the same??
<shruthima> hi kwmonroe/Mbruzek, I have done some alignment changes to Readme in IBM-IM ...Now what is the process to merge this changes in to IBM-IM charm in charm store???
<mbruzek> Hello shruthima you can follow these instructions: https://jujucharms.com/docs/stable/authors-charm-store#submitting-a-fix-to-an-existing-charm
<magicaltrout> not enough question marks shruthima! ;)
<mbruzek> Basically fix this readme in a branch and submit a merge proposal to get it added to the review queue.
<shruthima> ok and I have pushed the IBM_IM charm to the store, with a new charm publish commands, but how to attach the bug here.....!!!! Before pushing in this new way i have pushed into lanchpad and raised a bug (https://bugs.launchpad.net/charms/+bug/1575746) and linked to trunk branch. Do i need to change it ?
<mup> Bug #1575746: New Charm: IBM Installation Manager <Juju Charms Collection:New> <https://launchpad.net/bugs/1575746>
<mbruzek> Oh I see you are using the new process
<mbruzek> That is great, let me check this link out
<shruthima> ok
<mbruzek> shruthima: So you have some changes to the README.md file you would like to make?
<shruthima> yes i have some alignment changes
<mbruzek> shruthima: I didn't know you were using the new way before, so I gave you the wrong link: https://jujucharms.com/docs/devel/authors-charm-store#submitting-a-new-charm
<mbruzek> You should be able to `charm push` those changes into the ibm-im charm in the store.
<mbruzek> the result from that command will likely be ibm-im-1 rather than zero.  I already see the ibm-im charm in the review queue, because you filed a bug. So everything seems correct. You can change the charm code as much as you like before the review.
<shruthima> hmm thats fine ,actually i had a doubt if we push again with charm push command will it merge with the old one..
<mbruzek> After you push another version up, you should update the bug  with something like this: "please review ibm-im-#" where # is the revision you want reviewed.
<shruthima> ok u mean bug description?
<shruthima> mbruzek: ok u mean to update bug description ?
<mbruzek> Or just add a comment, which ever is easier
<shruthima> mbruzek : ok so new process is only to reflect in charm store ...next to raise a bug and link to trunk branch we need to follow the same old process is it ..?
<mbruzek> shruthima: Yes, we have been working hard on the new process and review queue, but those changes have not been released.
<mbruzek> shruthima: so for now we need to use the bug to track this change so it can be reviewed.
<shruthima> mbruzek : ok thank you for the information :)
<mbruzek> shruthima: Yes and thanks for asking these questions in #juju, I am sure the questions are useful for other people in this room
<shruthima> hmmm :)
<mbruzek> Does anyone know how to get to the controller machine in juju 2.0.beta ?
<mbruzek> One of my machines failed to provision and has no ip address. I want to get the logs from the controller to add to the bug.
<mbruzek> but I don't know how to refer to the controller with juju commands.
<aisrael> mbruzek: Also wondering about that. I've only found logs once a machine has been created. Before that, debug-log has nothing.
<mbruzek> aisrael: Yeah this machine is *not* being created and I don't know why.
<LiftedKilt> mbruzek: juju switch admin; juju ssh 0 ?
<mbruzek> LiftedKilt: yes that works, thank you for the information.
<mbruzek> We should add that to a document somewhere. aisrael do you have a suggested location?
<aisrael> Ohh, good find LiftedKilt.
<aisrael> mbruzek: https://jujucharms.com/docs/master/developer-debugging
<aisrael> mbruzek: Do you want to open a bug against docs, or should I?
<mbruzek> aisrael: I will do that, and create the text which you can review
<LiftedKilt> mbruzek: yeah it's a little obtuse that machine 0 is hidden in the admin model - you intuitively expect juju machine to show all the machines, but it shows the machines in the selected model.
<aisrael> mbruzek: ack
<mbruzek> LiftedKilt: It makes sense to me now you explained it to me.
<mbruzek> LiftedKilt: thank you for sharing that information with me
<LiftedKilt> mbruzek: for sure
<jcastro> http://askubuntu.com/questions/755885/is-there-a-way-to-adjust-the-interval-for-the-update-status-hook
<jcastro> any help on this one?
<mbruzek> aisrael: Please review my addition: https://github.com/juju/docs/pull/1061
<DavidRama> oue omw
<DavidRama> oups sorry
<jcastro> bdx: any word from the devopsdays pdx people on if your talk was accepted?
<natefinch> anyone online who knows about the deployer code?  Seems there's an incompatibility with some TLS changes I made in core last week
<tvansteenburgh> natefinch: are you talking about the juju-deployer python project, or the new golang deployer code?
<natefinch> tvansteenburgh: python
<tvansteenburgh> natefinch: i'm one of the maintainers
<natefinch> tvansteenburgh: I changed juju-core to only support TLS 1.2 last week... looks like CI found an incompatibility with deployer: http://reports.vapour.ws/releases/3938/job/maas-1_9-deployer-2x/attempt/49#highlight
<tvansteenburgh> natefinch: okay, i'll take a look soonish
<tvansteenburgh> dpb: fyi ^
<natefinch> tvansteenburgh: thanks, let me know if there's anything I can do to help... the bug is here: https://bugs.launchpad.net/juju-core/+bug/1576695
<mup> Bug #1576695: Deployer cannot talk to Juju2 (on maas2) because :tlsv1 alert protocol version <ci> <deployer> <maas-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1576695>
<tvansteenburgh> dpb1_: ^
<tvansteenburgh> natefinch: cool, thanks
<lazyPower> tvansteenburgh - do we have a shorter method to determine which unit is a leader in an amulet test, than sentry.run() in a loop?
<tvansteenburgh> lazyPower: nope
<lazyPower> cool, should i add that under some "common use cases" for the amulet docs?
<tvansteenburgh> lazyPower: either that, or file a bug and we can add a get_leader(service) or something
<lazyPower> sounds good to me
<lazyPower> https://github.com/juju/amulet/issues/131
<bwallis> anyone still experiencing really slow speeds to launchpad/most US hosted ubuntu sites?
<bwallis> was happening last night as well
<suchvenu> Hi
<suchvenu> I am getting the following error when I did,  juju destroy-environment local
<suchvenu> ERROR cannot connect to API: unable to connect to "wss://10.0.3.1:17070/environment/c9759ee0-88cc-403d-8b6c-aa4e628bf17d/api"
<suchvenu> Any idea on thsi error ?
<LiftedKilt> the openstack-lxd bundle on xenial leaves ceph broken - all the pgs are stuck in creation
<LiftedKilt> has anyone worked with that or found a fix? It works on trusty, so it must be a xenial quirk
<lazyPower> suchvenu - which juju version?
<suchvenu> 1.25
<suchvenu> Ubuntu Trusty version
<lazyPower> suchvenu - sudo lxc-ls --fancy, do you see any lxc containers listed?
<lazyPower> oo local provider, hang on there's a service you should have running not a container
<suchvenu> charm@islrpbeixv665:~/charms/trusty/ibm-db2$ sudo lxc-ls --fancy [sudo] password for charm: NAME                       STATE    IPV4  IPV6  AUTOSTART --------------------------------------------------------- juju-precise-lxc-template  STOPPED  -     -     NO juju-trusty-lxc-template   STOPPED  -     -     NO charm@islrpbeixv665:~/charms/trusty/ibm-db2$
<lazyPower> suchvenu - sorry that was a redherring. Its been a moment since i've used the local provider on 1.25
<lazyPower> suchvenu - can you pastebin the output of initctl list for me?
<suchvenu> http://pastebin.ubuntu.com/16194903/
<lazyPower> suchvenu - juju destroy-environment -y --force local
<lazyPower> suchvenu - as you were trying ot remove it, this will clean up the stale configuration files, and you can re-bootstrap afterwords
<lazyPower> i didn't see the upstart job listed for the local environment, so i think it just didn't complete the job of cleaning up after itself from a prior juju destroy-environment.
<suchvenu> ok
<tvansteenburgh> stub: https://bugs.launchpad.net/postgresql-charm/+bug/1577544 fyi
<mup> Bug #1577544: Connection info published on relation before pg_hba.conf updated/reloaded <PostgreSQL Charm:New> <https://launchpad.net/bugs/1577544>
<thedac> gnuoy: See my last comment on https://review.openstack.org/#/c/308070/ and consider a +2
<pacavaca> hey guys! when I'm doploying something (openstack) using juju, each machine gets several lxc containers and one called juju-xenial-template (smth like this). I noticed that this template container already has some predefined configuration for my NICs (eth0 and eth1). In particular, it assigns static IPs on one of them and I don't want that. How do I change this template (for all nodes), so that IPs are
<pacavaca> always assigned by DHCP?
<cory_fu> kwmonroe: You got a PR for that layer-basic change?
<kwmonroe> i do not cory_fu.  i'm not sure it's good. http://paste.ubuntu.com/16196042/  do i need to pip install requirements.txt?  should i activate vs including PATH extensions?  is there potential conflict with .venv for other charms (ie, should i call it .venv-newer-tox)?
<magicaltrout> kwmonroe: you in for the full conference or just flying in and out?
<kwmonroe> magicaltrout: i'm in it for the long haul.  Sun-Thu.
<cory_fu> You don't need to pip install requirements, because tox will handle that.  However, since it's currently doing a sudo pip install, why not just stick with that?
<magicaltrout> nice
<magicaltrout> they speak funny in canada
<kwmonroe> i'll learn 'em
<magicaltrout> hehe
<kwmonroe> cory_fu: not sure what you mean by "why not just stick with that".
<cory_fu> kwmonroe: http://pastebin.ubuntu.com/16196470/
<cory_fu> kwmonroe: https://github.com/juju-solutions/layer-basic/pull/66
 * magicaltrout writes some slides
<magicaltrout> better late than never
<kwmonroe> cory_fu: marcoceppi:  quick tox fix for charmbox: https://github.com/juju-solutions/charmbox/pull/33/files
<kwmonroe> this moves the tox fix to cb instead of layer-basic's Makefile since you guys are in such violent disagreement over cory's pull 66
<marcoceppi> kwmonroe cory_fu I'd prefer this, I've honestly put tox in a venv that I activate when i do charm testing stuff, this fixes it where you need it, but we still need to consolidate charm test for charm 2.2 to be docker/lxd ootb
<cory_fu> marcoceppi: Why isn't it using charmbox?  That's what we've standardized on for all of our CI infra
<marcoceppi> cory_fu: because, time.
<marcoceppi> cory_fu: also, the openstack engeineers depend on the old test runner
<marcoceppi> we need to get them onto bundletester, then get charm test to just boot the charmbox container and run tests
<admcleod1> is there any way to get info about a unit, from within another unit, without a relation to it
<marcoceppi> admcleod1: no, not really
<marcoceppi> admcleod1: charms only know about what they are connected to, implicit querying of other services would lead to a disaster of having toplogies that require other services but without an explicit relation for the operator to know they're logically connected
<cory_fu> admcleod1: juju run service/0 'unit-get private-address'
<admcleod1> cory_fu: from with another unit though
<admcleod1> marcoceppi: right
<cory_fu> admcleod1: But what you really want to do is make sure you expose the namenode and make sure that the namenode is listening on all addresses and then it should work
<cory_fu> admcleod1: With a relation.  For the dfs-copy action, we should make it work with the public address
<admcleod1> cory_fu: there is that, but will trying to copy data over the public address be an issue with some installations?
<admcleod1> s/address/interface
<cory_fu> It should work, too, we're probably just missing one of: listen on all addresses (0.0.0.0), open-port on the correct port, juju expose namenode
<cory_fu> Yes, it's not ideal, but you don't really have any choice if one of the namenodes is not juju deployed.  For two juju deployed services, we'd want the relation, like we discussed
<admcleod1> yeah true
<cory_fu> Anyway, I have to EOD
<admcleod1> cya
<magicaltrout> cory_fu's mrs has him tied around her little finger.....
<magicaltrout> oh no, he's just sensible and doesn't work 18 hour days
<kwmonroe> admcleod1: if you're going to adjust apache-hadoop-namenode to listen on all interfaces, you can do something like i did for bigtop recently: https://github.com/juju-solutions/layer-apache-bigtop-namenode/commit/ac0c472707e1f48ccbf416f1c1eb2e189b6bd8e9
<admcleod1> kwmonroe: i guess ill have to, seems a bit dodgy though
<admcleod1> kwmonroe: maybe an action to do it temporarily?
<kwmonroe> admcleod1: make it less dodge by creating a new dist.yaml port called "dfs-copy" that's "exposed_on: totally_dodgie", then make the action expose "totally_dodgie", do the copy, then unexpose it.
<admcleod1> heh
<admcleod1> kwmoroe: yeah but more because its listening on all interfaces
<admcleod1> kwmonroe: ^
<kwmonroe> oh, i don't think it's too spookie to listen on all interfaces.  any when we migrate services to hosts with different IPs, it's nice to not have to reconfigure.
<admcleod1> kwmonroe: i know a few network admins who might disagree.. but ok lets do it! :}
#juju 2016-05-03
<icey> how should one implement a peer relation in an interface layer / layered charm?
<marcoceppi> icey: create a peer.py file in the interface
<icey> marcoceppi: yeah, I found that, I'm grasping at straws here because I'm getting a nice build error (charmtools.build.tactics: Missing implementation for interface role: provides.py) and I'm working on adding several interfaces (and writing those) at the same time, they all seem to be correct but for this build error -_-
<icey> I'll just keep digging :)
<marcoceppi> icey: link to your interface?
<icey> marcoceppi: it's not up yet, but I think it may be fixed in charmtools 2.1.3
<icey> I popped it into charmbox and I can build it there -_-
<marcoceppi> icey: 2.1.3 is in pypi, we're working on getting a package built
<icey> eta for package on xenial? doesn't kill me to use it in charmbox for now but nice to know what to expect :)
<cory_fu> icey: Make sure that the relation is listed under "peers" in the metadata.yaml.  That error sounds like it's listed under "provides"
<icey> cory_fu: I have 3 provides relations, and a peer relation
<icey> and none of them are existing interfaces
<icey> it was one of the provides having the problem, if I removed it from the layer.yaml, it worked
<icey> and it worksd with the new charmtools
<cory_fu> icey: Also, if it's helpful, you can see an example of a peer relation interface layer here: https://github.com/juju-solutions/interface-namenode-cluster and how it's used in https://github.com/juju-solutions/layer-apache-hadoop-namenode
<icey> thanks cory_fu
<cory_fu> Glad to hear that the issue is fixed already in charmtools, though.  :)
<icey> cory_fu: I'm so confused about it, the other 2 provides interfaces I've written are the same except in name and 2.1.2 has no problem with them -_-
<icey> but yeah, no worries since it seems to be fixed in newer versions
<ahasenack> hi guys, I'm having issues bootstrapping on openstack (liberty) with juju-2, juju is trying http://10.96.5.21:5000/v2.0/auth/tokens (my endpoint is http://10.96.5.21:5000/v2.0) and fails with a 404
<ahasenack> 2016-05-03 13:27:03 DEBUG juju.provider.openstack provider.go:724 authURL: http://10.96.5.21:5000/v2.0
<ahasenack> 2016-05-03 13:27:03 DEBUG juju.provider.openstack provider.go:685 authentication failed: authentication failed
<ahasenack> caused by: requesting token: Resource at http://10.96.5.21:5000/v2.0/auth/tokens not found
<ahasenack> any tips? That url was grabbed from novarc, and nova commands works just fine
<jackweirdy> Is there any documentation for creating a provider in Juju?
<suchvenu> Hi kwmonroe
<suchvenu> when i do charm proof on the deployable charm , I am gettese
<suchvenu> charm@islrpbeixv665:~/charms/trusty/ibm-db2$ charm proof E: Unknown root metadata field (terms) E: min-juju-version: invalid format, try X.Y.Z
<suchvenu> These are coming in metadata.yaml file when we do charm build from the ibm-base layer
<suchvenu> What to do for these ? Do we need to remove these from deployable charm or from ibm-base layer ?
<D4RKS1D3> Hi everyone
<D4RKS1D3> Someone knows how to "delete" a command launched in juju?
<D4RKS1D3> the machine is off... but I need to stop this command
<axino> I _think_ juju queues up "commands" in mongodb
<D4RKS1D3> and you know how to enter in this mongodb queue?
<lazyPower> suchvenu - its landed in the repository but is pending release - https://github.com/juju/charm-tools/issues/190     I think you're OK to leave it in for now, i'm fairly certain this 2.1 patch will be going out soon.
<D4RKS1D3> axino, you know how to enter in this mongodb queue?
<lazyPower> oh, and i take that back, it hasn't landed its only been filed.
<lazyPower> nevermind me, i defer to kwmonroe  :)
<axino> ho you.
<lazyPower> yo yo axino
<axino> D4RKS1D3: connect to your controller and fire up a mongo client ? I don't know about the structure at all, sorry. What command are you trying to cancel ?
<D4RKS1D3> I enter here because i don not find any command to do this
<mbruzek> suchvenu: can you send me the result of the command 'charm version' ?
<mbruzek> suchvenu: I suspect your charm tools version is not current.
<axino> D4RKS1D3: what command do you want to "delete" ?
<suchvenu> charm-tools 2.1.2
<suchvenu> I need to go out urgentlly, Can you let me know through mail pls
<D4RKS1D3> Sorry for the delay axino I want to the delete an action
<D4RKS1D3> because i put a wrong command
<D4RKS1D3> but the machine is off
<D4RKS1D3> probably if i remove the command of the queue can "save" the state of this machine
<marcoceppi> mbruzek that is the latest charm-tools, 2.1.3 is being released, so they have the latest, but these bugs are being patched
<ejat> anyone tried the juju beta with azure?
<D4RKS1D3> no yet
<mbruzek> marcoceppi: yes I sent an email, with about the same information. Copied you, please reply if I said something incorrect.
<D4RKS1D3> axino, I am alredy in the database, you know what is the table?
<marcoceppi> mbruzek: it's fine
<marcoceppi> ejat: I have inthe past, you having issues>
<ejat> ?
<ejat> now looking into beta 6 ... trying to use juju client on windows
<ejat> and looking for documentation for azure credential to be place on credentials.yaml
<marcoceppi> ejat: you just need to run juju add-credentials azure
<marcoceppi> ejat: you just need to run juju add-credential azure
<D4RKS1D3> marcoceppi, you know what happend when you send a command?, this command is store in the database?
<D4RKS1D3> I do not know what happens when the machine is not alive and you send a command to this service
<D4RKS1D3> Someone knows?, thanks
<ejat> marcoceppi: ok thanks ... managed to get all the credential needed using azure cmd line
<marlinc> It should be possible to run bootstrap Juju to a local LXD installation right?
<julenl> marlinc: I think that's the default for local
<julenl> check out this link: https://jujucharms.com/docs/1.25/config-LXC
<marlinc> Okay julenl :)
<natefinch> marcoceppi, tvansteenburgh: have you guys had a chance to look at the TLS problem with deployer/python 2.7?
<marcoceppi> natefinch: yes, but considering Juju 2.0 is weeks out we're not going to jump on it right away
<natefinch> marcoceppi: ok, as long as you think it's fixable for 2.0, I'm fine with letting you figure it out :)
<marcoceppi> natefinch: yeah, we'll address before 2.0
<natefinch> marcoceppi: cool, one less thing I need to worry about :)
<bdx> hows it going everyone? Can someone elaborate on, or link me to some docs on the 'shared-db' network space?
<bdx> As seen here: https://jujucharms.com/nova-cloud-controller/xenial/0
<bdx> openstack-charmers: could someone please link me to some docs describing the intrinsics of what a 'compute-data' network is, what information/services communicate on this network? How is 'compute-data' network recognized by openstack services?
<bdx> as seen here: https://insights.ubuntu.com/2015/11/08/deploying-openstack-on-maas-1-9-with-juju/
<firl_> any neutron mitaka openstack charmers on?
<marlinc> How can I let Juju use a external LXD 'region'?
<rick_h_> marlinc: you can't at this point in time. It's up for discussion for 16.10
<marlinc> :(
<rick_h_> marlinc: sorry :(
<marlinc> Is it possible to do it manually by creating a 'cloud'?
<marlinc> Like with OpenStack
<rick_h_> marlinc: no, Juju is missing some code to handle sending some of it's calls across the networking vs locally
<marlinc> Damn, okay
<marlinc> Have to SSH in then I guess
<marlinc> Thanks anyway r
<marlinc> Thanks anyway rick_h_, hope to see new cool things in 16.10 then
<marlinc> All of of the tools are amazing already btw
<marlinc> I wish I had the money to actually properly try out MAAS etc
<rick_h_> marlinc: yea, we're getting planned up for the next cycle and should be good stuff
<rick_h_> marlinc: there's the virtual maas stuff?
<rick_h_> marlinc: I know some folks use that to try it out on one machine
<marlinc> Yea I did that once, using libvirt
<julenl> marlinc: is this what you want?  https://insights.ubuntu.com/2015/11/16/juju-and-remote-lxd-host/
<marlinc> Not sure julenl, I actually searched and found that as well but I didn't actually read it
<marlinc> The reason why I didn't read it was because of the talk about environment.yaml
<marlinc> I'm not sure whether I understand it any more, Juju used to use a environments.yaml file but I guess that's no longer used now?
<julenl> as far as I know... it does
<marlinc> Mm okay?
<marlinc> accounts.yaml
<marlinc> bootstrap-config.yaml
<marlinc> clouds.yaml
<marlinc> controllers.yaml
<marlinc> current-controller
<marlinc> models.yaml
<marlinc> ssh
<marlinc> Woops
<marlinc> Didn't except ls to do that when not in an interactive terminal
<D4RKS1D3> someone knows what happend when you send a command?, this command is store in the database?
<D4RKS1D3> I do not know what happens when the machine is not alive and you send a command to this service
<D4RKS1D3> Thanks in advance
<lazyPower> D4RKS1D3 - Hey, i saw this morning it was suggested to go poking around in the mongo database. I dont know that I agree with that. Its highly discouraged to go poking about in there unless you're familiar with the data schema
<lazyPower> D4RKS1D3 - I do believe that there is a timeout on the action you've queued.
<lazyPower> D4RKS1D3 if you have the action's UUID that it returned, you can query the status of that action
<D4RKS1D3> I do not know the id of the action lazyPower , this id is save in some log?
<lazyPower> D4RKS1D3 you can list all actions run against your controller with: juju action status
<D4RKS1D3> okey, thanks
<lazyPower> for more information see: juju action --help
<D4RKS1D3> juju action statusERROR no actions found
<lazyPower> marlinc - juju 2.0 uses cloud credentials. it supports autoloading through the environment, or an interactive prompt
<D4RKS1D3> That means if i turn on the machine juju do not destroy my machine
<lazyPower> D4RKS1D3 i'm not sure what you mean. but if you sent a juju destroy command, its entirely likely that it will get reaped yes.
<lazyPower> there may be something we can do to help, but we'll need some very detailed information in a bug report to start the process
<lazyPower> D4RKS1D3 : do you have some juju status output, and a small rundown of whats happened?
<ionutbalutoiu> Hello, guys. I have a juju 2.0 related question. I have a bundle with multiple charms. I deploy it. I remove one charm and its machine. When I redeploy the bundle, the charm I deleted get spawned, but also new machine for already deploy services. Is this intended ?
<D4RKS1D3> Thanks for helpme lazyPower
<lazyPower> ionutbalutoiu - yes, unless you remove that charm from teh bundle, it will always attempt to reach the state in which the bundle defines
<ionutbalutoiu> but, I don't want new machines for already deployed services. This is how juju-deployer works, I think.
<lazyPower> oh its adding additional machines?
<ionutbalutoiu> yep.
<lazyPower> i misunderstood, i thought it was only re-adding the machine that was removed. that seems like a bug, we should most definetly get that filed.
<lazyPower> D4RKS1D3 - pastebin the output of juju status for me
<lazyPower> D4RKS1D3 - and run me down what you've done that you're trying to prevent
<lazyPower> or what somethign else did on your behalf :) as i really have no idea
<lazyPower> ionutbalutoiu https://bugs.launchpad.net/juju-core/+filebug - can you file a bug with juju version, the bundle you're deploying, and steps to reproduce?
<ionutbalutoiu> @lazyPower yes, preparing the steps. I was looking now, if anything similar was already reported.
<lazyPower> Thanks :)
<D4RKS1D3> of course lazyPower
<ionutbalutoiu> lazyPower, I think it was a bundle problem. I'm good now. Juju deploy from 2.0 is behaving just like juju-deployer with bundles. All good :)
<D4RKS1D3> lazyPower, https://bugs.launchpad.net/juju-core/+bug/1577988 Thanks for help us
<mup> Bug #1577988: Revert destroy service when machine is off <juju-core:New> <https://launchpad.net/bugs/1577988>
#juju 2016-05-04
<jamespage> dosaboy, gnuoy: https://review.openstack.org/#/c/312229/ ready to land if good with you
<lazyPower> Tribaal when you're around i could use a patch pilot to land this one so we can get some clean tests back on bundles using es :) https://code.launchpad.net/~lazypower/charms/trusty/elasticsearch/amulet-test-bump/+merge/293703
<dosaboy> jamespage: landed
<jamespage> beisner, gnuoy: grrrrr https://openstack-ci-reports.ubuntu.com/artifacts/test_charm_pipeline_amulet_full/openstack/charm-neutron-gateway/299205/3/2016-05-04_03-12-11/test_charm_amulet_full/juju-stat-tabular-collect.txt
<jamespage> api-metadata still appears to be racey with conductors on xenial-mitaka
<verterok> Hi, I'm using juju 1.25 and getting my bootstrap node disk filled by blobstore.[0-9] files (512M each). the machine has a small-ish disk.
<verterok> is there a way to cleanup the blobstore files? or my only choice is to add a volume and move stuff around?
<shilpa> hi, I am pushing my charm to charm store, when i do charm login
<shilpa> I see this error : ERROR login failed: invalid OAuth credentials
<shilpa> how can i resolve this issue please
<cholcombe> what's the new method to get recommended status in the charm store?  I don't see it in the devel docs
<Tribaal> lazyPower: ack - today's been a bit of a mess but I'll have a look
<lazyPower> Tribaal - ack. Its a pretty minor change, the hook files were mode changes, and the tests were refactored
<Tribaal> lazyPower: by the way, trade you? https://code.launchpad.net/~tribaal/charms/trusty/ntpmaster/python3-hooks/+merge/293587 :)
<lazyPower> cholcombe - its dependent on the RQ tim is working on.  otherwise you follow the existing process of opening a bug, attaching all the info to it, and we handle the review manually
<Tribaal> lazyPower: funny that symlink property changes show up as file additions.
<lazyPower> Tribaal actualy i had the same thing just happen to ntpmaster
<lazyPower> Bazaar (bzr) 2.7.0
<Tribaal> (in the diff I mean)
<beisner> jamespage, yah but woot for the smarter workload status goods ;-)
<cholcombe> lazyPower, ok maybe i'll tell people to wait a week or so for the new process?
<lazyPower> cholcombe marco sent that mail out like a week or two ago :)
<cholcombe> lazyPower, whoops.  i need to go catch up on my emails :)
<lazyPower> cholcombe - it happens to me too. this is a byproduct of drinking from a firehose :)
<cholcombe> indeed
<lazyPower> we may have blown you into the next county, but boy that cold water is refreshing eh?
<cholcombe> :D
<firl_> any juju ceph-mon charmers there?
<marcoceppi> firl_: I'll grab one
<cholcombe> firl_, yo
<marcoceppi> found 'im
<firl_> haha thanks!
<firl_> for xenial-mitaka
<firl_> ceph has been depreciated for new deploys
<cholcombe> correct
<firl_> so for a 6 node cluster
<cholcombe> we'd like people to use ceph-mon going forward
<firl_> 3 mons and 6 ceph-osd units?
<cholcombe> yeah that sounds ok
<firl_> so ceph-osd colocates with ceph-mon
<cholcombe> you can even put the ceph-mon's into containers if you want
<firl_> and I can have ceph-mon on an LXC now
<firl_> perfect
<cholcombe> the mon's are lightweight
<firl_> ok awesome
<firl_> thanks cholcombe
<cholcombe> icey, and i thought it would make it more clear for people to deploy a monitor cluster and a osd cluster
<firl_> yeah
<firl_> just a paradigm shift and wanted to make sure it was right
<cholcombe> by default ceph-mon waits for 3 mons
<firl_> perfect
<firl_> now, any JUJU gui charmers on? hah
<marcoceppi> firl_: I can possibly help, but /me pokes jrwren and hatch
<firl_> :)
<firl_> we are having issues with deploying a bundle file to juju gui and the options being maintained
<firl_> We are about to try it from the command line ( have to find the command still )
<jrwren> firl_: can you describe the issues?
<firl_> sure
<firl_> I drag bundle file to juju gui via import, wait for deploy. After deploy finishes ( juju status ) options like os-data-network, fsid, etc for charms do not get applied
<firl_> want the bundle file as reference?
<jrwren> firl_: yes.
<firl_> ok 1 second
<firl_> jrwren http://pastebin.com/i5W1pw27
<marcoceppi> firl_: what version of Juju?
<firl_> of juju gui or juju
<firl_> or agent
<jrwren> I got nothing.
<jrwren> Makyo: ^^?
<firl_> â1.25.5-trusty-amd64â juju cli
<firl_> juju-gui = latest charm
<firl_> juju tools on state machine = https://streams.canonical.com/juju/tools/agent/1.25.5/juju-1.25.5-trusty-amd64.tgz
<firl_> If the juju quickstart works should we open a juju gui bug?
<Makyo> firl_: quickstart will deploy the bundle in the gui.  Is it all of the config options that go missing?
<firl_> I think only like 1 config value stayed the same ( neutron-gateway ext-port )
<firl_> re running now
<Makyo> firl_: it looks like there's a problem with the bundle, though it's still a bug that that information isn't surfaced in the gui
<Makyo> firl_: you can do `sudo pip install jujubundlelib`, then check the output of the bundle parser with `getchangeset bundle.yaml`
<Makyo> Those errors should be surfaced in the gui, though, I'll file a bug
<firl_> makyo, yeah switching to ceph-mon brought some of those up
<firl_> it looks like it deploys other charms without options because of another charms invalid options
<firl_> I think better UI feedback would be awesome
<Makyo> firl_: agreed, gonna file a thing on that
<cory_fu> tvansteenburgh: Do we have any idea how many tests are using Amulet's action_fetch (specifically, the return value)?
<tvansteenburgh> cory_fu: no, but i'm working on that code right now, what's up?
<cory_fu> Are you?  What are you changing, specifically, because I was also working on some changes?
<tvansteenburgh> cory_fu: um, i have a shit load of changes
<Makyo> firl_: filed at https://github.com/juju/juju-gui/issues/1614 - will take a look today, time permitting
<tvansteenburgh> cory_fu: all juju2-compat related
<cory_fu> tvansteenburgh: So, the problem that I'm having is that the return value of action_fetch doesn't provide you any way to distinguish between timeout or failure,  and if an action doesn't use action-set, then that is also indistinguishable from failure / timeout
<tvansteenburgh> cory_fu: juju2 compat for actions, config, and wait
<cory_fu> The other issue I was looking in to fixing was that it is a PITA to get the unit name to pass in, so I was looking at moving the action methods to UnitSentry, so you'd call it like self.d.sentry['service'][0].action_do('foo')
<cory_fu> Instead of self.d.action_do(self.d.sentry['service'][0].info['unit_name'], 'foo')
<tvansteenburgh> cory_fu: yeah, shoulda been that way from the start
<cory_fu> It actually wasn't hard to move the methods, and I'm just updating the tests now, but I assumed we'd want to keep shims in the old location for backwards compat.
<cory_fu> But maybe you're already moving them?
<tvansteenburgh> yeah we have to
<tvansteenburgh> no
<tvansteenburgh> cory_fu: problem is i changed all those method bodies
<tvansteenburgh> i hate you right now
<cory_fu> ha
<cory_fu> tvansteenburgh: Well, I care less about moving them than I do about the return value of action_fetch
<cory_fu> Because I have actions that are just success / failure and there's no way to tell if they worked
<tvansteenburgh> yeah. well i would prefer that you wait for mine and then rebase on that
<tvansteenburgh> or i can make the change myself
<cory_fu> +1 to you doing it.  It should be a trivial change, but it would also be backwards incompatible with the documented return value.  :(
<tvansteenburgh> yeah. i might add a kw param to control the behavior instead
<cory_fu> Well, that's not entirely true.  It's documented to return  "Action results, as json" which I took to mean the full output of `juju action fetch` but actually is json.loads(`juju action fetch`)['results'] if not (failure or timeout) else {}, which drops a lot of useful info
<cory_fu> And isn't at all clear from the docs
<tvansteenburgh> even so, there could be tests relying on the current behavior
<cory_fu> Anyway, a keyword param for the full output would be acceptable
<tvansteenburgh> it's either that or bump the major version,
<tvansteenburgh> which might not be out of the question considering the juju2 support that's going in
<tvansteenburgh> dunno, will ponder while i watch my paint dry, i mean tests run
<thedac> gnuoy: tinwood: jamespage: Trivial fix to keystone credentials bug https://review.openstack.org/#/c/312610/
<thedac> or wolsen if you have time ^^
<wolsen> thedac, I'll take a look now
<thedac> Thank you
<wolsen> thedac, is this something in stable?
<thedac> wolsen: no on master. The identity-credentials relation just landed
<wolsen> thedac, great
<thedac> This only affects that new relation
<wolsen> thedac, +2
<thedac> wolsen: thank you, sir
<wolsen> thedac, oh don't worry I'll have a mongo charm review coming soonish
<wolsen> thedac, I might tap you on the shoulder to give it a review as well
<wolsen> ;-)
<thedac> no problem, ping me when it is ready
<wolsen> thedac, sure its the issue that bradm ran into when clustering mongodb in vivid+
<marcoceppi> cory_fu: don't hate, but what do you think of charms.tool for a module for charmhelpers.core.hookenv?
<cory_fu> marcoceppi: Why would I hate?  But weren't we going to make it more specifically "juju hook tools"
<cory_fu> charms.hook_tools perhaps?
<cory_fu> Actually, you're right, we should drop "hook"
<cory_fu> marcoceppi: So yeah, +1 for charms.tool
<thedac> gnuoy: tinwood: jamespage:  Not sure what the procedure is for a new interface. Here is the keystone credentials interface: https://github.com/thedac/charm-interface-keystone-credentials and it can be tested with https://github.com/thedac/mock-keystone-client
<tinwood> thedac, I wrote the tests for the keystone-client directly into the interface git repo - but it's not merged yet as I'm not sure if the relevant fix on charm-tools has landed into the PPA yet.  Maybe gnuoy knows?
<tinwood> thedac, interface-keystone rather than keystone-client.
<thedac> right, I left tests out until that is sorted
<tinwood> thedac, ah, ok good.
<firl_> cholcombe you still around?
<gnuoy> thedac, I'll take a look today
<thedac> gnuoy: thanks
<firl_> or any other ceph-osd charmers around?
<gnuoy> thedac, landed and up on http://interfaces.juju.solutions/
<thedac> gnuoy: sweet. Thank you
<gnuoy> np
<mattrae> hi, how does Juju determine which interface to use for the private-address value? Iâm running into an issue in our manual provider environment where it is deciding to use the storage access network instead of the openstack management network where the default gateway resides
<lazyPower> mattrae - that depends on the provider and which version of juju.
<lazyPower> mattrae - but as i understand it, in maas it depends on how you've configured/tagged the networks in maas 1.9.   you model the networks there, and that information is then fed to juju
<mattrae> lazyPower: ahh cool, this is using the manual provider and juju 1.25.5
<lazyPower> mattrae - i'm not entirely certain but i think that is "autosensed" so its likely it pikced the wrong interface
<lazyPower> mattrae - i would most def. hit the list up with this question :(  I don't think the people that are initimately familiar with our networking model are US based.
<mattrae> lazyPower: cool thanks, thats good information :) do you know who might be familar with the manual provider?
<mattrae> ohh cool, i'll email the list, thanks!
<LiftedKilt> something is wrong with the ceph cluster in the openstack-lxd bundle - the cluster hangs on creating pgs
<LiftedKilt> also the ceph-mon charm creates the /etc/ceph/ceph.conf file without whitespace on the last line, causing the last line to be ignored until manually edited
<LiftedKilt> not sure if that is what is causing the problems with PG creation
<LiftedKilt> beisner jamespage: any ideas?
<lazyPower> LiftedKilt - Did you bug that? the ceph-mon newline for sure should be bugged
<LiftedKilt> lazyPower: I hadn't yet
<LiftedKilt> lazyPower: wasn't sure if I should wait and bug them together
<lazyPower> im not sure about the bundle, but if a config file is shipping with known defects, we should get that patched in short order :)
<lazyPower> cholcombe is pretty quick about that stuff too
<LiftedKilt> lazyPower: ok I submitted a bug report for the mon charm / newline issue https://bugs.launchpad.net/charms/+source/ceph/+bug/1578403
<mup> Bug #1578403: newline <ceph (Juju Charms Collection):New> <https://launchpad.net/bugs/1578403>
<lazyPower> LiftedKilt - thanks a bunch for the bug. I'll make sure the ceph team is aware of a bitesized fix :)
<LiftedKilt> great - thanks. I'm hoping that fixes the other issue as well actually.
<pacavaca> Does juju provide something for accessing service logs (after it's been deployed)? Or it can only show me it's own logs and for service logs I should go to the machine/container and locate them manually?
<cholcombe> LiftedKilt, one sec
<cholcombe> LiftedKilt, yeah the whitespace thing is a bug that needs to be fixed
<LiftedKilt> is the mds keyring config line being ignored on cluster bootstrap potentially responsible for the pgs failing to create?
<LiftedKilt> cholcombe lazyPower: filed a bug report for the second portion of the failure after talking to the ceph team https://bugs.launchpad.net/charms/+source/ceph/+bug/1578419
<mup> Bug #1578419: ceph and ceph-mon charm attach osds improperly, prohibiting pgs from creating <ceph (Juju Charms Collection):New> <https://launchpad.net/bugs/1578419>
<jamespage> hmm
<jamespage> LiftedKilt, I need to check on the recency of the openstack-charmers-next charms
<jamespage> the automated injestion process was broken for a while and think they are all stale
<jamespage> the stable charmsint he charm store will be up-to-date
<LiftedKilt> if there's a better group of ceph charms to use, I'm all ears
<jamespage> cs:xenial/ceph-mon
<jamespage> cs:xenial/ceph-osd
<LiftedKilt> ok - I will grab those into the bundle
<jamespage> please do that for all of the charms - everything in -next is stale atm
<LiftedKilt> I assumed the charmers-next charms were the latest
<jamespage> LiftedKilt, they normally are but...
<jamespage> not right now
<jamespage> release of charms was on the 21st - most of the team have been travelling since then so not much drift in development yet
<jamespage> so stable is less that two weeks old atm
<LiftedKilt> that would make sense why the deployment worked on the trusty deployment then - the openstack base bundle uses the regular charms
<jamespage> LiftedKilt, yah - I'm working an openstack-lxd bundle based on trunk charms - but ran out of test time...
<cholcombe> LiftedKilt, thanks
<jamespage> LiftedKilt, I think there was a change we backed out which picked the zone information from juju but that was not working well/consistently
<jamespage> so we backed it out quite late in the charm release cycle.
<LiftedKilt> jamespage: ok that makes sense
<wolsen> marcoceppi, ping - want to get your thoughts on something for mongodb charm on xenial
<marcoceppi> wolsen: absolutely
<wolsen> marcoceppi: so currently the charm specifies either master = True or slave = True in /etc/mongodb.conf and attempts to start with --replSet in order to enable replica set replication
<marcoceppi> wolsen: ah, the old charm
<marcoceppi> wolsen: I'm working on a new charm that doesn't suck
<marcoceppi> wolsen: but continue
<wolsen> marcoceppi: hah, well I'm just trying to put in just enough of a fix to get it working until you get yours out the door
<marcoceppi> wolsen: absolutley
<LiftedKilt> jamespage: I noticed that the lxd charm in cs:xenial/lxd  has changed the config from block-device to block-devices plural, and the description no longer mentions the ability to use a file path instead of a physical block device - did that functinoality get removed?
<wolsen> marcoceppi: so basically, replicaset replication is incompatible with master/slave repliation
<marcoceppi> right
<wolsen> marcoceppi: the charm by default scales (juju add-unit) along the replica-set lines
<wolsen> marcoceppi: afaict, the only way to support master/slave replication is to deploy two mongo services and specify the master/slave relationship after the fact
<wolsen> marcoceppi: which feels broken
<wolsen> marcoceppi: it feels the best way is to make the master config option and the replicaset config option mutually exclusive - but then, it seems odd to have a service that breaks on juju add-unit
<wolsen> marcoceppi: which leads me to just want to deprecate the master option
<wolsen> thoughts?
<wolsen> (e.g. dont' support the master/slave configuration - its deprecated in mongodb 3.x+)
<marcoceppi> wolsen: remove for xenial, that's fine for me
<wolsen> marcoceppi: well the trusty/mongodb charm would still be deployable to trusty
<marcoceppi> wolsen: sure, so why not remove master/slave for xenial only
<wolsen> marcoceppi: okay, I'll simply limit it for affected versions of mongodb (which includes xenial and wily)
<marcoceppi> wolsen: why not cull it from the wily and xenial charms
<wolsen> marcoceppi: is there a separate branch for wily and xenial for those?
<marcoceppi> wolsen: there should be
<marcoceppi> wolsen: if there isn't, then mongo isn't in those
<cholcombe> LiftedKilt, yeah i believe you hit a bug with this patch: https://github.com/openstack/charm-ceph-mon/commit/aef61caa46e7fd6ba5b1280653d9aec5ffcd03d1
 * wolsen looks
<cholcombe> we discovered a problem where if a crush bucket was missing the ceph-osd would fail to start.  Your crushmap also doesn't look right.  It's missing the host bucket
<LiftedKilt> ok - jamespage was saying that the charms in openstack-charmers-next are out of date. This patch made it into the generic xenial charms?
<jamespage> yes
<LiftedKilt> awesome thanks guys
<cholcombe> LiftedKilt, sorry about that.  We had kind of a crazy march with a lot of stuff landing
<LiftedKilt> cholcombe: I can imagine - everything was hitting major releases all at once
<wolsen> marcoceppi: nope, no xenial or wily
<marcoceppi> wolsen: patch, push to xenial only!
<wolsen> marcoceppi: ack
#juju 2016-05-05
<marcoceppi> hey cory_fu
<marcoceppi> so I know we talked about charms.tool for core.hookenv naming. What do you think about charms.model instead?
<marcoceppi> charms.model.log, charms.model.relation_id, charms.model.config
<cory_fu> marcoceppi: I like that much better
<tvansteenburgh> marcoceppi: i like charms.unit better than charms.model
<cory_fu> tvansteenburgh: unit is ok with log, but doesn't make as much sense as model for thinks like relations, config, leadership, etc
<cory_fu> kjackal: Hey, do you have the full unit log for that plugin instance, by chance?
<tvansteenburgh> true i guess. i was thinking of it in terms of "this operates in the context of a single unit"
<marcoceppi> tvansteenburgh: I might keep tool for things like log
<kjackal> cory_fu: let me check
<cory_fu> kjackal: Also, what arch did you run this on?  I think the lzo test might need a skipIf for arch, since it's not supported everywheree
<kjackal> cory_fu: I do not have the full logs. I am sorry. Arch, its x86_64
<cory_fu> Though I guess the only place it's missing right now is aarch64, and I doubt you ran the tests on that
<kjackal> I would like a walkthough the test
<kjackal> I am not sure why we expect those messages. For example we ask two slaves to upgrade and in the status messages we expect only one to report spec missmatch
<kjackal> cory_fu, there is always the chance I am reading this the wrong way
<marcoceppi> maybe charms.model.service.config charms.model.unit.log charms.model.action charms.model.relation* ? cory_fu tvansteenburgh
 * marcoceppi will play around with it a bit
<cory_fu> kjackal: Yes, I wanted to confirm that if the admin forgets to upgrade a unit, the status message will let them know
<tvansteenburgh> marcoceppi: i like that a lot
<cory_fu> marcoceppi: Yeah, me too
<aisrael> tvansteenburgh: bundletester isn't juju 2 compatible yet, right?
<tvansteenburgh> aisrael: it is
<aisrael> tvansteenburgh: latest in pip?
<tvansteenburgh> aisrael: yeah. you also need the juju2 versions of deployer and jujuclient, one sec
<tvansteenburgh> aisrael: well you can install those from tips in launchpad if you want. if you want a ppa instead lmk
<marcoceppi> tvansteenburgh: eta on landing the last few patches so we can just release those?
<tvansteenburgh> marcoceppi: they need reviews
<marcoceppi> tvansteenburgh: link?
<aisrael> tvansteenburgh: a ppa would be great, as long as that's no more work for you
<tvansteenburgh> marcoceppi: https://bugs.launchpad.net/juju-deployer/+bug/1575863 https://bugs.launchpad.net/juju-deployer/+bug/1576519
<mup> Bug #1575863: .deployer-store-cache relies on ~/.juju <juju-deployer:Fix Committed by tvansteenburgh> <https://launchpad.net/bugs/1575863>
<mup> Bug #1576519: Not able to deploy a local charm <juju-deployer:Fix Committed by tvansteenburgh> <https://launchpad.net/bugs/1576519>
<tvansteenburgh> aisrael: ppa:ahasenack/python-jujuclient and ppa:ahasenack/juju-deployer-daily
<aisrael> tvansteenburgh: ta!
<aisrael> stub: Have you tested your cassandra test changes with juju 2? Specifically, it seems like juju-deployer-wrapper.py isn't fully compatible.
<lazyPower> thedac beisner - question for you: What is the best way to make changes to python configs? like dashboard settings.py, where I need to add value to the installed apps array... do we expose any of this for ISV's to tap into?
<thedac> lazyPower: for openstack-dashboard you want to update the local_settings.py template which should override settings.py
<lazyPower> thedac - pointer to where i can find that? (sorry!)
<thedac> lazyPower:  https://github.com/openstack/charm-openstack-dashboard/blob/master/templates/mitaka/local_settings.py
<lazyPower> thedac - so for nexenta's case, they need to add a subordinate to configure this? or are there existing relations/amenities to do so for them?   this isn't as straight forward as the cinder plugin stuff i'm afraid
<thedac> lazyPower: there is a dashboard-plugin subordinate relationship with openstack-dashboard which is what you will want. I am trying to find you an example
<pmatulis> is there a way to see available charm-tools subcommands while in plugin mode? i.e. `juju charm ...`
<lazyPower> perfect, thats enough to get us started. Thanks thedac!  If you do fish up the example, i'd appreciate it :)
<marcoceppi> pmatulis: charm help plugins ?
<thedac> ok
<marcoceppi> pmatulis: why do you care about plugins specifically?
<thedac> jamespage: gnuoy: do you know of any examples of subordinates to opentack-dashbaord that use the dashboard-plugin relationship?
<pmatulis> marcoceppi, 'charm help plugins' doesn't give me anything. i'm reviewing existing docs. currently it says available commands can be discovered with `juju charm`
<thedac> lazyPower: looks like Nexta already has a charm with that relation. https://jujucharms.com/u/anton-skriptsov/dashboard-nexentaedge/trusty/0
<thedac> https://api.jujucharms.com/charmstore/v5/~anton-skriptsov/trusty/dashboard-nexentaedge-0/archive/metadata.yaml
<lazyPower> yeah, i'm bringing this up with him now.
<thedac> coolio
<lazyPower> do you have a moment to run support with me thedac?
<lazyPower> it would be helpful to have an openstacker wingman this with me
<thedac> Sure
<marcoceppi> pmatulis: no
<marcoceppi> pmatulis: where are you looking at this? we re-wrote the entire charm-tools guide already
<gnuoy> thedac, isn't there a juju gui subordinate that uses it?
<thedac> gnuoy: thanks. I look
<thedac> s/I/I'll
<gnuoy> thedac, looks like you can search the charm store by relation https://jujucharms.com/requires/dashboard-plugin
<thedac> ok, that is the only one I found already. :)
<thedac> gnuoy: thanks
<pmatulis> marcoceppi, should this page just be deleted then? https://jujucharms.com/docs/devel/juju-offline-charms
<marcoceppi> pmatulis: not really, charm pull is the new command
<marcoceppi> and charm pull-source
<pmatulis> marcoceppi, i see 'pull-source' only. anyway, is the juju plugin mode depracated then?
<rick_h_> pmatulis: yes, it's now only through the charm command itself
<pmatulis> rick_h_, thank you
<marcoceppi> pmatulis: you need the latest charm command
<pmatulis> marcoceppi, meaning? is there a ppa?
<pmatulis> developer-getting-started doesn't mention one
<marcoceppi> pmatulis: it's in xenial, or in ppa:juju/stable for trusty https://jujucharms.com/docs/devel/tools-charm-tools
<pmatulis> marcoceppi, perfect, i'm on xenial
<marcoceppi> pmatulis: sudo apt install charm then
<pmatulis> ah, not charm-tools ?
<marcoceppi> pmatulis: both
<marcoceppi> http://marcoceppi.com/2016/04/charm-2-point-oh/
<pmatulis> interesting. maybe update the above page? or is that not for public consumption?
<pmatulis> ok, looks like 'charm' is a dep of 'charm-tools'
<wolsen> marcoceppi, fyi I have a mongodb charm for xenial (with minimal changes to work + get amulet passing) here - https://code.launchpad.net/~billy-olsen/charms/xenial/mongodb/lp1513094 , where do I target an MP at? since the xenial series for the charm doesn't exist yet
<marcoceppi> wolsen: it's a new charm review
<pmatulis> marcoceppi, also, any reason why this command takes ~8 seconds to complete? 'charm --help add'
<wolsen> marcoceppi: ack
<marcoceppi> pmatulis: it's faster to do charm add --help
<marcoceppi> pmatulis: if you're going to overwrite that page with the auto help stuff you all do for juju charms could you not?
<pmatulis> marcoceppi, the waiting time is the same for me. and i don't know what you mean with your second sentence
<marcoceppi> pmatulis: it takes a few seconds because it has to load the plugins on each run, and you guys have a script that auto generates the reference page for juju commands, I'm request we not do the same for this charm-tools page
<pmatulis> marcoceppi, oh, well the commands.md file is auto-generated but it only affects juju-core. anyway, we still need to explain stuff and we need to use commands here and there to do that. we also use commands in examples
<tvansteenburgh> ahasenack: can you kick off a rebuild of python-jujuclient for your ppa?
<ahasenack> tvansteenburgh: sure
<ahasenack> tvansteenburgh: done
<tvansteenburgh> ahasenack: thanks!
<aisrael> Any thoughts on what's causing this? "update-alternatives: error: no alternatives for juju"
<tvansteenburgh> aisrael: that's gone
<tvansteenburgh> can't do it any more
<tvansteenburgh> to switch to juju1, sudo apt install juju-1-default
<tvansteenburgh> uninstall to switch back
<aisrael> tvansteenburgh: Shoot. Ok. I'm reviewing a charm that's doing some juju 1-specific stuff. Have we switched the jenkins stuff to use 2.0 yet? I'm wondering if I should test on juju 1, or push for changes to the tests.
<tvansteenburgh> aisrael: jenkins still using juju1
<aisrael> tvansteenburgh: roger, I'll switch and test, and comment about future compatibility wrt tests. Any idea when we'd require 2.0 compat?
<tvansteenburgh> aisrael: i defer to marcoceppi :)
<marcoceppi> aisrael tvansteenburgh when 2.0 is released
<aisrael> marcoceppi: tvansteenburgh ack, thanks!
<aisrael> and no quickstart in xenial? boo
<tvansteenburgh> juju deploy bundle.yaml
<tvansteenburgh> no need for quickstart :)
<tvansteenburgh> oh, juju1
<marcoceppi> aisrael: no quickstart
<lazyPower> drop it like its hot tvansteenburgh
<lazyPower> gah i wasn't all the way at the bottom i throught you dropped the science about juju deploy
<lazyPower> then i see there's no quickstart for juju-1 in xenial. d'oh
<ahasenack> tvansteenburgh: I need to do a dummy commit to trigger a version change, or else the builds won't upload
<ahasenack> this sometimes happens when a manual build is triggered, LP doesn't remember that
<tvansteenburgh> ahasenack: i'm sure i can find something to improve in a trivial commit
<ahasenack> tvansteenburgh: oh, ok. I was going to do it in the packaging branch, but if you have something trivial at hand, go for it
<tvansteenburgh> ahasenack: oh, in the packaging branch. yeah that makes more sense, go for it.
<ahasenack> ok
<ahasenack> tvansteenburgh: buld requested
<tvansteenburgh> ahasenack: thanks again
<tvansteenburgh> ahasenack: how do the versions get updated for the juju-deployer and python-jujuclient builds? is that a manual step?
<ahasenack> tvansteenburgh: yes. Since the recipe uses the revno, that's a free incrementing number we get, but the actual version has to be set in the debian/changelog file
<ahasenack> so the revno is enough for us to get upgrades in the same version, but if ubuntu releases something with a new version, the ppa, even though having more recent code, won't upgrade that
<ahasenack> tvansteenburgh: hm, deployed just failed to build
<ahasenack> test errors
<ahasenack> ERROR: test_multiple_connections (deployer.tests.test_guienv.TestGUIEnvironment)
<ahasenack> ERROR: test_deploy_unqualified_url (deployer.tests.test_guienv.TestGUIEnvironment)
<ahasenack> ERROR: test_deploy (deployer.tests.test_guienv.TestGUIEnvironment)
<ahasenack> ERROR: test_connect (deployer.tests.test_guienv.TestGUIEnvironment)
<ahasenack> and
<ahasenack> ERROR: test_close (deployer.tests.test_guienv.TestGUIEnvironment)
<ahasenack> all failed with OSError: [Errno 2] No such file or directory
<plars> Hi, I'm trying to deploy to an lxc container on maas, and I've done this for many other units that are deployed, but all the others have been on trusty. The lxc host is trusty as well, but the new one I'm trying to deploy needs to be xenial. I never see the machine come up though, and I suspect I'm hitting a systemd related incompatibility with trying to do
<plars> this:
<ahasenack> that's when calling     ["juju", "--version"], log).split('.')[0])
<plars> https://www.irccloud.com/pastebin/rciZj6wP/
<ahasenack> xenial
<plars> sorry ahasenack, didn't mean to interleave... thought you were finished :)
<ahasenack> I guess we need to update the dependencies to use juju-1-default or get the right juju2 one
<ahasenack> plars: no worries :)
<ahasenack> plars: never seen that error, sorry
<plars> So - 1. Am I right in assuming I cannot deploy lxc machines onto a trusty host? and 2. Does anyone know if I could simply upgrade to a xenial base for my lxc machines and deploy trusty *and* xenial lxc units to it?
<plars> err... s/lxc machines/xenial lxc units/
<pmatulis> marcoceppi, previously, there was a 'getall' tools command to grab all charms. how is that done now?
<tvansteenburgh> ahasenack: i'll take a look
<ahasenack> tvansteenburgh: I'll just update the deps, I bet there was no /usr/bin/juju
<ahasenack> just the versioned ones
<ahasenack> tvansteenburgh: do these tests work with juju-2? Do you know?
<tvansteenburgh> ahasenack: they do, yes
<ahasenack> ok, I'll put juju-2 in front then, so xenial uses juju2, and the rest will use juju1
<tvansteenburgh> ahasenack: sounds good
<pmatulis> marcoceppi, i tried 'charm pull wordpress ~/charms/' and the charm's files get put directly under ~/charms and not under ~/charms/wordpress . normal?
<marcoceppi> pmatulis: I didn't write that, you could file a bug against https://github.com/juju/charmstore-client
<lazyPower> that is however strange, as i've used charm-pull and it puts the code in a subdirectory named after teh charm
<lazyPower> eg if i'm in /tmp and i run charm pull elasticsearch, it creates /tmp/elasticsearch and puts the charm there
<lazyPower> pmatulis - ^   it really stripped the dir and spit out charm files in $JUJU_REPOSITORY (~/charms)?
<pmatulis> lazyPower, but what you wrote is not what i did so i'm not sure why you say it's strange. i don't know how i can be clearer. why don't you try it?
<lazyPower> oh, i missed the path at the end
<lazyPower> my mistake
<suchvenu> Hi
<suchvenu> I am getting the following error in my debug-log
<suchvenu> unit-ibm-db2-0[19719]: 2016-05-05 19:27:42 ERROR juju.worker.uniter.filter filter.go:137 tomb: dying unit-ibm-db2-0[19719]: 2016-05-05 19:27:42 WARNING juju.worker.dependency engine.go:304 failed to start "uniter" manifold worker: dependency not available unit-ibm-db2-0[19719]: 2016-05-05 19:27:45 ERROR juju.worker.uniter.filter filter.go:137 tomb: dying
<suchvenu> How can I resolve this ?
<lazyPower> suchvenu see this bug: https://bugs.launchpad.net/juju-core/+bug/1513667
<mup> Bug #1513667: Better error messaging around uniter failure <juju-core:Triaged> <https://launchpad.net/bugs/1513667>
<suchvenu> Hi lazyPower
<suchvenu> You restart the juju machine daemon by running `sudo restart jujud-machine-0` from machine 0
<suchvenu> Where should i run this from ?
<suchvenu> machine 0 is local host, right ?
<lazyPower> suchvenu - are you using the local provider?
<suchvenu> yes
<lazyPower> yeah but thats not the name of the service you need unfortunately. can you pastebin the output of initctl list | grep juju for me?
<lazyPower> sorry, sudo initctl list | grep juju
<suchvenu> sudo initctl list | grep juju juju-agent-charm-local start/running, process 9596 juju-db-charm-local start/running, process 9529 charm@islrpbeixv665:~$
<suchvenu> http://pastebin.ubuntu.com/16245865/
<lazyPower> restart both of those and if you could, let us know on the bug if it resolved the issue or if it gets better/worse/about-the-same?
<suchvenu> Restarted both and now the debug-log is moving further, I don;t see the error now
<suchvenu> However I see this status in Juju status
<suchvenu> http://pastebin.ubuntu.com/16245919/
<lazyPower> suchvenu - ok, sounds like the agent needs to be cycled on the db-2 unit. Its lost because it hasn't checked in with the controller in a specified time, is what i recall that meaning.
<suchvenu> I am redeploying the service
<suchvenu> lazyPower, why is this happening ?
<lazyPower> suchvenu i'm not certain :(
<lazyPower> suchvenu - the logs of that deployment would be helpful, and if we can capture any of the unit agent logs that are failing to start due to that uniter failure would be helpful.  so if it happens again, ping me and i can step you through capturing that. I haven't been able to reproduce that bug.
<suchvenu> ok
<jcastro> http://askubuntu.com/questions/766661/openstack-lxc-containers-missing-dns
<jcastro> can anyone help with this one?
 * jcastro glances over at beisner
<bdx> whats going on everyone?
<lazyPower> yo yo bdx
<bdx> lazyPower: how can I generate/obtain tools for beta7?
<lazyPower> bdx juju bootstrap --upload-tools doesn't work?
<bdx> unfortunately not
<lazyPower> hmm, not certain. I'm still on beta6 here.
<lazyPower> thanks for the heads up that i need to recycle my env :)
<bdx> ok, thanks. It could be another issue, I'm about to start debugging it now
<bdx> yea, good luck!
<lazyPower> oh hey bdx , not sure if you saw last week. hattip @ your contributions to the tls-layer. Skinnied up some code i had to write for swarm :)
<bdx> nice!!!!
<bdx> https://bugs.launchpad.net/charms/+source/percona-cluster/+bug/1578838
<mup> Bug #1578838: Services not running that should be: mysql <percona-cluster (Juju Charms Collection):New> <https://launchpad.net/bugs/1578838>
#juju 2016-05-06
<D4RKS1D3> Hi lazyPower , you have any notice about my but?
<D4RKS1D3> now I reinstalled the compute but I think probably in the future this option should be available
<stub> aisrael: No, I haven't tested Cassandra with Juju 2. It shouldn't be much work though, assuming Amulet and/or juju-deployer updates have been released.
<stub> aisrael: Some other bits of my test harness could need tweaking too
<aisrael> stub: ok, thanks. Here's the logs from running it w/2 and the latest amulet/deployer stuff
<aisrael> http://pastebin.ubuntu.com/16258792/
<stub> aisrael: I think that is my main test harness - the wrapper is just passing its arguements on through to the real juju-deployer IIRC.
<stub> aisrael: The PG charm will likely fail in exactly the same way (they share the harness)
<aisrael> stub: Yup. Hopefully that makes fixing it easier, too. :D
<stub> I'll find out next week ;)
<aisrael> stub: is that long of a run time to be expected?
<stub> aisrael: 6 minutes because none of the units ever got deployed? That is rather on the short side.
<aisrael> No no. The successful run ran for like, 10 hours
<stub> aisrael: That is much slower than I would expect. I don't have a recent full timing, but it runs on my 8GB laptop in an hour or two I think.
<aisrael> stub: Ok, I'll give it another run (testing your other mps). Is that hour or two run against the local provider?
<stub> aisrael: Yes
<aisrael> stub: ack, thanks. I'll pump up the vm ram and give that a go.
<stub> aisrael: thanks :)
 * stub wanders back into the long weekend
<lazyPower> marcoceppi - question for you about best practices with interfaces... I'm looking to add TLS to the etcd interface so communication between client/server is done over that encrypted tunnel , and basically deprecate the non TLS connection(s). This has implications on consumers, but once you've reconfigured the daemon for tls, it drops all notion of accepting connections without it...
<lazyPower> so i'm concerned this will cause a problem for users upgrading
<marcoceppi> lazyPower: interesting
<lazyPower> what i think i can do, which is slightly more complex is make SSL a configuration option, and have the interface adapt accordingly, and leave it off by default
<marcoceppi> lazyPower: will etcd relation provide the ssl details?
<lazyPower> correct.
<lazyPower> its going to need to send a client certificate with the connection string
<marcoceppi> lazyPower: so, eek, the best we can is do this xenial only and check what bundles are doing xenial/etcd to see the ramifications for this
<mbruzek> lazyPower: marcoceppi: isn't the relation communication done securely from the start? controller -> unit communication is done via ssh, I thought the unit -> unit communication secured too?
<marcoceppi> mbruzek: controller -> unit is done via API and unit -> unit is also api and that's encrypted, it's more about upgrading and having something that was doing plaintext suddenly move to tls and not knowing how to handle that drop or change
<marcoceppi> lazyPower: if we do this for xenial only we won't break anyone
<marcoceppi> becuase we dont' have a xenial charm for etcd
<lazyPower> multi-series charm in the layer though
<lazyPower> so, that doesn't help
<marcoceppi> lazyPower: we should research the ramifications
<lazyPower> mbruzek - etcd unit-unit is not secure, nor is client-server comms
<lazyPower> its done over plain HTTP
<marcoceppi> lazyPower: etcd is used in openstack calico bundle
<mbruzek> lazyPower: Oh you mean the non-juju unit to unit communication
<marcoceppi> lazyPower: that I can see on the store page
<lazyPower> marcoceppi - ok so dev the TLS bits, deploy a k8s cluster with the non tls enabled bit, upgrade it and see how badly it breaks?
<marcoceppi> lazyPower: so we should add tls layer, deploy etcd then upgrade-charm from your fork
<marcoceppi> lazyPower: yes, lets see what happens with the deployments we know use it, k8s and openstack-calico seem to the be majority of the consumers
<lazyPower> yeah thats what i was thinking was get a proper non tls to tls upgrade test.
 * marcoceppi acks
<lazyPower> but i wanted to ping you so you knew what we were going to run into
<lazyPower> i think this can work, but only if its done right, otherwise we're going to brick some deployments and thats no bueno
<icey> is it possible to get c-h from head into a layered charm?
<lazyPower> icey - i know that you can create your own wheel of it and stuff it in the charm
<lazyPower> it doesn't care, it'll use whatever is in the wheelhouse
<lazyPower> but thats not a long term solution
<lazyPower> i had to do tha tlastnight to check some charms.docker features i had in a pr that had not landed in pypi
<icey> lazyPower: basically, the base layer is pulling in 0.7.0 of c-h, I need some stuff that is committed, but isn't yet in pypi -_-
<lazyPower> icey - thats the exact same usecase i outlined
<icey> yeah, thanks :)
<lazyPower> you can make a wheel and use that :) Just stuff it in the wheelhouse and remove teh one the builder put in there
<lazyPower> disclaimer, i didnt look in the builder, so i just manually installed the .whl before hook execution
<icey> so I have to manually muckl around in the built charm :-/
<suchvenu> Hi
<suchvenu> Have a query on naming of interfaces
<lazyPower> you may need to poke the tactics.py file in charm-tools to see how we're using pip to build the wheelhouse (specifically WheelHouseTactic)
<lazyPower> hey suchvenu o/   ready when you are.
<suchvenu> http://pastebin.ubuntu.com/16261116/
<suchvenu> My interface name is db2(interface.yaml) and the launchpad stream is interface-ibm-db2. In layer.yaml i have given interface-ibm-db2
<suchvenu> I got disconnected.. :(
<suchvenu> lazyPower , you haresponded to my query ? I think I missed all
<lazyPower> suchvenu i have not
<suchvenu> *had responded
<suchvenu> ok
<lazyPower> 1 moment, i'm wrapping up something else and will take a look
<suchvenu> you got my query , or did you miss that ?
<suchvenu> sure
<lazyPower> suchvenu - i'm not sure i know what you mean by launchpad stream.
<suchvenu> I meant the branch name in Launchpad
<lazyPower> and according to this pastebin, your includes should look like:     ['layer: ibm-base', 'interface:db2']
<suchvenu> do we need to follow any naming convention for the interface ?
<lazyPower> suchvenu - have you looked at the interfaces site? http://interfaces.juju.solutions  -- no convention other than the name thats listed in the interfaces api should match what you have in interface.yaml
<suchvenu> If I keep db2 as te interface name in layer, how it should be in the Launchpad ? As of now its like this : lp:~ibmcharmers/charms/trusty/interface-ibm-db2/trunk
<lazyPower> thats fine,  the way the api works is you create an entity for the interface/layer respectively. You can then configure the DVCS url for that entity. so you simply plug that in for the repo
<marcoceppi> suchvenu: you don't want to put it under the charms/trusty namespace, that's for charms. This is an interface
<lazyPower> oh, but what marcoceppi pointed out, should be corrected :)
<lazyPower> he is correct
<marcoceppi> suchvenu: you can create a new launchpad project called interface-ibm-db2 but the interface.yaml should just have the name "db2"
<wolsen> thedac, if you have a minute - a trivial - https://review.openstack.org/#/c/313226/
<marcoceppi> suchvenu: https://launchpad.net/projects/+new once you fill that out you can do `bzr push lp:~ibmcharmers/interface-ibm-db2/trunk`
<suchvenu> lp:~ibmcharmers/charms/trusty/interface-ibm-db2/trunk . So can I use this same branch and update the interfaces.yam as db2 ?
<suchvenu> ok, different branch for interface
<marcoceppi> suchvenu: you do not want to put anything other than charms in the charms/trusty path, that will simply confuse the store. Since this is an interface you'll want to create a new project then push to that branch name in launchpad but you can keep the name as db2 in the interface. It's okay to have a different branch name and a different interface name
<suchvenu> So i need to register a new project here ?
<suchvenu> ok
<suchvenu> let me try create a new project here
<suchvenu> so here you say interface name can be db2 only and interface-ibm-db2 is not required ?
<suchvenu> in layer.yaml
<marcoceppi> suchvenu: right, so in the interface.yaml you can put name: db2 but the project in launchpad can be called whatever you'd like. So Id' recommend either interface-db2 or interface-ibm-db2
<suchvenu> In register project, it asks for Name, Url and SUmmary. Is this name you are referring to ? I can add all the interfaces we create into this project right ?
<suchvenu> but the project in launchpad can be called whatever you'd like => does this mean the branch name for the db2 interface or the new project i am going to create using Register project link you sent
<marcoceppi> suchvenu: no, it's typically one project per interface
<suchvenu> oh
<marcoceppi> when you create the project name in launchpad it should be named something like interface-db2
<marcoceppi> or interface-ibm-db2
<suchvenu> so here i will give the proj name as inter-ibm-db2
<suchvenu> ok
<suchvenu> So for charms we have a single project area, but for interface separte rpoject areas ?
<marcoceppi> suchvenu: yes
<suchvenu> ok
<suchvenu> It asks this : Select the licence(s) under which you release your project.
<suchvenu> WHich one to select ?
<suchvenu> marcoceppi you there ?
<marcoceppi> suchvenu: that's up to you, it's a license for the code, I'd recommend apache2 but that's entirely up to you
<marcoceppi> suchvenu: a license for the code of th einterface, not for db2
<suchvenu> ya, just wanted to know which is generally selected
<suchvenu> so trunk and devel I need to push over here, right ?
<suchvenu> and the other ones which i created under trusty needs to be deleted, right ?
<aisrael> Anyone see a provisioning machine with an agent-state error of 'cannot record provisioning info for "ubuntu-local-machine-1": cannot set instance data for machine "1": not found or not alive'
<aisrael> ^ ever see
<lazyPower> negative aisrael
<aisrael> lazyPower: ran my vm out of disk space, which might be the cause
<lazyPower> seems legit
<thedac> wolsen: +2 sorry for the delay
<wolsen> thedac, np and thx!
<icey> lazyPower: I've gotten it to drop both charmhelpers into the generated charm, but when I remove the base layer version, it seems to resurrect it when I deploy the charm
<mattrae> lazyPower: hi, do you know which version of juju-deployer i need to use with juju 2.0? i'm getting an error from juju-deployer complaining that .juju/environments.yaml doesn't exist, which isn't used in juju 2.0 https://pastebin.canonical.com/155977/
<mattrae> lazyPower: i'll see if i can try the latest juju-deployer on launchpad
<mattrae> looks like trunk also gives the same error
<mattrae> fginther: happen to be around? i saw you may be working on a juju-deployer branch that works with juju 2.0. should i use this branch? lp:~fginther/juju-deployer/updated-juju
<fginther> mattrae, that branch has already been merged into trunk (lp:juju-deployer), do you have the traceback handy?
<fginther> there may be a latent bug or two
<mattrae> fginther: sure, here is the traceback i'm seeing complaining about no eivornments.yaml.. do i need enviornments.yaml with 2.0? https://pastebin.canonical.com/155979/
<fginther> mattrae, no, you don't need an environments.yaml with 2.0.
<fginther> let me take a quick look
<fginther> mattrae, are you trying to run this out of a branch?
<mattrae> fginther: yeah i've tried the version that comes with xenial, and then i tried trunk
<mattrae> both give the same error
<fginther> mattrae, ok, if you're trying to use a bzr branch, you'll need to use a virtualenv or something. As it's being used now, it's calling into the deployer modules that were installed with the package
<fginther> you can also install from the daily ppa
<mattrae> fginther: yeah i followed the virtualenv instructions in the READ
<mattrae> i'll see if i can try the daily ppa
<fginther> hang on, I have it handy
<fginther> mattrae, ppa:ahasenack/juju-deployer-daily
<mattrae> fginther: awesome, looking better so far. i'm not getting that error
<mattrae> thanks!
<fginther> mattrae, you're welcome
<mattrae> fginther: if you're back, i'm getting another error saying that the environment isnt bootstrapped.. but i did bootstrap. do you see if i'm doing something wrong here? https://pastebin.canonical.com/155981/
#juju 2016-05-07
<bdx> openstack-charmers, storage-team: I have been testing out cs:xenial/ceph-0, and cs:xenial/ceph-osd-0, with no luck of getting either to deploy w/o error. Does anyone know the status of these charms?
<bdx> :q
<bdx> \qit
<bdx> \quit
<bdx> awwww
#juju 2016-05-08
<tvansteenburgh> is juju-2.0-beta7 in a ppa somewhere or does it have to be built from source?
<tvansteenburgh> i thought it'd be i ppa:juju/devel but apparently not?
<ejat> 2016-05-08 04:15:09 INFO install However the following packages replace it:
<ejat> 2016-05-08 04:15:09 INFO install   mysql-testsuite-5.7 mysql-server-core-5.7 mysql-client-5.7
<ejat> 2016-05-08 04:15:09 INFO install   mariadb-server-core-10.0 mariadb-client-10.0
<ejat> 2016-05-08 04:15:09 INFO install
<ejat> 2016-05-08 04:15:09 INFO install E: Package 'mysql-client-5.6' has no installation candidate
<ejat> 2016-05-08 04:15:09 INFO install Traceback (most recent call last):
<popey> https://jujucharms.com/get-started - these instructions do not work on 16.04
<popey> E: Unable to locate package juju-quickstart
<popey> installing juju-core results in no juju binary being installed either.
#juju 2017-05-01
<vasey> hey folks, i'm trying to bootstrap my juju controller on MAAS, and it's giving me an error bc it can't find a machine that matches its constraints; one of my machines isn't seeing any RAM when  it commissions, is why, but when i try to force a memory constraint to be 0.0 it doesn't work. any ideas?
<rick_h> vasey: hmm, so maas has the ram information or maas doesn't have the information?
<rick_h> vasey: the thing would be to drop the constraint then if it's not going to be able to match. A machine with 0 ram doesn't really mean anything unfortunately. We can file a bug that it should treat it as an empty constraint
<rick_h> vasey: but just dropping off the ram constraint should be ok?
<vasey> rick_h: maas doesn't have the ram information, it thinks it's 0.0GB
<vasey> when i try to add a ram constraint it doesn't override the 3584 MB constraint that's default for the maas bootstrap command
<rick_h> vasey: can you recommission the node to pick up the memory info?
<vasey> i tried, it doesn't help :(
<rick_h> vasey: hmm, I wonder if we can work around it. Can you add a tag to the machine in MAAS and then use the tags constraint to pick that machine?
<rick_h> vasey: it should override/skip any memory/default constraints
<vasey> oh i'll try that! thanks
<rick_h> vasey: yea sorry. I'm not sure how to replicate it to test it since MAAS picks up the memory in my setup
<rick_h> vasey: I wonder why maas is coming up empty
<vasey> https://pastebin.com/54gTvTz8 here's the output when i try that
<vasey> looks like it still wants the memory constraint to be in effect
<rick_h> bah humbug...hmm
<rick_h> vasey: can you file a bug here with your commands/etc you've tried out? https://launchpad.net/juju
<vasey> will do!
<vasey> done
<rick_h> vasey: ty, sorry I can't think of another way around it atm. So if you say mem= or mem=0.0 it won't work either? can you pastebin the --debug output there?
<vasey> both of those mem constraints don't work unfortunately
<vasey> i'll send you the debug in a sec
<vasey> rick_h: https://pastebin.com/YSGrp4tZ
<rick_h> vasey: hmm, so it seems it just doesn't listen to them at all then
<rick_h> vasey: k, sorry for the trouble. I'd love to get the info into maas and while we could work around this after bootstrap with direct placement, we can't do that on bootstrap. :/
<rick_h> vasey: I guess you could try the the manual provider route but that's obviously not the smooth UX we're shooting for
<vasey> rick_h: how do you do the manual provider route?
<rick_h> vasey: so you'd need to turn on the machines through maas and bootstrap to it over ssh. https://jujucharms.com/docs/stable/clouds-manual walks you through it
<vasey> thanks
<Budgie^Smore> o/ juju world
<kwmonroe> verterok: how/where did you deploy spark when it resulted in http://paste.ubuntu.com/24494765/?
<verterok> kwmonroe: hi
<verterok> kwmonroe: in canonical DC
<verterok> kwmonroe: using a mojo spec, but nothing fancy, just spark + nrpe
<verterok> kwmonroe: let me try with a clean mojo workspace
<kwmonroe> hmm, it's weird verterok, spark-34 tested clean last week across the clouds (and hasn't changed since):  http://bigtop.charm.qa/cwr_bundle_spark_processing/63/report.html
<verterok> kwmonroe: maybe it's failing because of the restrictions we have in our DC?
<verterok> kwmonroe: gimme a couple, the deploy is running
<verterok> kwmonroe: same error: spark/0*  error     idle   0        10.50.84.52            hook failed: "install"
<kwmonroe> verterok: yeah, i'm going to guess it's a restricted network thing.. and a good enough reason to hold the un-prom for apache-* until we can fix the current stuff.
#juju 2017-05-02
<kjackal_> good morning juju world!
<stub> Have we moved on from charms only supporting LTS releases? I've got an MP here adding zesty and yakkety.
<stub> Its a subordinate, so probably necessary if other charms support those series.
<erik_lonroth> oi
<mattyw> so I tried to bootstrap into aws (having just setup a new account): it got stuck in "Contacting Juju controller at 172.31.10.1 to verify accessibility..." for an hour (even though in the aws console I could see it was up". Ctrl+c says "Interrupt signalled: waiting for bootstrap to exit"
<mattyw> and that's it, it's waiting for something? but probably doing nothing - any thoughts?
<mattyw> seems like a bug?
<rick_h> mattyw: hmm, some issue getting ssh there? that's the normal thing it's waiting for there
<magicaltrout> looks a bit weird
<rick_h> mattyw: I hit that with my maas setup when I forget my 'sshuttle'
<magicaltrout> 172 looks internal to me
<mattyw> magicaltrout, indeed, it's the internal ip
<mattyw> hmm, I was using the london region for the first time every
<mattyw> I wonder if there's something weird about it
<magicaltrout> ah that might very well be the case mattyw
<magicaltrout> there have some hard-ish coded assumptions about available server types and stuff
<magicaltrout> rick_h: ?
<rick_h> magicaltrout: yes, there's some hard coded bits on the types of instances but that's not about connecting to the internal address.
<rick_h> it would fail earlier in that it couldn't find an instance type
<magicaltrout> oh yeah mattyw said the instance came up
<magicaltrout> good point
<mattyw> eu-west-2 certainly appears as a supported region
<magicaltrout> yeah
<magicaltrout> i just bootstrapped in it
<mattyw> this is all a totally new aws account I'm setting up
<magicaltrout> try again mattyw and see what happens
<mattyw> so there could be any number of things
<mattyw> am doing
<mattyw> this time with --debug :)
<mattyw> 13:51:51 DEBUG juju.api apiclient.go:695 will retry after error dialing websocket: dial tcp 52.56.222.236:17070: getsockopt: connection refused
<mattyw> magicaltrout, ^^
<mattyw> that's pretty much what the log is saying
<magicaltrout> looks a bit shit
<magicaltrout> weird though how it works for me
<mattyw> magicaltrout, looks to be the same thing using us-east-1
<mattyw> so it's something to do with it being a new account maybe?
<mattyw> don't know what thought
<magicaltrout> don't think so
<magicaltrout> aws accounts have worked ootb for me
<magicaltrout> well i've not done it in a while but they just needed a default vpc
<mattyw> this is the first time I've tried it with a brand new aws account...
<mattyw> what I mean is - an aws account that was created this morning
<mattyw> not just that it was new to juju
<magicaltrout> sure, but i did create a new account for juju stuff a while ago
<magicaltrout> and I don't believe I changed anything
<magicaltrout> its like its some funky routing weirdness
<magicaltrout> out of interest mattyw if you spin up a small ubuntu server on AWS
<magicaltrout> then bootstrap *from* that does it make it any happier?
<mattyw> magicaltrout, you mean using the manual provider?
<magicaltrout> no just bootstrapping from outside of your local network
<mattyw> I could do...
<mattyw> I'll try with my other credentials - I know they work
<magicaltrout> clearly its not idea, but would also help track down if its AWS end or your end
<mattyw> I'll try that first
<magicaltrout> s/idea/ideal
<mattyw> indeed
<mattyw> magicaltrout, huh - old credentials aren't working either
<mattyw> hmmm
<mattyw> ha - 2.2-beta3 has been released - I'm on an older ish client - I bet that's it
<tychicus> has anyone run into this before when attempting to make a persistent volume claim against a ceph rbd provisioner in k8s Failed to provision volume with StorageClass "fast": failed to create rbd image: executable file not found in $PATH, command output:
<mattyw> magicaltrout, ha! yep
<mattyw> all working now
<tychicus> in my case k8s is running inside openstack and I am connecting to the same ceph cluster that openstack is using, so I did not juju deploy ceph and add relations from the same juju controller
<mattyw> had an older ish client (2 weeks old - built myself from master)
<magicaltrout> good stuff :)
<tychicus> btw, I can statically provision claims
<tychicus> the error seems to indicate that the rbd binary is missing, I'm just not exactly sure where it needs to go
<lazyPower> tychicus thats gettign realesed this week
<lazyPower> tychicus sorry you hit that, but a fix is indeed incoming!
<tychicus> lazyPower: thanks, is there a work-a-round?
<lazyPower> tychicus thats a regression with our 1.6.1 release, and should be resolved with 1.6.2, we upped the snaps. You can do an in-place configuration change to get the fix before we release the charms
<magicaltrout> regression?! surely not
<lazyPower> 1 sec while i find which track/channel they are in
<tychicus> yes, in place configuration change sounds great!
<lazyPower> tychicus juju config kubernetes-master channel=1.6/edge
<lazyPower> tychicus juju config kubernetes-worker channel=1.6/edge
<lazyPower> magicaltrout may your code be forever bug free and you not give me an edge to raz you ;)
<lazyPower> magicaltrout in short, bless you.
<magicaltrout> my code is amazing....
<magicaltrout> ly full of bugs
<lazyPower> story of our lives some days eh? :)
<magicaltrout> wrote some gitlab tests last week
<magicaltrout> it'll be in the review queue this week
<tychicus> magicaltrout: if I may ask what is on the docket for gitlab?
<Budgie^Smore> o/ juju world
<magicaltrout> lots of amazing stuff
<magicaltrout> dunno tychicus what features are top of your list of requirements?
<lazyPower> o/ Budgie^Smore
<magicaltrout> those whom shout the loudest will likely win the feature request race
<Budgie^Smore> still killing bugs and taking names layer eh lazyPower?
<magicaltrout> lol
<lazyPower> Budgie^Smore welllllll
<lazyPower> theres an open ended question on if i'm writing bugs faster than i can patch them, but thats the general mantra :) yeah
<tychicus> well my plan is to: 1 install gitlab into k8s
<Budgie^Smore> lazyPower at least their giving credit where credit is due ;-)
<tychicus> 2 have all of the ci jobs run int k8s
<tychicus> then deploy to k8s
<tychicus> but I am sure that there are more useful thing that I have not thought about
<lazyPower> tychicus pretty sure we spoke to this, but there is a multi-executor that knows how to talk to k8s if you give it a kubeconfig
<magicaltrout> hmm well i don't have any plans to deploy gitlab into k8s cause its general charm stuff. I do want to leverage the ci -> k8s executor and docker repo asap
<lazyPower> https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/executors/kubernetes.md
<lazyPower> magicaltrout ^ I'm currently slammed but should see the break soon enough. We can pair on this on a for-fun friday proejct
<tychicus> yep that would be the step 2
<magicaltrout> cool, i'm just getting through yet another stupid week care of NASA but hopefully i can start stabbing away on gitlab amazingness in the next week or two
<magicaltrout> maybe whilst i'm at apachecon
<lazyPower> magicaltrout sounds good, i'm sure we'll be in touch
<lazyPower> magicaltrout i'm currently cannibalizing merlijins work after hours to get a che stood up for my chromium book.
<magicaltrout> ah yeah, thats pretty sweet
<lazyPower> well, if it worked
<magicaltrout> lol
<lazyPower> busted 3/3 times on gce
<lazyPower> so i have work tod o there to figure out why and submit a fix
<lazyPower> i think its just an ip binding issue
<magicaltrout> my new guy started today so in a few weeks i'll have him cranking on simple charm tasks
<lazyPower> oooo
<lazyPower> send him deep in k8s land
<lazyPower> i could use the extra hands
<magicaltrout> lazyPower: gizmo__ gizmo__ lazyPower
<gizmo__> hi
<magicaltrout> i told gizmo__ to test your documentation and stuff to get his head around charm stuff as a starting point lazyPower
<magicaltrout> of course as new stuff comes in and needs testing etc, feel free to prod him. Currently no direct charming experience but we'll be fixing that over the next month or two
<gizmo__> just don't prod too hard!!
<tychicus> LazyPower: forgive my lack of knowledge here "Needs manual upgrade, run the upgrade action"
<lazyPower> tychicus did you get that from etcd?
<tychicus> no kubernetes-worker
<lazyPower> hmmm
<lazyPower> oh super cool
<lazyPower> tychicus i forgot this landed last cycle. We decoupled upgrades from operational code upgrade, so the thought is
<lazyPower> you can juju upgrade-charm on any of your k8s charms, and it wont effect the workloads. (if you set the boolean toggle, defaulted to on so everyone should get this behavior by default)
<lazyPower> tychicus which means, when you juju config k8s-worker channel=1.6/edge, its found a new snap to install, but it wont do anything untill you run a manual action, as it *could* introduce downtime in mission critical scenarios
<lazyPower> tychicus so, juju run-action kubernetes-worker upgrade
<lazyPower> er juju run-action kubernetes-worker/0 upgrade  -- it will need to be repeated once for every unit of the application.
<lazyPower> this way you can stagger and ensure HA
<Budgie^Smore> lazyPower that looks like a nice safety measure in case you "forget" to drain the worker first
<lazyPower> Budgie^Smore thats what we're going for. Value add :)
<tychicus> that is super cool, thanks
<magicaltrout> do you know whats super cool?!
<magicaltrout> lazyPower! ;)
<tychicus> oh and I was going to say the etymology of conondrum
<magicaltrout> lol
<magicaltrout> nooooo
<Budgie^Smore> lazyPower I am not sure I would go that far :P as I am all about full automation but definitely a good safety net initially
<magicaltrout> admcleod isn't super cool
<lazyPower> Budgie^Smore well, we're all for that too. all of those actions can be scripted
<Budgie^Smore> magicaltrout careful now, you don't want to give lazyPower too much of a big head!
<magicaltrout> hehe
<admcleod> wat
<magicaltrout> nothing
<magicaltrout> return to sleeping
<admcleod> brexit
<lazyPower> Budgie^Smore the thing is, juju is a great empowering tool for encapsulating the operations but in terms of guessing your company culture and business logic, its not very omniscient. So instead of forcing you on rails, we giv eyou the primitives to roll that up with little fuss.
<magicaltrout> thats less insulting that "Theresa May"
<lazyPower> hahaha
<admcleod> magicaltrout: yeah but i forgot her name
<magicaltrout> like most of the uk population
<admcleod> magicaltrout: grey cardboard cutout lady
<admcleod> its true though, lazyPower is super cool
<lazyPower> well thanks all for the votes of confidence. Careful putting me on a pedestal, theres nowhere to go from there but down :)
<Budgie^Smore> lazyPower totally get that :) I would be just rebuilding the charm code instead of writing yet more code on top ;-)
<lazyPower> Glad to hear its helpful :)
<admcleod> lazyPower: there are other, much more majestic, guilded pedestals, on which pidgeons wearing gem encrusted crowns puff out their chests for no particular reason other than that their feathers are shiny.
<lazyPower> admcleod what kinda crazy business do you have going on over there in spain that you're putting pigeons on pedestals?
<magicaltrout> sometimes admcleod scares me
<lazyPower> seems dreadfully wasteful!
<admcleod> oh they're just there, in the pidgeon pedestal dimension
<tychicus> well, I don't get the $PATH error any more, but the claim just sticks at pending
<lazyPower> tychicus and the ceph secret is enlisted?
<tychicus> yes
<lazyPower> hmmm
<lazyPower> anything in dmesg/journalctl?
<tychicus> I can do static claims
<lazyPower> yeah i modeled the static claim in an action... which remained working. what we broke as the rbd auto provisioner when we moved to snaps. Confinement is a hefty hammer apparently.
<tychicus> bunch of app armor denied messages: apparmor="DENIED" operation="create" profile="snap.cdk-addons.hook.configure" pid=7965 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
<lazyPower> tychicus i'm going to need more details. When i tested the patch branch I was able to get rbd autoprovisioning working, but thats been some weeks ago now. I don't have the test results or workload manifests handy anymore to spin one up quickly.
<lazyPower> thats expected - a bit of a red herring.
<lazyPower> snap confinement at work
<tychicus> ah ok
<tychicus> just to confirm I should be looking at dmesg and journalctl on the master?
<lazyPower> tychicus correct
<lazyPower> the kube-controller-manager should be doing that enlistment
<tychicus> here is one item from dmesg spedific to kube-controller-manager and rbd
<tychicus> [ 2034.211833] audit: type=1400 audit(1493732994.271:175): apparmor="DENIED" operation="open" profile="snap.kube-controller-manager.daemon" name="/var/tmp/" pid=6055 comm="rbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<lazyPower> hmmm
<lazyPower> its attempting to create a tmp resource and apparmor denied it
<lazyPower> that may be related, but i didn't see that when testing
<lazyPower> is the pv/pvc still in pending? with no movement in the eventlog of k8s?
<tychicus> sorry, I just deleted it, let me re-create it
<lazyPower> ok
<lazyPower> no problem, i'm here all day :)
<magicaltrout> and the next day
<magicaltrout> and the next
<lazyPower> way to make it creepy magicaltrout
<magicaltrout> thats me
<lazyPower> :) <3
<Budgie^Smore> glad you can own it there magicaltrout
<magicaltrout> hehe
<tychicus> LazyPower: here is what I get from journalctl
<tychicus> May 02 14:36:15 juju-0aa679-default-14 snap[5794]: I0502 14:36:15.273296    5794 wrap.go:75] PUT /api/v1/namespaces/default/persistentvolumeclaims/mypvc: (5.581372ms) 200 [[kube-controller-manager/v1.6.2 (linux/amd64) kubernetes/477efc3/persistent-volume-binder] 127.0.0.1:33828]
<tychicus> May 02 14:36:15 juju-0aa679-default-14 snap[5794]: I0502 14:36:15.276311    5794 wrap.go:75] GET /api/v1/persistentvolumes/pvc-b23b5e28-2f44-11e7-b9c8-fa163e1e0ce5: (2.139686ms) 404 [[kube-controller-manager/v1.6.2 (linux/amd64) kubernetes/477efc3/persistent-volume-binder] 127.0.0.1:33828]
<tychicus> May 02 14:36:15 juju-0aa679-default-14 snap[5794]: I0502 14:36:15.278364    5794 wrap.go:75] GET /api/v1/namespaces/default/secrets/ceph-secret-admin: (1.12258ms) 200 [[kube-controller-manager/v1.6.2 (linux/amd64) kubernetes/477efc3/persistent-volume-binder] 127.0.0.1:33828]
<tychicus> May 02 14:36:15 juju-0aa679-default-14 audit[11601]: AVC apparmor="DENIED" operation="open" profile="snap.kube-controller-manager.daemon" name="/var/tmp/" pid=11601 comm="rbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<tychicus> May 02 14:36:15 juju-0aa679-default-14 kernel: audit: type=1400 audit(1493735775.306:336): apparmor="DENIED" operation="open" profile="snap.kube-controller-manager.daemon" name="/var/tmp/" pid=11601 comm="rbd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<lazyPower> tychicus looks like something has crept in since validation that its being blocked
<admcleod> the only thing creepier than magicaltrout is a thawing moose head.
<lazyPower> tychicus I'll take a task from this and circle back but it likely wont be until tomorrow.
<tychicus> thanks again for your help!
<magicaltrout> thanks
<lazyPower> admcleod and you just made it even creepier
<admcleod> there only one way to make this even creepier than it is.
<Budgie^Smore> wow the silence is deafening in here ;-)
<lazyPower> admcleod sucked all the air out of the room :) :)
<admcleod> shhh
<admcleod> watching pidgeons
<lazyPower> haha
<Budgie^Smore> and there was me thinking it was the Freenode netsplit / server crash that did that lazyPower... why do you have to pick on poor admcleod like that, it is soooo mean :P
<lazyPower> we have a weird dynamic
<lazyPower> we pick on each other and do good work when we pair
<jrwren> and I thought it was my bad comcast.
<Budgie^Smore> ah I know that dynamic well so it ain't that weird :P
<Budgie^Smore> picking on each other is safety valve on a pressure cooker
<admcleod> its more like a shallow frying pan with a spritz of margerine spray
<admcleod> some of the teflon coating is peeling off and ends up in the eggs so we're slowly poisoning ourselves
<admcleod> there is a tiny glimmer of hope. the pidgeon overlords may take pity on us.
<Budgie^Smore> so your saying it is time for a new frying pan there admcleod
<admcleod> perhaps a slow death is more comforting in its certainty than one unknown.
 * Budgie^Smore admits he is just bored of being a full time job seeker! 
<Budgie^Smore> maybe I should look at the CDK issues page and see if there is "something" I can fix there
<thomaszylla> hello
<lazyPower> hey thomaszylla o/
<Budgie^Smore> o/ thomaszylla
<admcleod> magicaltrout: have you seen 'theresa may awkwardly eating chips'?
<Spads> wat
<Budgie^Smore> admcleod I think you could have had stopped at "awkward" there
 * Budgie^Smore is a Brit living California 
<admcleod> haha
<Budgie^Smore> All I have to say about the election is "Go SNP!"
<admcleod> fingers crossed with my uk^H^Hscottish passport
<Budgie^Smore> admcleod right!
<Budgie^Smore> so to contain the "may awkwardly...", did you see her awekwardly knocking on doors in Aberdeenshire?
<Budgie^Smore> continue even, coffee needs to hurry up and kick in!
<admcleod> Budgie^Smore: haha no, i literally only saw a guardian article about her eating chips
<Budgie^Smore> admcleod: Daily Mail called it "cringeworthy footage"
<admcleod> heh
<admcleod> e
<tychicus> so I know that juju has a concept of spaces now, can juju be used to add new network interfaces?
<tychicus> for instance I used maas + juju to deploy openstack, but now I need to add a new bridge-mapping to neutron-gateway, but to do that I need a new network interface vlan definition and bridge definition
<rick_h> tychicus: not yet. It's what we want to get to.
<tychicus> rick_h: thanks so for now my best option is to modify /etc/network/interfaces to add the new interface/vlan definition, then I can add that to the bridge-mappings for neutron-gateway
<rick_h> tychicus: hmm, I'm not sure. I'm not sure if there's ways to do that through actions on neutron or what.
<rick_h> tychicus: /me isn't an OS guru unfortunately
<tychicus> ok, thanks
<tychicus> I'm not either, but juju has been very instrumental in helping me to start learning
<tychicus> if I reboot neutron-gateway, juju give the following error after reboot
<tychicus> Services not running that should be: neutron-l3-agent, neutron-metadata-agent, neutron-dhcp-agent
<tychicus> dpkg âget-selections lists them as not installed
#juju 2017-05-03
<tychicus> if you made changes to a juju config, is there a way to have juju "redeploy" the original config?
<lazyPower> tychicus you should be able to extrapolate what that original config was by looking at the defaults in config.yaml
<lazyPower> tychicus otherwise, you just juju config application foo=bar baz=bam
<tychicus> yeah, I did that
<tychicus> I think I horked something with openvswitch
<tychicus> isn't there a juju config âreset
<lazyPower> ah yeah
<lazyPower> juju config --reset foo,baz
<lazyPower> args being the keys you wish to reset to default
<lazyPower> #TIL
<tychicus> guessing that is only for charms and not for bundles
<lazyPower> Correct
<umbSublime> Is there any documentation to use juju to deploy applications to a public-cloud openstack ?
<Budgie^Smore> umbSublime https://jujucharms.com/docs/1.25/config-openstack
<umbSublime> thx Budgie^Smore
<Budgie^Smore> umbSublime that is for 1.25, for 2.1 https://jujucharms.com/docs/stable/help-openstack
<umbSublime> another quick question is, as an openstack public-cloud provider, is there a guide to make the OS compatible with juju ?
<umbSublime> I mean to be fully compatible and also shown in "juju clouds"
<Budgie^Smore> I haven't seen any yet, CentOS was added pretty recently
<umbSublime> hmm, I don't see CentOS with "juju clouds" on version 2.0.2-xenial-amd64
<Budgie^Smore> juju clouds just shows the different clouds and isn't related to the OS installed by Juju
<umbSublime> yes of course
<Budgie^Smore> umbSublime actually I am getting maas and juju mixed up, been a long day... juju probably will never support non-apt based OSes (and probably only Ubuntu OSes)
<umbSublime> that's fine. What I mean is, if I would be a openstack public-cloud provider, How would I make sure my openstack infra is compatible with juju (so my potential users can deploy to ubuntu instances with juju)
<umbSublime> I found this https://jujucharms.com/docs/stable/howto-privatecloud which can probably be adapted for my use-case I think
<Budgie^Smore> cool
<kjackal> Good morning Juju world!
<Mmike> Hi, lads. What are 'hosted models'? I'm getting an error when running the 'juju create-backup' command saying that 'backups are not supported for hosted models'
<Mmike> It's a deployment against openstack provider. So, if I specify a controller model then backups run fine, but is the default model also backed up then?
<Zic> lazyPower: hi, just to report you a strange things that just happens in our production cluster : the iptables's FORWARD chain default-policy pass to DROP from ACCEPT without *any* action of our team
<Zic> lazyPower: all pods has lost their network
<Zic> just re-switch the default-policy with "iptables -P FORWARD ACCEPT" and it was fixed
<Zic> did you ever see that?
<Zic> it affected only one node / 5
<Zic> the only other service witch touch iptables on this node is lxd, but it's not used on this server (it's just here because it's now a part of the metapackage ubuntu-server)
<Zic> wich*
<Zic> which*
 * Zic need moar coffee
<Zic> needs* </flood>
<Zic> ok, find it, it's not LXD, it's UFW : /etc/default/ufw
<Zic> DEFAULT_FORWARD_POLICY="DROP"
<Zic> confirmed, if I reboot another node, the default-policy for the chain FORWARD switch to DROP instead of ACCEPT
<Zic> trying to systemctl disable ufw
<Zic> & reboot
<Zic> hmm, same, maybe it's not ufw either :(
<lazyPower> Zic : thats a new one to me, i haven't seen that
<magicaltrout> ERROR cannot add application \"gitlab\": state changing too quickly; try again soon\
<magicaltrout> what does that mean in bundletester?
<admcleod> magicaltrout: its waiting for the state of 'gilab' to settle, but apparently its not?
<admcleod> magicaltrout: maybe its hook error/retrying very quickly?
<magicaltrout> its not even in the environment
<Zic> lazyPower: I did some new debugging session : it's the cluster which is still in 1.5.3 with docker_from_upstream=true (upgrading is already planed but customer have very few moment to do maintenance outage...), in this Docker version, Docker switch the FORWARD chain default-policy to DROP when doing "systemctl restart docker"
<Zic> lazyPower: in the Docker Ubuntu version, it does not
<lazyPower> Zic: ah good insight
<Zic> lazyPower: it mades me think if the last time we spoke about this docker_from_upstream, where all my containers had no network, it was maybe the exact same problem
<lazyPower> werid i would think kube-proxy would re-read teh tables and fi that.
<admcleod> magicaltrout: huh?
<magicaltrout> well juju status is empty
<lazyPower> *the
<lazyPower> *fix
<Zic> anyway, I plan to downgrade to docker_from_upstream=false before upgrading to 1.6 when I will have the maintenance area from my customer :)
<lazyPower> i think my bluetooth keyboard is dying on me
<admcleod> magicaltrout: is there some weird multi-model oops thing going on
<lazyPower> Zic just FYI with this weeks release that will happen for you automatically
<lazyPower> we're migrating users who have enabled from upstream to archive, and disable the config flag
<magicaltrout> nope as vanilla as it comes
<magicaltrout> although now i paste the command i see the same as well
<ryebot> I'm trying to bootstrap lxd on an aws box:
<ryebot> $ juju bootstrap lxd lxd-test
<ryebot> ERROR no addresses match
<ryebot> lxdbr0 exists
<ryebot> not sure what to check here
<admcleod> ryebot: try with --debug
<admcleod> magicaltrout: try with --debug
<admcleod> :}
<ryebot> will do, thanks
<Zic> lazyPower: nice, I expect that we will have no GC error on docker-ubuntu / K8s 1.6... or that pod limits will mitigate this bad effect
<tychicus> has any one run into an issue where neutron-l3-agent neutron-metadata-agent neutron-dhcp-agent sporadically go missing from neutron gateway?
<tychicus> issuing apt install neutron-l3-agent neutron-metadata-agent neutron-dhcp-agent
<tychicus> then sudo systemctl restart jujud-unit-neutron-gateway-1.service
<tychicus> will re-create the corresponding config files and bring things back online
<admcleod> tychicus: not i - you may want to also ask this in #openstack-charms
<tychicus> admcleod: didn't realize that was there, thanks!
<tychicus> separate question, I did something really silly I accidentally deployed units to my juju controller and juju remove-unit won't remove the units
<tychicus> is there any way to force the removal, or would I be better up backing up and re-provisioning my juju controller?
<magicaltrout> weirdly admcleod ... or maybe not maybe its a feature
<magicaltrout> if i destroy my controller
<magicaltrout> it runs bundletester again
<magicaltrout> but then i have to kill it again and rebootstrap
<magicaltrout> https://gist.github.com/buggtb/09ccdea9771f950ce324d2e46c24126d
<magicaltrout> some random stuff about it being a bundle
<admcleod> magicaltrout: what happens if you manually deploy th gitlab-server charm?
<magicaltrout> if i deploy it without the additional flags
<magicaltrout> it deploys
<rick_h> tychicus: you can force a bit with remove-machine the units on are
<rick_h> tychicus: I'm curious why they won't remove. Maybe there's an error/etc and it needs some juju resolved xxxx ?
<admcleod> magicaltrout: maybe something for tvansteenburgh / coryfu
<tychicus> rick_h: here is what I see
<tychicus> nova-compute/3             blocked   executing  0        10.110.0.111                    (leader-settings-changed) Missing relations: messaging, image
<tychicus>   neutron-openvswitch/11*  error     idle                10.110.0.111                    hook failed: "install"
<rick_h> tychicus: yea, it's in an error state. So to remove it you'll need to first mark it resolved to tell juju "yea yea, it's ok carry on"
<tychicus> are there any specific logs that you would like me to examine
<tychicus> rick_h, I tried that once before, but I'll try it again
<rick_h> tychicus: so as you do that it'll ignore one hook issue and it might run into an issue in the next hook and such
<rick_h> tychicus: so honestly, sometimes you have to do it a few times while removing things
<rick_h> tychicus: but as I said, one thing you can do is to take out hte machine under the unit as well
<tychicus> my only hesitation is that the machine is my juju controller
<rick_h> tychicus: ? well the unit isn't the controller. What machine is neutron-openvswitch/11 on ?
<tychicus> machine 0
<rick_h> tychicus: so this is an openstack on the controller dense mode?
<rick_h> tychicus: yea, that won't work then. best thing to do is run debug-log in one terminal and keep marking resolved and watch it keep trying to tear down the unit
<tychicus> what I did was: juju add-unit nova-compute âto 0
<tychicus> meant to do juju add-unit nova-compute âto 10
<tychicus> but missed a keystroke
<rick_h> tychicus: huh, didn't it fail with there being no machine 10?
<admcleod> tychicus: sometimes, i put "juju resolved thing/0 ; juju remove-unit thing/0" in a for loop, and go do something else for a minute
<tychicus> I think it may be a dependency issue because nova-compute depends on neutron-openvswitch
<tychicus> rick_h: no I never got the machine 10 command typed in, I had intended to place on 10 but accidentally placed on 0
<tychicus> admcleod: I'll give that a try
<rick_h> tychicus: oic, I got it the other way around.
<lazyPower> magicaltrout thats a fun bug for sure.
<lazyPower> magicaltrout i'm not sure why it would be complaining about quick state changes. I suspect thats something we need ot get filed as a bug though
<bdx> has anyone else noticed dangling security groups left behind by juju?
<bdx> http://imgur.com/GF8uPTg
<bdx> :-(
<bdx> only 57 instances deployed .... http://imgur.com/a/Z2e1s
<bdx> yet I have 640 security groups
 * bdx weeps
<rick_h> bdx: huh, there's been bugs there but they were fixed I thought. https://bugs.launchpad.net/juju/+bug/1385276 and https://bugs.launchpad.net/juju/+bug/1625624
<mup> Bug #1385276: juju leaves security groups behind in aws <bug-squad> <destroy-environment> <ec2-provider> <jujuqa> <repeatability> <security> <juju:Fix Released> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1385276>
<mup> Bug #1625624: juju 2 doesn't remove openstack security groups <ci> <landscape> <openstack-provider> <sts> <juju:Fix Released by gz> <juju 2.0:Fix Released by gnuoy> <juju 2.1:Fix Released> <juju 2.2:Fix Committed> <juju-core:Fix Released by gnuoy> <https://launchpad.net/bugs/1625624>
<bdx> rick_h: I just tagged you on that bug
<Budgie^Smore> anyone got any suggestions for intel nuc like systems?
<bdx> possibly you can help get some heat on it
<rick_h> bdx: rgr
<rick_h> Budgie^Smore: sorry, just use nucs here. I've not tinkered with the others like it
<rick_h> Budgie^Smore: biggest thing is the AMT support for MAAS which most of them I don't think do. Even in the NUC line you have to get a couple specific models
<Budgie^Smore> rick_h yeah I figured as much :-/
<Budgie^Smore> rick_h I am just having the one large system running windows (cause I like to play a game that doesn't run well under linux even with wine) struggle
<Budgie^Smore> rick_h trying to decide it is better to get nuc or nuc-like systems or spend the money on cloud credit
<rick_h> Budgie^Smore: so the cloud stuff is handy as you can move it around and make it bigger/smaller/etc. However, real hardware is always faster.
<rick_h> Budgie^Smore: when I push my nucs I'm always floored at how much faster they are than a VM
<Budgie^Smore> rick_h yeah I geet that having been a bare metal guy most of my career
<tychicus> Budgie^Smore: what's your budget, the intel xeon D stuff is really good, but a bit more expensive than a nuc
<Budgie^Smore> tychicus really only want to spend a couple hundred on each and have 4 or 5
<lazyPower> Budgie^Smore i have a handfull of gigabyte brix systems myself
<Budgie^Smore> lazyPower running MaaS?
<lazyPower> negative
<lazyPower> they dont support AMT so i image them every so often
<lazyPower> that or i could enlist them in maas and pull sneaker-net power
<tychicus> May be more than you want to spend, but you can get much better density than the nuc, since the xeon D can handle 128GB ram vs 16GB with the AMT capable NUC https://www.amazon.com/dp/B01M0VTV3E/ref=psdc_11036071_t1_B01M0X365V
<Budgie^Smore> yeah I also don't need 6Gb NICs and SFP+ ports... not really looking at doing SDN at home yet
<Budgie^Smore> admittedly 2 would be nice but I can "fake" that easily
<Budgie^Smore> https://www.amazon.com/ASRock-DESKMINI-110W-BB-US/dp/B01L3J1JFQ/ might be promising
<bodie_> Can't figure out how to get rid of my bad configs.  I have a couple of GCE controllers that I destroyed the real VMs for and now 'status' and so on hang
<bodie_> OS X
<bodie_> 2.1.2-elcapitan-amd64
<bodie_> Any pointers?  There doesn't appear to be a .jenv file in $HOME
<rick_h> bodie_: sorry, I don't follow. Status hangs, but the controllers are gone? What status are you checking?
<rick_h> bodie_: you can use juju unregister to remove controllers that you manually pulled from your controllers list
<bodie_> Hi Rick.  The controllers are still in my list, since destroy-controller also failed to finish...
<bodie_> I just want to erase everything and start over from scratch.
<rick_h> bodie_: k, you can use unregister to clean up the controllers from your listing. If you want to remove config/etc they're int he data directory (~/.local/share/juju/)
<bodie_> Ok :+1: thanks @rick_h
<rick_h> bodie_: k, let me know how you get along and if there's anything else you hit.
<bodie_> rick_h -- the real issue was that my deploy was stuck waiting for some machines to come up
<bodie_> GCE provider got set up OK, and I was able to deploy and use juju-gui
<bodie_> I'd previously tried to deploy canonical kube from my CLI, but the machines were stuck waiting
<bodie_> (Maybe due to a bad connection on the train leaving some API calls unfinished?)
<bodie_> So, I blew that setup away and tried to use juju-gui to deploy it
<bodie_> But I suspect somewhere in there something got mixed up
<lazyPower> tychicus the perk to a nuc vs that xeon is its a 1u vs 3 slices of toast.
<lazyPower> i myself have some space constraints. I actually have a 2u hp proliant sitting in my closet collecting dust because fan noise and space :|
<lazyPower> i had it running in my office -once- since i moved in. It sounded like a b2 bomber landed in my office and hangouts were out the window :{
<tychicus> don't get me wrong, I really like the form and noise factor of the nuc
<Budgie^Smore> not to mention those of us that want that environment aren't running huge workloads just need multiple small machines
<Budgie^Smore> How many times have you deployed CDK to it lazyPower?
<lazyPower> Budgie^Smore every release
<lazyPower> I also have an older i7 wokstation hooked in as a beefier worker. I wanted something to run the game servers on
<lazyPower> so to date: its 2 Brix, and 1 i7
<tychicus> my home lab still consists of an old dell core2duo machine and a mac mini, both were free so they were the right price
<Budgie^Smore> I think someone is missing out a significant niche market
<jrwren> those old core2duo's work wonders IME ;)
<tychicus> can the import-ssh-key or add-ssh-key command be associated with a controller rather than a model?
<tychicus> rick_h: admcleod: got the stuck charms removed
<tychicus> juju resolved --no-retry neutron-openvswitch/11; juju remove-unit neutron-openvswitch/11; juju remove-unit nova-compute/3
<tychicus> didn't know about the --no-retry option for resolved, but that did the trick
<tychicus> thanks again for your help, and pointing me in the right direction
<admcleod> tychicus: ah cool
<lazyPower> well to be fair i didn't include any of the appliances and arm based boards i have running
<lazyPower> i seem to run machines for the sake of blinken lights
<bodie_> rick_h: I managed to clean up and re-bootstrap my google provider, but when I `deploy canonical-kubernetes`, some machines remain pending.
<lazyPower> bodie_ do you have a fresh google cloud account?
<Budgie^Smore> lazyPower hehehe... I am just missing my lab systems
<bodie_> Yeah.  I created the project / juju credentials per the user guide
<rick_h> tychicus: good to hear
<lazyPower> bodie_ there are CPU restrictions on a new account, and i know that canonical-kubernetes is a fairly large requirement...
<bodie_> Mmm... that could be it
<lazyPower> bodie_ you're running into that limit :( i'm 80% certain of this
<rick_h> lazyPower: bodie_ yea, I think you need to request > 10 cpus or something
<lazyPower> bodie_ in the interim to get you un-blocked, you can deploy kubernetes-core, which is a much lighter bundle for experimentation
<bodie_> Righto
<bodie_> Thanks
<lazyPower> No problem, if that continues to be problematic, just let me know and i'll do what i can
<lazyPower> even if its perform a rain dance to appease our google overlords :)
<admcleod> i think they're pretty quick at increasing limits?
<lazyPower> admcleod in my experience it can take a few hours from request to fulfilment
<bodie_> Hail to the Basilisk
<admcleod> a few HOURS?
<lazyPower> but theyre pretty good about just handing it over
<lazyPower> yeah, submit support ticket
<lazyPower> wait
<lazyPower> profit
<lazyPower> unless you have an account rep, then you can call
 * admcleod hops on spaghetti monster and flies off towards the horizon
<bodie_> Apparently "free tier" (new $300 of credit mode) doesn't let you have more than 8 cores up at a time
<bodie_> c'est la vie
<Budgie^Smore> what would be a good price point for say a 5 (maas + 4 node) system cluster for a "home lab"?
<magicaltrout> one million dollars........
<Budgie^Smore> you got a million magicaltrout, I will build you the best "home lab" cluster ;-)
<magicaltrout> i'm building one actually similar to the ubuntu orange box that these chaps take on tour
<magicaltrout> except i'm cheap and cheating
<magicaltrout> but i am using these: http://www.udoo.org/udoo-x86/
<Budgie^Smore> yeah I liked the look of the orange box
<Budgie^Smore> what do you use for "power management"?
#juju 2017-05-04
<umbSublime> Budgie^Smore, magicaltrout I'm not even sure Canonical still uses those (pretty awesome) orange boxes for OS training anymore, IIRC they now use remote servers from different providers
<Budgie^Smore> umbSublime pretty sure you are right there, those were still cool though
<umbSublime> heck yah
<umbSublime> they had me drooling when they first came out :p
<stub> The orange boxes tend to get used where network connectivity is limited, cause they can be flown in with archive mirrors and whatnot prepopulated
<kjackal> Good monrning Juju world!
<BlackDex> Hello, can i run juju within a lxd when using MAAS as its cloud-provider?
<BlackDex> i mean the juju bootstrap
<BlackDex> so, i want to bootstrap juju within a lxd container and use maas for the rest
<BlackDex> currently i'm creating a kvm instance and run the bootstrap on that
<rick_h> BlackDex: not at this time. One "provider" per controller.
<BlackDex> and if i create a lxd and let it detect by maas? Or that isn't an option?
<rick_h> BlackDex: yes, if you load a vm of any sort into maas so that it's the maas api/provider that's in use you're ok
<BlackDex> oke rick_h Thx, i will try that :)
<kim0> Howdy folks .. I just tried to deploy kubernetes to Azure cloud .. And it is stuck .. I see 4 deployments have failed in Azure portal :/
<kim0> Can anyone help me debug this or get it working
<lazyPower> kim0: i can certainly try to lend a hand here. What units are failed and how did they fail?
<kim0> lazyPower: actually not units .. I think it's machines that failed
<lazyPower> kim0 ah, so azure failed to give you the machines?
<kim0> https://www.irccloud.com/pastebin/r7A8WpgV/
<kim0> yes .. the deployment to Azure failed
<lazyPower> that certainly looks indicative that azure didn't give you the vms.
<kim0> is there a way to delete those VMs and re-deploy them
<lazyPower> you can try juju retry-provisioning 0
<lazyPower> same with 1
<kim0> interesting Ok
<lazyPower> and it should re-request the machines from azure
<kim0> I had done juju add-machine
<lazyPower> but you may have to wait for them to enter a failed state
<kim0> but it's not appearing into juju status for some reason
<lazyPower> i dont think it will retry if they are marked as down
<kim0> $ juju show-machine 0
<kim0> model: gulfk8s
<kim0> machines:
<kim0>   "0":
<kim0>     juju-status:
<kim0>       current: down
<kim0>       message: agent is not communicating with the server
<kim0>       since: 04 May 2017 14:05:27+02:00
<kim0>     instance-id: machine-0
<kim0>     machine-status:
<kim0>       current: provisioning error
<kim0>       message: Failed
<kim0> It says .. "Provisioning error" I guess juju should know it has failed :)
<kim0> I tried juju "retry-provisioning 0" .. but as you expected, it's not retrying
<kim0> any way to force-fail the old machines or something
<kim0> it's been an hour really .. so I guess it might never fail them
<kim0> lazyPower: Any ideas ^ .. Thanks!
<lazyPower> kim0 I dont, the best i could offer woudl be to remove the model and try again.
<kim0> yeah .. I tried deploying this a couple of months back, and got the same VM provisioning failure .. so a little :/
<kim0> I can try one more time
<lazyPower> kim0 : do you have any restrictions on your account or anything similar?
<lazyPower> kwmonroe i know you have the broadest welath of knowledgea bout our azure provider
<lazyPower> kwmonroe do you see failed provisioning often?
<kim0> kwmonroe .. The error Azure portal gives me is like "PutVirtualNetworkOperation xxxx was cancelled and supersceeded by PutVirtualNetworkOperation yyy. Code: CancelledAndSuperseededDueToAnotherOperation)
<kim0> To me .. this looks more like juju's fault than Azure's
<kwmonroe> yup lazyPower.. bug 1673847 is the reference bug (kim0 has already commented).
<mup> Bug #1673847: azure does not handle failed deployment well (juju-2.1.2) <azure-provider> <intermittent-failure> <retry> <juju:Triaged> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1673847>
<lazyPower> kwmonroe fantastic. Thanks for confirming
<lazyPower> :(
<lazyPower> well poo, wont fix on 2.1 which means you wont see it in this series, but 2.2 is right around the corner
<kim0> Is it already fixed in 2.2 devel ? can I try that ?
<lazyPower> I don't see anything related to "fix committed" which tells me its still present in 2.2 devel
<kim0> kwmonroe: Thanks for confirming! Any advice to manually workaround this issue ?
<kim0> The bug OP says he hits this .. 1 out of 10 times .. to me, I hit it the 2 times I tried juju :)
<kim0> If I should just destroy the model & retry, I can do that too
<kim0> I tried "juju add-machine" which seems to work .. The machine is started in azure portal .. put it is not listed under my k8s model .. not sure why
<kim0> I was hoping to replace the ill machines with healthy ones
<kwmonroe> kim0: my workaround (i'm the bug OP btw) is to "juju add-unit <application>" on anything that juju status reports as "provisioning error".
<kwmonroe> kim0: it's not pretty, but it keeps any relations in tact and is a bit faster than totally removing the application and re-adding it with new relations later.
<kim0> aha .. so that will allocate a new VM and
<kim0> deploy on it
<kwmonroe> correct kim0
<kim0> my only worry, if unit/0 is "special"
<kim0> Ok .. easyrsa/0 was down .. trying to add a unit on that
<kwmonroe> kim0: it really shouldn't be.. there's no guarantee that /0 was the first unit to become ready (ie, you may have deployed 2 units at the same time and unit/1 just happened to beat /0 to ready state)
<kwmonroe> kim0: so things like charm leadership and even tests should not be relying on /0 as any indication of "first" or "leader" or whatever.
<kim0> For example .. etcd/0 is on a broken machine .. while etcd/1 & /2 are on working machines .. However it seems they are blocked waiting for etcd/0 !
<kim0> Nice .. easyrsa/1 is now healthy!
<kim0> kwmonroe: should I somehow remove the old easyrsa/0 ?
<kwmonroe> kim0: i'm not too familiar with etcd -- lazyPower, is there something special about etcd/0?
 * lazyPower reads backscroll
<lazyPower> kim0 kwmonroe - shouldn't be blocked waiting on etcd/0. Which unit has the asterisk next to its name?
<kwmonroe> kim0: i do remove the failed units because i can't stand being reminded of them every time i type juju status ;)  i think the syntax is "juju remove-unit easyrsa/0", but if that doesn't work, "juju remove-machine <machine-number-for-easyrsa/0>" should do it.
<lazyPower> i would presume etcd/1* if it was the first to come active which would earmark it as the leader for the rest of the units coming online.
<kim0> lazyPower: etcd/2 has the *
<kim0> is the "every unit on a separate VM" the norm in juju world ?
<lazyPower> kim0 - can you provide more detail as to where it appears they are waiting on etcd/0?
<kim0> mm it was just saying "blocked" .. since then I add-unit one etcd .. and now it says ready!
<lazyPower> Ok, it should only be blocked if its missing the easyrsa details
<kim0> that was indeed the case .. I had also added unit on easyrsa
<lazyPower> it requires TLS certs to operate as of about a year ago. I flipped the switch to disallow insecure connections
<kim0> sorry I don't know the order of events :)
<lazyPower> All good kim0 - its a learning experience :)
<kim0> exactly
<kim0> I'm trying to post the full juju status
<kim0> http://paste.ubuntu.com/24511284/
<lazyPower> ok that status message for etcd/2 should update within 5 minutes when it runs update-status again and it'll report 2 peers
<kim0> What does the * besides etcd/2 mean
<lazyPower> that denotes the current juju leader
<lazyPower> in some instances like the etcd charm, we use the juju leader to coordinate cluster events
<kwmonroe> kim0: ideally, each unit would be isolated (either on a totally separate machine or in a separate container).  the exception is for "subordinate charms".  these are things like nagios or ganglia monitors, rsyslog, etc that make no sense to stand alone in a VM.  in that case, both a principal charm (like etc) and a subordinate (like ganglia-node) would live side-by-side on the same unit.
<kwmonroe> kim0: this ideal isolation is not enforced, so you *can* jam a whole bunch of charms onto the same unit, but that usually leads to package conflicts or other headache..
<kim0> aha .. Ok! I was really thinking about container isolation (k8s style)
<lazyPower> you can also colocate using lxd which doesn't suffer from that, however it comes with other nuances you have to be aware of. Cross host container networking is only supported in MAAS at this time.
<kim0> nvm .. I'll keep separate VMs for now
<lazyPower> kim0 as this is your first dpeloyment, next go-around you can start with a much smaller bundle - kubernetes-core, which only requires 3 units.
<lazyPower> colocated 1 etcd/easyrsa, 1 master, 1 worker.
<lazyPower> same kubernetes experience, smaller requirements. CDK is more of a production-facing minimal deployment, where you wish to have HA control plane, and resilient etcd
<kim0> I actually care about a production ready deployment
<kim0> it seems remove-unit  does not remove the underlying machine
<kim0> I tried to remove the machine by hand .. but it either needs time, or is not working
<kwmonroe> kim0: use a bigger hammer:  juju remove-machine --force <number>
<kim0> Ok .. just did :)
<kim0> removed
<kim0> cool
<kim0> seems to be converging to a working setup :)
<kim0> is there a possibility to power-off all machines (to save money) .. yet start them tomorrow ?
<kwmonroe> kim0: even powered off, i think clouds will still charge you (not for IOPS or cpu time, but for holding the underlying resources for you)
<kim0> yeah I understand that .. but that cost is like 5% of the running cost
<kwmonroe> kim0: so if you really don't need the cluster overnight, just destroy the model and re-deploy it when you need it again
<kim0> well .. I've spent 2 hours on a bunch of add-unit / remove-unit / remove-machine --force
<kim0> so if possible .. I want to keep it
<lazyPower> kim0 it shouldn't have any issues coming back up from a stopped state
<lazyPower> kim0 if you find issues there, i want bugs please <3
<kim0> do I stop from azure or juju
<lazyPower> the azure cp
<lazyPower> you should be able to halt the vms or suspend them without any penalty to functionality
<kim0> cool!
<admcleod> or you could juju run shutdown
<kim0> I am approaching an "all-green" state .. exciting :D
<kim0> oh checking that out
<lazyPower> yeah
<lazyPower> juju run --all "shutdown -h now"
<lazyPower> admcleod i'm not sure if that marks the vm as halted in azure cp tho
<kim0> oh that's like a parallel ssh .. I see
<admcleod> lazyPower: neither!
<kim0> yeah .. it doesn't
<lazyPower> i know some providers decouple the power state in th hypervisor from the state of the unit...
<admcleod> *adds to notes*
<kim0> I have to "deallocate" the VM .. so I'll use the azure tools
<lazyPower> yeah
<lazyPower> ^
<lazyPower> do that
<kim0> Awesome!
<lazyPower> kim0 now, you're basically testing our failure recovery model :)
<lazyPower> fyi
<kim0> hhhh
<kim0> hope it works :)
<lazyPower> so if you do find bugs, i want them, plz plz plz dont let that go unnoticed
<kim0> Sure thing
<lazyPower> <3 appreciated
<kim0> one last thing
<kim0> Should I expect to be able to scale kubernetes worker nodes up/down & upgrade kubernetes versions from now on ?
<lazyPower> yes
<kim0> ie should the above work without a party ?
<lazyPower> we're cutting a 1.6.2 release soon (probably today)
<kim0> Awesome!!!
<lazyPower> so you can test that function relatively soon
<kim0> I will love to upgrade from 1.6.1 to that
<lazyPower> :)
<lazyPower> wish granted
<kim0> Great .. I appreciate a ping after it's push
<kim0> pushed*
<lazyPower> sure
<lazyPower> on here?
<kim0> Yep
<lazyPower> k
<kim0> lazyPower: how many hours roughly to go
<lazyPower> if you subscribe to the juju mailing list we also hit that, kubernetes users
<admcleod> lazyPower: the release notification also goes to a list too doenst it?
<admcleod> right
<lazyPower> reddit
<kim0> All VMs get public IPs right
<kim0> do those VMs get security updates too ? :D
<lazyPower> kim0 not without something like landscape client attached or installing unattended-upgrades
<lazyPower> kim0 and ot respond to your question: SUCCESS! -- 146 Passed | 0 Failed | 0 Pending | 442 Skipped
<kim0> :D
<lazyPower> we're close, getting clean test results from e2e on our 1.6.1 => 1.6.2 on 2 clouds now
<kim0> any way for juju to install unattended-upgrades on the nodes it's managing ?
<kim0> or should I do ansible for that :)
<rick_h> kim0: yea, sec. I highlighted that charm in the juju show last week
<rick_h> kim0: https://lists.ubuntu.com/archives/juju/2017-April/008838.html
<kim0> ð
<kim0> juju deploy unattended
<kim0> ERROR cannot resolve URL "cs:unattended": charm or bundle not found
<rick_h> kim0: sorry, it's just a user charm atm: https://jujucharms.com/u/paulgear/unattended/
<rick_h> kim0: try the copy/paste command there.
<kim0> it seems to use a local file ./unattended .. should I git clone it first
<kim0> I expected "juju deploy paulgear/unattended" to work but it didnt
<tychicus> rick_h: is the juju show something that is recorded?
<rick_h> tychicus: it sure is, check out https://www.youtube.com/jujucharms and there's a playlist for just the juju show episodes
<rick_h> kim0: the copy and paste should have gotten you juju deploy cs:~paulgear/unattended-2
<tychicus> fantastic, thanks!
<kim0> rick_h: sorry .. my eye totally missed that little box up there :)
<rick_h> kim0: all good, helpful for making it dirt simple to get the right username/etc.
<kim0> @channel .. Thanks for all the awesome help .. I have an all-green deployment now ;)
<rick_h> kim0: <3 awesome
<lazyPower> kim0 \o/ partyyyy
<kim0> :+1
<kwmonroe> kim0: head's up -- i just use the azure tools to put a machine in "Stopped (deallocated)", and when i restarted it, it got a new public ip.  this seems to cause juju to switch over to the 192.x private address, which is no longer addressable.
<lazyPower> kwmonroe good catch. we're not going to recover from that
<kim0> hmm
<kim0> At least you guys should allocate static IPs I guess
<kwmonroe> rick_h: is there a way for juju to "refresh" the public-ip from the provider?  or does it perhaps poll periodically to see if a public ip has changed?
<rick_h> kwmonroe: so...I know there's open bugs about machines rebooting to different IPs. I'm not sure what the resolution of those bugs has turned to off the top of my head
<marcoceppi> kwmonroe: from my experience the agent will recover, eventually
<kwmonroe> ok - i'll at least give it the update-status window and see.  meanwhile i'll checkout some lp bugs
<kwmonroe> thx rick_h marcoceppi
<kim0> how much is that window
<kwmonroe> 5 minutes
<kim0> cool :)
<kim0> Are charms written in a way such that any app is scalable .. For example, I see kubeapi-load-balancer and kubernetes-master and I jus don't know whether or not it's wise to try scaling those up
<lazyPower> kim0 - each of those components are written in such a way that you can scale them
<magicaltrout> you can scale charms, whether they expect to be scaled is up to the developer
<kim0> do I get some error if something should not be scaled
<lazyPower> an they will reconfigure when a scale event (up or down) happens.
<lazyPower> kim0 the only charm in that bundle that doesn't expect to be scaled at this point is easyrsa
<kim0> so what happens when I scaled that up
<lazyPower> we have an open item of medium priority on that functionality. it involves cloning the CA, doing intermediate signing certificates, and a dance that i haven't fully wrapped my head around.
<lazyPower> you'll get 2 separate Certificate Authorities, adding new units may be problematic at that point.
<lazyPower> however existing units will be uneffected.
<kim0> Ok thanks
<kim0> I guess it should at least error out, that scaling easyrsa is not a recommended action or something
<kwmonroe> kim0: the juju agent on my re-started unit does eventually sync / display the new public address, which means addressability is good again.  it took 15 minutes for me -- not sure why that amount of time, but i'll deallocate again and see if it's consistent.
<kim0> Awesome, thanks
<magicaltrout> marcoceppi: duno who monitors the form submission at developer.juju.solutions but if you find one from my new guy and a quality message that i didn't write at all
<magicaltrout> can you send him some tokens?
<kim0> Docs say "By default, the channel will be set to stable, which means your cluster will always be upgraded to the latest stable version of Kubernetes available." .. Does that auto-reboot nodes by default ?
<marcoceppi> kim0: it won't reboot your machines at all, just updates the software running on them
<kim0> marcoceppi: so a reboot is not even needed ?
<marcoceppi> correct
<marcoceppi> and if you combine that with things like live patching, you won't have to reboot for kernel updates either
<magicaltrout> winning
<kim0> cool stuff
<kim0> you still have to reboot for glibc updates though :P hhh
<kwmonroe> kim0: second deallocate/restart went faster.  the unit refreshed it's public ip 5 minutes after coming back up.
<kim0> Very good!
<lazyPower> that may cause an issue with the certs
<kwmonroe> kim0: so that's all well and good, but if things expect a static ip, you still might be in trouble.
<kwmonroe> right lazyPower
<lazyPower> certs add the public IP as a SAN
<lazyPower> at time of request
<lazyPower> which we have an open bug to re-key infra, but that hasn't been started yet
<kim0> afaik, the public IP isn't even "on" the VM ?
<kim0> does it go through the trouble of finding it out to add it to the cert
<lazyPower> sure does
<lazyPower> unit-get public-address is passed in as a subject-alt-name on the CSR
<kim0> is there a mode, where almost all VMs do not get public IPs to begin with
<lazyPower> kwmonroe https://github.com/juju-solutions/layer-tls-client/issues/8
<lazyPower> i filed a bug about this so we can track it and get layer-tls-client updated with some logic to re-key during normal operating events
<kwmonroe> kim0: ^^ :)
<kim0> ð
<kim0> so basically today, upon nodes reboot .. I should expect the cluster to break, right
<magicaltrout> reboots are for wimps
<kim0> hhhh
<magicaltrout> real men redeploy from scratch
<kwmonroe> kim0: no, you should not expect any OS-level reboot to change the IP.  it's only when you suspend/deallocate from the cloud control panel.
<kim0> Aha got it
<kim0> juju set-constraints kubernetes-worker mem=8G
<kim0> mm that ^ is still not too helpful to help me get the SSD variant of Azure VMs :/
<kwmonroe> kim0: docs will typically use the least-common-denom for application constraints.. in your case mem=8G is a common constraint that will work across aws/gce/azure/etc.  juju also supports cloud-specific constraints.  so in your case, if you're really sure you want azure, you could run "juju set-constraints <app> instance-type=Standard_D1_v2"
<kim0> Thanks!!
<kwmonroe> kim0: the list of instance types for azure (in order of cost) are here:  https://github.com/juju/juju/blob/2.1/provider/azure/instancetype.go#L29, and pricing here: https://azure.microsoft.com/en-us/pricing/details/cloud-services/
<kim0> kwmonroe: Thanks for all the help!
<kwmonroe> np!
 * magicaltrout gives kwmonroe a supportive pat on the back
<magicaltrout> well done kevin \o/
<kwmonroe> heh
<kim0> kwmonroe: fyi, it seems the instancetype.go is missing some newer VM types like Standard_DS1_v2 (actually all DSv2-series series) and Av2-series ..etc
<kwmonroe> yeah kim0 - looks like instancetype.go is not the definitive list (sorry 'bout that).  juju does support DSX_v2, and you can see the full instance-type constraint list here:  http://paste.ubuntu.com/24511657/
<kim0> cool np
<kim0> When I try to deploy a VM with constraint "instance-type=Standard_DS1" .. I only get "current: provisioning error"
<kim0> Any way to get more meaningful errors ?
<kwmonroe> kim0: what region are you deploying to?
<kim0> westeurope
<kwmonroe> kim0: i was gonna say your region might not have DS machines available, but https://azure.microsoft.com/en-us/regions/services/ shows westeurope is supported
<kim0> Can I see the error coming back from azure somewhere
<kwmonroe> kim0: you can go through the azure portal, select your resource group, and then "Deployments"
<kim0> kwmonroe: Got it .. I see the error
<kwmonroe> kim0: is it the PutVirtualNetworkOperation from bug 1673847?
<mup> Bug #1673847: azure does not handle failed deployment well (juju-2.1.2) <azure-provider> <intermittent-failure> <retry> <juju:Triaged> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1673847>
<kim0> Unable to create the VM bec this size is not available in the cluster where the availability set is created
<kim0> Strange error .. first time to get this from Azure!!
<kwmonroe> kim0: let's see if juju is exposing that with a different status format.. try "juju status <unit> --format=yaml"
<kim0> not really the machine part is only saying "provisioning error"
<kim0> http://paste.ubuntu.com/24511934/plain/
<kim0> I guess this *might* be bec I'm using a test account
<kwmonroe> ok kim0 - would you mind adding another comment to bug 1673847, listing this new error message?  i think minimally it would be nice if juju would expose these provisioning error messages rather than having to dig through the azure portal.
<mup> Bug #1673847: azure does not handle failed deployment well (juju-2.1.2) <azure-provider> <intermittent-failure> <retry> <juju:Triaged> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1673847>
<kim0> kwmonroe: Done
<kim0> kwmonroe: Are we nearing the 1.6.2 push :)
<kwmonroe> kim0: that's a question for lazyPower / kjackal / ryebot.  they're mashing lots of buttons atm.
<lazyPower> kim0 once my co-worker gets back from lunch we were planning on a release
<kim0> Sorry confused
<kim0> Awesome keep rocking :)
<Budgie^Smore>  o/ juju world
<lazyPower> \o Budgie^Smore
<lazyPower> got a 1.6.2 release coming your way shortly
<Budgie^Smore> lazyPower coolio, would need to find an environment to deploy it since I no longer have the setups I had :-/
<lazyPower> Budgie^Smore apply for cloud developer credentials
<lazyPower> help us find bugs
<lazyPower> http://developer.juju.solutions
<Budgie^Smore> lazyPower you know me, always happy to go bug hunting ;-)
<Budgie^Smore> OK I have filled in the form, soooooo now we wait ;-)
<lazyPower> awesome :) when marco isn't out doing sprint type stuff you should get an email with some creds
<lazyPower> or a request for more info
<lazyPower> either way, you'll hear back from us shortly
<Budgie^Smore> well even if it a day or 2 it is still faster than HR ;-)
<lazyPower> allright 1.6.2 has hit stable channels
 * lazyPower raises a cuppa coffee to the sky
<lazyPower> kim0 1.6.2 release ping
<kim0> \o/
<kim0> how do I upgrade to that
<lazyPower> https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/
<kim0> mm `juju status` does not show an upgrade is available .. just saying :)
<Budgie^Smore> mmm is juju status suppose to show upgrade availbility or just the current status of the model?
<kim0> Docs say: You can use juju status to see if an upgrade is available. There will either be an upgrade to kubernetes or etcd, or both.
<kim0> kubernetes-master seems to have upgraded itself to 1.6.2!
<lazyPower> juju status --format=yaml
<lazyPower> smart output i think hides that notation
<lazyPower> which is a good call, i had not thought about that.. one of those things i've just become accustomed to. inversely, if you're using the GUI, the GUI shows it under the charm detail
<lazyPower> kim0 thats snaps in action ;)
<kim0> even in the yaml format .. I cannot easily spot what should tell me there's an upgrade
<kim0> @lazyPower .. so it's normal that master auto-upgrades right
<lazyPower> kim0 only when there is an upgrade in its subscribed chanel.
<lazyPower> it wont auto-uprade between minor releases, eg: when we cut and push 1.7 to stable
<lazyPower> yo wont auto upgrade to 1.7, you will need to configure teh charms to look at that channel in order to receive the upgrade
<lazyPower> but for minor patch releases, you get those automatically
<marcoceppi> kim0: lazyPower juju searches for upgrades like daily
<kim0> yeah .. so for -worker .. there is an upgrade (it's now on 1.6.1) .. but my eyes can't see where the upgrade is
<marcoceppi> so you won't see an upgraded charm available for quite a while
<marcoceppi> well, maybe 6 hours
<kim0> master upgraded like 10 mins after you guys announced it :)
<kim0> lucky me I guess
<kim0> but -worker still waiting
<marcoceppi> lazyPower: we should add a "refresh" action to master and worker, so people like kim0 can just get the latest "now"
<lazyPower> kim0 juju upgrade-charm kubernetes-worker should get it prompting you to run the upgrade action.
<lazyPower> @marcoceppi juju run-action kubernetes-worker/0 upgrade already does that ;)
<marcoceppi> oh, udhhh
<lazyPower> <3
<kim0> Here's the yaml format: http://paste.ubuntu.com/24512609/
<kim0> there's no hint there is an upgrade, or is there
<lazyPower> kim0 - It may not tell you anything about the upgrade until the controller polls for upgrades to charms in the env.
<lazyPower> kim0 marcoceppi stated that was ~ every 6 hours or so. perhaps daily. I'm not 100% positive on exactly when it does that either but i can certainly find out and ping back.
<kim0> aha I see
<marcoceppi> kim0: you can still run the upgrade, even if juju doesn't tell you about one
<kim0> I triggered the update manually
<marcoceppi> it'll check when you run the command
<kim0> yep
<kim0> I suppose that kills any running pods .. or does it
<marcoceppi> that's why you'll get the prompt about having to run the upgrade action
<lazyPower> Only in rare instances will it incur downtime, and thats why its gated behind an upgrade action.
<lazyPower> but 90% of the time its only recycling kubelet, which has no effect on the running workloads
<kim0> Well for me, there was no "prompt" .. it just did its thing
<kim0> $ juju upgrade-charm kubernetes-worker
<kim0> Added charm "cs:~containers/kubernetes-worker-23" to the model.
<kim0> that was all .. no questions asked
<kim0> Upgrade done! well .. I have to say, this is sweet!
<lazyPower> kim0 thanks for the positive feedback :) the team appreciates it
<kim0> What if I want to change the VM type of worker nodes
<kim0> I can add a constraint, add new nodes .. but how do I get rid of the old ones
<lazyPower> kim0 i would recommend blue-green style deployment
<Budgie^Smore> kim0 you would have to add / destroy units for that
<lazyPower> kim0 juju deploy cs:~contianers/kubernetes-worker  worker-beta --constraints="mem=16G"
<lazyPower> add relations
<lazyPower> wait for teh dust to settle
<lazyPower> cordon the og nodes
<lazyPower> juju run-action kubernetes-worker/0 pause
<lazyPower> ... down the line...
<lazyPower> once all nodes have been evacuated
<lazyPower> juju remove-application kubernetes-wroker
<kim0> Got it!
<kim0> Why do I need to add relations manually
<lazyPower> i have a lot fo doc updates i see
<kim0> I didn't need that in the initial deployment
<lazyPower> well when you do the blue-green style, there's nothing telling juju how to wire the deployment
<lazyPower> bundles are pre-modeled applications in a specific formation for you to consume
<kim0> ah
<lazyPower> you could take the canonical bundle, and modify it with the alternative deployment and deploy it into the same model
<lazyPower> it will converge
<lazyPower> now that may come with its own flavor of challenges if you have mutated the model... which is why i would encourage you to do it manually
<lazyPower> what you can do is just export the model as well
<lazyPower> make changes in the yaml
<lazyPower> then apply that yaml
<lazyPower> there's a lot of options, but as a dev that really likes to know how things work, i'm always going to recommend the manual method. Keeps things simple when things go wrong and i can help you unwind or recover from that :)
<lazyPower> its harder when we're playing trace the bug
<marcoceppi> lazyPower:  it's easier to just juju set-constraints I think
<lazyPower> or that
<marcoceppi> kim0: we'll document this for sure
<lazyPower> but i hope you remember you did that when you dont want that instance type anymore :)
<lazyPower> https://www.reddit.com/r/kubernetes/comments/699v24/canonicals_support_for_kubernetes_162_released/
<lazyPower> upboats appreciated
<mwhudson> balloons: i think i need an illustrated map of the ppas you are using...
<tychicus> is it possible to start a machine that is powered off via juju?
<rick_h> tychicus: to power it back on with juju? how did you power it off via juju?
<tychicus> juju run --machine=4 "shutdown -h now"
<tychicus> machine is tied to maas, I know i can power it back on from maas, but I wasn't sure if there was a way to juju run âmachine=x start
<rick_h> tychicus: oh heh no. juju run works by ssh'ing to the machine
<rick_h> tychicus: so it has to be listening to ssh for that to do anything unfortunately
<tychicus> ok, that's what I throught
<Budgie^Smore> OK I upboated that, now if only I had somewhere to "play" with 1.6.2! ;-)
<tychicus> I couldn't find the upboat icon
<Budgie^Smore> tychicus see the arrows at the side of hte link?
<tychicus> ah those are the boat sails ;)
<tychicus> I'll run through a cdk  deployment today, if only I could figure out why my floating IP's work in openstack, but directly connecting an instance to the ext_net does not :(
<kim0> Would "upgrade-charm" also upgrade me to 1.7 when it's released
<kim0> or is it involved
<marcoceppi> kim0: you'll need to change configuration i beleive it just targets 1.6/stable
<kim0> ok still easy enough :)
<kim0> is it too much to ask for worker autoscaling for kubernetes :)
<rick_h> kim0: have to see if https://jujucharms.com/charmscaler/ will work out for you
<kim0> well that is interesting, however I really meant adding more nodes under k8s which this scaler doesn't seem to do
#juju 2017-05-05
<Budgie^Smore> I never got an op to "play" with that charm rick_h, still want too
<ME_54> hi
<ME_54> god nigt
<ME_54> good night ***
<ME_54> AlguÃ©m do brasil por ai ?
<Zic> hmm, just saw that kubernetes-master & kubernetes-worker automatically upgrades to 1.6.2 from 1.6.1 without action... so what part of https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/ do I need ? :D
<Zic> (hi here o/)
<kjackal_> hi Zic
<kjackal_> Zic: The binaries of kubernetes are shipped as snap packages. This is why you see them being upgraded to 1.6.2. The installation & management of your cluster is done through charms so by upgrading the charms you get you cluster lifecycle management upgraded.
<Zic> kjackal_: thanks, so I always need to do some juju upgrade-charm for upgrading the operationnal code
<kjackal_> Zic: yes
<Zic> I also have a lab which not run on baremetal but in LXD via conjure-up, do you know if I can install a specific version of charms/K8s via conjure-up+LXD ?
<Zic> (it's to test the 1.5.3 -> 1.6.2 upgrade of our production cluster in a lab)
<kim0> What I understood from being here yesterday, was that k8s auto-upgrades itself within the 1.6.x series .. but jumping to say 1.7.x will need me changing the config variables to point to 1.7
<kim0> I'd love to test upgrading 1.6.1 -> 1.6.2 like I did yesterday .. Can I force juju to install a specific version of k8s ?
<kim0> I think I need to change the "config --channel" thing .. but not sure what to set it to (instead of stable) .. Where do I see available channels!
<kjackal_> Zic upgrading snaps on lxd will not work due to this bug: https://bugs.launchpad.net/snapd/+bug/1668659
<mup> Bug #1668659: Using snaps in lxd can be problematic during refresh (using squashfuse) <snapd:In Progress by zyga> <https://launchpad.net/bugs/1668659>
<Zic> kjackal_: hmm, seems like it will be easier if I running my lab like a baremetal cluster, so without LXD and just classical VMs :/
<Zic> it's not a problem, from ressources point of view,  but I prefer to use LXD instead of classical VMs for labs
<Zic> s/I running/I run/
<kjackal_> Zic yes, physical machines should work.
<kjackal_> kim0: there is no easy way to pin snaps to 1.6.1 during deployment and then unpin them in order to trigger the upgrade
<Zic> kjackal_: for forcing 1.5.3, I just need to specify the old version of all charms composing the CDK bundle, right?
<Zic> (in the Juju GUI)
<Zic> before deploying
<kjackal_> the 1.6.x snaps are in the same track and in a way new versions shadow the old ones (nothing special, its like upgrading debs)
<kjackal_> kim0: ^
<kim0> Any option to demo "upgrades" to a friend ?
<kjackal_> Zic: kim0: You can upgrade from 1.5.3 to 1.6.x . Give me a moment to get the revisions of the bundles and the upgrade procedure
<kim0> it would be good to know how to get those revisions too I guess
<Zic> I extracted them from our production cluster, which is still in 1.5.3 since I'm searching a way to build a 1.5.3 to lab-cluster, where our customer can puts all his pods, then upgrading this lab to 1.6.2, and if it succeed, upgrading the production-cluster
<Zic> the production-cluster is running on baremetal & VMs at our DC
<Zic> the lab-cluster was just a machine with LXD
<Zic> but as conjure-up does not permit to deploy a specific version of CDK, I'm a bit screwed :) I think I will need to build a full CDK cluster for the lab also
<kjackal_> Zic: kim0: Here is the upgrade process from 1.5 to 1.6 https://insights.ubuntu.com/2017/04/12/general-availability-of-kubernetes-1-6-on-ubuntu/
<kim0> Thanks!
<kjackal_> Zic: kim0: you can lookup the charm revisions from the bundle. Give me a moment
<Zic> kjackal_: yup, but so I can only do that through juju CLI or GUI, not in conjure-up, so no LXD labs :( I will need to pop some VMware VMs and it's upset me as a big fan of LXD :)
<BlackDex> Hello, i have a environment where juju seems to be very very slow.
<BlackDex> And i see these messages in the logs of juju-controller
<BlackDex> 2017-05-05 10:20:48 DEBUG juju.apiserver.client status.go:197 Remote applications: map[]
<BlackDex> 2017-05-05 10:20:48 DEBUG juju.apiserver.client status.go:552 error fetching public address: "no public address(es)"
<BlackDex> 2017-05-05 10:20:48 DEBUG juju.apiserver.client status.go:558 no IP addresses fetched for machine "arh4pg"
<BlackDex> 2017-05-05 10:20:48 DEBUG juju.apiserver.client status.go:814 error fetching public address: no public address(es)
<BlackDex> 2017-05-05 10:20:48 DEBUG juju.apiserver request_notifier.go:140 -> [410] user-admin 121.930409ms {"request-id":2,"response":"'body redacted'"} Client[""].FullStatus
<BlackDex> 2017-05-05 10:20:48 DEBUG juju.apiserver request_notifier.go:80 [410] user-admin API connection terminated after 182.883216ms
<BlackDex> someone knows what could be the problem?
<BlackDex> i have tested the network, speed is fine, ping (inc. flood-ping) all work fine
<kjackal_> BlackDex: how do you measure the speed of Juju? Why do you say it seems slow?
<magicaltrout> I validate my juju speed against kjackal_ 's response time
<magicaltrout> for example
<kjackal_> whats up magicaltrout? I saw your http://spicule.co.uk/juju-bigdata.html ! Nice!
<magicaltrout> actually we've just started work yesterday on our new "Spicule Big Data Platform" stuff
<magicaltrout> for supported big data workloads via Juju/JAAS
<magicaltrout> so there will be a load more new stuff coming soon
<kjackal_> well done!
<magicaltrout> we're also going to be bringing a couple of column store databases to Juju for our supported "Business Analytics" environmengt
<kjackal_> magicaltrout: which ones?
<magicaltrout> probably greenplum and monetdb
<magicaltrout> so people can pick on data volume and complexity etc
<kjackal_> any plans to integrate asterixdb? https://asterixdb.apache.org/ i know one of the professors behind this from UCLA
<kjackal_> (I think)
<magicaltrout> yeah I like asterixdb i was tracking it through incubation
<magicaltrout> its certainly on the roadmap
<kjackal_> nice
<magicaltrout> i'd also like to do Druid.io
<magicaltrout> need to find some customers first I guess :)
<BlackDex> kjackal_: Well, i have deployed a lot openstack bundles, and this one is take a long time
<BlackDex> and magicaltrout the response time was quicker then the time `juju deploy` took ;)
<lazyPower> stub - are you around? (its super late and past EOW so i'm not hopeful)
<Budgie^Smore> o/ juju world
<lazyPower> o/ Budgie^Smore
<vmorris> hi all, running juju and lxd here on xenial. I'm soak testing the openstack-on-lxd installation and keep running into a problem where not all the containers will start properly. one always gets hung up in the forkstart and causes things like `lxc list` and `juju status` to hang
 * Budgie^Smore is still waiting ... 
<Zic> lazyPower: hi! I have a small question today :) -> if kube-api-loadbalancer is KO, does it affect the qualify of the service? or just the cluster health (daily operation)
<lazyPower> Zic: when you say KO you mean knocked out?
<Zic> yup
<lazyPower> as in taken offline?
<Zic> exactly
<lazyPower> it'll stop your kubelets frmob eing able to contact the masters. so you rkubelets will enter a degraded state
<lazyPower> but the workloads should remain running in their current formation
<Zic> ok, so no "PodEvicton" action ?
<lazyPower> basically you will be unable to effect change to your workloads, but you will stay online.
<lazyPower> correct
<lazyPower> the workers are on a POLL'ing loop with the configured master
<Zic> so normally, my "user-traffic" stay OK, but my operation (sysadmin & dev stuff) will be degraded
<lazyPower> without an active master to talk to, they just kind of go funky
<lazyPower> yeah
<lazyPower> user traffic should be uneffected
<Zic> lazyPower: thanks, because we had an outage between Paris & New York and had some bad effect on user traffic
<lazyPower> hmmm
<Zic> but I suspect is because we have no kube-dns pod on New York nodes
<lazyPower> yeah
<lazyPower> that sounds like the likely culprit
<lazyPower> yeah the ingress tables *should* be cached on the worker units
<lazyPower> if thats not the case i've missed something in the network design of ingress
<lazyPower> Zic we should be able to simulate this failure pretty easily if you can replicate a smallish cluster where kube-dns doesn't exist in your NA nodes.
<Zic> lazyPower: actually the only cases I feared was "PodEviction launched" if the node can't contact the master, or some unknown requests that the node needs to pass to the master before responding to the actual user (like Ingress things)
<lazyPower> the "pod connecting to the master before responding to user" is what i'm concerned with as well
<lazyPower> that should be cached, but i might have a misunderstanding there
<lazyPower> so long as the node has a listing of endpoints, it shouldn't have to contact the master. but if that table has a TTL that tells it when to re-check the endpoint mapping, we're in trouble.
<Zic> I sincerely expect it will, because my model is kinda screwed up if not :D
<Zic> lazyPower: yeah, it's what I expect also, it will be an outage only if the kubernetes-worker reboot during it can't contact the kube-apilb
<Zic> but if not, I see no reason why it will
<lzyPower> lazyPower: you lazy lout
<lazyPower> oh hey lzyPower. <3
<Zic> lzyPower: do you have any schedule (no need of a precise date :p) about enabling cloud-integration and federated cluster ?
<lzyPower> Zic: a member of the team is working on federation. we just landed a kube-fed snap
<lzyPower> Zic: and cloud-native still has no ETA. there's alpha level code there but it hasn't been touched in a couple weeks. Its high priority on this cycles roadmap though
<Zic> thanks for the update :)
<Zic> cloud-integration is a "must-have" for one of our customer which do hacky things without it :/ he ask about cloud-integration at each K8s upgrading
<Zic> federated-cluster is more about my own demand :) because I know that the model I use for our multi-region production cluster is not that good
<Zic> K8s doc recommend federated cluster for multiregion
<Zic> (without speaking of my earlier question about kube-apilb, we have some trouble with kube-dns & multi-region without federation, as request from "region A" can be resolved at a kube-dns in "region B", as there is only one endpoint for kube-dns entire cluster)
<Zic> (about response time, not so important as we have good transiters between EU & US but still this 0.300ms things :/)
<lazyPower> Zic: yeah, fed is def where you want to go with that
<lazyPower> we're actively cycling on it, and i suspect cloud-native integration will resume later this month or early next month
<lazyPower> Zic: atm i'm working on user auth and soak testing, so its all good stuff for ya :)
<Zic> oh nice too :p we always have our "Kubernetes as a Service" project somewhere
<Zic> user auth will help
<Zic> (the day we can give a customer an exclusive account with an exclusive K8s namespace... \o/)
<tychicus> LazyPower: just got CDK 1.6.2 up and running, maybe I missed something in the docs, but I can't seem to find what the username and password are for the k8s dashboard
<lazyPower> tychicus: its behind a TLS key validation. You need to kubectl proxy to establish a secure tunnel and then you can access the dashboard at http://localhost:8001/dashboard
<tychicus> ok
<lazyPower> tychicus: https://github.com/juju-solutions/bundle-canonical-kubernetes/tree/master/fragments/k8s/cdk#accessing-the-kubernetes-dashboard
<tychicus> "To access the dashboard, you may establish a secure tunnel to your cluster with
<tychicus> the following command:"
<tychicus> found it, sorry
<lazyPower> hey no problem :)
<lazyPower> that readme is info dense
<lazyPower> easy to miss that blurb
<tychicus> LazyPower: just as an FYI, rbd request for persistent volume claims are still DENIED by apparmor
<lazyPower> :/  this is troublesome
<tychicus> is that something that you would like me to file a bug for?
<lazyPower> yeah
<lazyPower> we're going to have to take this to the snappy team and see about getting a plug/slot created for this
<tychicus> should be bug be filed against juju or against snappy?
<lazyPower> Against the K8s charms
<lazyPower> tychicus: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues
<tychicus> thanks
<tychicus> lazyPower: bug report is in.  Thanks again for all your help.
<lazyPower> tychicus: thanks for filing that bug. I'll take this to the snappy team at my first availability and see what steps we can take to resolve this
<lazyPower> tychicus: i'll keep communication high on that bug as well so you know when there's something for you to test with the rbd autoprovisioner.
<tychicus> sounds good, I'm happy to test
<bdx> \q
<bdx> #maas
<bdx> stokachu, marcoceppi: cs:~jamesbeedy/lounge-irc-8, https://github.com/jamesbeedy/layer-lounge-irc
<bdx> https://review.jujucharms.com/reviews/122
<bdx> also https://jujucharms.com/u/jamesbeedy/lounge-irc/8
<bdx> it has sasl support
<bdx> so it works on aws
#juju 2017-05-06
<lazyPower> bdx: lol are we on the same wavelength?
<lazyPower> bdx: https://github.com/chuckbutler/irc-on-the-web
<bdx> oh sick
<bdx> lol
<bdx> that we are
#juju 2017-05-07
<kim0> Howdy channel .. I saw some discussion about cloud-integration (cloud-native) .. Can someone give me an idea what that is about .. Thanks!
#juju 2018-04-30
<veebers> babbageclunk: For things like "type FindToolsParams struct {" do the "json:<name>" parts match up with something declared elsewhere or does it just define how they are marshalled across the wire?
<babbageclunk> veebers: the latter
<veebers> babbageclunk: sweet thanks
<babbageclunk> no worries
<veebers> babbageclunk: to clarify what you where saying earlier, to bump the API you suggest making API be the newest version and add a "previous version" api to cover the diff? (i.e. so ClienAPI is always latest, incrementing to have a v2 means creating a ClientAPIv1 and ClientAPI is what v2 represents)?
<babbageclunk> veebers: yup, that's exactly right
<veebers> sweet, I'll make it so :-)
<anastasiamac> babbageclunk: sorry to put it on ur desk, but here it is - https://github.com/juju/juju/pull/8668
<babbageclunk> anastasiamac: oof. Ok, I'll have a look this afternoon.
<anastasiamac> \o/
<anastasiamac> babbageclunk: m happy to do it over ho once u've browsed as i imagine 144 files PR could b daunting...
<babbageclunk> anastasiamac: I know this is a weird thing to ask, but would a worker that checked credentials periodically (say daily or hourly) get us a lot of the way to what we want?
<anastasiamac> babbageclunk: there will b  a periodic worker too... however, for credentials specifically, as soon as we *know* that they r invalid we need to stop calls that depend on valid creds... why, for example, keep retrying if we *know* a call will fail?
<anastasiamac> babbageclunk: and like i mentioned, there r other things that we'd want to inject- status updates the most obvious one...
<babbageclunk> anastasiamac: yeah, that makes sense. Actually, I think I have another idea, want to discuss in a hangout?
<anastasiamac> yes
<babbageclunk> anastasiamac: anyway, I've been reading through the PR too.
<babbageclunk> ok, in standup?
<anastasiamac> yes
<veebers> kelvinliu: re: my questions on what make a model a caas model, I'm trying to find the right place to have a CaasClient (wrt ModelClient). It should either be contained or auto, passing an arg into a test doesn't make sense (when would you ever pass in a 'normal' client, the test is for caas)
<kelvinliu> veebers, understand ur concern,
<kelvinliu> veebers, the reason why the assess script parses the client_type was I thought we are mostly using `from_args` to create the client.
<veebers> kelvinliu: so, you dont' actually interact differently with a caas model when using the juju cli right?
<kelvinliu> veebers, ideally, we could have `create_client` accepts client type to initiate a client.
<veebers> kelvinliu: previously we used to versioned ModelClients to account for the different versions of juju (and the CI test code was in a separate repo), since then we now have a ModelClient that is valid for the version of juju that it is in the tree of
<veebers> kelvinliu: lets have a quick HO, higher bandwidth discussion that way :-) Use the standup HO?
<kelvinliu> veebers, I would say it will be mostly same/similar when u interact with caas model via juju cli
<kelvinliu> sounds good
<veebers> kelvinliu: is there a need for a CaasModel then? I think all the other checks needed for the test are commands outside of juju?
<veebers> there is some setup needed though right? to do with kubectl and paths etc.
<kelvinliu> currently inside the caasClient, it wraps deploying cdk bundle, validing cluster healthy and could add more cmds wraps `kubectl`
<kelvinliu> yes, to interact with the cluster via kubectl, we needs the kube/config and kubectl bins which are all prepared in `CaasClient`
<kelvinliu> veebers, i am in HO
<jam> manadart: given that you just replied to the PR, what is the current state of your changes?
<manadart> jam: In progress. I will address the remaining small things - DRY up the tests, Etag passthrough. ETA this afternoon.
<jam> manadart: k. think it is possible to land it before you leave for the rest of the week?
<manadart> I hope so. If not today, I will still check in and turn around review items. Should only be tid-bits.
<jam> manadart: quick feedback on the bit of patch I saw. Heading off to lunch now.
<srihas> hi guys, have just gotten a juju-controller setup. Do we need to add machines to juju explicitly or we just specify the tags while deploying charms. (OpenStack wiht MAAS+JUJU)
<balloons> Good morning
<rick_h_> srihas: howdy, once you have the controller bootstrapped you should be able to just deploy workloads using juju deploy and any constraints you need (such as a specific flavor or hardware characteristic)
<srihas> rick_h_: juju deploy --constraints tags=compute --config compute.yaml nova-compute
<srihas> it took third node; out of my 4 nodes tagged compute in MAAS
<rick_h_> srihas: oh I see, you're deploying openstack on maas?
<rick_h_> srihas: yea, that looks right
<srihas> how can I extend to the other three nodes the nova-compute?
<srihas> rick_h_: I am unable to use --to 1,2,4 for example
<rick_h_> srihas: so --to means to machines that show up in juju status
<rick_h_> srihas: so you have to do "juju add-machine" first and then use those numbers to reference the placement directive
<rick_h_> srihas: Juju tries to encourage the cattle vs pets idea so that machines aren't special
<srihas> rick_h_: aha, so I need to add machines first?
<rick_h_> srihas: well only if you want to specify --to, ideally you shouldn't need to
<rick_h_> srihas: you'd just tell Juju to deploy to machines with certain characteristics and Juju will work with maas to find machines that fit the bill and bring up up
<srihas> rick_h_: juju deploy --constraints tags=compute --config compute.yaml nova-compute
<srihas> found only one machine Ã¤nd deployed on it
<rick_h_> srihas: right, that looks peachy
<srihas> I have three other
<rick_h_> srihas: ok, so you'd need to use -n 4 for that command to find and bring up 4 machines
<rick_h_> srihas: once you have one there you can "juju add-unit -n 3 nova-compute"
<rick_h_> srihas: to scale up the existing application, with the same config/constraints, 3 more times
<srihas> exactly I want to do it
<srihas> rick_h_: I will try
<srihas> rick_h_: juju add-unit --constraints tags=compute -n 3 nova-compute ? like this probably
<rick_h_> srihas: no, once you specify the constraints Juju remembers them for future units
<rick_h_> srihas: so that your units are consistent with each other and you don't have to remember them months later
<srihas> juju add-unit -n 3 nova-compute
<rick_h_> srihas: +1
<srihas> rick_h_: thank you
<rick_h_> srihas: np, good luck! :)
<srihas> rick_h_: on the deployed node, how does juju figure out public IP for each system? for me its configuring an IP in a different network
<srihas> something I mixedup in MAAS it seems
<rick_h_> srihas: sooooo this can be a bit more interesting and complex. Juju and MAAS support the idea of network spaces. And when you deploy you can specify how the application should come on, on which networks/spaces/etc.
<rick_h_> srihas: check out https://docs.jujucharms.com/2.3/en/network-spaces
<rick_h_> and after that https://docs.jujucharms.com/2.3/en/charms-deploying-advanced#deploying-to-network-spaces
<srihas> rick_h_: I wonder if I can just change the configuring after assigning networks to spaces or do I need to redeploy
<rick_h_> srihas: yea, I think you'll have to redeploy. Changes to underlying MAAS won't auto update things running as there's no promise they're compatible with what was vs what is new
<srihas> rick_h_: ok! it's a learning for me, thanks again :)
<rick_h_> srihas: no problem, there's a bit to learn for sure
<parlos> Good Morning, quick question, whats the 'expected' way to detect when a deployment has completed, any API to call suitable for machine processing?
<rick_h_> parlos: so there's a juju plugin called "juju-wait" that I think most folks use for that
<rick_h_> parlos: https://pypi.org/project/juju-wait/
<parlos> rick_h thanks, will give it a go.
<theoneijf> I am running CDK on a bare metal machine and the cluster breaks after reboot.  Total newb and have no clue where to start troubleshooting
<srihas> rick_h_: spaces thing is really complex
<rick_h_> srihas: yea, the idea though is that if you're deploying software and managing what networks each bit speaks through it's hard to make that modeled well in a reusable way.
<srihas> I have read 4 times, not getting hold of it really
<rick_h_> srihas: k, let me see if I can get something more hands on to try
<rick_h_> srihas: check out https://insights.ubuntu.com/2016/01/21/introduction-deploying-openstack-on-maas-1-9-with-juju
<rick_h_> srihas: it's much more verbose and such
<srihas> rick_h_: I am on it
<srihas> I am changing spaces in MAAS, lets see
<rick_h_> srihas: cool, hopefully that's a more thorough walk through that's specific to openstack that'll click more
<veebers> Morning o/
<veebers> babbageclunk: go-guru-describe is great, thanks for putting me onto it
<babbageclunk> veebers: yeah, it's really handy, especially for a big type that's got methods in multiple files
<babbageclunk> veebers: I like go-guru-implements as well - it's slower but invaluable
<veebers> babbageclunk: sounds great, I'll have to give it a spin too!
<ice9> how to deploy a charm on local lxc container?
<veebers> babbageclunk, wallyworld: FYI: https://github.com/juju/juju/pull/8669 I'm just updating the upgrade functional test now, I'll add that to this PR too
<babbageclunk> veebers: ok, just looking at another PR then I'll check yours out
<veebers> babbageclunk: awesome thanks
<babbageclunk> veebers: approved
<veebers> babbageclunk: sweet cheers, I was hoping to get the functional test in in the same PR, it's taking longer than the 5 minutes I thought it would :-P It ok to add that shortly and have you sanity check that?
<babbageclunk> oh sure - forgot about that sorry
<veebers> no worries, I should have waited until it was ready and pushed the lot, but I was anxious to get judged and told what I did wrong ^_^
<veebers> kelvinliu: for when you're online, thoughts on this for the caas ci test. It gives a way to interact with the k8s bits and keeps the ModelClient 'clean'. This is with the understanding that the only k8s/caas specific bits is the add-k8s, everything after that can just use a ModelClient to interact: https://paste.ubuntu.com/p/wYmmjMF8nw/
<kelvinliu> veebers, looks good, will let u know when it's changed
<kelvinliu> veebers, thx
<veebers> kelvinliu: I can't guarantee it'll run out of the box ;-) may need some minor changes
<kelvinliu> veebers, yeah, i saw there are some places will need to change a little bit
#juju 2018-05-01
<veebers> babbageclunk: will juju version always be major.minor.patch? when we release 2.4 will it be 2.4.0 or 2.4?
<veebers> anastasiamac: ^^?
<anastasiamac> veebers: yes, always... 2.4.0 :)]
<veebers> awesome, cheers anastasiamac :-)
<anastasiamac> veebers: nws
<veebers> gah, I can't just take a 2.4-beta2 jujud, repackage it as 2.4-beta3.*.tgz and have a streams entry as 2.3-beta3 right? the actual upgrade will fail as it'll check the `jujud version` I presume?
<babbageclunk> veebers: you can put a force-version file in there, which will change what jujud version reports
<veebers> babbageclunk: oh, tell me more. Is that put in the agent tarball?
<babbageclunk> look at what's in the directory when you do upgrade-juju --build-agent
<babbageclunk> hang on, I'm just looking myself
<babbageclunk> yeah, it's FORCE-VERSION
<babbageclunk> veebers: https://github.com/juju/juju/blob/develop/version/version.go#L36
<veebers> babbageclunk: awesome thanks! I'll incorp into the functional test
<babbageclunk> yeah, I think it just needs to be included in the tarball - if you search for FORCE-VERSION in the codebase you can see where upgrade-juju --build-agent includes it.
<veebers> much appreciated (damn I tried finding that strongbad vid but couldn't find it)
<babbageclunk> appriciated?
<veebers> babbageclunk: my search only comes up with the technology introduction one
<babbageclunk> veebers: http://www.homestarrunner.com/sbemail53.html
<veebers> babbageclunk: you're a star!
<babbageclunk> thanks hrwiki.org, you saved my bacon again!
<veebers> ah and it's such a milestone vid too!
<veebers> hah
<vino> babbageclunk: hi I have the remaining unittests and addressed the review comments.
<babbageclunk> vino: ok, taking a look now
<vino> sure.
<veebers> babbageclunk: hah I'm vying for your attention too :-) I've finally pushed the upgrade CI test updates for the agent-stream PR if you could take a look when you can (and addressed your comments too)
<babbageclunk> veebers: ok, will do
<babbageclunk> hey veebers, I have to go and help wrangle the animals now, I'll loook at your PR first thing tomorrow, sorry!
<veebers> babbageclunk: no worries, good luck with the wranglin'
<ice9> when i bootsrap localhost, it throw error about unknown certificate authority and it doesn't create the controller!
<BlackDex> Hello there. I have an environment with juju 1.25.13 (not able to upgrade now) and i have several sub-charms (nrpe) running, which aren't beining removed. I tried several times to do remove-relation, but they are still there. No action is taken it seems
<BlackDex> i Also tried to restart the jujud-unit-nrpe on these nodes.
<BlackDex> no effect
<CG__> hi..
<CG__> am using jenkins charm..
<CG__> when i do $juju gui --browser
<CG__> it opens up a browser, and am looking to change the UI
<CG__> please suggest how to
<BlackDex> change the UI?
<CG__> yes, am looking to modify/change the UI
<BlackDex> of juju web-interface?
<BlackDex> i think you should take a look at https://github.com/juju/juju-gui
<CG__> yes correct
<BlackDex> and the juju-gui is located on the system where you installed the controller
<BlackDex> so where  you bootstraped juju to
<BlackDex> https://github.com/juju/juju-gui/blob/develop/docs/hacking.md
<BlackDex> is what you are looking for i think
<CG__> not exactly. Have tried that as well.
<CG__> am planning to develop my own UI
<ice9> is possible to deploy charms (model) on one lxc container or each charm must have it's own container?
<BlackDex> ice9: Why do you want to deploy multiple charms in one container?
<BlackDex> kinda defeats the purpose of containers
<ice9> BlackDex, if they are small services that you want to keep on one container only
<BlackDex> but why do you want to keep them in one container? containers don't use much resources, so i do not see why you want to merge those :).
<BlackDex> But it is possible
<BlackDex> just use `juju deploy cs:charm application-name --to 0/lxd/1` where you need to change the 0/lxd/1 to the correct machine id
<ice9> when i try to create a juju controller i get this error
<ice9> "x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate
<BlackDex> never saw that before
<ice9> how to specify ubuntu version when creating controller?
<bdx> ice9: juju help bootstrap
<bdx> ice9: `juju help <any-juju-command-you-want-help-with>`
<ice9> bdx, it's not clear in the help about which option can do that
<bdx> ice9: juju help bootstrap | grep series
<ice9> thanks
<bdx> np
<[Kid]> anyone had issues with juju deploying openstack on hosts that have shared storage?
<[Kid]> specifically fiber channel multipathed storage
<[Kid]> i am using conjure and juju is failing at provisioning the osd container
<[Kid]> hook failed: "mon-relation-changed" for ceph-mon:osd
<[Kid]> and it is saying it cannot lock the device that is one of the paths to my shared storage
<[Kid]> https://paste.ubuntu.com/p/Y6Hh758CPQ/
<veebers> Morning o/
<babbageclunk> ok veebers, looking at your PR now!
<veebers> babbageclunk: excellent, thanks!
<babbageclunk> veebers: approved! (with a couple of minor comments)
<veebers> \o/ thanks babbageclunk
 * babbageclunk highfives veebers
<veebers> o/*\o
<babbageclunk> oh thanks
<veebers> babbageclunk: so, to test the early error (arg not support on ye old controller) I need a MockAPIConnection and try get a upgradeJujuCommand command that uses that (and set the bestFacadeVersion)?
<veebers> babbageclunk: oh, or do I patch the s.APIState in the test (api.Connection) so that BestFacadeVersion returns the value I want?
<babbageclunk> veebers: yeah, basically - I think we should have something that does it, since it's a reasonably common kind of test for the API clients
<babbageclunk> Hang on, just having a look
<veebers> babbageclunk: awesome thanks, I had a look but the one thing I can find that does what I want (cmd/juju/machin/remove_test.go) doesn't mesh with the upgrademodel_test.go stuff that is currently there
#juju 2018-05-02
<babbageclunk> no, it'll be in the api package - this is the kind of thing I was thinking of: https://github.com/juju/juju/blob/develop/api/controller/controller_test.go#L375
<babbageclunk> veebers: ^
<veebers> babbageclunk: excellent, that looks to be exactly what I want, thanks!
<babbageclunk> cool
<[Kid]> anyone had issues with juju deploying openstack on hosts that have shared storage?
<[Kid]>  hook failed: "mon-relation-changed" for ceph-mon:osd
<[Kid]> https://paste.ubuntu.com/p/Y6Hh758CPQ/
<vino> babbageclunk: i have added unit test cases for verifying systemd failure and addressed review comments
<babbageclunk> babbageclunk: ok, taking a look now
<babbageclunk> doh, I mean vino^
<vino> babbageclunk: the push is still going on :)
<vino> its done..
<vino> babbageclunk: I am working on PR: https://github.com/juju/juju/pull/8670
<veebers> anastasiamac, babbageclunk: If you have a quick moment I would love a hand with this test, trying to do something similar to what babbageclunk linked above, but for api.Client (It currently doesn't have the option to pass in a apicaller at client creation, so I can't inject the best api version value)
<anastasiamac> veebers: lemme find u an equivalent in api tests :) gimme a sec...
<veebers> anastasiamac: cheers, I've looked but couldn't find one that would let me test FindTools returning the right error
<anastasiamac> veebers: k, mayb m not understanding what u r after... i thought u wanted something similar to what's in https://github.com/juju/juju/blob/develop/api/caasunitprovisioner/client_test.go#L27
<veebers> anastasiamac: something like that is what I was hoping for, wanting to test https://github.com/juju/juju/blob/develop/api/client.go#L284 but the current tests (example) https://github.com/juju/juju/blob/develop/api/client_test.go#L55 getting a Client I'm not sure if I can passing an APICaller so I can set best api version
<babbageclunk> veebers: sorry, otp
<anastasiamac> veebers: have u tried patching  a facade call (here best version) similar to https://github.com/juju/juju/blob/develop/api/client_test.go#L208
<anastasiamac> veebers: the same test file, line 333 has another patch example...
<anastasiamac> veebers: but geenral comment - we are not too thrilled to have JujuConnSuite based tests anywhere but in featuretests pkg... maybe the work u r doing, at least the tests, should reside in a new suite that complies with current standards? :D
<anastasiamac> veebers: m happy to discuss \o/
<veebers> anastasiamac: that patch example is pretty much my backup of what I wanted to do, but don't want to make people non-thrilled :-|
<veebers> anastasiamac: perhaps I'll implement the test this way and we can chat about a better way once i've added it to my PR?
<babbageclunk> veebers: oh wow, sorry - I didn't realise those tests were using JujuConnSuite.
<babbageclunk> veebers: The simplest thing is probably what anastasiamac suggests - make a new suite that works like the controller test I linked to, and just has one test for the version check.
<anastasiamac> veebers: babbageclunk +1 on a new suite :D
<veebers> anastasiamac, babbageclunk ok I'll give that a whack. New suite in the api/client_test.go file/
<veebers> ?
<babbageclunk> veebers: yup
<babbageclunk> veebers: use that controller test one as an example - the gc.Suite call is important to register it. I don't think you'll need a setup or anything either.
<anastasiamac> veebers: purest opinion - each suite deserves its own file :) but i can b swayed
<babbageclunk> I think that's overkill :)
<veebers> ack, ack I'll give it a whack
<anastasiamac> like i said :D
<anastasiamac> "purist" does not always mean "worth in practice" :D
<babbageclunk> Then you're a realist like me, we just disagree about exactly where the line is!
<anastasiamac> babbageclunk: one of the best things that vino siad to me "when ppl disagree, they progress [when trying to find a solution together]" :D i LOVED it
<anastasiamac> veebers: and fwiw, m *thrilled* u r  working in (and with) juju codebase \o/ really...
<vino> :)
<veebers> anastasiamac: ^_^
<babbageclunk> anastasiamac: true - if we all agreed it would just mean that we suffered from groupthink
<anastasiamac> babbageclunk: but on a srs note, m looking at a _test* file  2,779 lines long.... surely this is insane in any book :D
<babbageclunk> ugh
<veebers> anastasiamac: yeah that's crazy, someone should have removed 2 lines to make it 2,777 lines. That number looks *heaps* nicer
<veebers> (or ultimately remove 555 lines to make it even nicer ;-))
<anastasiamac> veebers: i was thinking to round it up to 3K :) surely 000s r prettiest :D
<anastasiamac> veebers: yeah or to round down as u suggest :)
<veebers> anastasiamac: true, but that would mean adding more lines. Perhaps a bunch of: /**********************************\n * This is a comment\m ***************************************/
<anastasiamac> nice :0 yes, i love this pseudo-latin that gets added everywhere as an example text... worth having our copy in this file :D
<veebers> sorry anastasiamac, babbageclunk I've hit a blank. The controller client can be created with controller.NewClient(apiCaller), but api.Client cannot (from what I see) there is only this; https://github.com/juju/juju/blob/develop/api/state.go#L264
 * anastasiamac looking
<anastasiamac> veebers: do u have a sec to ho?
<veebers> anastasiamac: I sure do, standup?
<anastasiamac> veebers: yes! let's
<babbageclunk> veebers: oh man, I'm sorry - this is way more difficult than I'd have expected. In the end I don't think it's essential to have a test for this.
<anastasiamac> babbageclunk: u r hurting my ears :(
<babbageclunk> I'm just not sure it's worth it. And while I was looking for a good example I found lots and lots of API clients that were checking the facade version but didn't have tests for it.
<anastasiamac> babbageclunk: i think that we r also leaning out client so that we can burn it away altogether... so i agree, if veebers will enjoy the exercise of figuring out how to test client without JujuCOnnSuite (for example by mocking the state call that return Client()), then he'll b pioneering a new territory... if however, it gets too furstrating, let it go...
<babbageclunk> yay!
<veebers> babbageclunk: this being a facade ver change, it needs to get in for the beta2 release so it can make it into 2.4 right?
<anastasiamac> veebers: babbageclunk: we prefer not to bump facade versions in point releases, so it's bets of it's in before 2.4.0
<anastasiamac> and , of course, the more test driving it gets, the better...
<anastasiamac> so the earliest u can but may b not strictly a  must for 2.4-b2?..
<veebers> anastasiamac: if we go b2 -> rc -> rc I'll def need it in b2 :-)
<anastasiamac> it'd b nicer, yes
<veebers> anastasiamac, babbageclunk: I got a solution for that test (thanks anastasiamac) It's pretty barebones in that it only allows to test for the failure I was looking for. Could I get a re-review when you're free?
<babbageclunk> veebers: looking now
<veebers> thanks babbageclunk, I'm sure sometime in the future I'll leave you alone so you can actually get your stuff done ^_^
<babbageclunk> veebers: yeah, that looks great! Did anastasiamac tip you off about export_test?
<veebers> Query, whats' needed for a charm to handle an upgrade? For instance setting up mediawiki related to a db works (status goes from blocked (needs db) -> started) do an update and status changes to blocked (needs db) but the application continues to work (i.e it's not blocked)
<anastasiamac> babbageclunk: noooo, veebers figured it all by himself... i was watching the magic
<babbageclunk> smooth
<veebers> hah, I had help from anastasiamac, she pointed me in the right dir
<babbageclunk> veebers: hmm, not sure why the status says it's blocked if it's connected to the db
<veebers> babbageclunk: yeah, I suspect (based on something wallyworld said) that the charms not handling the hooks properly when things get updated? (I'm not sure what exactly gets re-fired etc.)
<babbageclunk> veebers: yeah, that sounds plausible - I think it's config-changed?
<veebers> babbageclunk: cool thanks. I may have a look as it'll make this CI test change easier
<TheAbsentOne> If I get the message "clear_flag" unknown does that mean I have a version issue? Also how do I properly check the version of reactive framework/juju?
<TheAbsentOne> wow client crashed >.>
<TheAbsentOne> kwmonroe you here by any chance?
<TheAbsentOne> nvm fixed it!
<TheAbsentOne> is charms reactive tool from pip broken?
<TheAbsentOne> is adam gandelman on this Irc?
<rick_h_> TheAbsentOne: shouldn't be broken from pip. What's the issue?
<TheAbsentOne> I installed charms.reactive but when I try to run ``charms.reactive -p get_flags`` I get invalid syntax error and some traceback
<TheAbsentOne> rick_h_
<TheAbsentOne> same with a --help
<rick_h_> TheAbsentOne: this is run via juju run on a unit or something?
<rick_h_> TheAbsentOne: it's a library, not a command line client. I'm not following what you're trying to do here.
<TheAbsentOne> I tried to do this: https://jujucharms.com/docs/2.2/developer-debugging rick_h_
<TheAbsentOne> but allow me to ask how I can retrieve a list of all flags?
<rick_h_> TheAbsentOne: so I'm confused. corey_fu is setting me straight
<rick_h_> TheAbsentOne: looking at it, sec
<rick_h_> TheAbsentOne: so you installed charms.reactive from pip in what fashion?
<TheAbsentOne> first with pip install charms.reactive, then with pip3 - same issue
<TheAbsentOne> https://pastebin.com/8X6c2iEX rick_h_
<rick_h_> TheAbsentOne: ok, that's not python 2 compatible
<rick_h_> TheAbsentOne: so let's try something
<rick_h_> TheAbsentOne: run `sudo updatedb` and then once that completes `locate charms.reactive | grep bin` and see what comes out
<TheAbsentOne> ahn I uninstalled with pip and reinstalled with pip3 and it seems to fix it
<TheAbsentOne> I do get an empty list though :( thanks for the help rick_h_
<rick_h_> TheAbsentOne: huh, well I messed something up then because you're clearly running something with charms.reactive
<rick_h_> TheAbsentOne: try this `which charms.reactive`
<TheAbsentOne> ohn but the locate command found stuff, under usr/local/bin
<TheAbsentOne> and in my home folder too rick_h_
<rick_h_> TheAbsentOne: ok, so now let's see what `ls -al /usr/local/bin/charms.reactive` shows
<rick_h_> TheAbsentOne: yea, basically when you pip3 installed it there should be another version that is py3 and should work around somewhere
<rick_h_> TheAbsentOne: so I'm trying to find the py3 so we can test it out
<TheAbsentOne> the command returns nothing interesting only the file itself
<TheAbsentOne> but there is a charms.reactive.sh right? Isn't that what you are looking for?
<TheAbsentOne> rick_h_: https://www.dropbox.com/s/d5ejpkz49frlwvk/tempclicharms.png?dl=0
<rick_h_> TheAbsentOne: so let's try the one in your local directory and see if that works
<rick_h_> TheAbsentOne: the other thing might be we can edit the .sh script and point the top of it to python3 vs python2
<TheAbsentOne> but right now the command is running fine rick_h_ or is it something else you want to figure out?
<rick_h_> TheAbsentOne: ok, if it's running fine now okie dokie
<TheAbsentOne> unless I can help you with something about it? ^^
<TheAbsentOne> say rick_h_ do you want to give a quick look at something
<rick_h_> TheAbsentOne: shoot
<TheAbsentOne> rick_h_: So I'm creating a charm that uses the mysql-shared interface and the apache-layer to deploy apache and setup some pages in a wordpress like way. But it seems the mysql charm doesn't properly accept my request
<TheAbsentOne> https://pastebin.com/4znUZhvv this is my charm's heart
<rick_h_> TheAbsentOne: so does the apache unit have the default apache index page when you get it running at /index.html?
<TheAbsentOne> rick_h_: I assumed that worked (as I did a similar thing before) but nope, weirdly enough it installs the pages correctly but the service doesn't get started for some reason
<rick_h_> TheAbsentOne: did you expose apache?
<rick_h_> TheAbsentOne: is this on a public cloud with all ports closed by default and you'd need to use expose to open the port for the charm?
<TheAbsentOne> no public cloud (vmware cluster only accessible with a vpn) but I exposed it yeah
<TheAbsentOne> let me start the service manually
<rick_h_> TheAbsentOne: I mean I'd start with testing can you get the normal apache charm to work out and serve out the basic page on there first. Then look at how the charm works vs the layer and see what you might need to pull/copy
<TheAbsentOne> rick_h_: Yeah exactly I got that working before, I'll come back to you when I fix it. I'm just a bit confused right now. When I try systemctl restart apache2 I get asked for a password, is there a default password juju uses for things like this?
<rick_h_> TheAbsentOne: did you sudo do it?
<TheAbsentOne> Urgh >.> I'm really not paying attention thx rick_h_
<rick_h_> TheAbsentOne: sorry, let me know if I can help. I'm tossing around different sessions at a sprint but I'll try to check in
<TheAbsentOne> so basicly when I do that, the apache layer stuff is fine, this means I have to do it in a hook I guess
<TheAbsentOne> np rick_h_ thanks for helping out!
<rick_h_> TheAbsentOne: yea, might have to restart I guess if you change something there and the charm is doing it but that's not baked into the layer
<TheAbsentOne> exactly, I'll put the repository on github soon too, will make things easier to correct! After lunch ;) talk to you in a bit rick_h_
<TheAbsentOne> https://pastebin.com/gRcQJ3Dg do you need something more then this: ``database.configure('proto', 'admin', 'admin', prefix="proto")`` for the mysql-shared interface? Can't figure out why mysql charm is failing here
<stub> Do we still care about precise support in charm-helpers ?
<TheAbsentOne> could someone explain me why there is no interface:http in the vanilla tutorial/example layer-charm (https://jujucharms.com/docs/2.3/developer-layer-example)
<TheAbsentOne> and a provides: with that interface
<veebers> Morning team o/
<TheAbsentOne> nvm my question, it's late here figured it out. Morning for you veebers goodnight for me ^^
<veebers> Good night TheAbsentOne o/
<veebers> if a charm does "juju-log" where can I see that log message? can I use juju debug-log or similar, do I need to jump onto a machine to see logs?
<veebers> no, better question I know you can show the log of hooks run, but I can never remember how to do so
<babbageclunk> veebers: I'm not sure off the top of my head. I think they'll be in debug-log, but in the log for the model rather than the controller (which is where I'm normally looking).
<veebers> babbageclunk: ah, perhaps thats it. cheers
#juju 2018-05-03
<babbageclunk> veebers: extra data point - it looks like it might also happen when new controller machines are added? It looks like the mysql unit responds to the config-changed, and updates it status to "maintenance", at which point the mediawiki unit goes to "blocked", and then the mediawiki unit never changes back to "active"
<veebers> babbageclunk: cheers, I think I know when it's happening, I just have to confirm. (the db-relation-departed hook removes the canary file it uses to say "I have a connection") I think it's being triggered and miss-handled
<babbageclunk> veebers: ah, ok
<vino> babbageclunk: do u have a min...to discuss upon this issue i mentioned this morning
<vino> ?
<babbageclunk> vino: sure
<vino> hangout ?
<babbageclunk> I'm in standup
<veebers> Oh, babbageclunk btw: juju show-status-log mediawiki/0
<babbageclunk> veebers: oh right - I always forget that command. Will that show all the hooks that get run?
<veebers> babbageclunk: aye it does, in the order they where run, with the message etc. v/ helpful for what I want
<babbageclunk> cool
<ahop1983> Hello! Is there anyone out there with knowledge of using a pre-existing charm as a layer if it does not exist in https://github.com/juju/layer-index/tree/master/layers ?
<ahop1983> My team is running into this: https://bugs.launchpad.net/juju/+bug/1764317
<mup> Bug #1764317: bionic LXD containers on bionic hosts get incorrect /etc/resolve.conf files <bionic> <cdo-qa> <cdo-qa-blocker> <foundations-engine> <kvm> <lxd> <network> <uosci> <juju:Triaged by ecjones> <https://launchpad.net/bugs/1764317>
<ahop1983> Our idea of a fix is to dynamically generate the DNS data using a charm hook and merge it into the affected preexisting charms, but we are not sure of the best way to get this done.
<vino> anastasiamac: is there a way to check logs on status of upgrade at controller side ?
<vino> veebers: if anyone can help me on the above question..
<anastasiamac> vino: u can check controller logs:
<anastasiamac> swicth to controller model, ssh inot machine and broswe the logs
<veebers> Is there a why to find the gh/lp page for a charm? (i.e. https://jujucharms.com/mediawiki/ I want to propose a fix0
<babbageclunk> veebers: generally there's a link on the charmstore page
<veebers> ah right, I had thought so too. Perhaps I'll try file a bug with a pastebin of the diff to fix it.
<babbageclunk> veebers: https://bugs.launchpad.net/charms/+source/mediawiki
<veebers> babbageclunk: cheers L:-)
<veebers> where can one see the current bugs for 2.4? I can only see fix committed or in progress ones.
<anastasiamac> veebers: for next beta - https://launchpad.net/juju/+milestone/2.4-beta2
<anastasiamac> veebers: or all existing - https://bugs.launchpad.net/juju
<veebers> anastasiamac: ah right, I had assumed there would be bugs targetted against 2.4 in general
<anastasiamac> veebers: so have i but it does not think so.. it looks like tags were used at one stage but all tagged 2.4 bugs have been addressed :)
<veebers> anastasiamac: that's good, seems we're on top of the fixes going into 2.4
<veebers> anastasiamac: is https://bugs.launchpad.net/juju/+bug/1465317 still valid?
<mup> Bug #1465317: ubuntu devel macos win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju:Triaged> <juju-core:Won't
<mup> Fix> <juju-core 1.24:Won't Fix> <juju-core 1.25:Won't Fix> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317>
<anastasiamac> veebers: i do not have more info than on the bug.. mayb? :)
<anastasiamac> veebers: fwiw it hink we've had couple of attempts at resolving it for good (as opposed to band-aid solutions) but obviously have not resolved it.... would b brilliant to fix :)
<eriklonroth> Hello! We are trying to make use of "ansible" with juju. How would we make best use of that without needing to rebuild existing charms for our use-case? I've seen a "layer-ansible" somewhere but I would hope to get some input on the subject.
<TheAbsentOne> hi eriklonroth from what I've read the ansible layer should fill that need. Do you want a standalone charm or do you want things on top of the ansible layer?
<eriklonroth> Thanx! I think I need something standalone as I'm not yet sure how to puzzle this into the different services we are to create. It would be good to not have to go through a vast testing phase each time a change is made to ansible layers or/and the target charms.
<eriklonroth> ... a subordinate charm is perhaps the way to go ?
<TheAbsentOne> eriklonroth: I think it depends, in your case I would try first with a normal charm and https://github.com/chuckbutler/ansible-base layer to test playbooks. Once that works it might be easier to determine what you want the charm to do :)
<TheAbsentOne> https://github.com/chuckbutler/charms.ansible 's second method might be interesting to look at too
<eriklonroth> Thanx for that advice. What are your thoughts about this thing I just googled. v
<eriklonroth> https://github.com/cmars/juju-ansible
<TheAbsentOne> eriklonroth: I think it's outdated honestly, if it works sure nice thing but I don't see a reason to not use the reactive framework and the existing layers. It all depends however what you want to do with ansible and on what level
<eriklonroth> I see
<eriklonroth> OK, I'll take your advice to begin with and see where we end up. Do you know of any examples I can look at ?
<TheAbsentOne> unfortunately not really, haven't used it myself maybe others here can help
<srihas> hi, when I run "juju deploy --constraints tags=compute --config compute.yaml nova-compute" and check the status the public address is by default coming from the IP of of the first NIC in MAAS to that node
<srihas> https://paste.ubuntu.com/p/wGQJnxDMdm/
<srihas> Its always taking the IP from storage space while I expect from the management space. Is there a way to specify that in compute.yaml?
<zeestrat> srihas: You probably want to look at bundles https://jujucharms.com/docs/2.3/charms-bundles#binding-endpoints-within-a-bundle or specifying binds via the cli https://jujucharms.com/docs/stable/charms-deploying-advanced#deploying-to-network-spaces
<srihas> zeestrat: aha, will see into it. seems I understood something thatnk you
<srihas> zeestrat: but if there are 4 subnets in "management" space which IP will come to my_ip in the nova.config?
<srihas> when I bind the "management" space
<zeestrat> srihas: That's a good question. Not sure. Does the machine in maas have interfaces for all those subnets?
<srihas> zeestrat: no, I have given static IP from one of those subnets specifically
<srihas> I hope it solves
<zeestrat> srihas: Gotcha. Hope it does the right thing.
<srihas> zeestrat: no, it didn't it simply ignored the "bind" :(
<srihas> yayy, it worked, thanks zeestrat
<srihas> is there a way to tell juju to install ocata version? I got Mitaka version of nova-compute. Can someone help?
<zeestrat> srihas: You can use the openstack-origin option for most of the openstack charms, for exmaple "openstack-origin: cloud:xenial-ocata".
<zeestrat> srihas: If you look at the main openstack bundle from the openstack-charmers (https://jujucharms.com/openstack-base/, see bundle.yaml) you can see the "openstack-origin" option used for the latest release, queens.
<TheAbsentOne> zeestrat: have you used the mysql-shared or pgsql interface recently in a charm (reactive) by any chance?
<srihas> zeestrat: /win35
<srihas> nvm
<zeestrat> TheAbsentOne: No I haven't, sorry.
<TheAbsentOne> never lucky x)
<srihas> zeestrat: I think I understood it again, thank you
<TheAbsentOne> https://pastebin.com/4znUZhvv confused why this is not enough for the mysql-shared interface, got things working on mysql interface but not on shared where I can share dbname-credentials :/
<bdx> TheAbsentOne: it helps if you post the github repo with all of the charm code, off the top of my head I see a slew of issues there
<bdx> TheAbsentOne: here's how I've done it in the past https://github.com/omnivector-solutions/layer-documize/blob/master/reactive/documize.py
<bdx> TheAbsentOne: ^ code is now pretty stale though, it should be implemented using reactive Endpoints, and flags etc etc
<bdx> I'll ping you with an update when I've refactored that to use the new bits
<bdx> TheAbsentOne: hopefully that will get you thinking in the right direction though
<bdx> TheAbsentOne: it helps if you post the github repo with all of the charm code, off the top of my head I see a slew of issues there
<bdx> TheAbsentOne: here's how I've done it in the past https://github.com/omnivector-solutions/layer-documize/blob/master/reactive/documize.py
<bdx> TheAbsentOne: ^ code is now pretty stale though, it should be implemented using reactive Endpoints, and flags etc etc
<TheAbsentOne> thanks bdx, gonna take a look. I might get back to you if I find myself struggling once again; great link!
<bdx> np
<TheAbsentOne> bdx: it seems I used the configure function wrong, but weirdly enough the flag on database.available is never set. There must be another issue
<bdx> TheAbsentOne: make a very minimal example charm to zero in and debug just the mysql relation bits
<bdx> you could do it with two handlers
<bdx> let me see if I can get a quick example for you
<TheAbsentOne> bdx: I might have found it but my battery is dying on me so have to go. If I'm still in need of help I'll ping you for some help after putting everything online too, thanks for the guidance though!
<bdx> np
<veebers> Morning team \o/
<veebers> I'm pretty sure I've seen chatter re: percona-cluster and hooks issues recently, can anyone update me?
<veebers> To use a local copy of a reactive charm I need to build it right? I recall doing something like this *ages* ago but the details escape me
<veebers> heh, I think I have it. 'charm build' has done something without error, going to try that z^_^_
<bdx> TheAbsentOne: https://github.com/jamesbeedy/mysql-shared-example
<TheAbsentOne> damn bdx I was just typing I got it working xD
<bdx> :)
<bdx> it was good for me too
<TheAbsentOne> there is only one thing fishy about my status's/flags when the database already exists
<TheAbsentOne> but in all honesty, we need more examples of this bdx like real "state of the art examples"
<bdx> TheAbsentOne: you can look at the code of any of the upstream charms <- usually what I do when I'm in need of examples
<TheAbsentOne> I pretty much have the same now of your minimal example xD sorry for the work you had to do
<TheAbsentOne> and well as a matter of fact I was looking at https://github.com/omnivector-solutions/interface-conda/blob/master/provides.py for some inspiration
<TheAbsentOne> I'm still having issues in creating my own interface
<TheAbsentOne> anyway I'm off to bed, thanks again for the help bdx! Goodnight
<veebers> ugh, I've been watching the wrong application thinking it's the one causing the failure :-\
<anastasiamac> veebers: just knowing that gets u closer to determining the root cause
<veebers> anastasiamac: at teardown I'm seeing the machine being torn down but not the application and it keeps trying. That seems odd right? if it's machine is gone there essentially is no more application
<veebers> kelvinliu: where you looking at percona-cluster hooks issues recently?
<anastasiamac> veebers: not necessarily
<anastasiamac> veebers: if it's a unit than yes, however, the applictaion is k to exist without any units (machines)
<veebers> anastasiamac: oh ok, cool I'll continue digging
<veebers> I'm wondering if it'll be like yesterday where I spent hours digging all to come up with a 3 line fix ^_^
<anastasiamac> well, they do say that simplicity is ingenuios (or smth like that)
#juju 2018-05-04
<kelvinliu> hi veebers, I just saw u mentioned that in standup. I was looking at deploying percona-cluster on caas
<kelvinliu> veebers, the problem was `leader-elected` hook failed due to `network-get` could not find relation primary address(it's empty `{MACAddress: InterfaceName: Addresses:[]}`)
<veebers> kelvinliu: ah right, thanks. I could have sworn it was a relations thing but wasn't too sure ^_^
<kelvinliu> veebers, Is the issue on IAAS ?
<veebers> kelvinliu: aye, it's charm related. Not sure of the impact for caas.
<kelvinliu> ah, did ur deployment failed at the same hook?
<kelvinliu> https://pastebin.ubuntu.com/p/7JXwP44Ry4/
<kelvinliu> Is the error u got, veebers ?
<veebers> kelvinliu: no, the percona-cluster error was in deb-relation-changed
<veebers> it deployed fine, was when I attempted to relate it to a mediawiki app that it fails
<kelvinliu> ic
<kelvinliu> the problem might be different.
<veebers> I believe it is
<valenitn> hi guys
<valenitn> is it ok to ask for help on deploying with juju here?
<rick_h_> valenitn: sure thing
<valenitn> great, thanks
<valenitn> I'm trying to deploy a xenial charm on azure with storage
<rick_h_> valenitn: cool, you've peeked at https://jujucharms.com/docs/2.3/charms-storage ?
<valenitn> this worked fine a few weeks ago, but now I get the agent blocked in "allocating" and storage in "pending"
<rick_h_> valenitn: hmm, so have to see in the debug log what's up
<valenitn> yep, that's where I got the command from
<valenitn> there's nothing relevant in the juju logs for the unit or the machine
<rick_h_> valenitn: it might be in the controller logs as it sets up the storage to be used
<rick_h_> valenitn: the unit itself doesn't make the calls out to the storage provider
<valenitn> I think the storage works because I see the disks on the machine with lsblk
<valenitn> but they are not mounted
<rick_h_> valenitn: hmm, can you `juju switch controller` and check the logs on the controller machine?
<rick_h_> if there's nothing in the unit/machine log there it's the only other place I can think to look for any error/issue feedback
<valenitn> there is this in the logs, but I remember seeing it even when it was working:
<valenitn> machine-0: 08:09:36 WARNING juju.cmd.jujud determining kvm support: INFO: Your CPU does not support KVM extensions KVM acceleration can NOT be used : exit status 1 no kvm containers possible
<rick_h_> valenitn: yea, but that's nothing to do with storage. That just means you can't create kvm containers on that platform
<valenitn> on the machine syslog I see May  4 08:15:38 machine-1 HV_FCOPY: open /dev/vmbus/hv_fcopy failed; error: 2 No such file or directory
<rick_h_> hmm, that looks better more interesting. There's some instances of that out there. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1614618
<mup> Bug #1614618: hv-fcopy-daemon.service system failed start <amd64> <apport-bug> <kernel-da-key> <kernel-hyper-v> <uec-images> <yakkety> <linux (Ubuntu):Confirmed> <linux (Ubuntu Xenial):Confirmed> <https://launchpad.net/bugs/1614618>
<rick_h_> valenitn: might have to file a bug.
<rick_h_> valenitn: does it work intermittently? I see some links around bits of this stuff being racy
<valenitn> it failed consistently in the last days
<valenitn> I thought something on azure changed
<valenitn> maybe the ami for ubuntu?
<rick_h_> valenitn: yea, maybe something with a new kernel or maybe something Juju needs to be doing automatically that Azure changed. I'm not sure.
<rick_h_> valenitn: if you can file a bug with the charm/instructions for what you're trying we can chase it down
<valenitn> ok, will try to look a little more and file a bug
<valenitn> thanks for help
<rick_h_> valenitn: yea sorry I don't have a quick fix for you
<valenitn> np
<TheAbsentOne> rick_h_: do you know a good, recent interface example. I'm not really getting it how I can properly send information from one charm to another through a self-written custom interface :/ it's to_publish right?
<TheAbsentOne> https://jujucharms.com/docs/2.3/developer-layers-interfaces <-- does relations.unit in this tutorial represent all connected charms?
<srihas> hi guys, I have installed nova-compute on our compute nodes, Now I am thinking to install the percona clulster on another three nodes supposed to act as controllers. What does the "deploy --to lxd:0" mean here? I have skipped the neutron deployment as I want to do it later with cisco ACI.
<roadmr> srihas: "deploy --to lxd:0" means it will deploy into a new lxd container which will be created on machine 0
<roadmr> srihas: https://jujucharms.com/docs/2.3/charms-deploying-advanced#deploying-to-specific-machines
<srihas> aha
<srihas> roadmr: what if the machine is not yet in the list of machines on juju ? then I go the way I do --constraints tags=db --to lxd ?
<srihas> but then I cannot specify :0 or 1 or something, right?
<srihas> "To deploy to specific, pre-existing machines the --to option is used. When this is done, unless the machine was created via add-machine, a charm has already been deployed to the machine."
<roadmr> srihas: AFAIk there's always a machine 0, but you may be able to specify any existing machine
<roadmr> srihas: it sounds like you're following a document, that should tell you the machines that are available
<srihas> roadmr: I want to install percona on a new fresh machine thats not yet in the list of machines in juju
<srihas> juju machines doesn't show a machine with id 0 for me :o
<zeestrat> srihas: Are you following along https://docs.openstack.org/charm-deployment-guide/latest/install-openstack.html#deploy-openstack?
<srihas> zeestrat: yeah
<srihas> I am on it
<srihas> but its sometimes confusing me
<srihas> like now the swift-server.config has the bind_ip = 0.0.0.0 instead of specific IP
<srihas> :7
<zeestrat> srihas: Gotcha. I'd recommend maybe looking at using bundles which is mentioned in the next step https://docs.openstack.org/charm-deployment-guide/latest/install-openstack-bundle. It will make it easier to define things and map applications to machines in a predictable way
<srihas> zeestrat: thats a good point. I will study it though I can't deploy directly
<zeestrat> Also if you find some doc bugs you can file them here https://launchpad.net/charm-deployment-guide
<srihas> zeestrat: is there a way to add all the "ready" nodes to juju
<srihas> like I get them when I do the juju machines
<srihas> without any charms (atleast OpenStack related) deployed
<zeestrat> Just so I understand, is there a reason you can't deploy bundles directly?
<srihas> zeestrat: yeah, we will be using cisco ACI for neutron and ScaleIO for storage. so no ceph and neutron
<zeestrat> srihas: Right. But you're using openstack charms with juju for the other components such as Nova compute? You can just remove them from the bundle
<srihas> zeestrat: aha
<srihas> zeestrat: I will look around it, thank you for the suggestions
<srihas> will get back to you
<srihas> zeestrat: how can we add custom charms, for example if we use ScaleIO ?
<srihas> 16:39 < srihas> zeestrat: is there a way to add all the "ready" nodes to juju
<srihas> 16:39 < srihas> like I get them when I do the juju machines
<srihas> I think this is needed, I am missing some thing crucial here
<zeestrat> srihas: I'm actually not sure. I only use bundles which define which machines I want from MAAS. I'm thinking out loud now, but you can check if you can do a `juju add-machine` which should deploy a machine, then if you do something like `juju deploy nova-compute --to <machine-id>` where <machine-id> is the one you get after the add-machine.
<zeestrat> srihas: But I really think you should look at using bundles where you can define constraints which allows you to select which machines you want to deploy on from MAAS.
<srihas> aha
<zeestrat> srihas: Regarding ScaleIO, are you planing to use the charms from https://jujucharms.com/u/cloudscaling/ or write your own ScaleIO charms? I haven't used them so don't know the state of them.
<srihas> zeestrat: the ones from juju, they are old?
<srihas> https://github.com/thecodeteam/juju-scaleio -> I looked at them before
<zeestrat> Looks like last activity was in Jan 2017 so I'm not sure of the state.
<srihas> zeestrat: ok
<srihas> zeestrat: is there a guide to write "hello-world" juju charm ? (please bare with me)
<zeestrat> srihas: https://jujucharms.com/docs/stable/developer-getting-started
<srihas> zeestrat: thank you
<zeestrat> srihas: No problem. The bundle docs page talks a bit more about constraints and how to place things on different machines. https://jujucharms.com/docs/2.3/charms-bundles If you tag machines in MAAS you can target those using the `tags` constraint which is one of the constraints available: https://jujucharms.com/docs/2.3/reference-constraints
<zeestrat> srihas: I can whip up a short example, but you'll have to remind me next week
<srihas> zeestrat: sure, I will get back to you :)
<otama> HELP: Hi Team, is it possible declare a Cross Model Relations into a bundle files ?
#juju 2018-05-06
<veebers> Morning
<wpk> Evening
<veebers> hey wpk o/ how goes things?
<wpk> veebers: lots of work :)
<wpk> veebers: so I guess same old, same old :)
<veebers> wpk: heh, hopefully enjoyable work. ^_^
#juju 2020-04-27
<flxfoo> hi all
<flxfoo> maybe not the right place to ask but with rackspace I still have trouble creating a new controller
<flxfoo> usnig `metadata-source` (because there own default does not expose any images)
<flxfoo> I end up with
<flxfoo> ÂPNG
<flxfoo> Y
<flxfoo> oops sorry
<flxfoo> caused by: request (https://lon.servers.api.rackspacecloud.com/v2/10001843/servers) returned unexpected status: 403; error info: {"forbidden": {"message": "Policy doesn't allow standard_flavor:create:attach_volume to be performed.", "code": 403}}}])
<flxfoo> any idea where to look at?
<stickupkid> manadart, i'll fix the vpc issue on that aws script
<stickupkid> manadart, i'm not a fan of creating a VPC, so this might actually be worth it
<stickupkid> manadart, I updated it to re-use the VPC - https://github.com/juju/juju/pull/11412
<stickupkid> manadart, pure cattle approach
<manadart> stickupkid: Great. Are you working as usual today?
<stickupkid> I am
<stickupkid> well I am after Lunch
<stickupkid> haha
<stickupkid> hml, where did we get with the focal stuff?
<hml> stickupkid: the PR is readyâ¦ had to make a few changes, so I wanted another set of eye
<hml> eyes
<stickupkid> hml, I shall do it
<hml> stickupkid: ack
<stickupkid> hml, we want this to fail right? ./main.sh -V -S focal -l friday deploy.
<stickupkid> hml, or do we want it to bootstrap a new controller?
<hml> stickupkid: I was copying the behavior of the env var for bootstrap seriesâ¦ it should bootstrap a new controller if controller friday is not focal
<stickupkid> ok, let's fix that
<hml> stickupkid: uh?
<hml> stickupkid: chat at stand up?
<stickupkid> sureo
<stickupkid> hml, approved, I can't approve my own PR though, so can you approve it for me?
<hml> stickupkid: sureâ¦ since weâre in agreement now
<stickupkid> hml, yeah... happy with the changes
<hml> stickupkid: tick
<stickupkid> hml, we should think about how to add this to jenkins now
<stickupkid> hml, i'll have a look now
<hml> stickupkid: i think we need to look at series in jenkins over all - there are still some jobs that use trusty by default.  we should test it as an LTS, not necessarily by default etc
<stickupkid> ok, job for today then - hml
<hml> weâre overridding the default too often I think, should be more explicit
<hml> so when we want to update the default, itâs easier
<hml> stickupkid: shall we use the default series by âdefaultâ and set it for explict tests, rather than having it set as a default in random spots?
<hml> then the question is, which tests should we run for trusty, xenial etc.. and bionic moving forward
<stickupkid> hml, unsure - I'm not sure how to do it yet
<hml> stickupkid: would be a good place to have a test jenkins setup
<hml> :-D
<hml> stickupkid: investigate and compare notes in an hour?
<stickupkid> hml, I'm going to try and do the integration tests now, and see what the fallout it. Then I can check how others do it
<hml> rgr
<stickupkid> hml, question is, do we want to test LTS+non-LTS
<stickupkid> or is LTS alone enough?
<hml> stickupkid: we should still do non-LTSâ¦ but like weâve been, explicitly
<hml> stickupkid: what did you change?
<stickupkid> we only have a 60 minute timeout for the merge job, we're hitting that atm
<hml> stickupkid: why are we hitting it?  there is barely anythign running?
<stickupkid> 15:15:01 2020-04-27T14:14:19Z INFO Waiting for restart...
<stickupkid> 15:25:58 go (1.14/stable) 1.14.2 from Michael Hudson-Doyle (mwhudson) installed
<stickupkid> It took 10 minutes to install go
<stickupkid> LOL
<stickupkid> Another 10 minutes to fetch all the dependencies
<hml> stickupkid: so this isnât waiting on other jobs?
<stickupkid> 20 minutes to install
<stickupkid> hilarious
<stickupkid> as we download/build in containers the go mod cache is pure worthless
<hml> stickupkid: think we have enough time on the replacement deploy bundle integration tests that we can dump the nw-deploy-lxd-sub-profile-bundle-lxd
<stickupkid> yeah
<hml> stickupkid: https://github.com/CanonicalLtd/juju-qa-jenkins/pull/437
<hml> stickupkid: it has a link to the related juju pr
<stickupkid> hml, tick
<hml> stickupkid: https://github.com/juju/juju/pull/11501. :-D
<stickupkid> hml, it would nice to land this one https://github.com/juju/juju/pull/11412
<stickupkid> hml, that way we could add it to the integration tests
<stickupkid> hml, focal testing etc
<hml> stickupkid: ack, looking now
<stickupkid> hml, acceptancetests/assess_bootstrap.py <- I wonder if we can remove this if we target more architectures?
<hml> stickupkid: perhapsâ¦ maybe series too.
<stickupkid> hml, ah it bootstraps to maas, I've not do that yet
<hml> :-/ almost
<hml> stickupkid: how do you config â that you
<hml> have a default region that probably isn't us-east-1â
<stickupkid> hml, I've got an .aws credential and I set the default region
<stickupkid> [default]
<stickupkid> output = json
<stickupkid> region = eu-west-1
<stickupkid> that's my .aws/config and use autoload credentials
<hml> are you going to fix all the install petname pieces?  for jenkins :-D
<stickupkid> hml, yeah
<stickupkid> :(
<stickupkid> hml, forgot that everything is cattle in the integration tests https://github.com/CanonicalLtd/juju-qa-jenkins/pull/438
<hml> stickupkid: tick
<stickupkid> having a very productive day today
<stickupkid> tick this, tick that
<stickupkid> got loads of stuff working
<hml> stickupkid: https://pastebin.canonical.com/p/jVS3VyCXVF/
<hml> brwhahahahaha
<hml> :-D
<stickupkid> how do I solve this :thinking-face:
<stickupkid> I'm like revinventing juju in tests
<stickupkid> sigh
<stickupkid> but without a type system
<pmatulis> can an application's leader unit be set (changed) by the juju client?
<pmatulis> (the docs don't mention it)
<rick_h> pmatulis:  no
<pmatulis> rick_h, alright thanks
#juju 2020-04-28
<flxfoo> hi all
<flxfoo> sorry to bother again for a quick one.
<flxfoo> rax asked me to try changing the flavor (trying to bootstrap a new controller)
<flxfoo> list of "flavors" name contains spaces character
<flxfoo> so if I use `instance-type=4GB Standard Instance` that does not work... as juju client will consider `Standard` and `Instance` as parameters... Of course I tried to escape space character but with mo luck
<flxfoo> does anyone has some ideas for that?
<achilleasa> flxfoo: AFAICT from looking at the constraints parsing code, we currently split the constraint list on space so this (or any other key-value constraint combination with spaces for that matter) will not work.
<achilleasa> flxfoo: Can you create a bug for this?
<flxfoo> achilleasa: ok, where do I do that?
<achilleasa> flxfoo: you can create a new one here: https://bugs.launchpad.net/juju/+filebug
<flxfoo> ok I created a bug
<flxfoo> is there anything I can do meanwhile?
<achilleasa> flxfoo: are the instance types aliased or something that you can rename? Btw, what provider are you using?
<flxfoo> achilleasa: provider is rackspace
<achilleasa> flxfoo: if it's a blocker and you don't mind compiling juju I can push a branch with a quick patch which will allow you to use something like '\ ' to escape spaces till we fix the bug
<flxfoo> achilleasa: it looks like juju by default uses flavorId = 5, is there a parameter to pass to juju to update that?
<flxfoo> achilleasa: the blocking situation is that, rax deleted an image which the current ctrl would use to create containers, so the platform is pretty unmanageable. On top of that, the current ctrl has been bootstraped using a custom simplestream  because the image list provided by rackspace is empty.
<flxfoo> achilleasa: so I though to bootstrap a new ctrl with a new image id (that rax provided me) in order to migrate the model, so at least I can do something.
<achilleasa> flxfoo: if you pass "general1-4" as the instance type does it work?
<achilleasa> flxfoo: oh wait, according to https://developer.rackspace.com/docs/cloud-servers/v2/general-api-info/flavors/ ID 5 corresponds to the one you are trying to use (4gb standard instance)?
<flxfoo> achilleasa: tried it nope, it returns the list of available flavors which the ones with spaces
<flxfoo> achilleasa: yeah (my bad) I should have tried another one, but the issue remains with the spaces...
<flxfoo> achilleasa: this is rax support answer: It looks like the issue with the command is that you're attempting to create a boot from volume Standard flavor server. Standard flavor servers don't have the ability to use a CBS volume as the system disk. You'll either want to try the command without the flags for BlockDeviceMappings or choose a different server flavor such as General Purpose:
<achilleasa> I see. As mentioned, I can push a branch with a patch to get you unblocked until the bug is fixed
<flxfoo> achilleasa: thanks
<flxfoo> achilleasa: just a silly question, I suppose I can not create an instance on rackspace and tell juju to use it to setup the controller?
<achilleasa> flxfoo: you probably can if you set it up as a manual cloud (https://juju.is/docs/manual-cloud). Don't have access to rackspace so I can't verify this though...
<flxfoo> achilleasa: thanks for your time
<achilleasa> flxfoo: if you checkout (https://github.com/achilleasa/juju/tree/2.7-support-escaped-spaces-in-constraints) in $GOPATH/juju/juju and run 'make install' you will have a juju cli that supports constraints with slash-escaped spaces
<achilleasa> flxfoo: FYI, there is another related bug for zones with spaces and the fix for that (currently in review) will also take care of the issue you are having without the need to manually escape spaces
<thumper> https://github.com/juju/juju/pull/11506 fix for intermittent test failure
<stickupkid_> thumper, I'll check that one
<stickupkid_> thumper, any QA steps, other than hammer the test with -race?
<stickupkid_> manadart, https://github.com/juju/juju/pull/11412#issuecomment-620525235
<thumper> stickupkid_: nah
<thumper> stickupkid_: it took 10 - 20 minutes to replicate on my machine
<stickupkid_> thumper, I tried whilst waiting for aws to bootstrap and couldn't replicate
<thumper> yeah, that's cause I fixed it :)
<stickupkid_> before hand
<stickupkid_> haha
<thumper> ah... yeah, it took me a long time
<stickupkid_> anybody tried rebuilding dependencies for 2.7 branch
<stickupkid_> juju ssh 0 -m controller <- why does that not work and this does -> juju ssh -m controller 0
<stickupkid_> we totally we should have done juju ssh 0 -m controller -- bash
<timClicks> are storage pools model-level entities or cloud-level ones? if I run create-storage-pool in model a, will it be available from other models?
<hml> timClicks: they seem to be model-level from my experience
<hml> stickupkid: ran qa on 11412 with new code - success, though what is âERROR no available address(es)â from at the end?
<stickupkid> hml, yeah, that's fine it's trying to get the engine reports
<stickupkid> hml, it's optional at best
<hml> stickupkid: rgr
<hml> udpate my results in the pr
<jam> axino, looking at your charm code, I don't see install or start being handled, just config-changed/leader-elected/upgrade-charm
<axino> jam: yeah but the "hooks" directory has a "start" symlink to charm.py
<jam> axino, gotcha. I would also create an install symlink. You can have both and that should handle 2.7.3 and 2.8
<axino> jam: indeed, indeed. This is what the official operator doc says currently
<axino> I think I'll just resolve this bug
<axino> done
<axino> sorry for the noise o/
<jam> axino, np. I think it is very good to understand changes between releases
#juju 2020-04-29
<flxfoo> Hi all, (me again)
<flxfoo> From rackspace: Juju is generating the build request with the flavor ID of 5, but it is also using "block device v2" syntax, which is not supported on the Standard flavor. I recommend that you file a bug on Juju's launchpad (https://bugs.launchpad.net/juju ). Unfortunately, we are unable to support 3rd-party clients such as juju.
<flxfoo> should I file a bug?
<babbageclunk> flxfoo: yes please! Then we can prioritise and track fixing it.
<flxfoo> babbageclunk: ok
<stickupkid_> manadart, ping if you have _any_ free time today
<manadart> stickupkid_: Got some time now.
<stickupkid_> manadart, daily
<flxfoo> ok, I manage to pass most of the errors... I have one left , like juju aborts because he reaches max_duration as follow
<flxfoo> ERROR failed to bootstrap model: cannot start bootstrap instance: cannot run instance: max duration exceeded: instance "65d6ebb6-4c9d-47d5-adf2-d5812ec8bfe9" has status BUILD
<flxfoo> is there a way to change that `max_duration_exceeded`?
<stickupkid_> flxfoo, so I'm not sure - hml, might be more knowledgable, I presume rackspace/openstack might be worth googling here.
<timClicks> flxfoo: it's possible to add a bootstrap-timeout, e.g. "juju bootstrap --config bootstrap-timeout=900 ..."
<achilleasa> stickupkid_: or hml backport of the zones-with-spaces PR + extra fix for instance-types https://github.com/juju/juju/pull/11511
<hml> achilleasa:  looking
<achilleasa> ^ once landed I will need to forward merge 2.7 -> develop
<achilleasa> stickupkid_: fixed the typo in the alias expansion and also addressed some extra ineffassign warning in a separate commit. Can you take a look while the linters are running?
<stickupkid_> achilleasa, checking now
<stickupkid_> achilleasa, we skip some
<stickupkid_> goimports not found, goimports static analysis disabled
<stickupkid_> unconvert not found, unconvert static analysis disabled
<stickupkid_> ineffassign not found, ineffassign static analysis disabled
<achilleasa> we should also turn on the unused one... lot's of dead code that can be cleaned up
<hml> stickupkid_: must be the github actions
<stickupkid_> yeah
<stickupkid_> I'll do it tomorrow
<stickupkid_> coming to my EOD
#juju 2020-04-30
<hpidcock> PR please https://github.com/juju/juju/pull/11515
<babbageclunk> hpidcock: looking
<babbageclunk> hpidcock: approved
<hpidcock> babbageclunk: thanks
<wallyworld_> babbageclunk: piling on, i have a couple of PRs up if you have a little time to look
<babbageclunk> wallyworld_: otp with thumper, will look after that
<wallyworld_> oh sorry, ty
<wallyworld_> stickupkid: hey, so if this gets landed, it will make experiemtng with centos and windows images much easier https://github.com/juju/juju/pull/11513
<stickupkid> wallyworld_, nice, let me qa it
<wallyworld_> stickupkid: i used it to try centos on aws etc. we still need to teach juju how to inperpret an error saying "no image for you" as something other than a "these creds are broken" error
<hpidcock> can I get a PR reviewed at some point pls https://github.com/juju/juju/pull/11509
<wallyworld_> hpidcock: lgtm
<SachinKulkarni> Facing a strange issue while running "juju status". it's failing with an error "ERROR cannot unmarshal accounts: yaml: control characters are not allowed"
<achilleasa> hml: stickupkid followup fix for the constraints-with-spaces bug; can either of you review? https://github.com/juju/juju/pull/11519
<stickupkid> achilleasa, so "a  b" will be "a\ \ b" right?
<achilleasa> stickupkid: yes. Just as you would do in a shell command
<stickupkid> fair
<achilleasa> ideally we should also support quoted kv pairs
<achilleasa> but it's way more effort than this small change (you'd need a tokenizer with depth counters for nested quotes etc.)
<achilleasa> stickupkid: also, if you take a look at https://bugs.launchpad.net/juju/+bug/1847259, you will see that Pedro tried to slash-escape the spaces
<mup> Bug #1847259: Juju  --constraints "zones=NAME WITH SPACES" fails because of space chars <juju:Triaged> <https://launchpad.net/bugs/1847259>
<stickupkid> achilleasa, it's actually easier to read
<stickupkid> achilleasa, I used the prior to the previous commit to compare against
<achilleasa> hml: can you take a look at https://github.com/juju/juju/pull/11521?
<hml> achilleasa:  looking
<hml> achilleasa:  approved
<wallyworld_> stickupkid: last one :-) https://github.com/juju/juju/pull/11522
<stickupkid> wallyworld_, looking
#juju 2020-05-01
<manadart> Morning achilleasa. Care to review a small one? morning achilleasa
<manadart> Copy/paste fail.
<manadart> https://github.com/juju/juju/pull/11524
<achilleasa> manadart: looking
<achilleasa> it looks like reading application the local application settings from the leader unit on k8s is broken :-(
<achilleasa> because the ReadSettings call includes the app name and the operator always logs in as the application, token checks for the leader fail...
<achilleasa> most probably also affects 2.7 but hopefully be an easy fix (just a bump in the facade version)
<achilleasa> ... ah crap... not so easy to fix afterall (at least without bypassing the leader check on the server).... anyone around to chat?
<achilleasa> TLDR version: the ReadSettings call uses a RelationUnit struct {Relation, Unit}. When we read the application settings, the client passes the _application tag_ as the unit tag.
<achilleasa> it works for non-k8s charms because the uniter logs in as the unit and therefore we can check the token(app-tag, unit-tag from auth)
<achilleasa> on k8s, the auth tag is the app so this fails. Obviously, modifying the RelationUnit struct to include the unit *and* the app defeats the purpose of token checks as the client can put whatever they want in there
<achilleasa> not sure how to proceed here... any thoughts thumper or wallyworld? ^^^
<timClicks> [Call for testing] upcoming Juju 2.8 release https://discourse.juju.is/t/-/2994
