#juju 2012-05-28
<tog> Hi, I am new to juju. I have installed juju (local)  on 12.04 server running in Vbox. I am sitting on a corporate network behind a proxy. When tryng to deploy MySQL I get a DNS error for store.ubuntu.com. At home (no proxy), it works like a charm :-)
<hazmat> hmm
<hazmat> i think we'll need http proxy support for that use case
<hazmat> client side
<SpamapS> hazmat: desperately
<hazmat> SpamapS, distinct from apt proxy support
<SpamapS> hazmat: right
<hazmat> SpamapS, get into any bbq's this weekend?
<SpamapS> hazmat: planning on going to one today, but wife has been having braxton hicks contractions so I am hesitant to commit to any plans. :)
<SpamapS> hazmat: and I cooked up some tri-tip on Saturday that basically blew my mind :)
<SpamapS> hazmat: u?
#juju 2012-05-29
<koolhead17> hi all
<vrturbo> hi all
<vrturbo> have two problems
<vrturbo> have a private openstack cloud that needs http proxy for apt
<vrturbo> how do I bootstrap and have the zookeeper use the apt-proxy?
<vrturbo> second issue, how to define the default instance flavor for juju deploments
<vrturbo> ?
<imbrandon> where can i get the machine id for a unit, no other context is set , its from an outside script running on a node, so no hook etc
<imbrandon> i'm looking to pass it on cli to a app with --machine_id as the docs say, they just dont say what it is exactly or where to obtain it properly ( or any way at all )
<victorp> hi
<victorp> I am doing a juju upgrade-charm
<victorp> and guess what my new charm update was broken
<victorp> I have ssh into the instance and fixed it and now I would like to do a new upgrade-charm but the state of the instance is on an error
<victorp> and upgrade wont work, is there any way to change that or do it need to destroy the service and start again?
<imbrandon> victorp: juju resolved service/N
<victorp> imbrandon, thanks!
<victorp> do you also happen to know how to access file that have being copied as part of the charm, there must be a env variable or something for the folder no?
<imbrandon> in /var/lib/juju/ somewhere
<imbrandon> cant rember right off
<imbrandon> iirc
<victorp> imbrandon, thanks I solved it :) I was assuming that it was running under /charm/hooks rather than /charm/
<victorp> imbrandon, who is your wordpress charm coming along?
<imbrandon> good good
<imbrandon> oh i just read your blog posts :)
<imbrandon> took me a minute to put 2+2 :) but yea, i'm working on the nginx charms ( its broken into a few ) and the drupal charms mostly ( and the omg-wp custom wordpress one ) marcoceppi is doing most of the new wordpress one, but they all are based on work we did on omg-wp
<imbrandon> :)
<imbrandon> victorp: i noticed in the branch too it looked like you copy/pasted one of the hooks, it may just be the way loggerhead shows it as i dident check it out but if so just fyi symlinking works fine
<imbrandon> with hooks
<victorp> imbrandon, I just run into that problem and changed it into a link - hopefully should be fine now
<imbrandon> :)
<imbrandon> also there is "juju debug-hooks <service> <hook>" too if you get stuck, thats a life saver along with the jitsu wrapper/tools
<imbrandon> afk a few, but i'll be round all day if ya catch a snag
<victorp> imbrandon, cool I will start trying that
<victorp> imbrandon, thanks a lot
<imbrandon> np
<surgemcgee> Has anyone else figured out how to use a debconf-set-selections with Mercurial, git, or svn already? If  not, any other ways to use a password with repositorys?
<surgemcgee> Ok, looks like I can preconfigure the .hg/hgrc file in the project init.
<jcastro> negronjl: SpamapS: You guys have change access to the new charm pilot calendar, bus factor
<SpamapS> jcastro: I'll just remind you that I do not see messages that aren't ^SpamapS
<jcastro> k
 * SpamapS wonders if irssi could be fixed to highlight on the whole line
<imbrandon> SpamapS: depends on how much perl you want to dig into :)
<imbrandon> jcastro: hey on your way back down south, just stop off at KC and drop me a conney , kthxbia.
<imbrandon> then con someone over there to drop me a in-and-out burger from the left coast and i'll be set ( never grabbed on in SFO, totally skipped it LOL )
<aljosa> i have a juju agent using ~95% cpu "/usr/bin/python -m juju.agents.machine --nodaemon --logfile /tmp/local-dev/root-local/machine-agent.log --session-file /var/run/juju/root-local-machine-agent.zksession"
<aljosa> any idea what's wrong with my installation/setup? or is it some bug?
<imbrandon> do you have debug-log running ?
<imbrandon> iirc that will send zk into a frenzy sometimes ... other than that, anything more to go on ?
<aljosa> no, but log has mostly zookeeper errors "ZOO_ERROR@handle_socket_error_msg@1528: Socket [192.168.122.1:50821] zk retcode=-7, errno=110(Connection timed out): connection timed out (exceeded timeout by 0ms)"
<imbrandon> hrm, past me, maybe SpamapS or hazmat will pop in soonish and be able to help you trace it a bit more
<SpamapS> imbrandon: honestly.. in n out is only good because everything over there is such crap. Here in LA we make fun of in n out. ;)
<SpamapS> Its not "bad" per se.. but its just not deserving of the reputation it has from outside the state.
<hazmat> ah.. its local provider post reboot
<SpamapS> aljosa: kill it
<SpamapS> hazmat: hopefully we'll get that SRU to -proposed today
<_mup_> juju/proposed-support r488 committed by kapil.thangavelu@canonical.com
<_mup_> enable proposed on main AND universe.
<aljosa> is this some zookeeper related bug? log is basically full of zookeeper connection errors, timeout or something like "Exceeded deadline by 821282ms"
<hazmat> aljosa, the local provider environment doesn't survive reboots
<aljosa> ok, thanks for help and your time
<m_3> SpamapS: the last line of my irssi config file is `hilights = ( { text = "m_3"; nick = "yes"; word = "yes"; } );` which seems to do what you're saying... I think that's stock and not a plugin
<SpamapS> m_3: will try that, thanks
<m_3> I think the `text` part is magic SpamapS see if you see this
<imbrandon> m_3: i think he means the whole line and not just the word
<imbrandon> err name
<m_3> imbrandon: right... that'll hilight the line when the text is matched anywhere in the line... not just the nick match
<m_3> afaik
<imbrandon> oh yea it will
<m_3> _heavily_ copied/pasted without full understanding :)
<imbrandon> i took it as the other way as in like when you select with your mouse the line
<imbrandon> as in yea, it does what your saying we just both took SpamapS statement diffrent ways that at this minute both seem correct
<imbrandon> lol
<imbrandon> like you konw the "current line hilight" in an IDE
<imbrandon> thats how i was thinking, not that the word was said on that line
<m_3> recommend adv_windowlist.pl too
<imbrandon> yup, i cant live with out that one
<imbrandon> m_3: http://cl.ly/Gzi2
<imbrandon> see how mine hilights, just the name :) i was thinking for that whole line to turn yellow
<imbrandon> was the goal
<imbrandon> :)
<m_3> imbrandon: http://files.markmims.com/irssi.png
<m_3> actually like the bitlbee twitter plugin
<imbrandon> i used btlbee for a while but i couldent get used to it
<imbrandon> http://paste.ubuntu.com/1013228/
<m_3> I just forget the dang commands and have to hunt around every time
<imbrandon> m_3: that fnotify.pl one is very very nice, it sends my desktop or wherever i am notify-osd commands remote
<imbrandon> of mentions etc from my irssi running on the server somewhere else while attached
<m_3> yeah, I have fnotify in there, but never took the time to set it up
<m_3> you get it to sms or just growl / gnome-notify?
<imbrandon> its real easy if you only use one or two machines
<m_3> I just use one... always on, just attach/detach
<imbrandon> growl notify-osd ( for kde too )
<m_3> oh, but for client yeah... I'm on several
<imbrandon> but its very clean and easy to modify
<imbrandon> i bet it would take 5 min to make work withj prowl
<m_3> really want it to just notify to the ipad/iphone
<imbrandon> thats prowl
 * m_3 note to google prowl later
<m_3> thanks
<imbrandon> its push growl to the phone / pad / desktop
<imbrandon> free middle man service , and you have to get a 1.99 ( not a scam ) ios app, but the desktop and other apps are free
<m_3> cool
<imbrandon> they are the equiv of growl infact it uses growl on the desktop
<m_3> sounds liek just the ticket
<m_3> oops... gotta run the wife to dentist.. back online in the waiting room in a bit
<imbrandon> but yea for a one time $2 cost, best 2 bux i spent in a very very ;ong time
<imbrandon> and its got a nice simple rest api for custom stuff if you want, like i have github hooks setup to ping it etc
<imbrandon> l8tr
<imbrandon> m_3: haha your irssi window is very very close to mine, first time i've seen that, most ppls irssi setups are soooo diffrent
<imbrandon> i think i dropped the ACT: N from the top line and the rest is the same
<negronjl> 'morning all
<negronjl> jcastro:  Sorry I'm late in the conversation but, where is the charm pilot calendar ?
<jcastro> negronjl: I just made it
<jcastro> I am working on it now
 * negronjl nods
<negronjl> jcastro: thx ... let me know if I can help
<jcastro> yeah I can't get the script to work but that's just me
* jcastro changed the topic of #juju to: Reviewer: ~charmers || Review Calendar: http://goo.gl/uK9HD || Review Queue: http://jujucharms.com/review-queue  || Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms || OSX client: http://jujutools.github.com/"
<jcastro> negronjl: see topic, there's the schedule
<jcastro> m_3: your preferred day is today so I put you down for today, since that's kind of last minute feel free to just do it whenever this week, that sound ok?
<m_3> jcastro: Tuesday is best
<m_3> jcastro: thanks!
<jcastro> ok so everyone got their preferred days
<jcastro> and we have at least one dude a week
<jcastro> which I don't think will be a problem once we get the current queue down a few more items
<pkimber> \quit
<jcastro> ok so once we deal with bac's mp that brings our queue time down to 3/4 weeks.
<bac> :)
<jcastro> marcoceppi: imbrandon: ok I've added you guys to the calendar (see topic) if you want to commit to certain days and add them
<jcastro> otherwise, review the queue at your leisure!
<marcoceppi> jcastro: cool, thanks!
<imbrandon> jcastro: ty ty
<imbrandon> jcastro: you have james one 4th july, not certain but i'm not sure much would be done that day
<imbrandon> :)
<imbrandon> s/one/on
<jcastro> he's british, I don't think they celebrate that
<jcastro> :)
<imbrandon> heh dident think of that :)
<imbrandon> whoops
<imbrandon> lol
<SpamapS> jcastro: I will deal with bac's thing after I get juju uploaded to Debian this week
<SpamapS> I don't know if thats appropriate for charmers.. at this point we're blocked on getting things into the distro
<SpamapS> jcastro: btw, thanks for getting the calendar setup. Looks great!
<imbrandon> i'ma try and do saturdays, at least every other one, since thats when most everyone else is afk anyhow mostly
<SpamapS> imbrandon: you only need to commit to 1 saturday per month
<imbrandon> but today is my step-dads bday, 70 years old, soooo i'm off to take him and my mom to lunch
<jcastro> SpamapS: niggling items are fine I think, it just forces us to check it at least once a week
<imbrandon> i'll be back in a few  , ok one sat ( first one of the month ) garenteed, but i'll obviously do more as i have time etc etc
<imbrandon> hows that :)
<imbrandon> jcastro: i cant add to the calendar, my google account is me@brandonholtsclaw.com
<imbrandon> bbiab :)
<jcastro> fixed
<SpamapS> Man I'm about to run out of colors for the google calendars I subscribe to
<SpamapS> 9 so far
<nathwill> SpamapS, you lie! http://hypertextbook.com/facts/2006/JenniferLeong.shtml
<SpamapS> nathwill: wee, only 99,991 left by the most conservative estimate!
<nathwill> SpamapS: time to sign up for more calendars!
<SpamapS> nathwill: though I'd like for them to *stand out* not to be distinguishable
<nathwill> lol
<jcastro> SpamapS: ok so this works out great with the charms-tool review, that leaves mims and juan to go directly into the charm contest queue.
<jcastro> SpamapS: you and negronjl did awesome driving that number down from 34!
<SpamapS> jcastro: I think over the next month the real measure will be the avg-days-in-queue
<SpamapS> jcastro: our target should be 3
<SpamapS> well, lets say 7
 * jcastro nods
<jcastro> negronjl: oh mira, we'll need graphs of that stuff, but probably not a priority right now
<jcastro> ok so I'm about to file bugs for everything in the spreadsheet that does NOT have a bug report.
<jcastro> so I'm about to launchpad spam everyone, be warned!
<SpamapS> jcastro: woot
<negronjl> jcastro:  got it ... graphs...  I gotta finish some CloudFoundry stuff first and I'll get on that.
<jcastro> it's not CloudFoundry important. :)
<negronjl> SpamapS, jcastro:  In the meantime, we should think on what to track on those graphs.
<jcastro> we'll be able to backgraph too? I am interested in how horrible we were last cycle
<jcastro> exact same as distro: http://reports.qa.ubuntu.com/reports/sponsoring-stats/
<jcastro> I don't think we need "reviewers of the last month" though
<negronjl> jcastro: got it
<m_3> sure
<m_3> crap, wrong channel :)
<negronjl> lol
<jcastro> jamespage: would accumulo fall in your domain or would it be a seperate community charm?
<jcastro> http://accumulo.apache.org/
<jcastro> SpamapS: hey, good news, I only needed to file 5 bugs in charms. Looks like while people hated the spreadsheet, we did a decent job keeping it up to date and filing a bug
 * imbrandon returns from old people lunch :)
<imbrandon> man, 70 ... I hope I make it that long
<imbrandon> momma always told me not to look into the eyes of the sun; but momma, thats where the fun is ... ... rev'd up like a duce, a nother runner in the night, blinded by the light!
<imbrandon> Its a 60's and 70's rock while you code day. Yup.
<imbrandon> SpamapS or hazmat: what would be the most proper way for me to get what juju considers to be the machine_id from on the machine its self but not from/in a hook or juju at all for that matter ( e.g. a root cron bash script or similar )
<imbrandon> end goal is to call like "relation-get --machine_id <machine_id> -s /var/lib/juju/instance/.juju.hookcli.sock db" or something very similar
<imbrandon> is that just the auto incremented machine number , like the same one i would use to "juju terminate-machine N" ?
<imbrandon> thought i tried that, maybe not
 * imbrandon might dig into the source a bit and see if i can tell or get more confused
<marcoceppi> relation-get uses -r and uses relation ids, you can't relation-get to a machine directly
<imbrandon> marcoceppi: i think it was relation list i was thiking of to get the rid's
<imbrandon> marcoceppi: and i know now, well not a documented way , so i'm trying some 'intresting' things on the cli
<imbrandon> :)
<hazmat> imbrandon, cat /etc/init/juju-machine-agent.conf | grep MACHINE
<hazmat> its in the env for the machine-agent process
<SpamapS> imbrandon: what machine id ?
<SpamapS> oh that machine id
<SpamapS> that seems like you're doing something evil
<SpamapS> imbrandon: danger will robinson. You are stepping outside the documented API. What are you getting at?
<imbrandon> https://juju.ubuntu.com/docs/internals/unit-agent-hooks.html?
<imbrandon> SpamapS: JUJU_CLIENT_ID. and yea outside the documented api but its only half implmented i *think* and i'm trying to use it early
<hazmat> client id isn't really used.. its basically set to the string 'constant'
<SpamapS> imbrandon: what are you trying to do though?
<hazmat> it was for concurrent usage, but we execute serially
<imbrandon> JUJU_CLIENT_ID=13 relation-get -s /var/lib/juju/units/nginx-4/.juju.hookcli.sock -r loadbalancer
<hazmat> imbrandon, client_id != machine_id
<SpamapS> heh so you can set client id to anything and it will work?
<imbrandon> hrm , i think i needed the machine id for another cli app
<hazmat> SpamapS, as long its the string 'constant' ;-)
<SpamapS> imbrandon: that -r looks wrong
<imbrandon> SpamapS: i just added the -r
<SpamapS> imbrandon: you want a relation ID there.. you can get those from relation-ids
<imbrandon> and no it dont work
<SpamapS> JUJU_CLIENT_ID=13 relation-ids -s /var/lib/juju/units/nginx-4/.juju.hookcli.sock loadbalancer
<hazmat> there's no context on the agent though outside of executing a hook..
<SpamapS> imbrandon: that will print all of the relationships under the 'loadbalancer' relation
<hazmat> for the cli api to be able to responsd
<imbrandon> Traceback (most recent call last):
<imbrandon> Failure: twisted.protocols.amp.UnknownRemoteError: Code<UNKNOWN>: Unknown Error
<imbrandon> 2012-05-29 19:06:23,434 ERROR: Traceback (most recent call last):
<imbrandon> Failure: twisted.protocols.amp.UnknownRemoteError: Code<UNKNOWN>: Unknown Error
<SpamapS> ah so he needs jitsu?
<SpamapS> imbrandon: grab juju-jitsu from the PPA
<SpamapS> 0.6 has 'jitsu run-as-hook'
<imbrandon> SpamapS: well i want to do this from a script
<SpamapS> imbrandon: thats fine, it will work from a script
<imbrandon> hazmat: yea thus trying to set up manually :)
<imbrandon> SpamapS: ahhh ok
<imbrandon> i'll try that then
<imbrandon> i thought it forced a tmux session
<imbrandon> i'm "almost" getting it to work just by poking arround though :) but yea jitsu is likely much easier, but at least i got to konw the dir layout and such better
<imbrandon> been poking arround in /var/lib/juju/* heh
<imbrandon> SpamapS: is there much/any docs on jitsu ? so i can at least do a lil bit of it with out naggin ya too much
<SpamapS> imbrandon: --help ? ;)
<imbrandon> kk
<imbrandon> good nuff fo me :)
<imbrandon> btw i ran accross a bug i think, got a sec to step through the process with me and if so i'll file it
<imbrandon> ok so
<SpamapS> imbrandon: run-as-hook != debug-hooks
<imbrandon> say i fire up 4 nginx plain webservers, no lb or databases , just keep this simple
<imbrandon> then from the aws console or via api i attach a eip to one of the nodes
<imbrandon> zk still keeps the old IP and i cant get to it via juju ssh service/N anymore
<imbrandon> and when hooks fire it lists the wrong ips etc etc on relations
<imbrandon> for that node
<SpamapS> imbrandon: sounds like a rockin por^H^Herfect webserver
<SpamapS> imbrandon: yeah, EIP messing with the public-address is a real problem. :-P
<imbrandon> well am i missing something, like a zk-relook-at-nodes-ips  or something ?
<imbrandon> ok
<imbrandon> so it is a bug/known problem and not just me being ignorant ?
<SpamapS> damnit.. not installing run-as-hook .. doh
<SpamapS> imbrandon: its a known problem ys
<imbrandon> seems like there could be a hook that fires on network changes , and then it could make zk refresh ? heh
<jamespage> jcastro, looks very similar to hive so should not be that hard to charm
<jcastro> jamespage: ok so should I have a seperate bug for it?
<jamespage> jcastro, raise one for the time being
<jcastro> k
<jamespage> I think its a distinct charm - but one that will make use of hadoop and zookeeper charms
<SpamapS> imbrandon: FYI, juju-jitsu 0.6 didn't have run-as-hook like I thought. I just released 0.8 .. you'll have to wait till the PPA builds it (or branch/autoreconf/./configure/make/make install it)
<imbrandon> kk, i'll got a few other things to do in the meantime i'll wait as long as its been uploaded right ?
<imbrandon> if not i'll do a co
<imbrandon> nice, an apt-mirror show stopper bug, looks like i get to do a lil perl brushing up on too this week
<imbrandon> SpamapS: think i might be able to bribe you for a sponsored upload in 24 or 48 hours to debian ( I'm the listed maintainer and upstream so no nmu or anything , just not a DM or DD so cant actually upload ) I havent talked to my normal DD sponsor in months , no idea if he is arround
<imbrandon> heh
<imbrandon> trust me i dont make new releases for it every cycle even, so i wont be making a habbit of it :)
<SpamapS> imbrandon: sure just throw a .dsc at me. :)
<imbrandon> ty ty , yea i havent even began to clean it up and still need to track down this bug, i'll likely make a round through the debian bts too since i dont release that often just to knock it all out in one go if possible, thus 24 probabbly closer to 48
<imbrandon> assuming your not feeding a little one by then :)
<imbrandon> i really should take the time to do the DM process at minimum
<imbrandon> $someday
<imbrandon> i want to get Ali's script if its still in use, it was setup so me and one or two others that was regularly sponsored would email a special email address with a signed .dsc and it would autobuild and smoke test it before ali even looked at it and emailed back the results etc like lil dak kinda, assuming that went ok it forwarded it on and then when there was time to finish the review presonally it was uploaded ( normally less than a day ) , pretty
<imbrandon> for people
<_mup_> juju/trunk r538 committed by kapil.thangavelu@canonical.com
<_mup_> [merge] proposed support, add support for using proposed repository pockets for
<_mup_> main and universe as a source for juju if specified via juju-origin: proposed.
<_mup_> [r=clint-fewbar][f=926550]
<_mup_> Bug #1006099 was filed: unable to set extended desktop <juju:New> < https://launchpad.net/bugs/1006099 >
<surgemcgee> Almost... How many does the world need? I fugure I can do 3 a week.
<m_3> nice... local provider now adds upstart configs to my local machine that peg the cpu when zk isn't available... the services "respawn" too
<SpamapS> m_3: #winning
<jimbaker> good progress
<SpamapS> m_3: look on the bright side, it doesn't fill up your disk anymore ;)
 * SpamapS submits his talk for Linux Foundation's CloudOpen event "Cloning SysAdmins with the Cloud and Juju"
<imbrandon> nice
<imbrandon> juju add-unit sysop
<imbrandon> juju add-relation bofh unsuspecting-user-accounting
<koolhead17> hi all
<m_3> koolhead17: o/
<SpamapS> koolhead17: hey, you should assign yourself as maintainer of the owncloud charm
<koolhead17> SpamapS, hi there. sure
<SpamapS> bkerensa: and you should grab subway
<koolhead17> SpamapS, i been bit off IRC for some reasond
<SpamapS> koolhead17: we all need a break sometimes :)
<koolhead17> SpamapS, i have some more charms to spread :)
<bkerensa> SpamapS: what?>
<koolhead17> and owncloud4 has released as well
<SpamapS>  10 subway              : Benjamin Kerensa <bkerensa@ubuntu.com>
<koolhead17> m_3, how are things
<SpamapS> bkerensa: are you subscribed to the juju mailing list?
<bkerensa> SpamapS: no?
<bkerensa> >.<
<bkerensa> I better add myself
<SpamapS> bkerensa: ahh, ok. You need to assign yourself as maintainer of subway.. add   "maintainer: Benjamin Kerensa <bkerensa@ubuntu.com>" (without the quotes of course) to metadata.yaml
<bkerensa> SpamapS: yeah I heard thats a new requirement
<bkerensa> will do
<SpamapS> m_3: ahem... you too .. nfs, ganglia, node-app, postgresql ... all "yours" ;)
 * koolhead17 thinks SpamapS is on assigning mode today :)
<m_3> SpamapS: yeah, I'll grab maintainer for them... prob friday (moving truck tomorrow morning)
<m_3> koolhead17: crazy atm
<koolhead17> m_3, kind of same this side. L(
<koolhead17> :)
<m_3> SpamapS: nevermind... done
 * m_3 was in default "aahhhh" mode, but it only takes two shakes to update maintainer
<SpamapS> m_3: thanks!
<negronjl> SpamapS: how's the list of shame ?
<SpamapS> negronjl: about to get a lot shorter :)
<negronjl> SpamapS: nice
<koolhead17> negronjl, list of shame? 0.o
<negronjl> koolhead17: It's a list that SpamapS has that lists the charms without maintainers
<koolhead17> ooh ok
#juju 2012-05-30
 * SpamapS tests out an updated juju for precise-proposed
<imbrandon> SpamapS: have you tried that jitsu ? i'm getting all kinda errors with it, python modules missing etc
<imbrandon> wonder if its just that machine is fubar
<SpamapS> imbrandon: pastebin?
 * SpamapS uploads 5 SRU fixes for precise.. hopes rest of SRU team doesn't beat him with a hammer
<imbrandon> http://paste.ubuntu.com/1014277/
<SpamapS> imbrandon: ahh looks like there are some python library files that have to be installed
<imbrandon> ImportError: No module named aiki.invoker
<SpamapS> imbrandon: confirmed
<imbrandon> okies
<SpamapS> question now is where to install them
 * SpamapS decides libdir
 * imbrandon goes back to breaking other things :) got like 5 projects 99% done
<imbrandon> heh
<imbrandon> i hate that
<SpamapS> imbrandon: lazy is never doing anything you don't want to do.. suck it up ;)
<imbrandon> :) thats the thing i want to do all^most all of them :)
<imbrandon> i just hate haveing 5 at 99% wish i had 2 complete and 2 barely started
<imbrandon> is how i work better , mostly
<imbrandon> but each one had blockers so thus ended up like this for a week
<imbrandon> :)
<imbrandon> gotta go spend most of the after noon witha  client later today too, fun fun, i _love_ onsites when there is no real reason for it :)
<SpamapS> imbrandon: people are just complex computers. Hack them like you hack PHP :)
<imbrandon> heh
<imbrandon> never thought about it like that but very true
<imbrandon> so why does jitsu have upgrade-charm and a few other identical sub commands ?
<imbrandon> just curious , dident look at the code to see if they are actually the same or not
<SpamapS> imbrandon: they are meant as wrappers for testing
<SpamapS> imbrandon: sort of a half finished thing
 * SpamapS wills autoreconf and ./configure to go faster
<imbrandon> ahh
<SpamapS> imbrandon: nearly have run-as-hook working now
 * SpamapS releases that as 0.10
<imbrandon> nice
<imbrandon> nearly ? you sound like me now
<imbrandon> heh
<SpamapS> no it works
<SpamapS> finally learning the full power of automake/autoconf
<SpamapS> imbrandon: should build in < 10 min
<imbrandon> rockin
<SpamapS> I wish they'd update LP so I could use the latest bzr builder
<SpamapS> has {latest-tag}
<SpamapS> so you can actually have a non-trunk automated build
<imbrandon> heh, like travis builder on github ? hahahahah
<imbrandon> j/k
<SpamapS> imbrandon: you're more than welcome to port all my shit to github for me. :)
<imbrandon> you know i got to raz ya now and then , only a few things i can do it with :)
<SpamapS> though frankly, I'm not all that excited about using a non-open-source service
<SpamapS> would rather we run our own gitolite or something
<imbrandon> heh, i'd be doing good if all mine is, i still have half of it on bitbucket
<imbrandon> that sounds like a GREAT idea to me
<SpamapS> well actually
<SpamapS> I'd rather that LP just grew git
<SpamapS> so people would shut up and stop caring about VCS
<imbrandon> yea but we can use ubuntuwire for what its orig reason for living was again
<imbrandon> just stuff like this untill lp grew it
<imbrandon> qa.ubutnuwire.com came long before qa.u.c :) its how it was modeled :)
<imbrandon> anyhow i checked and there is still 3 or 4 Dell 2650's for ubuntuwire in the canonical dc
<imbrandon> that we could slap it on and do some proof of concept workflow stuff and maybe hurry LP allong
<SpamapS> godamnit launchpad
<SpamapS> 0.10 != 0.1
<imbrandon> or hell add it ourselfs now its fully open
<imbrandon> i should revamp *.ubuntuwire.com with the new branding, it should all still be auto deploying from the lp bzr branch on push iirc
<SpamapS> huh?
<imbrandon> thinking out loud
<SpamapS> Why wouldn't you just give LP git..
<SpamapS> ?
<SpamapS> NIH? (I totally get that.. ;)
<imbrandon> heh no
<imbrandon> i would if i thought i coudl pull it off
<imbrandon> not sure a project that big i could do alone tbh
<imbrandon> would want to do a lil planning
<imbrandon> hrm actually there isnt a server component to git like there is bzr, its just bare repos and gitweb ... hrm it MIGHT not be that bad
<imbrandon> mostly just gui stuff
<imbrandon> mostly , not all
<SpamapS> imbrandon: the "server bit" of bzr isn't really all that much. Its just cmds to execute on the server side
<imbrandon> yea but i think thats one reason its so slow too isnt it
<imbrandon> ?
<SpamapS> imbrandon: the harder thing is mapping LP's branch namespacing into git's colocated branches, but I'm sure that would be solvable in a furios night of hacking.
<imbrandon> because omg like bzr or not , you got to admit bzr is SLOW
<SpamapS> imbrandon: "so slow" is so laughable
<SpamapS> most things you do in bzr take 1 - 2 s where as git is 0.5s consistently
<bkerensa> OMG! Bzr!
<imbrandon> SpamapS: push a fresh branch
<SpamapS> imbrandon: Its all relative I guess. :)
<SpamapS> imbrandon: just as fast as git now because of stacking
<imbrandon> and that happens alot in bug fixing and drive by fixes like ubuntun grows alot of
<imbrandon> stacking ?
<SpamapS> yes stacking
<imbrandon> is it actually in ?
<imbrandon> ive not seen it work yet
<imbrandon> still slow here
<SpamapS> lp:~clint-fewbar/ubuntu/precise/juju/mything will automatically stack on top of lp:ubuntu/precise/juju .. any shared commits will not have to be retransferred on push/pull
<SpamapS> stacking has been around for years
<bkerensa> =o
<bkerensa> SpamapS: if the branch is up to date?
<SpamapS> the other "slow" bit is the SSH negotiation
<imbrandon> oh then no, its stil slow as piss then with stacking too
<imbrandon> SpamapS: bs, i can push a clean git over ssh and it takes less than 10s, same branch of omg-wp takes almost 3m on bzr
<SpamapS> imbrandon: thats where bzr's "smart" side comes in because you basically say "I'm at this point in the graph and I want to push to you" and it says "I"m at this point" and then you push whats between. Git just has a map, and you read it real quick, and push what you need. Definitely 1-2 seconds faster, but conceptually identical
<SpamapS> imbrandon: is that git-bzr pushing or real bzr pushing? I'm dubious. Also.. are you stacking on omg-wp somehow?
<imbrandon> real pushing
<SpamapS> the initial push is definitely going to be slower
<SpamapS> because bzr's branch format is far less efficient than git's
<imbrandon> i'll time it real fast if you want, i'll make 2 clean subdirs of omg and git initi and bzr init them toand then run time
<bkerensa> imbrandon: I just did a complete teardown on a brand new System76 :D
<SpamapS> but all subsequent stacked-on branches will be quite fast
<imbrandon> sure, but i do that first push more often than stacks in ubuntu
<imbrandon> as do most drive by contributors
<imbrandon> one sec, i am gonna time it , cuz i'm sure in my head i'm not exagerating here
<imbrandon> will only take a sec anyhow, not like a big test
<SpamapS> imbrandon: why do you do that first push?
<SpamapS> imbrandon: and most drive by's would be checking out the existing branch and pushing a new one stacked on it
<SpamapS> so I don't really think thats true
<imbrandon> cuz i do that quite often, that stacking you speak of dont work like you think,i'll time that too
<imbrandon> s/work/as fast as
<stevanr> hello
<bkerensa> hi stevanr
<stevanr> need some help..
<stevanr> hi bkerensa
<imbrandon> ello
<stevanr> after bootstrap I get https://pastebin.linaro.org/558/
<SpamapS> imbrandon: so that initial branch creation time was about 21s, vs. pushing a single small commit, which was 11s. :-P I am defeated. Please lets try to make bzr's death painless. ;)
<imbrandon> heh mine is STILL pushing
<stevanr> here's my conf file https://pastebin.linaro.org/557/
<imbrandon> so umm no
<SpamapS> imbrandon: still not 3m ;)
<SpamapS> imbrandon: but what are you pushing?!
<imbrandon> omg
<SpamapS> imbrandon: mine spent 10s finding what to stack on, then the other 10s comparing graphs
<SpamapS> imbrandon: so you're not stacked
<imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/omg-bzr$ time bzr push lp:~imbrandon/+junk/omg-bzr
<imbrandon> Warning: Permanently added 'bazaar.launchpad.net' (RSA) to the list of known hosts.
<imbrandon> Created new branch.
<imbrandon> real	4m19.228s
<imbrandon> user	0m1.091s
<imbrandon> no but wait,  now i'm gonna stack one
<imbrandon> sys	0m0.306s
<SpamapS> imbrandon: yeah +junk is *ALWAYS* going to suck
<SpamapS> *always*
<imbrandon> ok ok , they all do for me
<imbrandon> seriously
<imbrandon> all the same, i never get fast bzr pushes
<SpamapS> stevanr: reading
<stevanr> SpamapS, tnx :)
<SpamapS> stevanr: can you use a differen't pastebin?
<SpamapS> stevanr: my phone is downstairs.. don't feel like getting it for the 2-factor auth
<stevanr> SpamapS, lol, sry
<imbrandon> i never understood why pastebin has a sso anyhow
<imbrandon> wth is up with that
<SpamapS> imbrandon: fast is relative. Its not going to beat git. We know that. But 10s to push 1 rev up is ok. Not great, but ok.
<SpamapS> imbrandon: no, he did linaro pastebin
<bkerensa> ahh
<imbrandon> SpamapS: yea but no joke i mean the diff between minutes and seconds, not 11s and 22s, i could live with that
<SpamapS> stevanr: just use 'pastebinit' .. should end up on paste.ubuntu.com
<bkerensa> pastebinit for the win although I wish it supported more pastebins then just Ubuntu Paste
<bkerensa> SpamapS: if he has it installed otherwise "sudo apt-get install pastebinit"
<SpamapS> imbrandon: so, you're using something called +junk .. and you expect it to be .. not sucky?
<imbrandon> SpamapS: lenaro and ubuntu both use sso
<imbrandon> SpamapS: thats the first time ever i've pushed to junk
<SpamapS> imbrandon: I have to agree that 3m is *WAAAAY* too long for new giant branch pushing.
<stevanr> SpamapS, ok so here's the status message after bootstrap http://paste.ubuntu.com/1014345/
<SpamapS> seeing 2kB/s at any time when I'm on my 30down/5up connection makes me think the other side of the pipe is on holiday
<stevanr> SpamapS, and here's my environments.yaml file http://paste.ubuntu.com/1014347/
<imbrandon> seriously some evening we'll get a byobu session going over here and i'll show ya , but thats some other day, but for real man i'm not exagerating at all on this one
<SpamapS> stevanr: your machine agent is broken
<SpamapS>     agent-state: not-started
<SpamapS> stevanr: with local provider, that starts at 'bootstrap'
<stevanr> SpamapS, i know :)
<stevanr> SpamapS, my question is 'why'
<SpamapS> stevanr: it keeps a log, I forget where.. checking now
<imbrandon>  /var/logs/juju-machine*
<imbrandon> iirc
<SpamapS> stevanr: ahh, it would be in /tmp/local-dev/youruser-local/machine-agent.log
<SpamapS> imbrandon: not on local
<SpamapS> local provider just cocks everything up :-P
<imbrandon> oh
<SpamapS> its amazing when it works
<SpamapS> but *EVERYTHING* seems different
<imbrandon> yea i would think making it the same would be a goal
<stevanr> SpamapS, cool tnx, i'll get back soon
<SpamapS> imbrandon: apt-get update/apt-get upgrade to get juju-jitsu 0.10 .. tested and works now
<imbrandon> nice, kk
<SpamapS> # jitsu run-as-hook mysql/3 config-get
<SpamapS> {u'tuning-level': u'safest', u'query-cache-size': -1, u'query-cache-type': u'ON', u'binlog-format': u'MIXED', u'max-connections': -1, u'preferred-storage-engine': u'InnoDB', u'dataset-size': u'1G'}
<SpamapS> unnnhh
<SpamapS> thats hot
<SpamapS> stevanr: that file should have clues. There's also an upstart job running it, so make sure it is not in the wrong state (like stop/waiting)
<imbrandon> sweet if that works here thats EXACTLY what i wanted
<imbrandon> i woudl kiss you but your married
<imbrandon> doh
<imbrandon> no key in the env on the nodes
<imbrandon> but thats ok, i can add it to the install hook to set it
<SpamapS> imbrandon: what key?
<imbrandon> jitsu run-as-hook omg-wp/3 config-get
<imbrandon> Could not find AWS_ACCESS_KEY_ID
<SpamapS> imbrandon: you don't run it on your local machine
<imbrandon> thats was form the node
<imbrandon> actually ON omg-wp/3
<SpamapS> imbrandon: hm, I don't get any such errors
<imbrandon> Unpacking replacement juju-jitsu ...
<imbrandon> Setting up juju-jitsu (0.10-0stable1~precise1) ...
<imbrandon> (juju-jitsu) root@ip-10-226-55-144:~# jitsu run-as-hook omg-wp/3 config-get
<imbrandon> Could not find AWS_ACCESS_KEY_ID
<imbrandon> (juju-jitsu) root@ip-10-226-55-144:~#
<SpamapS> imbrandon: very weird
<imbrandon> env , see if its set from something else
<SpamapS> imbrandon: running on ec2 as well.. no such error
<SpamapS> and no such env var
<imbrandon> let me log out and back in, i was already in a jitsu wrapper
<imbrandon> when i updated
<SpamapS> imbrandon: I wonder.. are the access-key/secret-key set in the environments.yaml there?
<imbrandon> oh yea, i have a env.y on the node
<imbrandon> why ?
<SpamapS> thats probably confusing it
<SpamapS> its a bit of a hack
<imbrandon> (juju-jitsu) root@ip-10-226-55-144:~# ls -l .juju/environments.yaml
<imbrandon> -rw------- 1 root root 211 May 30 06:12 .juju/environments.yaml
<imbrandon> (juju-jitsu) root@ip-10-226-55-144:~#
<imbrandon> yup , moved it out of the way and works perfect
<imbrandon> sweet
<SpamapS> imbrandon: sounds like a bug tho
<imbrandon> is that how its telling if its local or remote ?
<SpamapS> jimbaker: ^^ note that run-as-hook doesn't work right when a local ~/.juju/environments.yaml is present
<SpamapS> imbrandon: no I suspect its doing something wicked w/ the juju internal libs
<stevanr> OK I ran destroy-environment and bootstrap again and now it's in "running" state
<imbrandon> seems like it could just look for /var/lib/cloud/instance/* exists instead of env.y
<SpamapS> oh yeah, its importaing all kinds of weird stuff from juju's python libs
<SpamapS> stevanr: awesome
<imbrandon> yea
<SpamapS> stevanr: would love to stay and help but I need to hit the sack
<stevanr> SpamapS, ok :)
<stevanr> SpamapS, tnx
<hazmat> SpamapS, your awakes..
<hazmat> run as hook is crack
<hazmat> don't use it
<SpamapS> yeah
<SpamapS> reading it now
<hazmat> please remove it
<SpamapS> hazmat: it seems to work tho ;)
<hazmat> SpamapS, it was to easy to make a miskate
<SpamapS> hazmat: you have some way we can run hooks outside unit agent execution?
<hazmat> if you mis-understand it
<hazmat> and blow up your local machine
<hazmat> well. maybe overly dramatic.. but cause issue
<imbrandon> SpamapS: hahah thats exactly whats its doing
<imbrandon> def get_zk_client_connector(options):
<imbrandon> 36	+    # Running on a Juju machine or on an admin system? Distinguish by
<imbrandon> 37	+    # first checking for an ~/.juju/environments.yaml file; if not
<imbrandon> 38	+    # check the machine for an upstart conf file
<SpamapS> hazmat: sounds like a reason to be wary, not to remove it
<imbrandon> 39	+    env_config = EnvironmentsConfig()
<imbrandon> 40	+    try:
<imbrandon> 41	+        env_config.load()
<imbrandon> 42	+    except juju.errors.FileNotFound:
<SpamapS> hazmat: I would like a real way to do what it enables tho
<hazmat> SpamapS, sounds like a reason to enforce wariness...
<imbrandon> if you have another way i'm all ears :)
<hazmat> i hate layout landmines for users
<hazmat> er. laying out
<SpamapS> hazmat: jitsu isn't about wariness.. its about crack actually. Fresh, strong crack.
<hazmat> SpamapS, it really shouldn't be
<SpamapS> hazmat: so, your open-port is totally legit? :)
<hazmat> Spamap, it is
<SpamapS> until we change ZK
<SpamapS> then its crack too
<hazmat> SpamapS, no, then its just broken
<hazmat> SpamapS, it won't damage your system accidentally
<hazmat> SpamapS, its not modifying zk directly, its using the api
<SpamapS> you really haven't explained what run-as-hook does dangerously
<imbrandon> well i could get this info from zk with phpzk, thats where its gonna end up anyhow is in php
<imbrandon> if you like that idea better L(
<imbrandon> :)
<SpamapS> hazmat: I believe you, but I want something that does exactly this for a number of reasons.
<hazmat> SpamapS, executing hooks locally, completely changes any notion of env for a hook.
<SpamapS> I don't know what you mean by locally
<hazmat> client side
<SpamapS> I run it on the unit I want the info from
<SpamapS> it works at that level
<imbrandon> this isnt running client side we;re on the unit
<SpamapS> can't we just enforce that?
<SpamapS> like, you can only connect to the socket of the unit you're pretending to be?
<imbrandon> why enforce things like that ...
<imbrandon> wasted energy
<hazmat> imbrandon, because say you start a backup or delete files in such script
<hazmat> intending it for remote use
<hazmat> you point it to someone on irc
<hazmat> and they execute it locally by accident
<hazmat> ...
<hazmat> landmine
<imbrandon> with great power comes great responsibility , we;re not talking about desktop users here, we;re talking what should be competent devops
<hazmat> then we should stop recommending jitsu to anyone not in charmers
<SpamapS> what landmine has me handing out scripts that people blindly run?
<hazmat> SpamapS, they carefully examine it, and think it runs remotely
<hazmat> on the unit
<SpamapS> thats why we changed it to run-as-hook
<SpamapS> Its pretty obvious to me that this is just giving you a hook context locally
<hazmat> changing the camo on a landmine, doesn't change the nature of the landmine
<hazmat> what's the underlying common use case?
<SpamapS> I can't imagine anyone ever going "Oh this will some how magically be transported to the unit and run there"
<hazmat> inspect/get the relation data
<imbrandon> hazmat: all i'm saying is we cant protect them from everything esp when we;re making a sword, there is bound to be some shard parts
<hazmat> SpamapS, i think its documented that juju is 'cloud magic' ;-)
<SpamapS> hazmat: but anyway, we can fix that really easily
<imbrandon> that could hurt ppl, just like the dd tool installed on every desktop could wipe a hdd
<SpamapS> hazmat: lets just require that the socket for the unit be accessible
<hazmat> SpamapS, +1 on the latter
<imbrandon> bah that will just make those that dont want to jump that hook do it a real crackfull way like editing zk or mongo
<imbrandon> document it , say here be dragons and let them cut a finger off once or twice
<hazmat> imbrandon, didn't you just use it for the time 10m ago?
<imbrandon> i can promis that dd is installed on ever ubuntu system and can do just as much dammage
<hazmat> imbrandon, and are you executing it from the client?
<imbrandon> hazmat: no i'm not ut my plan was not to be on the node 100% of the time either
<SpamapS> bug 1006277 opened
<_mup_> Bug #1006277: run-as-hook needs to require the target unit agent to be local <juju-jitsu:New> < https://launchpad.net/bugs/1006277 >
<SpamapS> imbrandon: we can make a --force ;)
<imbrandon> ok
<imbrandon> that works
<SpamapS> the thing has crap online help anyway
<SpamapS> usage: run-as-hook [-h] [-e ENVIRONMENT] [--loglevel CRITICAL|ERROR|WARNING|INFO|DEBUG] [--verbose] SERVICE_UNIT COMMAND [ARG [ARG ...]]
<SpamapS> expose a service unit(s) port
<SpamapS> doh
<imbrandon> heh
<SpamapS> ok, sreep now kurinto san tired
<imbrandon> gnight
<hazmat> imbrandon, its because the 'machine' identity is never really established.. sure dd can screw up a disk, but A) you know what machine its running on, ie. zero ambiguity, B) you need sudo ;-)
<imbrandon> gnight too hazmat if your headed off
<hazmat> with run-as-unit.. A) is never really clear
<hazmat> imbrandon, just woke up.. have a good one
<hazmat> SpamapS, g'night
<bkerensa> SpamapS: fixed the maintainer meta data thanks for the heads up
<bkerensa> gnight SpamapS
<imbrandon> ahh i'm not going , was just thinking all was on the same timeline a;)
<imbrandon> hazmat: yea i see what your saying but i also see this as a "professionals tool" like a skill saw or similar
<imbrandon> dangerious yes, you better know how to use it
<imbrandon> etc
<hazmat> imbrandon, right.. but in that case its very different then the other jitsu commands
<imbrandon> hazmat: as in juju as a whole not just jitsu
<imbrandon> yea, i dont see the harm is making it very hard, as long as i can have --let-me-do-the-crack_sudo-make-me-a-smammich true
<imbrandon> :)
<imbrandon> s/is/in
<imbrandon> i still dont see where it could wipe things local though
 * imbrandon looks some more
<imbrandon> hazmat: and really i think the GOOD(tm) awnser to this is for me and juan to finish the REST API. or learn go quicker so we can do it there w/e
<imbrandon> cuz thats all i really want, is the info that may only be available durring a hook execution but the API would store and expose
<imbrandon> ya know ?
<imbrandon> bkerensa: the system nice ? desktop or laptop ? semi afk now while i play with my newfound crack
<hazmat> imbrandon, i'd really like feedback on the rest spec, its something that needs to be in juju, and i'm happy to shape jrapi into that, but the spec itself needs to get proposed first or it becomes a port issue
<imbrandon> oh, i did not know the spec was actually down someehwre
<imbrandon> i;ll start looking at it today then, and yea i'm more than happy to help aslo shape it into that and test it as well
<imbrandon> is it a spec/blueprint on LP ?
<imbrandon> or in the docs ? or elsewhere ?
<negronjl> hazmat:  the spec is not that diff. from jrapi ... the changes wouldn't be that deep
<imbrandon> and yea i totaly agree about the porting thing
<imbrandon> negronjl: heya
<negronjl> imbrandon, hazmat: the README in jrapi is quite close to the spec
<imbrandon> sweet, thats a good thing right hehe
<hazmat> negronjl, still needs fairly large changes.. testing, rewiring the existing client commands to use the rest api, deploying the rest api as part of bootstrap, upload support, auth, etc... fwiw.. i'm planning on starting on the REST work mid june.
<imbrandon> probably mostly implmentation details
<imbrandon> heh well hopefully i dont bug you toooo much as i likly wont be able to wait that long to begin
<imbrandon> but yea whatever IS done between now and then should be in line with the goals ( looks like it already is started that way ) so its not tottaly way off
<imbrandon> when the time comes
<imbrandon> who knows, when i get to the office tomarrow they may tell me i got 6 months of nose to the keyboard stuff to do and i wont get any of this done
<imbrandon> heh
 * imbrandon knocks on wood
<negronjl> im out for the night ...
<imbrandon> night man
<imbrandon> take it easy
<bkerensa> imbrandon: laptop
<bkerensa> imbrandon: http://i.imgur.com/8L7hf.jpg
<_mup_> juju/trunk r539 committed by kapil.thangavelu@canonical.com
<_mup_> [merge] show-errors-when-acquiring-node, use human error consumable error
<_mup_> messages when no maas nodes are available. [a=julian-edwards][r=fwereade,hazmat][f=980855]
<fwereade> hazmat, ty; sorry, I didn't see the changes go in :(
<hazmat> fwereade, no worries
<hazmat> fwereade, i haven't merged the port one
<hazmat> fwereade, i think it needs to handle https port 443 better.. ie introspect protocol to get default port
<hazmat> instead of just blindly using 80 if not specified
<fwereade> hazmat, hmm, good point
<doitdist_> Hi! I am not sure if Rackspace is already supported by Juju? If not will it be in future?
<marcoceppi> doitdist_: Rackspace will be supported soon. Currently juju supports OpenStack but only with the EC2 and S3 middleware API turned on
<doitdist_> ok thanks. what time scale is "soon" :-)
<doitdist_> within a year? or 6 months? or no idea
<marcoceppi> I can't say for sure since I'm not a juju dev, but there's a preliminary branch with basic support. I imagine by 12.10 release - but that's just a guess
<doitdist_> ok thanks!
<marcoceppi> np!
<marcoceppi> It's a pretty hot topic, given there are so many public OpenStack installs starting up, including Rackspaces
<doitdist_> yes right...
<mgz> how far are rackspace from being a normal openstack service these days?
<marcoceppi> mgz: public beta
<mgz> ace. because their legacy bits don't work with core things like cloud-init.
<marcoceppi> mgz: I know, I hear their goal is to go live by the end of the year with OpenStack
<imbrandon> pos/win 21
<negronjl> 'morning all
<negronjl> 'morning all
 * negronjl is reviewing the queue today
<SpamapS> negronjl: saweeet
<negronjl> I just checked the calendar and I'm not in it to review but, there is nobody to do it either.... If I'm stepping on anyone's toes by reviewing, let me know ...
<SpamapS> bkerensa: 01:10 < bkerensa> SpamapS: fixed the maintainer meta data thanks for the heads up
<SpamapS> bkerensa: subway still has no maintainer
<SpamapS> negronjl: go for it man. the pilot thing is just a commitment.. you can review wheneve ryou want to :)
<negronjl> SpamapS: thx ... Just making sure I don't step on anyone's toes :)
<bkerensa> SpamapS: why?
<bkerensa> SpamapS: I added the info to the metadata.yaml
<bkerensa> whether it has been merged yet is another question
<SpamapS> bkerensa: and where did you push that to?
<SpamapS> bkerensa: I don't see anything in the review queue :)
<bkerensa> SpamapS: I will have to check
<SpamapS> bkerensa: my bad, its there
<SpamapS> bkerensa: just so new it doesn't have 'days' next to it, so I missed it. ;)
<SpamapS> bkerensa: merged
<bkerensa> SpamapS: ahh ;)
<surgemcgee> Finaly! Now we can deploy many Django projects with one charm. Remove the relation to remove the project. Update the project repo, blah, blah, blah.
<surgemcgee> http://ec2-23-22-131-174.compute-1.amazonaws.com
<surgemcgee> It should be ready for prime time in ~week
<imbrandon> surgemcgee: nice i was just cleaning up the ubuntu community django webthemes this morning, i might snag it and put instructions on how to use it a README for that branch
<jcastro> imbrandon: what's the tldr on RPMs?
<imbrandon> i hadent got to them in a few days but only about an hour or so to finish thit
<imbrandon> it*
<imbrandon> i can do that this evening
<imbrandon> it is "built" physicly, just has a few script errors on install and such
<imbrandon> jcastro: swag delivery man just showed up, that was fast, ty ty
<SpamapS> surgemcgee: awesum :)
<jcastro> imbrandon: and for suse?
<imbrandon> same source, seperate build using the openbuild service i'm told will work
<imbrandon> like the equiv of us rebuilding a deb src
<imbrandon> so it links on our stuff but no real changes
<imbrandon> same with cent as well ( as long as the deps are there, now i'm not sure on that one )
<imbrandon> CentOS
<imbrandon> zomg, ALL of adobes on and offline as well as iOS products in one packge , from them not a scammy reseller, for CHEAP , and i do mean ALL , even a subscription to typekit ( i alreay have but still )
<imbrandon> $30 a month
<imbrandon> for everything
<imbrandon> man if they would just release linux clients, or beef the web versions up just a tiny bit more
<imbrandon> i would denounce my apple fanboism
<_mup_> Bug #1006553 was filed: Juju uses 100% CPU after host reboot <juju:New> < https://launchpad.net/bugs/1006553 >
<mars> ^ I have the runaway process going right now, in case it is of interest to anyone who wants to debug it.
<jcastro> imbrandon: ok so you'll investigate the build service after this first cut of the RPM?
<imbrandon> yup, i had plans on it since 99% of the work will be done for it
<negronjl> SpamapS: ping
<SpamapS> negronjl: pong, sup?
<negronjl> SpamapS: promulgate is complaining to me .... ERROR:Branch has not been pushed.
<negronjl> SpamapS: not my charm so I don't think I can push ...
<SpamapS> negronjl: promulgate can only operate on remote branches
<negronjl> so ... charm promulgate lp:.... ?
<SpamapS> negronjl: bzr push --remember lp:~charmers/charms/precise/foo/trunk && charm promulgate
<negronjl> SpamapS: ah
<negronjl> SpamapS: you had mentioned that before and I forgot .... maybe promulgate should do that too
<SpamapS> negronjl: you can do 'charm promulgate -b lp:~charmers...' too
<negronjl> SpamapS: better
<SpamapS> negronjl: but at some point, you're going to have to make the "official" branch
<SpamapS> negronjl: one thing we probably *should* have it do is bzr reconfigure --unstackd
<SpamapS> negronjl: we don't want our official branches stacked on anything else
 * negronjl nods
<SpamapS> not sure if it already stacks them or not
<negronjl> Varnish charm promulgated
<SpamapS> negronjl: *woot*
<SpamapS> You know what would be like, super badass if a cloud provider/OS could pull it off? Elastic RAM
<SpamapS> just let me add/remove RAM as needed from my cloud instance
<jcastro> hey alright! varnish!
<imbrandon> SpamapS: isnt that elastic cache , kinda
<tooth> as needed?
<tooth> that would be... interesting.
<SpamapS> imbrandon: no not via the network
<SpamapS> like, RAM
<imbrandon> ahh , like swap only on something fast
<SpamapS> Right now I think Amazon sells its excess RAM in the form of t1.micros
<tooth> I can understand if they did it in a way that requires a reboot
<SpamapS> It would be cool if I could just say "woo... cache is getting full.. add 600MB of RAM
<tooth> but live would be interesting. the OS you have would have to know what to do with a sudden increase.
<imbrandon> some providers you can, e.g. linode
<SpamapS> tooth: right but how cool would it be if it could just be added on the fly
<tooth> badass, as you put it. :-)
<SpamapS> I'm sure container providers can do that
<imbrandon> no on the fly but via api and reboot
<imbrandon> yea they xenhost
<SpamapS> imbrandon: sure, boot from ebs lets you do that on ec2
<SpamapS> but just thinking out loud
<imbrandon> yea i know, me too lol
<SpamapS> Back when I ran racks of my own servers..
<SpamapS> I always wanted to just crank up the RAM when traffic spiked
<SpamapS> didn't need much more CPU.. just needed more cache because there were more unique things going on
<imbrandon> it would be cool just not sure how it would work plugable and still be fast, would need a fast interface that was hotplug like thunderbolt
<imbrandon> probably more, thunderbolt is just repinned PCIe
<imbrandon> same chipset
<SpamapS> no
<SpamapS> that would defeat the purpose
<SpamapS> I want the unused RAM on the box
<SpamapS> You can tell me no.. if there's no more to give
<SpamapS> Just, opportunistically, adding RAM to a running box would be better than adding a whole other box
<SpamapS> I guess really you can just get it by adding VMs though
<imbrandon> then you wana xenhost with "plugable" ram, the same thinf that lets the kernel use the plugable hardware ram woudl do it virt too
<SpamapS> "scale out FTW"
<imbrandon> just think ram chips that work like sas drives, then hand them to someone else and pay them to put in the box when ya need em :)
<imbrandon> hehe
<SpamapS> Dunno if I said this last night, but the first 12.04 juju SRU is in the queue waiting to be accepted for testing
<hazmat> SpamapS, sweet!
<hazmat> SpamapS, this might be an interesting alternative to gource.. http://ubietylab.net/ubigraph/content/Demos/index.html
<hazmat> not opensource though
<SpamapS> hazmat: I'd definitely love to have something flexible like that
<SpamapS> hazmat: wow.. xmlrpc built in :)
 * SpamapS just made some things pop up on the ubigraph screen
<jimbaker> i think the python interface is pretty nice too
<SpamapS> well its basically just xmlrpc
<SpamapS> so.. yeah :)
<SpamapS> seems like its a dead upstream tho
<SpamapS> no new releases in 4 years
<SpamapS> but.. fun yak shaving ;)
<jimbaker> that's the only issue, 2008 and no open source
<jimbaker> seems like it was a good academic project
<SpamapS> we should see if we can do a juju-quake the same way those guys did nagios quake a while back
<SpamapS> I can't remember the details exactly
<SpamapS> but I think it was like, a big open arena and servers would spawn demons as notifications
<jimbaker> SpamapS, sounds like a cool way of mapping an abstraction into a spatial layout. juju resolved is the final step in shoot down any relation problems. juju add-unit to quench any fires. juju remove-unit to bring capacity to the right load level (would that a health draining effect?)
<jimbaker> sounds like true bike shedding to me
#juju 2012-05-31
<bkerensa> imbrandon: have your considered submitting some patches to OpenPhoto? :)
<jcastro> hey jamespage, how's june 7th look on your calendar?
<jcastro> we have 2 webinars to do, but it's right around clint baby time
<jcastro> and we can't move them
<jamespage> jcastro, lol
<jamespage> lemme take a look
<jamespage> jcastro, I can work around 'bug triage'
<jamespage> so I'm available
<jcastro> 1500 UTC and 1800UTC are the times, I take it the second one is out of hours for you?
<vila> I'm trying to update a charm that was started for oneiric (lp:~canonical-bazaar/charms/quantal/udd/trunk), but when I try to push at lp:~canonical-bazaar/charms/quantal/udd/trunk, I get: bzr: ERROR: Permission denied: "~canonical-bazaar/charms/quantal/udd/trunk/": : No such distribution series: 'quantal'.
<vila> meh, first url is: lp:~canonical-bazaar/charms/oneiric/udd/trunk
<vila> jcastro: ^ any idea ?
<mgz> they've moved.
<mgz> just delete the current branch and push up again.
<vila> hey mgz :)
<vila> that was an initial push
<vila> and branching from lp:~canonical-bazaar/charms/oneiric/udd/trunk worked
<vila> mgz: so what did move ?
<jamespage> jcastro, its a bit late but I can time shift to accomodate if needed
<jcastro> I'll see if negron or mims can do the 2nd one
<mgz> vila: just push to a non-distro path for now
<mgz> as you're just developing it, doesn't need a fancy path to work with the charm store
<mgz> so just push lp:~canonical-bazaar/charms/udd
<vila> true, I can work locally
<vila> bzr: ERROR: Permission denied: "~canonical-bazaar/charms/udd/": : Project 'charms' does not exist.
<vila> forget it, I'll work locally
<jamespage> jcastro, ta
<jamespage> jcastro, assume we have some pre-canned stuff for the webinar?
<jcastro> yeah, it's just some slides we can reuse
<jcastro> we'll have a call like, earlier that week
<jcastro> and bash it out
<jamespage> jcastro, ack
<jcastro> it's easy, I set them up with the lies and promises, you tell them what it really does. :)
<jcastro> then you field live questions from the audience
<jcastro> it's pretty fun actually
<mgz> vila: confusing, that should work
<vila> mgz: yeah, I'm confused too by the url scheme used here, which is why I asked the question in this channel
<mgz> so, the old scheme was lp:~charmers/charms/SERIES/PROJECT/trunk
<mgz> and quantal happens to not have been created yet
<mgz> the new scheme is lp:charms/PROJECT
<mgz> what personal forks are meant to be now isn't clear, I don't see why lp:~USER/charms/PROJECT shouldn't work, but no one seems to be using that yet
<cheez0r> Hey folks, I'm trying to stand up Maas+JuJu and I'm encountering something strange when running 'juju bootstrap'- the account has a ssh keypair, but when I run 'juju status' I get repeated errors that read "<DATE> ERROR SSH forwarding error: ssh_exchange_identification: Connection closed by remote host" and nothing else, seemingly indefinitely.
<cheez0r> Is this just a 'be more patient, it'll respond eventually' situation or a 'you're missing a step' situation?
<mgz> cheez0r: can you just ssh to the host directly?
<cheez0r> I don't know its IP address, MaaS doesn't give me that info
<mgz> it may be that either it's borked in your known_hosts, or the ssh server isn't up yet
<mgz> cheez0r: if you pass -v when doing status you'll get more info, including the host name
<cheez0r> k thanks
<cheez0r> hrm, it's specifying a hostname in the ssh connect, not an IP
<mgz> cheez0r: right.
<cheez0r> This is strange, because I'm using the steps in the howto- the dns name doesn't resolve though
<cheez0r> is there a DNS Server on the MaaS host that it's using?
<mgz> not sure.
<marcoceppi> cheez0r: have you installed mass-dhcp?
<mgz> amusingly, there's a comment in the juju code saying it really wants an ip, but txaws only exposes the host... which then spread to the design of all the other providers
<cheez0r> marcoceppi: yes, which apparently installs dnsmasq, so I'm adding a new dnsmasq.conf file now
<cheez0r> I'm going to try defining the hostname it's looking for and see what it does
<marcoceppi> cheez0r: right, maas master does all sorts of dns fun times
<cheez0r> marcoceppi: right, so I added the nodes to MaaS and specified a hostname there, shouldn't it add entries for each of those hostnames so they resolve?
<marcoceppi> cheez0r: it should, if the machine was fully commissioned. You'll also have to make sure your machine is using the MaaS as it's DNS reslover
<cheez0r> right- I'm following the howto at https://wiki.ubuntu.com/ServerTeam/MAAS/Juju#MAAS:_getting_started_with_Juju
<cheez0r> it has me install dnsmasq on the MaaS host and then commission the nodes
<jcastro> imbrandon: huats: ajmitch: koolhead17: AlanBell: MarkDude: https://lists.ubuntu.com/archives/juju/2012-May/001662.html
<jcastro> ^^ and other folks working on juju charms, hp has donated 3 months worth of instance time on HP Cloud. See the mail for more info.
<marcoceppi> \o/
 * koolhead17 clicks
<MarkDude> Inm a minute, I just woke up to my name in an ITworld article http://www.itworld.com/it-managementstrategy/279368/oscon-nonprofit-pavilion-deals-limited-space
<cheez0r> HP is doubling down on Juju/Ubuntu
<koolhead17> marcoceppi, hola sir
<MarkDude> Way cool
<koolhead17> awesomeeeeeee
<jcastro> MarkDude: imbrandon: it'd be _awesome_ to use HP Cloud to build the first cut of the RPMS?
<MarkDude> That sounds like a good idea
 * MarkDude is waiting for elections to be over 1st. I was concerend I would get involved folks that dont win their posts
<koolhead17> jcastro, RPMS
<SpamapS> jimbaker: hey, I was thinking more about an "unprovider" and I had an interesting thought
<SpamapS> hazmat: ^^
<jimbaker> SpamapS, what's that?
<SpamapS> What if we just added an 'add-machine' and 'remove-machine' command?
<SpamapS> Doesn't most of the information about the machine come not from queries to the provider, but from the machine agent?
<jimbaker> SpamapS, but such machines would not be managed by the provisioning agent?
<jimbaker> SpamapS, it's registered in ZK, the PA doesn't sit in the path. so if the add-machine/remove-machine were to do the registration in ZK, that probably would work
<SpamapS> something like 'juju add-machine --private-address 1.2.3.4 --public-address 4.5.6.7'
<SpamapS> jim	right
<SpamapS> jimbaker: right
<jimbaker> SpamapS, we could probably play with this first in jitsu. seems like a good idea to me
<SpamapS> yeah we could
<SpamapS> have to think more about how the provider code will be utilized tho
<SpamapS> IIRC, only the provisioning agent makes calls to the provider code
<jimbaker> SpamapS, basically you would just to ensure that machine agent is running on the given machine, since that's what the provider/provisioning agent work in concert on
<SpamapS> hm, except the file storage bits
<SpamapS> jimbaker: right
<jimbaker> the file storage bits are important, as is access to ZK. the provider stuff works in concert to ensure that this all just works. but assuming some security setup, it could be done. worth doing, just to try out the idea
<hazmat> SpamapS, an unprovider?
<hazmat> you mean like a machine just registering itself?
<jimbaker> basically jitsu add-machine/remove-machine could enable some sort of hybrid approach. you could provision machines with chef/puppet/capistrano/blaster of choice. link them to a juju environment in ec2. then at some point rework that so ZK/file storage could also be setup like that
<hazmat> i've had a few feature requests for something similiar in private email
<hazmat> however the provisioning agent is queried for all info about a machine
<hazmat> status, dns, etc
<jimbaker> hazmat, not the provisioning agent. it's not in that path. machine/user agents set status/addr info in ZK. eg, the unit agent is responsible for running set_public_address
<hazmat> jimbaker, for the unit
<hazmat> jimbaker, not for the machine
<hazmat> its not the provisioning agent per se, but the provider
<jimbaker> hazmat, correct
<hazmat> if the provisioning agent can't find a machine's instance_id, it will attempt to allocate one.. if one exists and its not  bogus, its just going to cause problems for the agent
<hazmat> er. it is bogus
<hazmat> SpamapS, what's the goal?
<SpamapS> hazmat: allow juju to integrate into environmetns with an entrenched provisioning solution.
<SpamapS> hazmat: I'm suggesting that we have a provider whose backend is just user provided data about the machine resources available... like MaaS without the "install a fresh new server every time" :)
<hazmat> SpamapS, sounds useful
<SpamapS> hazmat: yeah, and I was wondering if we can just fake it w/ jitsu.. but I think we'd need an actual provider for it actually
<hazmat> indeed
<jimbaker> SpamapS, still a pretty minimal provider impl for the "unprovider"; the provider is necessary for juju admin access to ZK (it provides connect) and for such things as looking up an ip address from an instance id (see for example, juju.control.utils). it should not be much more than what the dummy provider does
<SpamapS> jimbaker: Yeah just needs a source of truth
<SpamapS> jimbaker: which could perhaps just be ZK. :)
<jimbaker> SpamapS, indeed, sounds like an excellent source of truth :)
<jcastro> imbrandon: marcoceppi: hey so as far as moving the bootstrap.
<jcastro> is this something we should file a bug on?
<jcastro> "don't let people do this."
<jcastro> or were we cheating to being with? :)
<imbrandon> yea, there is a bug
<imbrandon> iirc
<imbrandon> jcastro: ^
<jcastro> ok let's deal with that later
<imbrandon> np/win 26
#juju 2012-06-01
<roy-feldman> I have software license question regarding charms
<roy-feldman> Do charms automatically inherit the AGPL license by calling Juju services?
<roy-feldman> Use case 1: I write a charm from scratch
<roy-feldman> Use case 2: I write a charm that requires a relation to a charm that has an AGPL license
<marcoceppi> roy-feldman: charms can be any license, though if it's to be in the charm store it needs to have an approved OSI Open license
<roy-feldman> thanks
<marcoceppi> roy-feldman: https://juju.ubuntu.com/Charms#Charm_Inclusion_Policy_for_Reviewers those are the criteria for inclusion
<roy-feldman> The issue came up at Crowbar presentation I just attended.
<roy-feldman> Do you know if adding a relation to a GPL or AGPL licensed charm trigger the copyleft clause?
<marcoceppi> IANAL, but I don't think AGPL's service clause applies in charm relations since technically charms are communicating with the juju bootstrap and not directly to each charm, but not being a lawyer
<roy-feldman> That make two of us ;-)
<roy-feldman> Thanks Marco
<marcoceppi> juju add-relation causes the juju-agent to ping each service individually, and their response is reported to the juju-agent which then passes the information to the other charm and the cycle continues
<roy-feldman> Personally, I will publish my charms with a OSI license, but when I talk to business people the issue inevitable comes up
<marcoceppi> right, I would check with SpamapS or one of the juju core devs, they are more knowledgeable on things of this nature
<marcoceppi> I believe it was designed in a way that mixing charms with different licenses wouldn't be an issue
<roy-feldman> Music to my ears
<roy-feldman> I am talking to people who are pushing Crowbar, which is comparable to Juju + MaaS
<roy-feldman> They jumped on the issue that Juju was AGPL, so I was put on the "backfoot."
<roy-feldman> Short of consulting a lawyer,  can you suggest a way to confirm the licensing status of Juju charms?
<marcoceppi> Talk to one of the devs, they're all asleep now
<roy-feldman> Any suggestions as to which ones?
<roy-feldman> jcastro, negronjl?
<marcoceppi> SpamapS is knowledgeable with license stuff
<roy-feldman> Thanks again
<roy-feldman> Ciao
<hazmat> charms are any license
<hazmat> juju is agpl
<hazmat> charms are effectively input outputs to it
<hazmat> their is no linking
<hazmat> in this context, there is little point to it being agpl.. its effectively gpl
<hazmat> hmm.. two charms communicating
<hazmat> its not really linking by any common definition.. its basically each charm writing its own file and reading different files.
<imbrandon> yea i think of it as each charm is calling anothers public api
<imbrandon> in that case its not bound by agpl etc
<hazmat> http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
<hazmat> that's exactly on point to this topic
<hazmat> well the agpl triggers on offering a network service to users
<hazmat> in this case its the same user deploying the different charms..
<imbrandon> hazmat / SpamapS : you know how --placement was taken but you can still use palcement: local etc etc etc , i was thinking about that , what if ( not littraly ) but as far as juju is concerned the bootstrapped zk node is a charm too so things could become a subordiate of it, like say a 3rd party api or webui or whatever
<imbrandon> maybe show up as the juju-info interface
<imbrandon> or i dunno , not real well thought out yet
<SpamapS> imbrandon: thats the eventual plan.. to make "juju" a charm that is no different than the others, except it is deployed without ZK
<SpamapS> woot, juju SRU accepted
<vila> hi guys, trying to use juju on quantal I encountered an issue where the /var/log/syslog says 'zookeeper respawning too fast, stopped'
<vila> does that ring any bell ?
<vila> note that I arrived there because after 'juju bootstrap', 'juju status' couldn't connect to my instance (whereas it succeeded in the same environment with a precise image)
<jamespage> vila: that would indicate that zookeeper keeps crashing
<jamespage> please can you look in /var/log/zookeeper and see if there are any interesting error messages
<vila> jamespage: yup, but if I then connect via ssh , I can 'service start zookeeper'
<vila> jamespage: before I start it manually, there is *no* log file there
<koolhead11> had anyone faced issue with juju creating massive log
<jamespage> vila, you can try but that message comes from upstart trying to restart it
<koolhead11> like in few GB
<jamespage> koolhead11, I think there is a SRU in progress for that
<jamespage> koolhead11,  https://bugs.launchpad.net/juju/+bug/958312
<_mup_> Bug #958312: Change zk logging configuration <verification-needed> <juju:Fix Released by hazmat> <juju (Ubuntu):Fix Released> <juju (Ubuntu Precise):Fix Committed> < https://launchpad.net/bugs/958312 >
<koolhead11> ooh cool. so i am not the only one who hit this bug. cool
<koolhead11> jamespage: awesome.
<jamespage> koolhead11, you could verify the fix in -propose if you like
<koolhead11> jamespage: i will do that coming week :)
<jamespage> vila: does it start OK when you do it by hand?
<vila> jamespage: I scp'ed the log files after a juju bootstrap, install went well AFAICS
<koolhead11> or can do right away :)
<vila> jamespage: 'by hand' == ? (I have always use juju so far ;)
<jamespage> gah - I have to duck out for a bit - vila - I'll be back in about 1.5 hours if you can wait...
<vila> jamespage: sure, ping me then
<koolhead11> jamespage: i was looking for you last week
<koolhead11> trying to get hadoop working, ended up using source from there website
<jcastro> niemeyer: ah excellent. So much activity that we need another list. mwahaha.
<imbrandon> and second project :)
<niemeyer> jcastro: Well, the list wasn't really based on activity
<niemeyer> jcastro: The project was
<niemeyer> jcastro: The list is a division of topics for real
 * jcastro nods
<niemeyer> jcastro: Most people interested in using juju would be extremely bored with the topics we've been debating around the port
<jcastro> SpamapS: so I just saw mhall119's django generating charm
<jcastro> thing
<negronjl> 'morning
<jcastro> it's basically awesome.
<SpamapS> sweet
<SpamapS> wait, mhall did that?
<SpamapS> I thought somebody else did one
<imbrandon> yea there are like 3, but mhall119 is the best so far imho
 * mhall119 will do a writeup on it
<mhall119> first I need to change it's name
<mhall119> and create an LP project
<SpamapS> mhall119: its that big?
<SpamapS> mhall119: would you consider folding it into charm-tools?
<mhall119> SpamapS: it adds on to Django
<mhall119> like,  it's a django app you have to add to your project
<jcastro> SpamapS: reminder ping on cloudopen CFP
<SpamapS> jcastro: I submitted to cloudopen 2 days ago
<SpamapS> jcastro: what I'm not sure about is the AWS conference
<jcastro> <3
<SpamapS> mhall119: can you take me through the workflow?
<mhall119> SpamapS: sure
<mhall119> first, you get the code: https://launchpad.net/naguine
<mhall119> it's a django app, you can  either branch it locally into your Django project directory, or (when I build it) install it system-wide as a package
<mhall119> then, in your django project,  you run "python manage.py charm --settings naguine"
<mhall119> and it spits out your new charm into ./charms/precise/<project_name>/
<mhall119> then you check it for missing dependencies, and add any custom actions you need to install, and also anything custom to do on db-relation-changed
<imbrandon> sounds perfect for charm tools :)
<jcastro> charm create django ./myapp ?
<imbrandon> :)
<imbrandon> i bet i could wrangle a php version of the same thing to spit out a skeleton symphony2 php-app , could be the basis for some of those defaults we talked about , in any case i do think mhall119's would make a great addition to charm-tools
<imbrandon> using composer.phar  to do the dependancy stuff
<SpamapS> mhall119: yeah, this should be in charm tools unless you are just against giving up control of it to the whole of ~charmers
<SpamapS> mhall119: basically 'charm create --django yourapp'
<SpamapS> mhall119: I'm worried about exploding the ecosystem with many many projects and names and such, so if you'd consider moving it into charm-tools.. I'd consider giving you a gold star sticker. ;)
<shazzner> quick question: is there a drupal charm for precise? it seems like work was started them stopped
<marcoceppi> +1 charm tools
<shazzner> *then
<SpamapS> shazzner: poke imbrandon
<imbrandon> mhall119: the cake is a like i dident get the last gold sticker
<SpamapS> shazzner: he's been sitting on my review comments for about a month :)
<imbrandon> shazzner: i'm on it, actually i was gettting raely to upload it today
<shazzner> ok cool :)
<SpamapS> if you contribute
<SpamapS> to charm tools
<SpamapS> you will have cake
<imbrandon> SpamapS: cuz i went to 7
<SpamapS> there is cake for drupal charmers
<imbrandon> heh cake is a lie
<shazzner> I was thinking of creating a drupal theme sub-charm
<imbrandon> shazzner: no, for real though , i'd welcome any help etc etc but i'm getting ready to push a big update to it later today, got a little busy post-uds
<imbrandon> shazzner: perfect
<shazzner> we'll see I don't know I've been slacking
<shazzner> imbrandon: cool :)
<imbrandon> shazzner: i can show you the interfaces, its made to accept themes and plugins from a seperate charm
<SpamapS> imbrandon: the 6 one was *SO* close
<shazzner> imbrandon: awesome, probably just point me to the lp directory
<imbrandon> SpamapS: i finisied it too
<SpamapS> so where is it?
<imbrandon> github till i get em both done
<imbrandon> :)
<SpamapS> <sigh>
<shazzner> haha
 * SpamapS goes back to bug traiage
<imbrandon> heh
<imbrandon> shazzner: just watch the ~drupal namespace, i renamed the druapal 6 one to cs:precise/drupal6 and the 7 one will be the drupal one
<mhall119> SpamapS: marcoceppi: I'd be happy to get it into charm-tools if you guys can help me
<imbrandon> should be pushed here in just a few hours max, likely sooner
<shazzner> imbrandon: ok awesome
<mhall119> the problem is that it needs to be run by django, using the same environment as django
<shazzner> thanks for the quick reply :)
<mhall119> which often means inside a virtualenv somewhere
<imbrandon> np, email me anytime if i'm not on irc
<imbrandon> <-- @ubutnu.com
<imbrandon> bah, but spelled right
<imbrandon> shazzner: btw if your sub charm looks for a webroot interface on the local container relation that will give you the base drupal install
<imbrandon> so you can dump things in say webroot/sites/all/{themes,libraries,modules/contrib,modules/custom}
<imbrandon> etc
 * shazzner writing this all down
<SpamapS> mhall119: thats no problem I think
<SpamapS> mhall119: We can make 'charm create' do anything to bootstrap the point where you pull in your django app and run the necessary bits to spit out the charm.
<SpamapS> We should perhaps do the same thing with rails in parallel so we abstract at the right level
<marcoceppi> SpamapS: good idea
<SpamapS> like maybe it should be '--framework django --app /path/to/my/django/app'
<SpamapS> and then we can have an alias for that which is 'charm create-django /path/to/my/django/app'
<mhall119> you'll want an optional --python /path/to/executable/for/python
<imbrandon> charm create webapp --framework djgano .....
<SpamapS> mhall119: perhaps there should be a bootstrap.sh or virtualenv.sh in the dir that is automatically run ?
<SpamapS> mhall119: seems like there should be a convention for that
<mhall119> most likely they will already have a local environment setup
<imbrandon> with php there is composer.phar that is run from the dir that has packages.json to do the same type of thing
<mhall119> all the webapp frameworks and languages are so different, do we gain much by trying to make a single "webapp" target?
<imbrandon> sure, i think thats what makes it perfect for abstration
<imbrandon> take the hard bits and make it all uniform , i mean we're mostly talking about spitting out skeletons anyhow
<imbrandon> for someone to build on, not complete apps
<imbrandon> Pylons RoR Django Symphony2 ZF2 Drupal Wordpress ... etc
<mhall119> pretty complete skeletons in my case
<SpamapS> mhall119: they have different mechanics, but they all have the same concepts which can lead to a rich charm. settings, dependencies, etc.
<imbrandon> mhall119: :)
<SpamapS> mhall119: you don't need to worry about that though. I'm just suggesting that we should abstract properly so nobody has to duplicate the same process when we add rails, symfony, etc. etc.
<mhall119> right well, if somebody is going to take on this task, I'll help make the Django part work, but it's more than I'm going to be able to do myself
<SpamapS> mhall119: there is huge value for a sysadmin to be able to take their process knowledge of charming one type of app, and be able to map it to another framework entirely. HUGE value.
<mhall119> sysadmins will be doing this? not app developers
<mhall119> ?
<imbrandon> devops
<jcastro> imbrandon: SpamapS: hey you guys wanna get together later on G+ to talk debian and RPMs? Or do you prefer to head down and skate?
<imbrandon> i'm good either way
<SpamapS> mhall119: well I'd hope that devs and ops would take equal responsibility
<SpamapS> mhall119: so if the dev knows juju, she does it, and if the ops knows juju, she does it.. ;)
<SpamapS> jcastro: I'm actually downloading a Debian iso so I can test juju + local provider right now
<_mup_> Bug #1007544 was filed: test suite assumes /etc/lsb-release will exist <patch> <juju:New> < https://launchpad.net/bugs/1007544 >
<SpamapS> crap.. just realized.. local provider won't work on Debian
<SpamapS> since its tied to uptstrat
<SpamapS> upstart even
<SpamapS> ok, so its EC2 only.. oh well
<imbrandon> whats tied to upstart ? cloud-init ?
<SpamapS> everything ;)
<SpamapS> machine agent
<SpamapS> provider agent
<SpamapS> unit agaents
<imbrandon> upstarts packaged for debian isnt it ?
<SpamapS> sort of
<SpamapS> its not really usable
<SpamapS> nor is it allowed for packages to embed .upstart files along side .init files
<SpamapS> pretty much useless
<hazmat> well we don't  have it in packages
<hazmat> we generate them and drop them on disk during initialization
<hazmat> as long as we have cloud-init we can parameterize the startup stuff as needed
<hazmat> oh.. local provider..
<hazmat> SpamapS, is cloudinit in debian?
<hazmat> yeah.. same principle there.. what's the default/recommended init sys for deb?
<SpamapS> interesting..
<SpamapS> debian has invalid certs
<SpamapS> hazmat: its going into debian, at some point soon
<hazmat> are they going down the sysd, or are they still doing the old sysv  jaunx
<SpamapS> debian is going down the path of most insanity IMO
<SpamapS> "we'll have ALL init daemons"
<SpamapS> choose your own adventure, if you will
<hazmat> SpamapS, but packages can't support more than one init sys?
<SpamapS> hazmat: that policy is about to change
<SpamapS> hazmat: steve langasek has been working on it for some time, and I've been promising to help him at some point too ;)
<shazzner`> huh
<shazzner`> erc is being weird
<SpamapS> damn, txaws bug
<SpamapS> this seems a bit evil
<SpamapS> it defaults to reading *.pem from the cwd
<SpamapS> with no warning
<SpamapS> like "you are running from a dir owned not by you... you may be trusting an evil .pem"
<SpamapS> ok well juju in Debian works fine for EC2
 * SpamapS uploads
<hazmat> SpamapS, the new txaws in trunk.. is a bit borked imo
<SpamapS> hazmat: whats broken?
<hazmat> its basically throwing deprecation warnings on its own internal usage.. so if you use the only available std api, you can get hit with deprecation warnings with no recourse to fix
<SpamapS> hazmat: half-done transition?
<hazmat> SpamapS, appears so.. i haven't really dug into it.. outside to identify the rev.... 147 afaicr
 * hazmat disappears in a puff of busy
<mhall119> SpamapS: marcoceppi: if you guys are interested http://mhall119.com/2012/06/charming-django-with-naguine/
<SpamapS> mhall119: nice
 * SpamapS skims.. likes.. reads more
 * SpamapS fixes last lintian warning in juju package and hopefully does one final sbuild
<hazmat> mhall119, sounds like the making of a good generic django charm ;-)
<mhall119> hazmat: nope
<mhall119> I was very intentionally not making a generic charm
<hazmat> mhall119, i remember, just teasing
<mhall119> ah :)
<hazmat> jcastro, what do you use for doing screencasts?
<jcastro> recordmydesktop
<jcastro> hazmat: http://askubuntu.com/a/4433/235
<hazmat> jcastro, danke
<SpamapS> Alright, juju 0.5+bzr539 uploaded to Debian
<jcastro> \o/
<SpamapS> will sit in NEW queue for probably a week
<SpamapS> HEY .. juju users.. there's a juju version in precise-proposed
<SpamapS> PLEASE TEST
<hazmat> SpamapS, did you test it? ;-)
<SpamapS> hazmat: extensively actually
<SpamapS> hazmat: local does not work, but ec2 does
<hazmat> SpamapS, awesome.. i think i hit a regression somewhere
<SpamapS> hazmat: local could be made to work if we rip out the upstart bits
<hazmat> SpamapS, upstart bits?
<SpamapS> yes, the machine agent running on bootstrap
<hazmat> SpamapS, or just finish the upstartification ?
<hazmat> SpamapS, got a minute for a g+?
<SpamapS> If we want local to work on non-Ubuntu platforms, we're going to have to abstract upstart completely
<SpamapS> hazmat: cerrtainly
<hazmat> SpamapS, jcastro invites out
<marcoceppi> mhall119: nice!
<SpamapS> hazmat: FYI, the proposed source bootstraps ok. Deploying stuff now
<negronjl> done for the day ... enjoy your weekend everyone.
<hazmat> SpamapS, hmm.. cool
<hazmat> negronjl, have a good one
<SpamapS> hazmat: ahh, local provider is broken
<SpamapS>     elif [ $JUJU_ORIGIN = "proposed"]; then
<SpamapS> missing a space
 * SpamapS wonders if shell code even cares that it just made him curse
<SpamapS> shell code don't care. shell code don't give a F***
<_mup_> Bug #1007657 was filed: proposed origin does not work with local provider <juju:New> < https://launchpad.net/bugs/1007657 >
<SpamapS> alright, brain officially melted.. will have to solve that on Monday
#juju 2012-06-02
<mhall119> SpamapS: that's up on /Quotes
<jcastro> marcoceppi: we're at 81.5% AR.
<jcastro> We might want to start thinking of ideas again
<jcastro> I've been waiting for a "lull" since release
<jcastro> but that's not really happening
<marcoceppi> clean up competition again
<jcastro> I think concentrating on tag:12.04 first?
<jcastro> is it possible to hook up Oli's thing to a specific tag?
<marcoceppi> probably
<jcastro> off to meta before I xbox
<jcastro> marcoceppi: whoops, I am in the wrong channel, offtopic. O_O
<SpamapS> mhall119: :-D
<JoseeAntonioR> hey guys, I'm having some probs, when bootstrapping it gives me this error: error: Environments configuration error: /home/same/.juju/environments.yaml: environments.sample.default-series: required value not found
<hazmat> JoseeAntonioR, add default-series: precise
<hazmat> we need to add that to the defalt output.
<JoseeAntonioR> hazmat: yep, I did that and solved it, thanks!
<imbrandon> man zfs
#juju 2012-06-03
<JoseeAntonioR> imbrandon: ping!
<imbrandon> JoseeAntonioR: pong
#juju 2013-05-27
<ahasenack> discourse takes a long time to deploy
<ahasenack> aws m1.small2
<marcoceppi> ahasenack: There's an asset complilation step that takes a bit of time
#juju 2013-05-28
<wedgwood> marcoceppi: do you know if a "best practices" document has been put together yet, perhaps in the new docs?
<marcoceppi> wedgwood: not yet
<AskUbuntu> How do I build juju-core from source? | http://askubuntu.com/q/301107
<jcastro> Daviey: so maas sru is well on it's way
<jcastro> what shall we do about juju?
<Daviey> jcastro: for precise?
<jcastro> yeah
<jcastro> Daviey: pretend only the LTS exists when I talk about juju and maas. :)
<Daviey> heh
<Daviey> jcastro: Okay, well - there needs to be an SRU for the co-installable of juju binary (update-alternatives), stolen from Raring
<jcastro> Daviey: ok, do we know who is assigned to that?
<Daviey> jcastro: Yes
<Daviey> jcastro: Jorge is handling that :)
<FunnyLookinHat> Hey guys - last I checked Rackspace Openstack wasn't compliant with Juju - what were the exact features that were missing?  I believe they're running the openstack API now
<jcastro> Daviey: I mean engineering-wise
<jcastro> FunnyLookinHat: if you know they are instead of believe then it should Just Work.
<jcastro> did they update recently?
<jcastro> because if they did that would be awesome.
<FunnyLookinHat> jcastro, well, not 100% sure, but according to their guys in #rackspace , they're nearly identical to trunk at this point... so they're not sure what would be missing.
<FunnyLookinHat> In fact, they're closer to it than AWS  :)
<jcastro> http://askubuntu.com/questions/132411/how-can-i-configure-juju-for-deployment-on-openstack
<jcastro> give it a shot
<FunnyLookinHat> will do - thx
<jcastro> and lmk if it works, if it does then I will tell the world
<jcastro> sorry I'm in the middle of something otherwise I'd try it myself
<Daviey> jcastro: There isn't currently an owner.. I'd love to review mgz or Mimms doing it :)
<jcastro> Daviey: you tell me what you need, you need mgz/mims to work on it I can work that
<Daviey> jcastro: an SRU of the current juju package to support co-installabiltiy
<jcastro> ack.
<jcastro> FunnyLookinHat: did rax do an announcement or anything?
<FunnyLookinHat> jcastro, not that I'm aware, but I'm building a config right now to see what happens
<FunnyLookinHat> OS_USERNAME and OS_PASSWORD - for an openstack config - these will be machine usernames/passwords?  or these are the credentials for my openstack account for keystone ?
<FunnyLookinHat> well - I'm guessing that isn't the issue, because I was able to get "ERROR 'object-store'"
<jcastro> mgz is usually on top of the openstack provider stuff, but he's not around
<jcastro> I'll ask him to check on RAX though
<FunnyLookinHat> jcastro, well I think I'm nearly there actually - have you seen this error before? http://pastebin.com/puJ9ruVy
<FunnyLookinHat> I went ahead and manually created the container in storage to match the yaml and it seemed to work
<jcastro> I hadn't even tried it
<jcastro> I was assuming they would announce when it all landed
<marcoceppi> FunnyLookinHat: that's an odd looking pyjuju error. It probably has something to do with constraints
<FunnyLookinHat> marcoceppi, Do tell :)
<FunnyLookinHat> constraints = something I can change in my yaml ?
<FunnyLookinHat> jcastro, yeah I don't know - they seem fairly open to fixing things, but not to testing necessarily
<marcoceppi> I don't know how to fix it, just speculating that it's something juju is trying to consume. So constraints are --constraints and it gives you things like controlling mem, cpu, instance-type, etc
<marcoceppi> FunnyLookinHat: do you have juju-core installed? It might be worth testing with that
<FunnyLookinHat> Right right -
<FunnyLookinHat> marcoceppi, well I tested juju locally ( lxc ) and it worked fine
<FunnyLookinHat> Could it have something to do with their machine IDs being single digit numbers?
<FunnyLookinHat> err - instance-type IDs
<marcoceppi> FunnyLookinHat: that shouldn't affect anything, HP cloud uses numerics for their instances as well
<FunnyLookinHat> testing with juju-core now
<FunnyLookinHat> marcoceppi, ok - I wasn't aware of juju-core.... with it installed I had to change a few params but got a bit further.  Does this make any sense to you ? http://pastebin.com/raw.php?i=qweMjW4z
<FunnyLookinHat> RS guys are guessing it requires content-length
<FunnyLookinHat> header, that is.
<FunnyLookinHat> Is there a way to enable verbose request logging with juju-core ?
<hazmat> FunnyLookinHat, re rackspace.. no network security options
<hazmat> i've gotten it farther than that, but that was a little while ago that i was testing
<FunnyLookinHat> hazmat, that's why Juju doesn't currently support it?  Or why that single request failed ?
<FunnyLookinHat> Ah
<FunnyLookinHat> What network security, specifically?
<hazmat> i added rax auth support for pyjuju, but its not much use without the rest.
<hazmat> FunnyLookinHat, rackspace does do nova sec groups or quantum sec groups
<hazmat> ie. no net security at an iaas level
<FunnyLookinHat> Ah
<hazmat> currently juju assumes that capability.. we could do a noop for it to make it work with rackspace.. capabilities detection against nova and keystone (for quantum)
<FunnyLookinHat> Yeah - I'm not sure the loss of that feature would be missed if you could deploy on RS
<FunnyLookinHat> I wouldn't miss it at least...  :)
<FunnyLookinHat> hazmat, assuming either a no-security option was implemented, or rackspace implemented it, would juju "Just work" at that point?
<FunnyLookinHat> I'm only concerned about juju-core btw
<FunnyLookinHat> which I believe means... newer?
<hazmat> FunnyLookinHat, pretty much
<FunnyLookinHat> Ok - good to know.
<hazmat> re sec.. re jcore yes newer, its a reimplementation in golang
<FunnyLookinHat> Ah ok yeah - that's what I had thought.  :)
<hazmat> FunnyLookinHat, re the second error after container creation.. you need to spec a valid image id there as 'default-image-id' in environments.yaml
<AskUbuntu> How to preserve custom configurations across reboots when using juju and maas? | http://askubuntu.com/q/301241
<AskUbuntu> Juju deploy issue : Connection was refused by other side | http://askubuntu.com/q/301243
<_mup_> Bug #1185198 was filed: ERROR 'ServiceRelationState' object has no attribute 'role' <juju:New> <https://launchpad.net/bugs/1185198>
<sidnei> hazmat: ^
<hazmat> interesting
<hazmat> sidnei, finally.. a bug static compilation would have found.. thats a client side error?
<hazmat> there's only ref to that in the upgrade_charm
#juju 2013-05-29
<sidnei> hazmat: it was during upgrade charm yes
<sidnei> hazmat: on the client yes
<jcastro> evilnickveitch: old-docs are building again
<jcastro> evilnickveitch: they were totally broken
<jcastro> evilnickveitch: when will a staging site be ready? I need to add things to policy and create a best practices page but I don't want to do it on old docs
<_mup_> Bug #1185496 was filed: Packaging needs to support parallel installation with pyju <juju:New> <juju-core:New> <https://launchpad.net/bugs/1185496>
<arosales> Weekly Charm meeting coming up at the top of the hour
<arosales> Notes at the pad: http://pad.ubuntu.com/7mf2jvKXNa
<arosales> Hanout URL = https://plus.google.com/hangouts/_/c34514986acd40525bcd5fa34bcb11f10d118ba8?authuser=0&hl=en
<arosales> and if you want to watch to live web cast, the link is http://youtu.be/mQT25UVtLjk
<JoseAntonioR> arosales: if marco or jaca
<JoseAntonioR> or jcastro are around, you can use ubuntuonair
<jcastro> on it!
<arosales> jcastro, thanks
<arosales> jcastro, any bits I need to change?
<jcastro> nope
<jcastro> got it
<JoseAntonioR> jcastro: remember that what should go on the iframe is http://www.youtube.com/embed/mQT25UVtLjk
<JoseAntonioR> not what you pasted in there :)
<jcastro> oh
<jcastro> fixed!
<JoseAntonioR> now, gtg, classes ahead
<jcastro> thanks for the save!
<JoseAntonioR> jcastro: not fixed, fix the whole link instead
<JoseAntonioR> what you did won't work
<jcastro> oh I need the whole embed link from arosales?
<JoseAntonioR> (remove watch?v=)
 * JoseAntonioR disappears
<jcastro> oh I don't have that
<JoseAntonioR> jcastro: remove the link that you pasted, put http://www.youtube.com/embed/mQT25UVtLjk instead
<JoseAntonioR> it's a different page
<jcastro> I did put that link in there
<jcastro> hard refresh
<JoseAntonioR> according to my browser, it's http://www.youtube.com/watch?v=embed/mQT25UVtLjk&feature=youtu.be
<JoseAntonioR> but anyways
<JoseAntonioR> have fun!
<ahasenack> is there a way to hack the juju client to use my own charm store? Like, when I run "juju deploy foo", it grabs foo from somewhere other than the charm store
<ahasenack> because we have branches up for review for a month already, and that would make our lifes easier
<ahasenack> so we wouldn't have to specify urls for each charm, just the name
<jcastro> I believe the plan was to allow any arbritrary url there
<jcastro> hazmat: ?
<hazmat> ahasenack, no
<hazmat> jcastro, highlander style is the intent.
<hazmat> jcastro, it had an env var config once upon a time, but that got shot down
<hazmat> maybe we can revisit
<hazmat> in future there's a notion this could be an env property, with the env downloading charms
<ahasenack> ok
<hazmat> ahasenack, atm the only prod implmentation of the store is the charm store one that pulls from lp
<hazmat> so effectively you'd end up with the same content
<hazmat> unless it was reimplemented
<mthaddon> hi folks, does juju enforce (at certain times) whether services are exposed or unexposed?
<mthaddon> i.e. if you've manually "exposed" services via an external security group command, could juju stomp on that?
<ahasenack> hazmat: I was hoping for something simple as some sort of "prefix" url, to use when the charm name was unqualified
<ahasenack> like, if I say "juju deploy foobar", it uses lp:~ahasenack/something/foobar
<mthaddon> ahasenack: any reason why you can't deploy from a local branch instead?
<ahasenack> mthaddon: I can, and with deployer it's certainly easier, but sometimes I would just like "juju deploy foo" to use *our* charm and not worry about the url
<hazmat> mthaddon, it monitors the groups for the instance and checks their content periodically (in practice 30s)... but extraneous/external groups aren't checked.. however in ec2 because juju launches the instance and sans vpc there's no way to attach groups it means that juju's enforcement suffices, not so in openstack
<mthaddon> hazmat: we've just had two instances where a service that's been unexposed (as far as juju is concerned) but with manual secgroup rules for over a month suddenly have those rules deleted by the bootstrap node - possibly triggered by seeing an instance in error state or some other event - does that sound feasible?
<mthaddon> (in openstack)
<hazmat> mthaddon, the secgroup rules for should be getting polled regularly and acted upon
<hazmat> from juju
<hazmat> based on the exposed ports
<hazmat> mthaddon, if its something you want i'd suggest attaching a new group to those instances with the ports you want
<mthaddon> ok, so the fact that it's been over a month or so is just luck on our part - it could have happened any time after deploying the service
<paraglade>  HexChat: 2.9.5 ** OS: Linux 3.2.0-44-generic x86_64 ** Distro: Ubuntu "precise" 12.04 ** CPU: 8 x Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz (GenuineIntel) @ 800MHz ** RAM: Physical: 7.7GB, 55.8% free ** Disk: Total: 450.6GB, 70.7% free ** VGA: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller ** Sound: HDA-Intel - HDA Intel PCH1: HDA-Intel - HD
<paraglade> A NVidia ** Ethernet: Intel Corporation 82579LM Gigabit Network Connection ** Uptime: 3h 49m 39s **
<ahasenack> a relation-set command on one unit is what triggers a *_changed hook run in th other?
<ahasenack> or rather, between services
<ahasenack> it feels like calling relation-get in a _joined hook is always racy
<marcoceppi> ahasenack: you can try to call relation-get. there's no guarantee that there will be data in either the joined or changed hook. both should check for values. though joined only gets called once per relation changed gets called at least once
<ahasenack> marcoceppi: I'm not liking the mixing of _joined and _changed that most charms seem to be doing
<ahasenack> marcoceppi: that "if there is no value, exit 0 and wait to be called again". That doesn't mean you will be called again out of the blue, it's just because you are (likely) in _joined, not _changed yet
<marcoceppi> ahasenack: not true. joined is called once, then changed is called once. after that each time data on the wire changes changed is called again
<marcoceppi> there ate times where changed won't have data in relation-get
<ahasenack> marcoceppi: I'm seeing something in a charm, and have a question, maybe it's a difference between gojuju and pyjuju
<ahasenack> marcoceppi: the question is
<ahasenack> marcoceppi: in _joined I do, for example, 10 relation-set
<ahasenack> marcoceppi: do these variables get propagated to the other side immediately, or only after _joined finishes running?
<ahasenack> do you know?
<ahasenack> or, put it another way
<ahasenack> let's say _joined has two commands: relation-set foo=bar
<ahasenack> sleep 10h
<marcoceppi> should be investigator
<marcoceppi> immediate *
<ahasenack> and _joined on the other side does relation-get foo in a loop
<ahasenack> will it see foo=bar before 10h?
<marcoceppi> but I can't confirm
<ahasenack> marcoceppi: another one: you said each time data on the wire changes, _changed is called
<ahasenack> marcoceppi: is that batched up? For example, a hook calls 10 relation-set commands
<ahasenack> only when the hook ends will the other _changed hook be called? Or right after each relation-set?
<marcoceppi> another great question ahasenack,I don't actually know. I assume it would create 10 separate changed requests which is probably why a lot of charms send where data all at once at the end of the hook execution
<ahasenack> hm
<ahasenack> marcoceppi: the relation-set doesn't seem to be immediate
<ahasenack> http://pastebin.ubuntu.com/5714726/ we have these as joined hooks
<ahasenack> and the lower one is not printing the foo, bar or baz values
<marcoceppi> ahasenack: interesting
<dpb1> hi all
<dpb1> Is "machine recycling" no longer something that juju does in juju-core?
<sarnold> what's "machine recycling"?
<dpb1> my term for re-using instances from destroyed services/removed units.
<dpb1> s/instances/machines/
<sarnold> ah, as a way of avoiding the expense of giving a machine back to the cloud, just to re-request, and re-image the thing?
<dpb1> i.e., when I do juju remove-unit ubuntu/0; juju add-unit ubuntu; pyjuju would not spin up another instance, but would re-use the machine that ubuntu/0
<dpb1> sarnold: right.  I never liked the feature, since it would never work to do this in practice.
<sarnold> hehe, d'oh.
<sarnold> just when it sounded kind of convenient. :)
<sarnold> though I could imagine that the goal would be to provide a clean-slate for deployment every time
<dpb1> sarnold: ha, well.  i mean, charms just never co-existed well
<dpb1> sarnold: so is this a goal of juju-core?
<dpb1> I mean, a purposful change?
<sarnold> dunno, sorry, was just curious what you meant. :)
<dpb1> sarnold: ah, ok haha
 * thumper reads scroll-back
<thumper> sarnold: hi there, I worked on this, so can give some info
<thumper> and dpb1
<dpb1> ah yes, would be nice. :)
<sarnold> thumper: cool :)
<thumper> dpb1: right now, inside juju-core there is a machine assignment policy that is hard coded for each provider (ec2, openstack, etc)
<thumper> right now we are looking to make this configurable...
<thumper> some time back, machines used to get reused
<thumper> however we couldn't guarantee the state of the machines at all
<thumper> as there isn't good uninstall stuff around charms
<thumper> so a new policy was created to not reuse machines at all
<thumper> and the different providers changed to use that policy
<thumper> this is a temporary measure
<thumper> until we get containerisation in
<dpb1> let me guess, when lxc isolation gets in...
<thumper> when you install a unit onto a machine, it makes it dirty
<dpb1> yes, that would be good
<thumper> lxc containers will appear as "machines"
<thumper> so when you install a unit into a container, the container gets dirty
<thumper> but the machine running the container is clean
<thumper> so when you destory the unit
<thumper> the container goes away with it
<thumper> but the hosting machine will still be clean
<thumper> so will get reused
<thumper> this is work in progress now
<dpb1> thumper: do you know approximately how far out containerisation is?  (just looking to slot work on my end as well, not looking to hold your feet to the fire)
<thumper> real soon nowâ¢
<dpb1> ah ok..
<thumper> in practice, probably several weeks
<thumper> if it is more than a month, something is horribly wrong
<dpb1> I'll keep an eye out then, thanks.
<thumper> np
<dpb1> thanks for the explanation as well, makes sense
<sarnold> thumper: cool, thanks :)
<thumper> happy to help
<sarnold> thumper: will that containerisation work allow co-mingling charms in a container without using the subordinate hack?
<thumper> sarnold: probably, in the same way you can install (or force) two charms onto one machine now
<thumper> ideally we'd like to record the intent with some form of constraint
<thumper> but yes...
<thumper> hopefully
<thumper> containers will look just like machines
<thumper> so you could deply --force to a container
 * dpb1 is looking forward to this feature arriving. :)
<sarnold> thumper: nice, thanks :)
<jcastro> heya thumper
<jcastro> you pretty much got that dave guy plugged in or need anything from me?
<thumper> hi jcastro
<thumper> jcastro: I think me and FunnyLookinHat are good for now
<dpb1> marcoceppi: thx for the review on landscape-client.  Understood about jitsu, I'll keep an eye out for what is coming next.
<jcastro> oh that was his irc
<jcastro> funny
<thumper> jcastro: yeah :)
<FunnyLookinHat> Yo - thumper - quick Q - what sort of density could we expect when it comes to using the containerization you were suggesting ( via LXC, I believe ) ?  And how would the overhead factor in?  Could I host, say, 50 PHP apps on one 4 GB Box ?
<thumper> FunnyLookinHat: sorry NFI
<thumper> lxc is supposed to be very low overhead
<thumper> but I guess the density will depend on how much the different PHP apps are being hit
<FunnyLookinHat> NFI?  :)
<thumper> if they are 50 apps doing not much, then I guess so
<thumper> No Fucking Idea
<FunnyLookinHat> haha
<sarnold> I'd expect it to depend upon the way the lxc containers are created.. if it is hardlinked or bindmounted files shared amongst them, it ought to be very cheap, not much more than just hosting 50 php apps on one box without containers..
<FunnyLookinHat> What if we were to try to put both the DB and Apache within each LXC ( for portability and back-up purposes ) ?  I guess I'm not sure how to predict multiple container'd daemons all floating around working with limited resources
<sarnold> .. but if the files are independent to each container, the kernel won't be able to share RSS of them all, and it'll be a lot like 50 VMs, but with shared kernel space instead... not -as- bad as 50 vms, but not like a single machine, either..
<FunnyLookinHat> sarnold, mind if I PM ?
<FunnyLookinHat> err - nvr mind
<kyhwana> FunnyLookinHat: hmm, you'd be hit with a bunch of IO? though again, probably not more than if you had them all running outside a container
<FunnyLookinHat> So - our goal is to deploy a web application on a per-customer basis...  with a better density than Juju currently offers ( i.e. one instance per VPS )
<FunnyLookinHat> For security reasons each user has their own directory with the full PHP application - encryption keys, etc.
<FunnyLookinHat> Jorge had suggested containers as a solution - which I believe are being worked on currently...
<kyhwana> FunnyLookinHat: i'd make sure you deploy a kernel with user namespaces tho, if you get root inside a lxc container without user NS's, that's the same as root outside it, apparently
<FunnyLookinHat> So I'm trying to estimate what sort of density I could expect - if I could usually get away with 50 per 4 GB box using the same MySQL and Apache daemons, what would I get using LXC container s?
<sarnold> kyhwana: mostly, apparmor confinement on the lxc container provides some protection against e.g. echo b > /proc/sysrq-trigger ...
<kyhwana> FunnyLookinHat: i'd _guess_ about the same
<kyhwana> sarnold: hmm, what about a kernel priv escalation exploit?
<sarnold> kyhwana: those are also available to userns roots :) just how well-written do you think all those 50-ish filesystem drivers are? :)
<kyhwana> sarnold: :P
#juju 2013-05-30
<jcastro> jamespage: man, you guys totally crushed the incoming charm queue
<jcastro> http://jujucharms.com/review-queue
<sinzui> hey charmer's is it possible to restart the agent on a unit. I have a stopped agent, but I can see the unit's service appears to be fine
<jcastro> hey FunnyLookinHat
<jcastro> did you ever find out if it worked on Rackspace?
<FunnyLookinHat> jcastro, we're close
<FunnyLookinHat> Two issues:
<FunnyLookinHat> 1) RS currently is returning a 411 error when trying to auth with Juju Core - the strange this is that the request isn't being sent with a content-length header... but they really shouldn't be rejecting the request for that I don't think
<FunnyLookinHat> 2) RS doesn't _currently_ support security groups - nova / quantum - but they're "working on it" - in reality, a better scenario might be a noop flag to not use security.
<jcastro> also did you notice a new juju-core release announcement on the list?
<FunnyLookinHat> so I'm currently forking out code to remove all Open/Close port stuff to see if it will "work" that way - and if so I might submit a patch for the noop,
<FunnyLookinHat> Ah no - which list?
<FunnyLookinHat> I don't think I'm on it.
<jcastro> https://lists.ubuntu.com/mailman/listinfo/juju
<FunnyLookinHat> Thanks
<SpamapS> FunnyLookinHat: how is rackspace working w/o cloud-init ?
<FunnyLookinHat> SpamapS, cloud-init ?  I don't know...  I'm only going off of what hazmat has suggested and my own conversations with #rackspace
<FunnyLookinHat> Realistically - I've been stuck at this 411 error for three days now, so I'm going completely off of conversations and not experience
<hazmat> FunnyLookinHat, SpamapS, they have config drive support for userdata afaicr
<hazmat> smoser was working with them on that for cloudinit
<SpamapS> hazmat: and cloud-init in their ubuntu images?
<hazmat> SpamapS, indeed
<SpamapS> hazmat: sweet
<kmyst> i'm getting a ConnectionRefusedError trying to issue a juju bootstrap against a node I enlisted and commissioned...the enviroments.yaml file i used was the one from the maas documents.  what (if anything) is wrong?
<marcoceppi> kmyst: can you run juju bootstrap -v and include the output in a pastebin?
<kmyst> marcoceppi: sure thing
<kmyst> marcoceppi: http://pastebin.com/uzsKubYy
<marcoceppi> kmyst: What's maas-server set to? Do you have access to that address?
<kmyst> marcoceppi: what do you mean set to? and yes i'm logged in to the machine
<marcoceppi> kmyst: in your environments.yaml, what's it set to
<kmyst> marcoceppi: oh! http://192.168.99.1/MAAS i've also tried http://192.168.99.1:80 and http://192.168.99.1:5240 and possibly tacked /MAAS onto the end of those last two
<marcoceppi> try http://192.168.99.1:80/MAAS
<kmyst> marcoceppi: http://pastebin.com/tmT90vD0
<marcoceppi> kmyst: alright! You've connected. Now, it's saying you don't have any nodes "commisioned" (I think that's the term, it's been a long time since I've used maas and juju)
<kmyst> marcoceppi: uh well it was in commissioning and then it went to ready then i told it to start and now it's allocated and installed and running :)
<marcoceppi> kmyst: so, you'll need more nodes commissioned/ready in order to deploy things
<kmyst> marcoceppi: so one isn't enough for testing in my lab?
<marcoceppi> kmyst: no, so you'll need multiple ones. The idea is MAAS provides the ability to treat bare metal like cloud servers
<kmyst> marcoceppi: i just never got juju to do anything since i got the node up and running/allocated/installed
<marcoceppi> So when you bootstrap and deploy you allocate physical maas nodes to juju for it to install a charm/service on each
<kmyst> marcoceppi: right i know that much and was testing to try and spin up one cloud server
<kmyst> so even with me doing the above i can't juju against the one node?
<marcoceppi> kmyst: you can bootstrap against one node, but you'll need another node to deploy anything
<marcoceppi> bootstrap is just what's used for the orchestration, you must bootstrap (and use one node) before you can start deploying things
<kmyst> marcoceppi: gotcha so if i'm reading this output correctly the bootstrap failed because no matching node is available?
<marcoceppi> kmyst: correct. So did you provision the maas node, then install juju on that and are trying to bootstrap from within the "only" maas machine?
<kmyst> basically
<marcoceppi> kmyst: so, you don't need to actually do that :)
<kmyst> missed that in the documents :)
<marcoceppi> You run juju from your local machine, as a client, when you bootstrap it it'll then use that "only" node as the bootstrap node. The more nodes you add the more things you can deploy with
<kmyst> i feel a facepalm coming on
<kmyst> i got that one node declared then when it was in commissioning i tried juju, nothing, so i powered it up and it did its thing and went to ready so i tried juju again with no results so i then just started it from the nodes page and it went to allocated
<kmyst> the whole while i was thinking juju wasn't supposed to work at this point yet :)
<marcoceppi> kmyst: so once it's commisisioned, and you power it on, and it does its thing, you just need to power it off at that point
<marcoceppi> then it's all ready to roll and you can juju against it :)
<kmyst> that's kinda what i thought but when i got that connection refused error i just kept pressing on and started it manually and watched it install the OS
<kmyst> so i guess my one node is goofed up eh? :)
<hazmat> SpamapS, FunnyLookinHat no cloud-init in default rackspace images
<SpamapS> doh
<FunnyLookinHat> hazmat, couldn't you just build a custom image w/ it?
<hazmat> FunnyLookinHat, definitely
<hazmat> FunnyLookinHat, but you'll get a deprecation warning from juju-core re default-image-id
<FunnyLookinHat> eh - I'll kindly thank juju-core for the warning and move on about my day
<FunnyLookinHat> :D
<FunnyLookinHat> hazmat, building an open stack cluster in the office tomorrow w/ a few 1Us we have lying around...  any good tutorials on getting cloud-ready Ubuntu images to be used in it?
<hazmat> FunnyLookinHat, the images are @ hosted cloud-images.ubuntu.com, the tutorials for openstack + maas + juju also cover it (https://help.ubuntu.com/community/UbuntuCloudInfrastructure)
<FunnyLookinHat> hazmat, ah slick - bookmarked.  Thanks !
<hazmat> FunnyLookinHat, the ha setup info is here.. its a bit more involved https://wiki.ubuntu.com/ServerTeam/OpenStackHA
<FunnyLookinHat> oh wow - minimum recommended servers to just install for testing is 6 w/ juju-jitsu ?  What about with juju-core ?
<hazmat> no different
<FunnyLookinHat> I feel like I should be able to get something running with 3...  :D
<hazmat> except jitsu deploy-to is built in
<FunnyLookinHat> I'm aware that 6 is recommended for production though
<hazmat> via juju deploy --force-machine
<FunnyLookinHat> ah
#juju 2013-05-31
<alicam> Anyone online who can help me setup on EC2 in Sydney (ap-southeast-2) because nothing I do is working!
<alicam> ap-southeast-2 is not recognised as a valid region when you add it to the environment file.
<alicam> When I add ec2.ap-southeast-2.amazonaws.com as the ec2-uri variable, as an override for region, it breaks the secure transport, and the auth fails.
<thumper> alicam: I have also noticed problems with ap-southeast-2
<thumper> alicam: sorry, don't have a fix though
<thumper> not all regions created equal
<thumper> sydney ec2 lies
<thumper> in its api
<thumper> I start an image there
<thumper> but ask over the api if it is running
<thumper> nope
<thumper> but I can see it in the aws console
<thumper> doesn't matter, api lies
<thumper> so *sadface*
<alicam> Sadface here too...
<alicam> Looks like I'll try for Singapore of Nth Cal
<alicam> Any experience with those?
<thumper> sorry, no experience there
<thumper> good luck
<marcoceppi_> alicam: north California should be fine. haven't tried Singapore though
<alicam> Thanks
<alicam> Thanks Marco. I tried Singapore and it couldn't speak to the instance. It fired up an instance, but then lost contact with it! eird
<alicam> Weird
<alicam> Marco, is there any reason why I'd have trouble specifying t2.micro instances in my constraints? I don't need m1s
<alicam> t1.micro instances, I meant, sorry!
<alicam> marcoceppi_: is there a way to make NFS share an instance with memcached, in the same way that mysql and php-fpm can be made to share?
<ahasenack> hi guys, where in launchpad can I see the merge proposals against a specific charm?
<ahasenack> or, in lp lingo, "+activereviews"?
<jamespage> ahasenack, all of the official charm branchs are owned by ~charmers
<jamespage> but http://jujucharms.com/review-queue is the definitive source
<jamespage> jcastro, sorry about all of the openstack merge proposals
<jamespage> :-)
<ahasenack> jamespage: hm, ok, but I wanted to get an email when a MP was put up for review against a specific charm
<jamespage> adam_g and I will work through those (i.e. we won't merge our own proposals)
<jcastro> jamespage: I wasn't complaining
<jcastro> I was more like "dang, impressive"
<jamespage> jcastro, :-)
<ahasenack> jcastro: hey, is there a charm school today?
<jcastro> yeah
<jcastro> I'll post the reminder to the list
<ahasenack> ok
<jcastro> sidnei: scale of 1 to 10 how much work is that zero downtime for haproxy?
<jcastro> sidnei: that link was awesome btw.
<jcastro> http://www.igvita.com/2008/12/02/zero-downtime-restarts-with-haproxy/
<jcastro> ^^ for those interested
<dpb1> Is there a workaround-type-replacement for debug-hooks missing in juju-core?
<dpb1> I want to run commands interactively in the context of a hook on a machine to test out what is happening.
<sidnei> jcastro: im considering other alternatives mentioned elsewhere, let me dig a couple more links
<jcastro> dpb1: I'm not aware of any at this time
<jcastro> marcoceppi_: ^^^
<sidnei> jcastro: http://blog.balancedpayments.com/payments-infrastructure-suspending-traffic-zero-downtime-migrations/ is the other one i had in mind, it requires haproxy 1.5 though
<sidnei> http://labs.animoto.com/2010/03/10/uptime-with-haproxy/ is a variation of the first one
<marcoceppi_> dpb1: not that I know of yet
<dpb1> Hey marcoceppi_, :(
<marcoceppi_> dpb1: I haven't really tried yet, A lot of my testing is "hook broke, ssh in, patch file, resolved --retry, check again"
<dpb1> marcoceppi_: ya, same.
<dpb1> marcoceppi_: I was thinking at one point of trying out some kind remote debugging, but then I... slapped myself.
<marcoceppi_> dpb1: it'd be nice if core added that again *severe winking towards #juju-dev members*
<dpb1> marcoceppi_: I sent an email to juju-dev, hopefully that gets some attention. :)
<jcastro> http://ubuntuonair.com/ is up to date, we'll star the charm school in about 2 minutes!
<jcastro> ok let's begin
<jcastro> if you want to ask questions during the charm school then feel free to do so here
<jcastro> you can follow the video stream on http://ubuntuonair.com/
<jcastro> today we're doing How to Write a Charm Part II
<jcastro> and Mark Mims is going to show us a charm from scratch using what we call a platform charm -- this example will be node.js!
<evilnickveitch> \o/
<marcoceppi_> woo who!
<arosales> charm schooling :-)
<jcastro> m_3: you appear to have frozen
<arosales> jcastro, m_3 thanks!
<m_3> tmux-driven-presentations... whoohoo!
<blabla> hi, can someone please point me to the last Jono Bacon Q&A?
<blabla> can't find the last videos in the youtube channel
<jcastro> for juju?
<jcastro> anyone ever get an error similar to this
<jcastro> error: Get https://s3.amazonaws.com/juju-e4698ca2abde47dddd405d1f595745e596f/provider-state:
<jcastro>  remote error: handshake failure
<jcastro> I'm doing a bootstrap and it's alternating between that and error: The specified bucket does not exist
<marcoceppi_> jcastro: get them all the time
<ahasenack> hm, I'm not understanding why relation-get needs a unit id
<ahasenack> in a config-changed hook, I understand I need a -r <relation_id>
<ahasenack> isn't that enough? the relation ids are between services, not units
<ahasenack> i.e., the r_id between server/0 and client/0 is the same as between server/0 and client/1
<ahasenack> meaning in my mind that whatever relation values have been set, the relation id is enough to read them
<ahasenack> it wouldn't be different if I did relation-get .... client/0 or client/1
<sarnold> ahasenack: would it provide any utility for client/N to determine which of server/0 or server/1 to prefer for its queries/requests?
<ahasenack> sarnold: the get command ("question") isn't sent to the server unit, it's "juju" that answers
<ahasenack> if I understood the question correctly
<sarnold> ahasenack: sorry, I'll back up a bit..
<ahasenack> 2013/05/31 21:19:57 INFO worker/uniter/jujuc: running hook tool "relation-get" ["-r" "test-r:1"]
<ahasenack> 2013/05/31 21:19:57 DEBUG worker/uniter/jujuc: hook context id "andreas-client/1:config-changed:1660150820142556165"; dir "/var/lib/juju/agents/unit-andreas-client-1/charm"
<ahasenack> 2013/05/31 21:19:57 INFO worker/uniter: HOOK error: no unit id specified
<ahasenack> that was the error
<ahasenack> this is a config-changed context
<ahasenack> I added several units before, I printed the relation-ids and they are all the same for all units
<ahasenack> meaning, the relation id is between services, not units
<sarnold> ahasenack: some clients / protocols (memcached? httpd?) allow clients to query a server and when providing a service, you might wish to spread out which servers get the queries.. I'm curious if requiring the unit id would allow writing config files to say "this client should prefer server/0 before server/1", and another client to configure "server/1 before server/0"
<ahasenack> sarnold: ok, I see. What I understood is that it doesn't matter which unit I put in that command, the answer will be the same
<ahasenack> hence, why do I have to put the unit in there at all
<ahasenack> unless with relation-set I can scope things for a specific unit...
<ahasenack> hm
<sarnold> ahasenack: memcached isn't a perfect example, since most front-end libs will do something slightly better anyway.. I was just wondering if the intent was to make this feature possible.
<ahasenack> let's run a hook again to get relation-set --help
<sarnold> hehe
<ahasenack> hm, no, relation-set only accepts at most a relation id
<sarnold> heh
<ahasenack> while
<ahasenack> 2013/05/31 21:38:36 INFO andreas-client/1: usage: relation-get [options] <key> <unit id>
<ahasenack> so, I don't know
<ahasenack> relation-get prints the value of a unit's relation setting, specified by key.
<ahasenack> (that was from --help)
<ahasenack> that help doesn't seem accurate, as I can call relation-get without any parameters in a relation hook
<ahasenack> neither key nor unit are mandatory in that context
<ahasenack> mailing list to the rescue
<ahasenack> at best I'll know the answer just before hitting "send"
<sarnold> :)
#juju 2013-06-01
<freeflying> ia transaction only supported with destroy-* in latest juju-core?
#juju 2014-05-26
<lazyPower> bradm: apologies. It was late when I lent a hand to that venture and had not looked at the bug tracker.
<lazyPower> I'll leave a note to investigate first thing Tuesday morning. Just hopped on to see the ping :) Happy holiday o/
<AskUbuntu> MaaS + JuJu on a single PC, MaaS as host for VM Nodes (LXC + KVM) | http://askubuntu.com/q/472230
<cjohnston> wallyworld_: ping
<wallyworld_> hi
<wallyworld_> cjohnston: what can i do for you?
<cjohnston> wallyworld_: could you please look at bug #1319947 and tell me what else you may need
<_mup_> Bug #1319947: LXC local provider fails to provision precise instances from a trusty host - take 2 <juju-core:Confirmed> <https://launchpad.net/bugs/1319947>
<wallyworld_> cjohnston: the cloud init log from the lxc container would be useful
<cjohnston> wallyworld_: meaning like machine-1 or somehting?
<wallyworld_> cjohnston: /var/log/cloud-init.log or similar
<wallyworld_> from the container
<cjohnston> wallyworld_: the containers are stuck in pending
<wallyworld_> cjohnston: you should be able to ssh into them
<cjohnston> wallyworld_: http://paste.ubuntu.com/7519544/
<wallyworld_> cjohnston: pending normally means that the containers have come up but the juju processes inside haven't and so the phone home ping doesn't happen
<wallyworld_> but you should be able to ssh in
<cjohnston> juju ssh 1
<cjohnston> ERROR machine "1" has no public address
<wallyworld_> how about lxc-ls --fancy and trying to ssh into the ip address?
<cjohnston> wallyworld_: no output
<wallyworld_> does lxc-ls --fancy say the containers have started
<wallyworld_> oh, maybe not
<wallyworld_> that implies perhaps that the precise image was not downloaded
<wallyworld_> what's the contents of /var/lib/lxc
<cjohnston> jenkins  juju-precise-template  lpdev
<wallyworld_> and juju-precise-template contains stuff like config, rootfs etc?
<wallyworld_> is there any info in the lxc logs on the host to indicate why the container could not be started?
<cjohnston> config  fstab  rootfs
<wallyworld_> cjohnston: what version of lxc do you have installed?
<wallyworld_> dpkg -s lxc ?
<cjohnston> wallyworld_: would I be looking in something like lxc/lxc-monitord.log ?
<cjohnston> Installed: 1.0.3-0ubuntu3
<wallyworld_> maybe, not sure tbh
<wallyworld_> that's the correct version i think
<wallyworld_> cjohnston: is this your own machine or a cloud instance you are using?
<cjohnston> wallyworld_: http://paste.ubuntu.com/7519597/
<cjohnston> my desktop
<wallyworld_> if it were a cloud instance we could perhaps ssh in to poke around
<wallyworld_> you have juju-local installed?
<cjohnston> juju-local:
<cjohnston>   Installed: 1.18.3-0ubuntu1~14.04.1~juju1
<wallyworld_> hmmm, i'm running out of ideas
<wallyworld_> cjohnston: out of interest, does starting a trusty container work?
<wallyworld_> ie set default-series: trusty in env config?
<cjohnston> it did, I haven't tried it since 18.3
<wallyworld_> hmm. so just precise
<wallyworld_> cjohnston: what you can do is type in by hand the lxc commands that juju would use to start a precise container to see where any error might be
<wallyworld_> juju just shells out and calls lxc-create etc
<cjohnston> ack.. I'll see if I can find time for that while I'm sprinting
<cjohnston> coffee break.. ping me later if you get time.. thanks wallyworld_
<wallyworld_> cjohnston: if you could, that would be great, since i'm out of obvious suggstions
<wallyworld_> ok will do
<sebas5384> hello charmers and juju'ers :)
<sebas5384> awesome charm!! http://manage.jujucharms.com/~gnuoy/precise/content-fetcher
<sarnold> wow looks neat :)
<sebas5384> sarnold: yeah but doesn't have git clone :(
<sarnold> sebas5384: it feels like something it'll grow eventually :)
<sarnold> I was hoping to see something for .gpg or sha256 sum validation, but again, hopefully something it'll grow
<sebas5384> yeah will see
<mmelo> Hi guys , i need a little help.
<mmelo> In my local environment after changed dhcp.conf configurations to force specific ip address to the charms juju dont refresh this new addresses to the charms.
<sebas5384> mmelo: know nothing about dhcp :(
<sarnold> mmelo: I'm no wizard here but that feels like one of the problems easiest solved with destroying and rebuilding the environment
<mmelo> i lost my relation between wordpress and mysql for example, i try to recreate relation but does not work
<hackedbellini> hi guys. So, some of my lxc changed ips, but the relation is still using the old one
<hackedbellini> In the logs, I didn't see any call for 'db-relation-changed' after the ip changed. Is there a way that I can manually force it?
<hackedbellini> note that I cannot destroy any unit/service/relation/environment as I'm on a production server
<avoine> hackedbellini: I don't think Juju was planned for that. Can you trigger a relation-set from other hooks? like start, stop, upgrade, etc
<hackedbellini> avoine: I tried triggering the upgrade hook by forcing it with the '--force' flag. The config file that contains the db ip is being overridden (I tried changing by hand but it changes when a hook is called)
<hackedbellini> but for some reason, although juju knows the new ip of the db, it is not getting it right on the 'relation-get'. The most strange part comes now: I have 2 mediawiki installations (same charm but deployed with different aliases) connected to the same mysql unit. When mysql unit changed ip, the change was propagated to one wiki, but not to the other
<hackedbellini> I tried restarting juju-agent just now.... I saw in the logs that _a lot_ happened in the units. But the same is happening... one wiki has the new mysql ip and the other don't
<sebas5384> constraints on juju-local is working?
<avoine> hackedbellini: strange
<avoine> hackedbellini: maybe this could help you: https://pypi.python.org/pypi/juju-dbinspect
<hackedbellini> well, as someone just said to me, the mediawiki strange problem where one unit "changed" the ip and the other don't might have another reason. It seems a workmate here changed it by hand
<hackedbellini> but well, for some other charms, the realtion is still reporting the old ip
<hackedbellini> avoine: thanks! I'll take a look
<sebas5384> constraints with juju-local isn't working or, im doing something wrong hehe
<sebas5384> juju set-constraints --service drupal mem=2G cpu-cores=2
<hackedbellini> avoine: I need the system administrator to install some packages for me so I'm able to use the tool you suggested
<hackedbellini> in the mean time: I did some testing and I'm almost sure now. The lxc ip changed, but the "provider" of the db relation (mysql, postgresql, etc) is not calling 'relation-set' again
<hackedbellini> On  the other charm, 'relation-get' is returning the old ip. So, if I made mysql/postgresql run relation-set again, it would probably make things right. Do you know how can I do that by hand?
<avoine> hackedbellini: I think not, well not directly
<avoine> hackedbellini: let me check I think I have an other way
<hackedbellini> avoine: http://pastebin.ubuntu.com/7523369/
<hackedbellini> this is what is happening when I try to open a shell on juju-db
<hackedbellini> it tries to do a 'cat /var/lib/juju/agents/machine-0/agent.conf', but that file doesn't exist
<hackedbellini> it exists actually, but not in that path
<avoine> hackedbellini: that might be risky but you could check the relation cache under: /var/lib/juju/agents/unit-mediawiki-0/state/relations/
<hackedbellini> the right path would be /var/lib/juju/.juju/local/agents/machine-0/agent.conf
<avoine> ouch
<avoine> that's a bug
<hackedbellini> avoine: hrm, I can't find any unit-xxx directory
<hackedbellini> I tried: find . -type d -name "*unit*" but it didn't find anything
<hackedbellini> where more could this be?
<avoine> hackedbellini: this is on your mediawiki machine
<hackedbellini> I mean, that relations cache direcotory you said
<hackedbellini> ahhh, ok
<hackedbellini> avoine: found it. But this is the only information present there: http://pastebin.ubuntu.com/7523432/
<avoine> hum, not very usefull
<hackedbellini> avoine: yes :(
<hackedbellini> I'm totally lost here
<hackedbellini> avoine: is there anything I can do with the juju-db utility so I can connect to mongo?
<avoine> hackedbellini: maybe changing the wrong path hard coded
<avoine> but you wont be able to modify the database
<avoine> only inspect it
<avoine> so no very usefull in your case
<hackedbellini> avoine: hrmmm, didn't know that
<avoine> I thought there was a cache somewhere that you could change but there is not
<avoine> hackedbellini: you could comment here to ask for a raise in the priority of this: https://bugs.launchpad.net/juju-core/+bug/1256053
<hackedbellini> avoine: very nice! I'll surely add me to the "affected" people and see if I can make a useful comment there. Thank you!
<AskUbuntu> Juju Ceilometer-Agent is not reporting about nova-compute | http://askubuntu.com/q/472646
<bradm> lazyPower: no need to apologies, I was glad of the help :)  Plus, some of us didn't get the holiday, I'm in a slightly different timezone.
#juju 2014-05-27
<hazmat> hmm bellini is gone
<hazmat> bummer.. okay working on a workaround
<hazmat> fwiw.. workaround added as comment to relevant bugs.. https://gist.github.com/kapilt/a61efcb4eaef9e685397
<sebas5384> ERROR cannot assign unit "nova-compute/0" to machine 0: machine "0" cannot host units
<sebas5384> bye bye
<sebas5384> :(
<AskUbuntu> What types are allows in config.yaml in juju charms? | http://askubuntu.com/q/472802
<nottrobin> ^ what AskUbuntu said - does anyone know what config types are allowed? Is there a "dictionary" type?
<marcoceppi> nottrobin: click on the link, the question has been answered. The short answer is no dict type, int, float, string, boolean only at the moment
<sarnold> lol
<sarnold> marcoceppi: nottrobin is the questioner and answerer :)
 * marcoceppi saunters away
<nottrobin> marcoceppi: thanks =D
<nottrobin> marcoceppi: I went and found the answer myself
<marcoceppi> cool
<caribou> marcoceppi: is it possible to have timing issue (i.e. race condition) with the definition of relations when a 'relation-change' hooks kicks in ?
<caribou> I'm debugging an openstack charm and if I print the result of a 'relation_get' at the beginning of the "-changed" hooks the value is present
<marcoceppi> caribou: there's a chance the relation data won't be available at the time of the hooks execution
<caribou> if I don't print it (for debugging purpose), then it fails because the value is not defined
<marcoceppi> caribou: there's always a chance relation data won't be available during -changed relation, which is why you should build in verification that the values you need are present before continuing
<caribou> hmm, how do I work around this  ? wait for it to appear ?
<caribou> since the hook will not get re-fired once it becomes available
<marcoceppi> caribou: most charms do an idempotency guard and just exit 0 until it's available
<marcoceppi> caribou: yes it will
<marcoceppi> relation-changed will always fire at least once during a relation creation event, then will execute each time data on the wire changes
<caribou> marcoceppi: ah, ok. I was tempted to add such a guard but didn't know if it would get refired
<caribou> marcoceppi: thanks I'll do that
<marcoceppi> most of the time this results in two relation-changed events being queued. one is the first one that will always happen (which may or may not have the data) then one for each subsequent run
<marcoceppi> caribou: cheers
<caribou> marcoceppi: this explains why I got the data when running within debug-hooks and not when running live
<marcoceppi> caribou: right, there's enough latency that you don't need the second -changed event
<caribou> marcoceppi: understood !
<AskUbuntu> Destroy a juju service and also its associated machine | http://askubuntu.com/q/472849
<ghartmann> anyone else is having issues with juju local provider ?
<ghartmann> I was very happy with juju but it became unusable just about two months ago
<stub> ghartmann: Working for me
<ghartmann> I can't get juju local to work anywhere, even with virtual machines. devel / stable
<stub> I can't seem to send syslog messages to a related rsyslog service. Anyone got it working in their charm?
<hazmat> ghartmann, what symptons?
<ghartmann> machine goes pending and it's not delivered
<ghartmann> it seems to be related with the developer tools for saucy
<cjohnston> Does charmhelpers CLOUD_ARCHIVE_POCKETS need to be updated for trusty?
<niedbalski__> hey lazyPower , what does 'store error on...' means on the review queue? (http://manage.jujucharms.com/tools/review-queue)
<lazyPower> Thats a great question niedbalski__. marcoceppi can you shed some insight into that one?
<marcoceppi> niedbalski__ lazyPower it means that "charm proof" fails for that charm
<marcoceppi> err, the store error is something else
<marcoceppi> it means that the charm exists in a promulgated branch but isn't actually in the charm store
<niedbalski__> marcoceppi, there is a manual process for doing that ?
<lazyPower> marcoceppi: is that basically the branch was pushed but charm promulgate was not run against the charm?
<jcastro> http://askubuntu.com/questions/tagged/juju?sort=newest&pageSize=15
<jcastro> some new incoming questions!
<jcastro> yo lazyPower
<lazyPower> sup jcastro
<jcastro> you're doing the review on elasticsearch?
<jcastro> I don't remember if that was you or just in "the pile"
<lazyPower> its in the pile atm.
<lazyPower> i've touched it, so has mbruzek
* Topic unset by jcastro on #juju
 * mbruzek waves
<jcastro> sigh, whoops
* jcastro 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 || Weekly Reviewer: marcoceppi
<whit> lazyPower, is the outstanding issue with ES the peer relation thing?
<lazyPower> whit: That was the last known issue. hazmat has some activity against the charm stating its good in his use cases.
<lazyPower> that and there's some missing offline environment installation logic for feature parity with the existing charm
<lazyPower> otherwise i think its all thumbs up from here
<hazmat> whit, which peer relation issue?
<hazmat> whit, it doesn't have any that i'm aware of
<whit> hazmat, we are talking about the ansible branch?
<hazmat> whit, yeah.. simple offline and website relation needs port set were the items of note i had.
<hazmat> whit, yes
<hazmat> whit, also some philosophical discussion about removing either cluster or rest named relation
<hazmat> but that's legacy from the charms impl
<hazmat> from the old impl
<whit> hazmat, yeah, bw
<hazmat> but its needless confusion imo
<whit> yeah
<lazyPower> hazmat: so the charm embedded relationship exchange works? We don't need to worry about the multicast workaround thats going on there?
<hazmat> lazyPower, that stuff was garbage
<hazmat> needed ec2 credentials or multi-cast support.. its stuff that never should have been in the charm
<hazmat> lazyPower, relations hooks can configure the address set for peers automatically.. and the ansible version of the charm does just that, its much more universal and simpler.
<lazyPower> welp thats duly noted then. All we are missing is offline support, and that could easily be added as an issue to be fixed post promulgation - but I don't know that we want to set the precident for removal of features to be promoted in the store.
<lazyPower> ergo: what if someone is in an offline environment and has this deployed? we just broke it for them.
<hazmat> also note its currently breaking the interface on 'http' for the website rel
<hazmat> it needs to pass the port
<hazmat> one liner
<lazyPower> ah right, and that.
 * lazyPower glosses over the obvious
<mhall119> marcoceppi: ping
<marcoceppi> mhall119: pong
<mhall119> marcoceppi: hey, we have a cloud devops track for UDS/UOS June 10-12, can you be a track lead for it? jcastro is already one
<marcoceppi> mhall119: uh, sure
<mhall119> marcoceppi: jcastro: I'd also like a track lead from the community, any recommendations?
<james_w`> is there a spec for the actions work?
<cjohnston> is it possible in one juju deployer file to be using precise and trusty for different charms?
<marcoceppi> cjohnston: yes
<marcoceppi> cjohnston: remove the series: key, then put the series in all the charm: lines
<cjohnston> ack
<cjohnston> ta
<marcoceppi> ie, charm: cs:trusty/mysql
<hazmat> er.. charm_url: cs:trusty/mysql
<hazmat> you can keep the series at the top level, and just override on the ones you need it as well
<cjohnston> what if I'm not using cs charms? charm: graphite for example
<hazmat> cjohnston, series: trusty
<cjohnston> ack.. sweet
<hazmat> cjohnston, or charm_url: local:trusty/mysql ..
<hazmat> cjohnston, this might be post trusty version btw. (0.3.6) .. latest is 0.3.8 on pypi
<cjohnston> ok
<mhall119> marcoceppi: jcastro: so far you two are the only track leads I have picked for DevOps, it would be nice to have a third, can you recommend somebody?
<jcastro> someone from gaughen's team
<nottrobin> how do I give a juju charm instance a specific public address? - rather than just an IP address?
<nottrobin> also Is there any way to run bundles directly without starting a "juju-gui" instance? (I'm following https://juju.ubuntu.com/docs/charms-bundles.html)
<jcastro> juju-deployer -c bundle.yaml will do the bundle without the gui
<mhall119> gaughen: ping
<mhall119> jcastro: anybody from the community side?
<gaughen> mhall119, pong
<gaughen> let me read a bit of the history here
<mhall119> gaughen: I'm looking for a 3rd track lead for Cloud DevOps in the upcoming UDS/UOS
<gaughen> mhall119, I can do that
<gaughen> count me in
<mhall119> awesome, thanks, will send out an email with instructions
<nottrobin> jcastro: thanks, that looks perfect
<jcastro> mhall119, jose'
<jcastro> s been doing a bunch of work lately if he's interested
<mhall119> jcastro: can't, jose's already a lead for community track
<jcastro> thief!
<mhall119> he was ours first!
<jose> mhall119: if it's possible I can help with both
<mhall119> jose: ok, you're on both now
<jose> mhall119: cool, thanks :)
<mhall119> no, thank you :)
<jose> :)
<khuss> hello there..
<khuss> i'm just getting started with juju and have some questions
<khuss> i have a MAAS server which has 30 nodes.. (Dell PowerEdge)
<khuss> i installed juju on the MAAS controller
<khuss> when I try juju status it, just hangs
<khuss> here is the strace output
<khuss> setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0 read(4, 0xc200407000, 4096)             = -1 EAGAIN (Resource temporarily unavailable) write(4, "GET /MAAS/api/1.0/nodes/?agent_n"..., 494) = 494 epoll_wait(5, {}, 128, 0)               = 0 futex(0x11a0d38, FUTEX_WAIT, 0, NULL)   = 0 epoll_wait(5, {}, 128, 0)               = 0 epoll_wait(5,
<lazyPower> khuss: did juju return a routeable address for the bootstrap node?
<khuss> LazyPower: that's the part I am confused with
<khuss> there are 30 nodes but I want to install an app only on some nodes
<khuss> when we do juju status, does it have to contact all nodes
<khuss> here is the yaml file
<khuss> environments:   maas:     type: maas     maas-server: 'http://localhost:80/MAAS'     maas-oauth: ''     admin-secret: topsecret     default-series: precise
<khuss> here is the output from the deploy
<khuss>  juju deploy wordpress -v verbose is deprecated with the current meaning, use show-log 2014-05-27 16:59:04 INFO juju.state open.go:68 opening state; mongo addresses: ["node17.master:37017"]; entity ""
<lazyPower> khuss: no, it should only contact teh bootstrap node when running status.
<khuss> is the bootstrap node is different from the node where I installed juju
<khuss> i'm installing juju on the same node where maas cluster and regional controllers are running
<khuss> in other words, how does juju determine which node to use as a bootstrap node
<lazyPower> khuss: When youd efined your MAAS provider, if ti has any units enlisted, it will spin one of those nodes up and return it as teh bootstrap node.
<khuss> how do I know which node has been configured as the bootstrap node
<lazyPower> khuss: do you have more than one unit allocated to a user in your MAAS control panel?
<lazyPower> khuss: in this instance, it would be difficult to discern the bootstrap node, and i'm assuming this is why you're asking - http://i.imgur.com/mWrBIbo.png
<lazyPower> but if you look in your environment's .jenv file
<lazyPower> in $HOME/.juju/environments/env-name.jenv
<lazyPower> there is a line that states state-servers:
<lazyPower> and it has an array of nodes defined as the state server. This is the unit that MAAS gave back to Juju as the bootstrap node during that provisioning request
<khuss> yes.. there are many allocated to the user
<lazyPower> http://paste.ubuntu.com/7530723/ <- it will look similar to that
<lazyPower> it shoudl have a defined hostname, and the public-ip of the unit
<lazyPower> or maybe i've got it backwords and the hostname is the public address, and the ip listed is private - i'm not positive on the order - i do know that it returns more than a single address though.
<khuss> user: "" password: "" state-servers: [] ca-cert: ""
<lazyPower> if neither of those addresses are routeable, your juju status call will fail.
<khuss> in my case, state-servers is set to []
<lazyPower> Looks like it didn't finish provisioning the bootstrap node if there are no state servers defined. Was there any output from your bootstrap?
<khuss> it just came out
<khuss> if i run it now, it says the following:
<khuss>  juju bootstrap ERROR environment is already bootstrapped
<khuss> i think i need to take a step back
<khuss> I've close to 42 servers on this Dell Rack
<khuss> I added them on MAAS
<khuss> and close to 20 of them are allocated to the admin user
<khuss> in fact, I didn't allocate them but I just powered the nodes up and they go allocated to the admin user
<lazyPower> khuss: it may be prudent to add another user to the system so you can discern which nodes are assigned to a 'manual' provisioning system and which are under the control of juju.
<khuss> the names given to these nodes are not resolvable
<lazyPower> s/system/maas/
<khuss> you mean add a juju user in maas
<lazyPower> correct
<khuss> and then just allocate one node to that user?
<khuss> and then do bootstrap again?
<lazyPower> you shouldn't need to do that. the idea is the user's api credentials would handle the allocation, and become immediately identifiable in MAAS if juju is managing the machine.
<khuss> how do I remove the current juju bootstrap
<lazyPower> juju destroy-environment <env>
<khuss> ok..
<khuss> does the name given to node be resolvable for the bootstrap to work
<lazyPower> if it gets fussy with you, add --force
<khuss> in other words, shd I add them in /etc/hosts file
<lazyPower> yes. Juju reaches out over ssh to install the state server components
<lazyPower> you should be able to add your MAAS region controller as a dns provider to your /etc/resolv.conf and those nodes should become resolveable
<khuss> thats a good tip..
<lazyPower> in my case, i added 10.0.10.2 as a nameserver, and set search maas, and everything maas produces is resolveable for me.
<khuss> one more question though.. what does it mean when maas says a node is allocated to admin
<khuss> it is not something that I did manually
<lazyPower> it means that the admin user requested the units power to be on.
<lazyPower> so therefore, nobody else can interact with that machine through maas, its occupied
<khuss> got it.. may be the problem is with the DNS
<lazyPower> if you'ev tried bootstrapping a few times
<khuss> i will destroy the bootstrap
<lazyPower> and none of them have succeeded, the unit is technically allocated in maas, and wont be dallocated - reason being - juju didnt' complete and it *should* have sent a destroy command to maas to return teh machine to the pool.
<lazyPower> if thats not the behavior you're seeing, it may be time to file a bug once we've sussedo ut why you cant resolve your nodes. The networking portion of maas can be tricky at first, it took me a day to figure out my networking for the VMAAS setup i have here.
<khuss> i will try a few things..
<khuss> first, I will fix the DNS
<khuss> so that juju can resolve the names
<khuss> juju is going to pick a node that is allocated to the user right?
<khuss> may be there should be only one of such nodes..
<khuss> could you print your /etc/resolv.conf
<lazyPower> actually no
<lazyPower> khuss: juju will make the request to allocate a node when you issue the bootstrap command
<khuss> ok. that means none of them need to be in the allocated state
<khuss> currently, I've close to 10 in the allocated state
<khuss> is there a way to return them to the pool
<lazyPower> power them down from the maas admin interface
<lazyPower> http://i.imgur.com/26doez3.png
<khuss> ok got it
<khuss> one more thing about the DNS server
<khuss> currently my region/cluster/juju - all in one node
<khuss> this node is not a DNS server
<khuss> it has /etc/resolv.conf pointing to 8.8.8.8
<khuss> do I need to make this as a DNS server for juju to resolve nodes?
<marcoceppi> khuss: maas will setup a DNS server for you
<khuss> marcoceppi: i'm not sure if it did
<khuss> how do I check it
<marcoceppi> your nodes will need to point to it, it however, doesn't nessisarily need to point to it, though you may need to configure the DNS server to forward DNS lookups to another serer (like 8.8.8.8)
<marcoceppi> khuss: is this on 14.04
<khuss> 13.10
<marcoceppi> khuss: hum, there's quite a big difference in the maas versions between 13.10 and 14.04
<lazyPower> khuss: Since you're just getting started it would make a good turning point to go ahead and bump that up to an LTS if you have the option.
<khuss> i could probably do that
<khuss> i can probably do an upgrade.. right
<marcoceppi> khuss: if you do ps -aef | grep bind you should see a running process
<khuss> bind      1339     1  0 May21 ?        00:03:13 /usr/sbin/named -u bind
<khuss> it is running
<khuss> can i upgrade from 13.10 and 14.04
<khuss> without doing a reinstall
<marcoceppi> khuss: of course
<khuss> just do the upgrade using apt-get right?
<marcoceppi> khuss: sudo do-release-upgrade is the best path forward
<khuss> i also had some weird issues with not powering on the nodes.. hopefully the new version will help
<khuss> once I do the upgrade, do I need to rebuild the nodes
<khuss> or can I leave them or do I need to add them again
<khuss> brb
<marcoceppi> khuss: they would probably still be in there
<khuss> marcoceppi: i just updated to 14.04
<sebas538_> marcoceppi: hey! o/
<marcoceppi> hey sebas538_
<marcoceppi> khuss: cool, is maas still running?
<sebas538_> marcoceppi: do you know if constraints are working in local env type?
<marcoceppi> sebas538_: which constraints?
<sebas5384> hardware
<sebas5384> like cpu, mem, etc..
<marcoceppi> Most probably won't work (like arch, mem, cpu, etc) since it's LXC
<sebas5384> :9
<sebas5384> :(
<lazyPower> sebas5384: since LXC uses shared resource, i dont think that would lend itself well to constraints.
<sebas5384> but cgroups isn't for that
<lazyPower> ah, good point. I dont know that we have support for them yet.
<lazyPower> that may be worth asking in #juju-dev to see if that's on the roadmap, already there, et al.
<sebas5384> http://www.mattfischer.com/blog/?p=399
<sebas5384> yeah! i will ask about that
<sebas5384> :)
<sebas5384> https://bugs.launchpad.net/juju-core/+bug/1323446
<_mup_> Bug #1323446: constraints on local provider <constraints> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1323446>
<khuss> marcoceppi: yes maas is still running. will try creating the juju bootstrap
<tvansteenburgh> anyone know of a good example of a python charm that uses charmhelpers but doesn't symlink hooks back to a single python source file?
<khuss> anybody have experience on installing Maas on a Dell PowerEdge
<khuss> I see a problem where the server is not getting powered on when I change the status to "commissioned" from "declared"
<khuss> there is no error message in any of the log files
<Mosibi> khuss: this is a juju channel... but okay... you have entered the ipmi credentials?
<hazmat> tvansteenburgh, not really
<hazmat> tvansteenburgh, there's a few but there not great examples
<tvansteenburgh> hazmat: thanks
<hazmat> sebas5384, so.. i have a jury rigged local provider you could do constraints on..
<hazmat> sebas5384, its actually manual provider, where i create the containers
<hazmat> its not very user friendly.. but its what i use day to day.. https://github.com/kapilt/juju-lxc
<sebas5384> hmmm nice hazmat
<sebas5384> hey hazmat nice work man!
<hazmat> sebas5384, most of the tricks in there have been added to the local provider..
<sebas5384> yeah! nice the lxc-clone for example?
<hazmat> sebas5384, the only real feature delta there is its easy to mod the lxc creation with cgroup constraints.. i've got it modded for apparmor profile selection (nested containers)
<hazmat> sebas5384, yup
<sebas5384> well, hazmat thanks :)
<hazmat> sebas5384, aufs is off by default due to compatiblity issues, but you can enable it via an environments.yaml flag.. btrfs is automatically used if found on /var/lib/lxc
<sebas5384> hazmat++
<sebas5384> hehe
<hazmat> last line re local provider in core
<khuss> i'm having problems in doing juju bootstrap. Could anybody help
<khuss> the bootstrap is failing with the following message
<khuss>  juju bootstrap Launching instance WARNING picked arbitrary tools &{"1.18.3-precise-amd64" "https://streams.canonical.com/juju/tools/releases/juju-1.18.3-precise-amd64.tgz" "c7dee5df130e242c436c43c21278a3f24997d23ca48ee02b93b8126d2f415cd7" %!q(int64=5359855)}  - /MAAS/api/1.0/nodes/node-ce3ce5d8-e1ba-11e3-85bd-b8ca3a5bc3f8/ Waiting for address Attempting to connect to node12.master:22 Attempting to connect to 10.209.0.134:22 ERROR bootst
<cory_fu> Hrm.  I'm having trouble coming up with a good reason to ever do anything in the start hook in a charm.
<cory_fu> Even if you don't have any dependencies on a relation, you're likely going to be re/starting the service in the config-changed hook, so why bother doing anything in start as well?
<marcoceppi> cory_fu: I like to put all the start/restart logic in the start hook
<marcoceppi> cory_fu: then in all my other hooks just call "hooks/start"
<cory_fu> Hrm.  Fair enough
<marcoceppi> it's there to model the event, it may also be called when a unit "wakes up" (in the event ofa suspend)
<cory_fu> Though, a well written charm should set up the services such that a suspend or restart of the instance should bring the service back up, no?
<marcoceppi> cory_fu: depends
<cory_fu> On?
#juju 2014-05-28
<cjohnston> mornin... /15
<AskUbuntu> Unable to access MAAS nodes | http://askubuntu.com/q/473350
<ejat> ERROR bootstrap failed: cannot start bootstrap instance: could not create hosted service: POST request failed: BadRequest - The hosted service is not valid. (http code 400: Bad Request)
<ejat> itry to bootstrap in azure
<ejat> anyone can help me ?
<ejat> $ juju status -e azure
<ejat> ERROR Unable to connect to environment "azure".
<ejat> Please check your credentials or use 'juju bootstrap' to create a new environment.
<ejat> Error details:
<ejat> environment is not bootstrapped
<jcastro> anyone see this? http://manage.jujucharms.com/~fgimenez/precise/cakephp
<lazyPower> jcastro: i saw it in the rev queue yesterday. Looks interesting
<dvr077> \quit
<dpb1> Hi -- how do get this into the charm store? bzr+ssh://bazaar.launchpad.net/~landscape-charmers/charms/trusty/landscape-client/trunk/
<dpb1> I want to be able to do juju deploy cs:trusty/landscape-client and have it work
<khuss> maas is failing to power on sever. I am using Dell PowerEdge. Any ideas on where to look for why this is happening
<dpb1> Right now I get: $ juju deploy cs:trusty/landscape-client
<dpb1> ERROR charm not found: cs:trusty/landscape-client
<dpb1> khuss: look in the /var/log/maas/celery* logs
<dpb1> khuss: iirc
<khuss> i don't see anything in the celery logs
<khuss> iirc?
<khuss> the celery log shows power on request
<khuss> but the server is not powering on
<dpb1> iirc = if i remember correctly
<khuss> got it
<dpb1> khuss: good.  and what did you configure for power settings in the page for this server?
<khuss> IPMI2
<khuss> the power off is working
<khuss> but not power on
<lazyPower> dpb1: you don't have a trusty branch promulgated. There's only a precise branch afaict
<dpb1> lazyPower: how do I get that done?  I have to submit for review?
<lazyPower> dpb1: has anyone reviewed landscape against trusty? I know that when I looked at the precise charm, it was g2g after some minor tweaks. if you just pushed to the landscape-charmers branch of trusty, and it wasn't promulgated into teh store API - it wont show up in the store.
<lazyPower> dpb1: yep. A charmer will need to look at it and ack the branch then promulgate it.
<dpb1> khuss: sec, let me check
<khuss> dbp1: ok
<dpb1> khuss: my next step would be to try 'ipmipower' with the right options.  The script is just a shell script and it's in /etc/maas/templates/power/ipmi.template  You can see the commmands that it sends and try them by hand.
<dpb1> lazyPower: ok, let me put that up then.  We know of no changes necessary for trusty and have been using it there for a while now
<khuss> dbp: sure let me check ipmipower
<dpb1> lazyPower: ok, put up the bug: https://bugs.launchpad.net/charms/+bug/1324163  thanks!
<_mup_> Bug #1324163: Please promulgate landscape-client to trusty <Juju Charms Collection:Fix Committed by davidpbritton> <https://launchpad.net/bugs/1324163>
<khuss> is it possible to have maas server and juju bootstrap server on the same machine
<khuss> i guess i don't understand why we need a separate juju instance for deploying services
<lazyPower> khuss: seperation of concerns. You can achieve what you're looking for if you do run a manual environment. but that quickly gets cumbersome if you're managing > 10 machines.
<dpb1> khuss: no, you cannot.  but you can deploy a service "--to 0" which will put that service on the bootstrap node.
<khuss> dpb1: lets say we have 10 nodes in the MAAS. how to tell juju to use the first node as the bootstrap node
<dpb1> khuss: look at 'juju help constraints'.  You can even do things like "tags=foo", which will allow fine-grained placement, if you need it.
<khuss> can we tag a machine from MAAS and then ask juju to use that machine for bootstrapping
<dpb1> yup
<dpb1> works
<khuss> dpb1: i don't see an option to tag a node from MAAS GUI
<dpb1> khuss: let me check where it's at
<dpb1> khuss: my mistake.  tagging maas nodes is only available through the api (maas-cli package).   'maas <profile> tag -h' will give you more details.
<dpb1> khuss: I personally like to use constraints like memory/cpu/etc if possible.
<khuss> dpb1: thats not very useful when you have homogenous nodes
<dpb1> khuss: agreed
<dpb1> khuss: I actually have a script that adds a tag of the machine name to each node, which allows you to select whatever you like.
<dpb1> khuss: FYI: http://paste.ubuntu.com/7537513/  it's pretty simple
<khuss> dpb1: ok thanks
<khuss> dpb1: found the problem with the ipmi power on issues. The Dell iDRAC is not reachable from MAAS server. There is a networking problem. Thanks for the tip on using ipmipower command
<dpb1> khuss: great.  hit that many times myself. :)
<hackedbellini> I'm writing a charm here that connects to a db relation and provides another one. In that other relation hook, I want to be able to do a 'relation-get' for the properties defined in the db relation. Is it possible? AFAIK, if I do a relation-get inside a xxx-relation-changed, it will get those values for the xxx relation, not the db.
<lazyPower> hackedbellini: you'll have to cache them somewhere on disk on the host, you cannot receive the values from another relation's context through relation-get.
<hackedbellini> lazyPower: hrm, I see. It's exactly that workaround I was trying to avoid =P
<lazyPower> hackedbellini: yeah, i'm sorry I don't have better news for you. I think that's more of a scoping thing than anything else. It's reasonable to say that relationship contexts are isolated though
<hackedbellini> lazyPower: np :)
<lazyPower> hackedbellini: however, if you're using charmhelpers, theres a really nice caching class that just got merged in last week.
<lazyPower> so it makes your cache lookups fairly inexpensive
<hackedbellini> lazyPower: hrm, seems very nice! Where can I find it? I don't know exactly what is charmhelpers, although the name is familiar somehow
<lazyPower> hackedbellini: charmhelpers is a suite of python modules that aid charm creators. Its in the config class, it auto-caches to a dictionary on disk and willc heck there first before pulling data down otw
<lazyPower> tvansteenburgh is the man to talk to about the feature. He proposed it lastweek
<hackedbellini> lazyPower: very nice! I'll take a look at it, lets see if it solves my problems :)
<tvansteenburgh> hackedbellini: this is a good intro to charmhelpers: http://www.youtube.com/watch?v=6kWfLujVwNI
<tvansteenburgh> hackedbellini: and here's the Config lazyPower mentioned, with some sample usage: http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/hookenv.py#L158
<hackedbellini> tvansteenburgh: ahhh cool! I'll take a look at the video. And the example seems very simple! So, I can import charmhelpers directly inside the hook, if I understood correctly? No need to change PYTHONPATH or include anything?
<tvansteenburgh> hackedbellini: yes, you'll need to get it on your path. the video covers a way to do that from within your hooks module
<hackedbellini> tvansteenburgh: nice! Thank you for the links :)
<tvansteenburgh> hackedbellini: you're welcome!
<mhall119> jcastro: where can I get the latest vagrant packages from?
<mhall119> you mentioned the one in the archives is a bit out of date
<jcastro> http://www.vagrantup.com/downloads.html
<mhall119> no PPA?
<jcastro> I don't think so
<mhall119> ok
<jcastro> you only need it until the next ubuntu release, heh
<mhall119> that's what they always say :)
<lazyPower> mhall119: if you're on precise, you'll want to get it from upstream
<lazyPower> otherwise, teh trusty package is only .1 release behind last i checked.
<marcoceppi> mhall119: I tried backporting the trusty vagrant to precise in a ppa, it ended up being a mess
<lazyPower> There's a nice ruby dependency chain there that needs some love
<mhall119> lazyPower: I'm on trusty, but already installed from upstream
<lazyPower> its not a bad idea to use the latest and the greatest. hashicorp is known for making decent products. Their newer stuff with integrated proxy'ing is really nice.
<lazyPower> jcastro discovered it shortly after our last charm school and was demo'ing it to the team. Deploy juju-gui, let other people deploy to your VM environment.
<khuss> i've only one environment setup in juju but the juju status gives the following message
<khuss> ERROR Unable to connect to environment "". Please check your credentials or use 'juju bootstrap' to create a new environment.  Error details: environment is not bootstrapped
<khuss> it doesn't show the environment name
<marcoceppi> khuss: what does juju switch say?
<khuss> marcoceppi: juju switch says "maas"
<khuss> marcoceppi: which is the enviornment name
<khuss> marcoceppi: i did juju bootstrap -e maas
<khuss> marcoceppi: it is doing the power cycle of the blade and going thru the install
<marcoceppi> khuss: is the node on right now?
<marcoceppi> it might still be bootstrapping
<marcoceppi> how long ago did you run the bootstrap
<marcoceppi> can you ssh in to the machien?
<khuss> marcoceppi:  it failed the first time and I just started it again
<khuss> marcoceppi: this is what I got at the first time - curl: (7) couldn't connect to host tools from http://localhost:80/MAAS/api/1.0/files/?key=aedd9246-e6a1-11e3-af69-b8ca3a5bc3f8&op=get_by_key downloaded: HTTP 000; time 0.000s; size 0 bytes; speed 0.000 bytes/s ERROR bootstrap failed: rc: 1 Stopping instance... Bootstrap failed, destroying environment
<khuss> marcoceppi: i did resync-tools and then just tried the bootstrap
<marcoceppi> khuss: your mass might not be configured properly. it shouldn't say localhost for URLs
<khuss> marcoceppi: i did that configuration because the cluster controller is on the same machine.. shd I give the IP address instead
<marcoceppi> khuss: definitely, you can run sudo dpkg-reconfigure maas-region-controller to set the IP address again
<khuss> marcoceppi: do I need to reconfigure the region-controller? it is just on the juju environment file right? What if i change from localhost to the ip of the machine
<marcoceppi> khuss: OH, this is in your environments.yaml
<khuss> marcoceppi: yes
<marcoceppi> that should be fine
<marcoceppi> misunderstood
<khuss> marcoceppi: let me see how the bootstrap goes this time..  i tried curl on that link (in the error message above) and it didn't work
<marcoceppi> khuss: well it'll probably give you a new bucket id
<khuss> marcoceppi: failed again. 2014-05-28 20:20:03 INFO juju.cmd supercommand.go:302 running juju-1.18.3-precise-amd64 [gc] 2014-05-28 20:20:03 DEBUG juju.agent agent.go:384 read agent config, format "1.18" 2014-05-28 20:20:03 DEBUG juju.provider.maas environprovider.go:30 opening environment "maas". 2014-05-28 20:20:03 ERROR juju.cmd supercommand.go:305 Get http://localhost:80/MAAS/api/1.0/nodes/?agent_name=b4a4c73b-29e3-4333-8e0b-8f82074896
<marcoceppi> khuss: set that to the IP address that both you and the machines can get to
<marcoceppi> khuss: once you do that, run `rm ~/.juju/environments/maas.jenv`
<marcoceppi> then sync-tools
<marcoceppi> then do a bootstrap
<khuss> marcoceppi: ok
<khuss> marcoceppi: docs http://maas.ubuntu.com/docs/juju-quick-start.html seems to be wrong.. juju ---sync-tools doesnt work.. "juju sync-tools" does
<marcoceppi> khuss: thanks for the heads up! I'll file a bug
<khuss> marcoceppi: np
<khuss> marcoceppi: bootstrap completed without error. however, juju status gives this error - ERROR state/api: websocket.Dial wss://1-10-2.master:17070/: dial tcp: lookup 1-10-2.master: no such host
<khuss> marcoceppi: may be a DNS problem?
<khuss> marcoceppi:  juju status still doesn't work
<khuss> marcoceppi: actually it worked after adding the host to /etc/hosts.. may be there is a better way to use the local DNS server
<lazyPower> khuss: have you added the maas master node to your /etc/resolv.conf along with a search declaration for the local domain? in this case it appears to be search 'master'
<lazyPower> without quotes
<khuss> lazyPower: no i've not .. let me try that
<khuss> lazyPower: i added it on the /etc/resolv.conf.. looks like i need to edit some other files in Ubuntu
<lazyPower> khuss: it wont persist past a reboot
<lazyPower> if it works, then add it to /etc/resolve.conf.d/head (i think) and it should fix you up and persist after a reboot.
<khuss> lazyPower: ok. thanks
#juju 2014-05-29
<designated> do juju charms have a way to bond network interfaces?
<hsawhney1234> Hi I am trying to run a juju charm on my private openstack cloud but I get the following error
<hsawhney1234> cannot start bootstrap instance: cannot allocate a public IP as needed: failed to allocate a floating ip
<hsawhney1234> any idea what I need to do.
<hsawhney1234> ?
<hsawhney1234> the error returned is
<hsawhney1234> cannot start bootstrap instance: cannot allocate a public IP as needed: failed to allocate a floating ip
<hsawhney1234> returned unexpected status: 404; error info: {"itemNotFound": {"message": "FloatingIpPoolNotFound: Floating ip pool not found.", "code": 404}}
<bloodearnest> marcoceppi: am i right in understanding that there's no way to fake/double relations with amulet? i.e. if you have a mongodb relation, you have to deploy mongodb and relate to your charm in order the the sentries to be able to inspect relations?
<marcoceppi> bloodearnest: at the moment, yes, you have to deploy mongodb
<bloodearnest> marcoceppi: kk, thanks
<rbasak> fwereade: a bit late, sorry, but I just remembered that I was supposed to poke you about a 1.18 release (or somebody, anyway). I think James asked about this last week. Do we have a schedule?
<fwereade> rbasak, hmm, not sure about another 1.18, what did you need for that?
<rbasak> fwereade: Utopic needs the latest commits to work, and we need to upload that to push those fixes back to Trusty.
<fwereade> rbasak, ok, would you raise that on the call please? nate is there and should be able to handle the tech side
 * fwereade dashes
<rbasak> Will do. Thanks!
<bloodearnest> marcoceppi: having issues using amulet to deploy local charms
<bloodearnest> marcoceppi: aaaand now it works. ignore me, sorry for the noise
<bloodearnest> marcoceppi: ah, no, I am getting failures. Am doing d.add('name', '/path/to/charm') but deployer is giving me this error
<bloodearnest> AttributeError: 'NoneType' object has no attribute 'branch'
<arosales> tvansteenburgh: have you seen bloodearnest's issue in latest amulet?
 * tvansteenburgh reads
<tvansteenburgh> bloodearnest what version of amulet?
<bloodearnest> tvansteenbur.5.0-0ubuntu1~ubuntu14.04.1~ppa1gh:
<bloodearnest> bah
<bloodearnest> tvansteenburgh: 1.5.0-0ubuntu1~ubuntu14.04.1~ppa1
<bloodearnest> tvansteenburgh: I am trying to deploy 3 local charms (they are not public charms)
<tvansteenburgh> bloodearnest your bug is fixed in the 1.5.1 milestone: https://launchpad.net/amulet/+milestone/1.5.1
<bloodearnest> tvansteenburgh: right, will it hit the ppa anytime soon?
<tvansteenburgh> sorry, only marcoceppi can answer that. i only fix the bugs, he releases :)
<bloodearnest> tvansteenburgh: I will try with the 1.5.1 tag from github, thanks!
<arosales> tvansteenburgh: thanks for the answer. bloodearnest when marcoceppi returns he should be able to answer on date of next release
<bloodearnest> tvansteenburgh: hmm, my charm is in version control, fwiw, bzr
<bloodearnest> ah, but some of the others are not yet
<bloodearnest> arosales: thanks for the prod :)
<bloodearnest> tvansteenburgh: fyi, that gets me further, but then I get this: http://paste.ubuntu.com/7545136/
<Marek1211> how do I know which charms should be related to wchich ones..? In the GUI it gives me suggestion which charms I CAN link to which so should I just make as many links as I can? Its openstack deployment.
<tvansteenburgh> bloodearnest: looking
<lazyPower> Marek1211: there's a bundle that will give you the deployment map of a simple openstack cluster, 1 moment while i fish that up
<lazyPower>  bundle:~makyo/openstack/2/openstack
<lazyPower> or: https://jujucharms.com/sidebar/search/bundle/~makyo/openstack/2/openstack/?text=openstack
<tvansteenburgh> bloodearnest: humor me and try deleting /tmp/charm_pf_xiam/ and try again
<bloodearnest> tvansteenburgh: doing that, but I got it a few times
<bloodearnest> with different tmp dirs
<tvansteenburgh> bloodearnest: ok, then i'll need to repro and fix
<bloodearnest> am  digging in to it
<tvansteenburgh> bloodearnest: cool, thanks
<Marek1211> thank lazyPower I have already deployed my environment and looks like on the pic in the link. I made as many relations as possible but was wondering if this is the right way to do it...
<Marek1211> https://dl.dropboxusercontent.com/u/105701583/juju.PNG
<lazyPower> i dont see anything inherently wrong with that... but i'm not an authority on teh openstack deployments
<tvansteenburgh> bloodearnest: i think i found the problem
<tvansteenburgh> bloodearnest: if you're running from source now, try changing this line: https://github.com/tvansteenburgh/amulet/blob/master/amulet/charm.py#L135
<tvansteenburgh> to:
<tvansteenburgh> temp_charm_dir = os.path.join(d, os.path.basename(os.path.dirname(path)))
<bloodearnest> tvansteenburgh: trying it now
<bloodearnest> tvansteenburgh: hmm. so now I'm getting the orginal error again
<tvansteenburgh> bloodearnest: weird, didn't expect that
<bloodearnest> yep, is odd
<bloodearnest> tvansteenburgh: I gotta eod, will dig some more tomorrow
<Marek1211> Is it possible to Autoscale with Juju ?
<natefinch> Marek1211: not automatically, no
<natefinch> Marek1211: it's something we'd like to support eventually, but it's a tricky problem, mostly around knowing when you *need* to scale up/down.
<Marek1211> Okay, thanks :) doing a school project on juju+openstack, wanted to make sure, thanks!
<sebas5384> natefinch: landscape don't integrate with juju charms to scale?
<natefinch> sebas5384: nope
<sebas5384> damn
<natefinch> sebas5384: there's no integration between landscape and Juju
<sebas5384> hehe
<sebas5384> would be nice to have... :)
<AskUbuntu> How can build relation between Rabbitmq-Server (as buffer for request interface) for my owm locla charm( process the requests) | http://askubuntu.com/q/474097
<sebas538_> what must be done to have more than on local environment running at the sametime?
<sebas538_> i already changed the storage-port
<sebas538_> but i'm geting "ERROR cannot use 37017 as state port, already in use"
<designated> is anyone aware of juju charms for openstack services that would support multiple interfaces as well as bonded network interfaces with vlan tagging?
<AskUbuntu> Ubuntu MAAS Setup - Newbie - adding nodes | http://askubuntu.com/q/474140
<steinm> Anyone know how I can use the constraints to define the size of the root-disk foe EC2?
<steinm> For what I understand the following should be possible also for EC2 "juju deploy --constraints "root-disk=16384M" mysql", but I get a '(error: no instance types in us-east-1 matching constraints "cpu-power=100 root-disk=16384M")'
<steinm> Any suggestions ?
#juju 2014-05-30
<AskUbuntu> How can I get the file from local server on my intranet instead of internet in hook install | http://askubuntu.com/q/474178
<vbn> http://vk.com/away.php?to=http%3A%2F%2Fhaxxjp.net
<vbn> https://zhovner.com/tmp/killwebkit.html hack for TELE
<sarnold> vbn: ?
<vbn> ?
<vbn> http://vk.com/club43237732
<vbn> paludis/monkey/arachnist ddos
<vbn> http://vk.com/videos-43237732?z=video-43237732_168162885%2Fclub43237732
<vbn> H@h@H@H@Hh2
<vbn> porno
<sarnold> perhaps you're not where you think you are.
<sarnold> info #juju
<bloodearnest> tvansteenburgh: fyi, after the tmpdir change, this is what I get: http://paste.ubuntu.com/7550440/
<bloodearnest> tvansteenburgh: what's doubly odd is that I have added local bzr repo to the two charms that didn't have it
<mthaddon> can anyone help with a local provider issue? http://paste.ubuntu.com/7550592/
<vbn> porno
<vbn> porno
<tvansteenburgh> bloodearnest: hey, just starting my day
 * tvansteenburgh reads pastes
<bloodearnest> tvansteenburgh: no problem, I'm switching to another task for now, but let me know if you need me to test anything
<tvansteenburgh> bloodearnest: cool, will do. should be fairly easy to repro locally (i hope)
<bloodearnest> tvansteenburgh: fwiw, the 2 "inverse" charms are autogenerated from the charm-under-test's metadata.yaml, in order to only have to deploy 1 extra unit rather than n when testing.
<bloodearnest> and to reduce external dependency count
<tvansteenburgh> bloodearnest: are you running HEAD from marcoceppi/amulet?
<bloodearnest> tvansteenburgh: yes, installed via pip3 install --user git+git://github.com/marcoceppi/amulet.git
<tvansteenburgh> ok thanks
<marcoceppi> sounds like we have a bug, also, we should do another release
<bloodearnest> tvansteenburgh: only diff is that one line patch you said yesterday
<tvansteenburgh> okay
<bloodearnest> mthaddon: I've seen that a few times in local on trusty. The juju state server stops taking connections. A destroy and rebootstrap usually fixes, but don't know the root cause. I think I saw a bug on it somewhere...
<mthaddon> bloodearnest: thx, will try looking for a bug report
<tvansteenburgh> bloodearnest: when you have a min, undo the patch from yesterday and try this instead (works for me): http://pastebin.ubuntu.com/7551446/
<bloodearnest> tvansteenburgh: ok
<bloodearnest> tvansteenburgh: \o/
<bloodearnest> tvansteenburgh: I still got an error, but that was in my charm
<tvansteenburgh> bloodearnest: suhweet.
<tvansteenburgh> bloodearnest: i'll get a PR submitted for this
<bloodearnest> tvansteenburgh: is odd, I did try with an explicit abs path, but maybe that was before trying HEAD
<tvansteenburgh> yeah, you may have run into the vcs problem prior to being on head
<khuss> marcoceppi: i am getting error error: cannot run instances: gomaasapi: got error back from       server: 409 CONFLICT (No matching node is available. while running juju status
<khuss> nodes are in the ready state
<bloodearnest> marcoceppi: tvansteenburgh: so, next hurdle - I am trying to use amulet to deploy a "fat charm" that requires a build step before deploying
<bloodearnest> I tried running the build step before running amulet, but it seems that if amulet finds a bzr repo in the charm, it checks out the latest revision, rather than copying the directory with it's local changes?
<tvansteenburgh> bloodearnest: i think it's deployer doing that, not amulet (not that is solves your problem)
<hazmat> bloodearnest, deployer will do buildsteps automatically..
<bloodearnest> tvansteenburgh: ah, right. But we use deployer to do exactly that in production deploy
<hazmat> bloodearnest, if you have a build hook
<bloodearnest> hazmat: we have a "make charm-payload" convention
<bloodearnest> hazmat: are there docs on build hooks
<hazmat> bloodearnest, build: path_to_script in each service
<hazmat> er in each charm
<hazmat> bloodearnest, not really re docs.. it was a feature add from your team a while back afaicr
<hazmat> ported over from pyjuju days
<bloodearnest> hazmat: really? I never heard of it
<bloodearnest> maybe from is
<bloodearnest> IS
<hazmat> bloodearnest, tvansteenburgh that does sound like an amulet issue wrt
<hazmat> bloodearnest, oh.. yeah. from is
<hazmat> sorry mixed streams
<bloodearnest> hazmat: makes sense, but we still didn't know about it. It's a really good idea, will start to use it
<bloodearnest> hazmat: so, the the charm's metadata needs a build: step?
<hazmat> bloodearnest, if you skipped the make charm-payload  and had a build script that does the same ref' it from your deployer config you'd be good
<hazmat> but amulet's generating deployer config, so have to patch amulet
<hazmat> bloodearnest, yup
<hazmat> bloodearnest, not exactly..
<hazmat> bloodearnest, each service referencing a charm in a deployer config, needs a build: relative_path_in_charm
<hazmat> which specifies an exec to call to build the charm
<hazmat> ie. its deployer config not charm metadata.
<bloodearnest> hazmat: amulet supports loading a deployer config, which it then modifies with the sentries as needed AIUI
<bloodearnest> hazmat: right
<hazmat> bloodearnest, you can also use db inspect plugin.. to bypass the need for sentries entirely..
<bloodearnest> hazmat: do you still need an actually deployed service to relate your charm to when using db plugin? Or can it fake the whole relation?
 * bloodearnest would love to be able to fake relations
<hazmat> bloodearnest, no you need the actual relations
<hazmat> bloodearnest, fake for speed?
<bloodearnest> hazmat: yeah
<hazmat> bloodearnest, lxc + btrfs + apt-http-proxy is the speediest combo atm
<hazmat> er.. s/lxc/local
<bloodearnest> hazmat: yep, that's what I'm running
<tvansteenburgh> bloodearnest: fwiw if you want to use Deployment.load() in amulet right now, you'll have to use https://github.com/tvansteenburgh/amulet/tree/lp-1324272
<tvansteenburgh> fixes queued up here: https://github.com/marcoceppi/amulet/pull/36
<bloodearnest> tvansteenburgh: thanks, good to know
<hazmat> tvansteenburgh, so what's the value add of amulet?
<bloodearnest> hazmat: but a bootstrap/deploy/settle/test/destroy-environment per test adds up
<hazmat> bloodearnest, oh.. that's test framework idiocy
<hazmat> bloodearnest, i've patched to just do juju-deployer -TW
<hazmat> which saves the bootstrap node
<bloodearnest> hazmat: nice
<bloodearnest> hazmat: which reminds me - juju-deployer defaults to the use the default juju api port, but if you have multiple local environments, with non-standard api server ports, is there a way to tell juju this?
<bloodearnest> s/tell juju/tell juju-deployer/
<hazmat> bloodearnest, which version of deployer you using?
<hazmat> bloodearnest, latest versions of deployer detect all of this correctly..
 * hazmat wonders if it did before anyways.. 
<hazmat> it was parsing the jenv file for the exact state server address and port
<bloodearnest> 0.3.6, from stable ppa
<bloodearnest> on trusty
<hazmat> 0.3.8 is latest stable in pypi.. i don't generally push to ppas. there's a daily recipe though
<bloodearnest> will try from pypi
<bloodearnest> hazmat: installing 0.3.8 with pip install --user -U juju-deployer, I get:
<bloodearnest> ImportError: cannot import name ErrorExit
<hazmat> intersting
<hazmat> bloodearnest, full traceback pastebin?
<hazmat> bloodearnest, just did it in a virtualenv.. works fine
<bloodearnest> hazmat: http://paste.ubuntu.com/7552241/
<hazmat> bloodearnest, i get http://pastebin.ubuntu.com/7552245/
<hazmat> bloodearnest, likely your package versions are interferring
<hazmat> bloodearnest, that's why i'd recommend a virtualenv
<bloodearnest> yeah, just tried in venv, got a different error, no bzrlib
<bloodearnest> this is fresh trusty vm, so could be missing some base stuff
<hazmat> bloodearnest, re bzrlib.. you have to install bzr separately due to new pip insanity..
<hazmat> bloodearnest, pip install bzr --allow-external bzr --allow-unverified bzr
<bloodearnest> yeah
<hazmat> there's an extant bug for that one against deployer.. its a bit lame though.
<hazmat> i'm hoping this will fix the pip insanity.. http://lwn.net/SubscriberLink/599793/a595880fa4546f4c/
<hazmat> either that or we get bzr uploaded to pypi
<bloodearnest> hazmat: et voila. Will use this env for further testing, thanks
<hazmat> bloodearnest,fwiw  re test without reboot lp:~hazmat/charm-tools/dont-waste-my-time
<rbasak> mgz, sinzui: did you say that bug 1320891 shouldn't be able to happen again? Or is it exactly the same as the external dependency change/availability issue?
<_mup_> Bug #1320891: make-release-tarball.bash fails with godeps failure <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1320891>
<sinzui> rbasak, it is less likely to happen
<sinzui> rbasak, since we go over the network to get deps. a failure can always happen and it will fail because there are unmet deps
<rbasak> sinzui: OK, so let's say that in the future we eliminate the network failure possibility by caching all dependencies locally. In this case, is it possible that something like bug 1320891 could recur, or is that fixed now?
<_mup_> Bug #1320891: make-release-tarball.bash fails with godeps failure <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1320891>
<sinzui> rbasak, locally for whom?
<rbasak> sinzui: whoever is running make-release-tarball.bash
<sinzui> rbasak, understood. there are several competing projects try to solve go's love ovf tip
<sinzui> rbasak, the issue remains that if you have never run the script before, you don't have a cache. As I/jenkins are origins of source packages, do you mean that we should be using a cache?
<rbasak> sinzui: I think so, yes. We should (in the long term) maintain a cache somehow, whether that is via a vendor branch or something else.
<sinzui> rbasak, yeah, go wont accept that
<rbasak> If I then wanted to run make-release-tarball.bash myself, I'd be able to (ideally) get access to that same cache.
<mgz> we could just generate tarballs on jenkins...
<sinzui> though I have used proxies and falsified certs to make that happen on closed networks
<rbasak> This is basically what we have already in the Debian world of source packages and build dependencies.
<rbasak> (but that doesn't apply to go here because of how it is different)
 * sinzui is not saying he is proud of that, but putting together a https file server claiming to be someone else to make juju work is awesome
<rbasak> :)
<mgz> sinzui: what do I still need to do to plug in all the git builder bits...
<sinzui> A script that calls or sources the make-release-tarball script, then calls the run-unit-tests script
<mgz> sinzui: I can just do that in place in the job, right?
<mgz> and I set up the gui tool on the cron
<mgz> sinzui: I'll get to it.
<sinzui> you can to prove what you want to do. I think a proper script can be written later (version controlled)
<jose> arosales, mbruzek: ping
<mbruzek> jose, we are just finishing up our other meeting.
<jose> np
<arosales> jose: sorry on my way
<james_w`> hi
<james_w`> I have a local juju env, and one of the units has started failing
<james_w`> it's failing to talk with 127.0.0.1:37017
<james_w`> what is supposed to be running there?
<sebas5384> james_w`: mongodb i think...
<sebas5384> jcastro: do you know what else than change the storage port is needed to bootstrap more than one local env?
<sebas5384> can't find anything more about that
<jcastro> I believe we don't specifically support multiple local environments
<jcastro> james_w`, do all subsequent units also fail to talk? or just the one?
<sebas5384> jcastro: oh... i see..
<jcastro> sebas5384, I know some people have gotten it to work
<jcastro> sebas5384, but it seems to be very "here be dragons"
<jcastro> sebas5384, I think splitting it into say, 2 VMs with one LXC environment in each would be cleaner
<sebas5384> jcastro: hehe i imagine is not an easy task
<sebas5384> jcastro: tell me more about that, so you are talking about having one vm with the juju(client) and in the other vm the lxc ?
<sebas5384> that's possible???
<sebas5384> because that would be really awesome, like having a juju-remote thingy hehe
<jcastro> no I mean 2 vm's, and inside you have the LXC containers
<jcastro> but they'd be 2 different environments
<jcastro> so like, take 2 vagrant boxes ... with the LXC containers in each one
<sebas5384> so a vm for each juju-local?
<sebas5384> ok
<jcastro> yeah
<sebas5384> jcastro: in the doc haves something like "Override the shared storage port if you have multiple local providers, or if the default port is used by another program."
<khuss> juju status shows error: cannot run instances: gomaasapi: got error back from       server: 409 CONFLICT
<khuss> the nodes are in ready state
<jcastro> sebas5384, yeah that conflicts with what thumper told me as to what they support.
<sebas5384> jcastro: http://askubuntu.com/questions/470917/can-i-have-multiple-local-juju-environments
<jcastro> sebas5384, can you ask on the list what the status of support is on multiple local providers?
<sebas5384> i'm trying that approach
<jcastro> ok
<sebas5384> jcastro: of course :)
<jcastro> also, we're having the Ubuntu Online Summit in 2 weeks
<sebas5384> uhuu
<sebas5384> where?
<jcastro> if you want to join in on the hangouts, we're going to do like a bunch of classes, etc.
<jcastro> it'll be online, on g+ and here
<sebas5384> great!! jcastro i'll be online then
<sebas5384> jcastro: if there's any thing i can help :)
<jcastro> I'm sending an announcement to the list
<jcastro> sebas5384, yeah people can submit sessions for whatever they want, I'll put the instructions in the email
<sebas5384> some folks here are now using the drupal charm with a juju-local :)
<sebas5384> great! i will be waiting the info
<khuss> has anybody seen this error message while trying to deploy a service?
<khuss> RROR 2014-05-30 13:26:36,274 maasserver ################################ Exception: No matching node is available. ################################ ERROR 2014-05-30 13:26:36,274 maasserver Traceback (most recent call last):   File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 112, in get_response     response = wrapped_callback(request, *callback_args, **callback_kwargs)   File "/usr/lib/python2.7/dist-packages/dj
<james_w`> jcastro: it appears to have spread to all units
<james_w`> (sorry, had to dash to the dentist)
<james_w`> I thought mongo would be run on the bootstrap machine, rather than each individual unit
<arosales> Juju is a finalist at IBM's App ThrowDown
<arosales> http://ibmappthrowdown.tumblr.com/
<arosales> feel free to browse the selctions and cast your vote
<sebas538_> more than one juju-local running in the same machine, hell yeah!
 * sebas5384 is happy
<designated> does anyone know if juju charms have a problem accepting a bonded, vlan tagged interface as opposed to something like eth0?  I created a 2x10Gbe bond with 802.1q tagging, will referencing bond0.10 for example, present a problem for charms?
<sebas538_> hey!
#juju 2014-05-31
<sebas538_> somebody used juju-nat ?
<sebas538_> cmars: ping
<sebas5384> cmars: juju-nat can be used to expose ports from a service through the host machine? let's say a virtualbox(host machine)
<cmars> sebas5384, yes
<cmars> sebas5384, how do you have virtualbox set up as a host? manual provider?
<cmars> or are you using the local provider inside vbox?
<sebas5384> cmars: juju-local
<sebas5384> im using lxc on the host
<cmars> sebas5384, i'm not sure if juju-nat will work in that setting, though I've not tested juju-nat with local (I typically deploy into lxc containers with the manual provider or cloud providers)
<sebas5384> cmars: hmmm gotcha
<sebas5384> well i teste with a juju-local, and tried to expose the ports of a service through the host machine(vbox)
<sebas5384> but didn't work :P
<sebas5384> would it be cool to have a tool like that
<sebas5384> do you think that your plugin can be extended to meet that feature?
<cmars> sebas5384, indeed. the iptables commands would be similar. the tricky part is the way vbox networking is usually set up
<sebas5384> yeah
<cmars> bridging or the host-only interfaces would have to be used
<sebas5384> but i'm already exposing 80 and 443 in using vagrant :)
<cmars> ah, they've certainly figured that out... good point. there should be a way then
<cmars> sebas5384, i'll have to play with vbox
<sebas5384> yeah, i was using something like "iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.0.3.170:80"
<sebas5384> but that rule was breaking some things hehe
<cmars> juju-nat specifies -d DEST and the interface, see https://github.com/cmars/juju-nat/blob/master/cmd/common.go#L104
<sebas5384> i was there, trying to understand hehe
<sebas5384> hmmm
<sebas5384> so you specify the interface, never tried that
<cmars> pretty sure it shouldn't be the default vbox NAT one
<sebas5384> yes
<sebas5384> eth2
<sebas5384> so an interface parameter in the juju-nat
<sebas5384> maybe would fix that problem
<sebas5384> :)
<sebas5384> cmars: juju nat-expose drupal/0 --interface eth2
<sebas5384> just saying hehe
<cmars> sebas5384, i might be able to do a bit better. detect if we're using the local provider, and then require an interface (if I can't figure out a way to autodetect one)
<sebas5384> cmars: what you think?
<sebas5384> hmmm
<sebas5384> nice
<sebas5384> liket that
<sebas5384> *liked
<sebas5384> cmars: i'm cloning here the project from git :P
<sebas5384> just for playing, btw thank you for this tool!
<cmars> sebas5384, https://github.com/cmars/juju-nat/issues/5
<cmars> sebas5384, thanks :)
<sebas5384> nice!!
<sebas5384> cmars: i don't know go lang, but, do you think i can do it?
<sebas5384> or its toooo easy for you
<sebas5384> hehe
<cmars> sebas5384, golang is pretty easy to pick up, though it might become contagious to write
<sebas5384> cmars: hehe contagius? what you mean?
<cmars> sebas5384, some developers can't stop writing in it once they start
<sebas5384> hahahhaa
<cmars> habit-forming, i should say
<sebas5384> nice, like that kind of lang
<sebas5384> cmars: well I will try to make that happen
<sebas5384> if i cant do it, can i ping you?
<cmars> sebas5384, certainly
<sebas5384> great! thanks cmars!
<sebas5384> cmars: ping
<AskUbuntu> Running Openstack on 3 nodes | http://askubuntu.com/q/474911
<s3an2> Hi, is there a reason when deploying the ubuntu juju charm using the MAAS provider br0 is added instead of just using eth0?
#juju 2014-06-01
<rmb938_> I am trying to setup juju with openstack and I am having an issue bootstrapping in. It gets this error: cannot allocate a public IP as needed: failed to allocate a floating ip caused by: Resource at http://controller:8774/v2/2469f191c2b445b9a57642e386b971b0/os-floating-ips not found which doesn't make sense because I can use nova to view floating ips perfectly fine and it uses the same url
<gh0st> Hello
<gh0st> I have a problem with charm relation i juju
<gh0st> is someone know this platform very well?
#juju 2015-05-25
<jose> jcastro: hey! just to confirm, office hours this Thu?
<marcoceppi> jose: it's a holiday in the states today, I don't think jcastro is around
<jose> oh, well
<jose> marcoceppi: just to confirm, we're having office hours on Thu?
<jose> wanna check my schedule to see if I can host
<aisrael> jose: I see it on my calendar, from 4-5pm est
<aisrael> jose: on Thursday
<thomi> Hi - it seems juju-deployer adds ssh keys to ~/.ssh/known_hosts, which means that from time to time it sees a key mismatch when we tear down an old deployment, and happen to deploy to a new instance with the same IP address. Does that sound plausible?
<thumper> yes
 * thomi files a bug
<thomi> thumper: https://bugs.launchpad.net/juju-deployer/+bug/1458693 I'll buy whoever fixes it a beer, if you're in the same city as me
<mup> Bug #1458693: juju-deployer fills up ~/.ssh/known_hosts <juju-deployer:New> <https://launchpad.net/bugs/1458693>
#juju 2015-05-26
<jose> aisrael: gotcha, thanks!
<thomi> thumper: does 'juju destroy-service <foo>' call the 'stop' hook for the service's juju charm?
<thumper> thomi: by default, I think yes
<thomi> hmmm
<thomi> thumper: ...and 'juju destroy-service <foo>' should block until the 'stop' hook has finished, right?
<thumper> no
<thomi> oh?
<thumper> nothing blocks
<thumper> except bootstrap
<thomi> ahhh, well that might explain something
<thomi> thumper: is there a way to call a charms 'stop' hook from within a deployed unit? I'm seeing some odd things where calling 'service stop <foo>' does something different to asking juju to destroy the service
<thumper> from the client do this:
<thumper> juju run --unit=foo/2 'hooks/stop'
<thomi> ahh, thanks
<thomi> ok, problem solved. Turns out if your charm is missing relation-departed and relation-broken hooks (even though this charm doesn't use relations), 'juju destroy-service' won't shut down the service nicely... confusingly, 'juju debug-hooks stop' shows the stop hook getting called. I have no idea what's going on, but happy that I found a reproducible way to get things back into a sane state.
<Zetas> i've got my openstack infra stood up and connected, everything is green across the board and i can login to horizon
<Zetas> but im trying to make sure my changes to the ceilometer charm are working and im not sure how to force it to log something to the database
<bloodearnest> hmm, any idea why I might be getting a permssion denied error running relation-get from inside a juju-run environment?
<bloodearnest> specifically:
<bloodearnest> relation-get --format=json -r db-admin:42 - updown-app/0
<bloodearnest> some context: I previously added/removed the db-admin relation to perform a db migration
<bloodearnest> if I juju run again, it works
<lovea> users
<lovea> Trying to use JUJU with aprivate Openstack cloud
<lovea> All the Openstack endpoints, e.g. keystone and swift and nov-cloud-controller have IP addresses belonging to a management network. The juju bootstrap process fires up a juju-state-machine-0 but this is on the private tenant network and cannot see the management network endpoints. Bootstrap fails with connection errors. Any ideas?
<mattyw> lazyPower, ping?
<lazyPower> mattyw: pong
<mattyw> lazyPower, hey hey, hope you're well... The mongodb charm. If I deploy 1 unit, relate it to my charm. Then add some units to mongo at a later date it should still setup a replicaset right?
<lazyPower> mattyw: correct, i would test in a staging env however
<lazyPower> i haven't looked at mongo in quite some time
<lazyPower> i'm not even sure if we've upgraded to deploy the 3.x series
<mattyw> lazyPower, ok thanks
<lazyPower> Hmm.. do we not have access to unit-get in action context?
<lazyPower> i take that back, we do when i'm in debug hooks
<lazyPower> marcoceppi: tvansteenburgh aisrael - is there a pattern for calling actions from amulet? eg: i have a health check action, and i''d like to flex it in an amulet test. is our path forward for now to just subprocess call it and parse the output of the uuid? or is there a branch w/ action helpers pending?
<marcoceppi> lazyPower: there is not a mechanism yet in amulet
<marcoceppi> I'll open a feature request for it
<lazyPower> ok, i figured that might be the case. Thanks for the confirmation
<lazyPower> http://paste.ubuntu.com/11373549/
<lazyPower> however that is silly nice to have, at a glance health check until we get the actual health-check hook
<marcoceppi> lazyPower: we've talked a bit more about health and we're shying away from actions tbh
<lazyPower> marcoceppi: considering its a stop-gap fix until the hooks are impl, whats the issue w/ an action?
<lazyPower> just curious
<marcoceppi> lazyPower: well it's not a wholistic view of health, which is what you really want, it's just a snapshot. cory_fu and I (and others) talked about using a monitoring relation instead for this
<lazyPower> well, thats a fair statement in 80% of services out there. YOu're polling for a snapshot of a single units health vs the cluster - whereas this is a builtin of the service.
<lazyPower> etcdctl does introspection of the cluster and reports a sanity check essentially - this is like the benchmark to figure out if your cluster is even configured properly
 * marcoceppi nods
<lazyPower> but most services wont have something like this, so yeah - 100% understood
<lazyPower> and i agree w/ that statement too
<tvansteenburgh> hazmat: are we on for 4pm today?
<hazmat> tvansteenburgh: yup
<lazyPower> yo yo hazmat o/
<hazmat> lazyPower: greetings!
<lazyPower> glad to see you're still kickin over there :)
<jose> hey guys, any idea when that hvm patch for aws t2.micros is landing?
<lazyPower> jose: i haven't heard anything about it yet
<jose> lazyPower: huh. I saw the mp being approved on gh
<jose> or, well, as you call it on gh, pr
<lazyPower> seems like you know more about it than I do
<lazyPower> if you're using the nightly docker container, should be able to test it now
<lazyPower> or you can fetch/compile if you're opposed to using the container
<jose> I'll check.
<lazyPower> hmm... getting an interesting error when attempting to bzr branch lp:charm-helpers -  http://paste.ubuntu.com/11374382/
<aisrael> lazyPower: I get the same error
<lazyPower> marcoceppi: have we updated charm-helpers repo with anything? or is this a breaking change introduced in bzr?
<jose> that issue should be there if the branch is set to be private, but it's public...
<jose> lazyPower, aisrael: seems to be a LP error. getting it with another branch
<lazyPower> thanks for confirming jose
<marcoceppi> thats' weird
<marcoceppi> lazyPower: what did you do to achieve this?
<jose> marcoceppi: general LP error
<lazyPower> marcoceppi: it appears to be an outage spurned by a launchpad rollout that just hit about 20 minutes ago
<lazyPower> marcoceppi: see #is-outage, they're on it.
<aisrael> Seems to be working now
<lazyPower> aisrael: weird, still broken for me
<jose> ^
<lazyPower> must have a sweet canadian LP mirror thats got the fix
 * lazyPower is instantly jealous
<lazyPower> jose: try now, appears to be resolved for me
<jose> +1
<jose> thanks for the heads up
<tvansteenburgh> dpb: can you meet at 3:30 instead of 4?
<tvansteenburgh> dpb1: ^
 * dpb1 checks
<dpb1> tvansteenburgh: so, in 30 min?  (meeting is at "2pm" here)
<tvansteenburgh> dpb1: yeah
<dpb1> tvansteenburgh: ok
<tvansteenburgh> cool, thanks
<Zetas> i finally got my openstack system running but I'm not the best way to get images added. I followed marcoceppi's guide for standing up openstack on 2 machines but every image i try to add just sits there and says "queued" forever.
<lazyPower> Zetas: incoming help
<Zetas> i've tried uploading some of the images found at this url http://docs.openstack.org/image-guide/content/ch_obtaining_images.html
<Zetas> ok thanks lazyPower
<beisner> hi zetas - can you tell us the command you're using to add the glance image?
<zetas> beisner: im adding it from horizon :/
<beisner> zetas, ok, t-shooting needs command line.
<zetas> ok, I thought maybe there was a command to add some basic images by default. When I stood up the openstack bundle on AWS it came with come coreos images if i recall correctly.
<zetas> My manual installation did not
<beisner> zetas, yep, glance will be empty by default.
<lazyPower> beisner: are we planning on adding an action to glance to load up the Ubuntu images? *shameless plug*
<beisner> zetas, as far as troubleshooting it, I'd use the glance command line api to confirm basic service functionality.   ie.     glance image-list       should exit 0 (good), even with no images.  that would confirm that glance is able to authenticate and talk to all of its friends.
<beisner> lazyPower, you're the 2nd to ask ;-)   I think an "import all currently-supported Ubuntu cloud images" action would be really useful.
<zetas> ok, i'll google for glance commands to add images and stuff as well, thanks for your help
<zetas> hrm... beisner: i take it this isn't a good sign heh http://paste.ubuntu.com/11376730/
<lazyPower> beisner: I should have known you cats were already on the trail for that one, but it never hurts to ask :)
<beisner> zetas, http://paste.ubuntu.com/11376741/
<zetas> ok awesome, thanks
<beisner> lazyPower, so actually, the glance simplestreams sync charm has some awesomeness.   configure it and relate it to glance, and you always have fresh images in glance as they hit cloudimages.
<beisner> but yeah, use cases for actions is likely to grow wildly.
<lazyPower> wat
<lazyPower> we have a charm that does this for you?
<beisner> i think it needs a little updating love, but yep.
<beisner> we use it in serverstack
<beisner> that ensures that when CI nova boots new instances, they are the most up-to-date (smallest apt-get update delta).
<zetas> woot it worked, thanks beisner
<zetas> im gonna try cs:trusty/glance-simplestreams-sync-1
<zetas> see how it works
<beisner> zetas, great!  so before adding to it,  i'd poke around the cli to see if you can import a small cirros or ubuntu cloud image.   generally speaking, if glance image-list works, the apis and authentication are probably happy.   next line of t-shooting might be command syntax, image format, or a storage issue.
<zetas> yea, image-list output an empty table
<zetas> im gonna keep poking around the CLI while this allocates
<zetas> my poor macbook is not loving running all these inside a virtualbox vm haha
<beisner> zetas, an empty table with no errors is actually good.
<beisner> echo $?
<beisner> after glance image-list    to confirm it exits 0, without error.
<zetas> 0
<zetas> yep, seems to be all good
<beisner> zetas, http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img
<beisner> zetas, glance image-create --name="trusty" --is-public=true --progress --container-format=bare --disk-format=qcow2 < trusty-server-cloudimg-amd64-disk1.img
<beisner> zetas,  ^ those are rips from some automation which I know work.
<zetas> awesome, as soon as it finishes downloading that image im gonna run it and see what happens
<beisner> zetas, good luck, i've got to head out for a bit.
<zetas> thanks for all your help beisner
<beisner> zetas, you're welcome - happy to help
<zetas> :)
<zetas> hmm poop. I tried to deploy an instance with my new image but apparantely i don't have a hypervisor haha. I guess nova-compute isn't happy for some reason.
 * zetas debugs
<thumper> lazyPower: ping
<lazyPower> thumper: pong
<thumper> lazyPower: got a few minutes for a hangout?
<lazyPower> thumper: not atm
<thumper> lazyPower: will you later?
<lazyPower> After dinner
<thumper> eta?
<thumper> lazyPower: are you east coast?
<lazyPower> thumper: yup
<thumper> lazyPower: so 6pm there now?
<lazyPower> yup
<thumper> when would be good?
<lazyPower> i'll ping after i eat
<thumper> :)
<thumper> ok
<lazyPower> i'll be around fairly late this evening, working on some leftover stuff from before holiday
<thumper> kk
<lazyPower> thumper: ping/pong - back from food
<thumper> lazyPower: hangout?
<lazyPower> https://plus.google.com/hangouts/_/canonical.com/django-afterhours
<thumper> hah
#juju 2015-05-27
<miken> Hrm... I'm seeing "error trying to stop watcher: connection is shut down" consistently when trying to upgrade a charm (rabbitmq). That is, it happened 2 out of 2 times on the initial upgrade-charm, and resolved itself 2 out of 2 on a resolved --retry. Does anyone see anything in this paste that could indicate an issue with the charm? http://paste.ubuntu.com/11380563/ (or a way I could avoid it)
<lazyPower> miken: thats odd, and doesn't indicate something is awry with the charm that I can see. it looks like something in the env tanked briefly and resolved itself on the next go
<miken> lazyPower: yeah, that's what I thought too initially, which is why I was surprised when I re-bootstrapped to test again and had exactly the same behaviour the second time (ie. upgrade-charm failed initially with that error, then resolved --retry resolved without issue)
<lazyPower> hmm...
<lazyPower> config-get is what failed though
<lazyPower> or rather, returned > 1
<lazyPower> can you attach to the unit after a deploy, then run the upgrade-charm sequence, and call config-get and examine the output?
<lazyPower> debug-hooks in a consistent failure case like that should get us enough of a reproduceable env to see whats happening
<miken> Sure - let me redeploy. My guess is that I'll see a similar api connection error.
 * miken does that.
<lazyPower> ta miken
<thumper> miken: anything you see with something like "error trying to stop watcher" is a juju bug, not a charm bug AFAICT
<thumper> miken: which version of juju?
<miken> 1.23.2-trusty-amd64
<miken> Yes, as above, I did assume it was a juju bug, but given that it reproduced itself twice only for that charm, I didn't know if there was something specific to the charm triggering it. I'm trying for a third time now, with debug-hooks.
<miken> Right, I should have said s/issue with the charm/something in the charm that might trigger/
<miken> thumper, lazyPower: Didn't trigger the error on the third redeploy with debug-hooks. Oh well :/ (if it was important, I'd redeploy again and try for a 4th time without debug-hooks, but otherwise I'll just move on)
<lazyPower> miken: without being able to capture the env and debug whats happening - i think you're fine to move on for now. but if it crops up, by all means please capture logs and file a bug
<thumper> agreed
<lazyPower> miken: appreciate the time spent attempting to reproduce for us. *hattip*
<redelmann> hi there, someone online for a quick help?
<lazyPower> redelmann: we can try, whats the trouble?
<redelmann> lazyPower, hi!
<redelmann> lazyPower, i recently install docker inside a juju unit
<redelmann> lazyPower, docker create a docker0 bridge network
<redelmann> lazyPower, now all relation to that unit get provate-address of bridge0
<redelmann> lazyPower, this happend in MAAS but not in AWS
<redelmann> lazyPower, it's a know bug? or something im doing wrong?
<lazyPower> thumper: hey have you seen this before? MAAS unit-agent is picking up on a bridge interface and not the host device
<lazyPower> redelmann: this is most definately a networking bug in the juju unit agent if its picking up the wrong interface to be providing as a private address
<thumper> lazyPower: oh... yeah...
<thumper> rings a bell
<lazyPower> ok, so if you've heard of it chances are we have a bug somewhere
<lazyPower> let me fish this up and see if there's anything listed as a work around until it gets patched redelmann
<thumper> the network selection logic is a bit fubared on maas right now
<lazyPower> 1 moment
<thumper> I know it is being worked on
<thumper> but I don't know the status
<thumper> one horrible thing you could do...
<redelmann> lazyPower, i search a lot, but i couldn't find anything
<thumper> is to name it alphabetically after 'eth0'
<thumper> that *might* work
<lazyPower> thumper: seriously?
 * thumper shrugs
<redelmann> thumper, i try to disable Docker0 bridge, but now i don't get any private-address in relation :P
<thumper> I didn't write any of that
<lazyPower> i'm not blaming you, i swear
<lazyPower> not this time anyway
<thumper> IIRC it choses the first network adapter
<thumper> chooses
<thumper> i may be wrong
<lazyPower> redelmann: so you disabled the docker bridge, and it doesn't show up in ifconfig -a, but its no longer sending an address on the wire for private-address?
<thumper> wallyworld: do you know the status of the maas networking stuff?
<redelmann> thumper, lazyPower: netroks are in alphabetic order (eth0: noip, juju-br0: private ip, etc"
<thumper> ah...
<thumper> phoey
<wallyworld> thumper: not in any detail
<redelmann> lazyPower, exactly.
<lazyPower> redelmann: ok, i'm not finding a bug searching launchpad either. Can you file a bug detailing this issue?
<lazyPower> we need to get it triaged and on the docket for someone to look at it
<thumper> if in doubt, file a bug
<redelmann> lazyPower, is like it try to get address of first interface
<lazyPower> i know there's a whole herd of networking stuff inc. and this may be on that ticket, but without a bug we wont know.
<thumper> the juju team can always either mark as a dupe or invalid
<thumper> but better to have the bug than not
<lazyPower> https://bugs.launchpad.net/juju-core/+filebug
<thumper> lazyPower: cheers
<thumper> someone should make a bot that files bugs for us :)
<thumper> an irc bot
 * lazyPower kicks mup
<thumper> probably need a valid person list
<thumper> with some auth
 * thumper thinks:
<redelmann> lazyPower, ok. i'am in home right now. but tomorrow in work i will create an issue.
<redelmann> lazyPower, thumper: thank yoy very much
<lazyPower> redelmann: awesome. if you need me to take a look at it feel free to ping me here and i'll look it over and route some eyes at it.
<lazyPower> redelmann: sorry you ran into that :( Not a very stellar experience ot have a unit just drop a private-address once a new bridge pops up
<redelmann> lazyPower, for the record, it happen in KVM enciroment.
<redelmann> lazyPower, environment. Sorry my english :P
<lazyPower> that'll be good info to have in the bug, so if it happens in KVM but not on a BM host we can isolate it :)
<lazyPower> make sure you include juju-version, maas version, and steps to reproduce
<redelmann> lazyPower, OK, thanks
<lazyPower> cheers redelmann
<lazyPower> thumper: are you going to make this bot your new friday freetime project?
<thumper> lazyPower: ha, nah
<lazyPower> :) just teasin anyway. Its 11, i'm outy5000. See you in the am o/
<jamespage> Tribaal, morning - we have an issue with http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/revision/373?start_revid=373
<jamespage> its breaking anything todo with the hacluster charm due to the way that the data is passed for that relation
<jamespage> Tribaal, I've reverted it for now - under bug 1459175
<mup> Bug #1459175: relation_set is broken <Charm Helpers:Fix Committed> <https://launchpad.net/bugs/1459175>
<stub> jamespage, Tribaal : That will affect Bug #1458546 and the corresponding MP (different issue probably - py3 vs. settings being lost)
<mup> Bug #1458546: relation_set broken under Python3 <Charm Helpers:In Progress by stub> <https://launchpad.net/bugs/1458546>
<stub> I didn't see any dataloss with 1.23, so not sure what went wrong with the hacluster charm
<stub> (unless it is py3 and you were swallowing the AttributeError?)
<jamespage> coreycb, hey - minor feedback on that charm-helpers merge
<jamespage> stub, the hacluster charm uses some fairly horrid serialization techniques for the data that gets passed
<jamespage> I suspect this is what breaks
<coreycb> jamespage, good catch! fixing
<Tribaal> jamespage: we'll need this to be in at some point however, without this the size of arguments passed to a relation is limited to the system's command-line size limit
<jamespage> Tribaal, don't doubt that
<jamespage> Tribaal, we have a horrid workaround in nova-cc due to that issue
<Tribaal> jamespage: ok, so we're not the only ones to need the --file thing to work at least :)
<jamespage> Tribaal, maybe it could be opt-in rather than on by default?
<Tribaal> we need it because we set relatively complex errorpage stazans on the haproxy charm
<Tribaal> jamespage: whatever works. We could make it another charmhelpers method (set_rlation_with_file) or something
<Tribaal> but that feels dirty
<Tribaal> ideally, there should be only one obvious way to do this :)
<Tribaal> what breaks for the hacluster charm?
<coreycb> jamespage, fixed c-h and the rest of the charms and resent you an email with mp links as I'd changed the names of the branches which changed the mp names
<mbruzek> good morning jcastro
<jcastro> hi!
<jcastro> how was your break?
<mbruzek> jcastro: Good I went camping and got rained on
<mbruzek> jcastro: how was canada
<jcastro> mbruzek: lovely
<lazyPower> jcastro: Nice! re: shirts
<redelmann> lazyPower, hi there. i report this https://bugs.launchpad.net/juju-core/+bug/1459327
<mup> Bug #1459327: Juju MAAS netwoking with custom bridge inside service <juju-core:New> <https://launchpad.net/bugs/1459327>
<redelmann> lazyPower, from the last chating with you
<lazyPower> redelmann: perfect, thanks for following up. i'm in ameeting give me a moment to take a look
<redelmann> lazyPower, ok. tellme if more info is needed
<jcastro> kwmonroe: heya, so the texaslinuxfest guys just pinged me reminding us the deadline for talks is tomorrow, and we haven't submitted anything.
<kwmonroe> wat jcastro?!?  http://2015.texaslinuxfest.org/content/call-papers says June 28, 2015 11:59 p.m.: Deadline for proposals
<jcastro> oh shit
<jcastro> that's 30 days away.
<jcastro> my bad
<kwmonroe> did they tell you the 28th and you just assumed may, or did they say may?
<jcastro> well they sent me the mail today with a reminder, I saw 28th and basically panicked.
<jcastro> kwmonroe: but hey, if you do it by tomorrow it's a full 30 days out of the way!
<kwmonroe> i see what you're doing there
<arosales> upper--, hello
<upper--> arosales: :)
<nevermam> Hi Antonio..I am an IBM charmer.Can you please share with me the charm review checklist, which we can use as guidelines/best practise, while creating charm..
<tvansteenburgh> arosales: ^
<tvansteenburgh> neverman: i'd start here https://jujucharms.com/docs/stable/authors-charm-store
<tvansteenburgh> nevermam: also read "Charm store policy" and "Best practices"
<arosales> nevermam, hello and welcome :-0
<arosales> nevermam, in addition to the links tvansteenburgh gave you I am working on creating a checklist I would like to propose to the juju list and get feedback on.
<arosales> nevermam, that may be the list you are after, and once I get a +1 from folks I propose adding it to the review docs.
<jcastro> also if anyone has any things to add to those doc pages I'd be happy to integrate them if it helps the next person
<lazyPower> hey marcoceppi, i think i know why clearwater-bono didn't make it into the revq. There was no branch attached - its a pointer to their GH repository
<lazyPower> iirc, attaching a branch was part of the requirements
<lazyPower> redelmann: i apologize for taking so long to get back to you, but this is exactly what we were looking for. Thanks for the bug report
<redelmann> lazyPower, great. i get a Â¿workaround?
<lazyPower> Nothing as of yet, but its now in the queue for review by the core team. If someone on the core team knows how to work aroudn this bug, they should be chiming in on the bug soon, otehrwise we'll get an official patch landed to address it soon
<redelmann> lazyPower, just setting docker0 to some strange network like: "128.1.0.0" and juju start working again
<lazyPower> redelmann: really? thats interesting...
<redelmann> lazyPower, a little reserch from here: https://github.com/juju/juju/blob/master/network/network.go
<lazyPower> redelmann: have you tried using something like the docker core bundle to deploy your docker + networking solution?
<lazyPower> not the most ideal situation, but adding flannel networking will reconfigure the docker0 bridge w/ an ip from etd and that may resolve the issue in a juju-centric manner
<lazyPower> https://jujucharms.com/u/lazypower/docker-core/4
<redelmann> lazyPower, we already have our docker scripts for the projects, it was easier to use docker from the same project
<lazyPower> ack, just curious
<redelmann> lazyPower, but that's is too much infrastucture for us roght now.
<redelmann> right
<redelmann> lazyPower, we are using docker for isolating proccess from network
 * lazyPower nods
#juju 2015-05-28
<nevermam> Thanks arosales and tvansteenburgh..I will go though the charm store best practies, and look forward for the new addition to the review docs by arosales
<stub> jamespage, Tribaal : I don't want it to be opt in, as I'm also hoping that juju-log, leader-set and everything else will grow --file for similar reasons.
<stub> jamespage, Tribaal : Maybe that requires bug fixes in juju-core. Maybe the haproxy charm is relying on weird quoting behavior it can no longer rely on. It would be nice to know.
<stub> c/haproxy/hacluster/
<Tribaal> stub: jamespage: I'd like it to be default as well, it just makes more sense to me.
<Tribaal> (design the problem away)
<stub> Tribaal, jamespage : I've set the bug to incomplete and added a comment. Without an actual example of the problem, it is just going to get broken again.
<arosales> nevermam, thanks for the ping here. Feel free to ping if you have any other questions
<arosales> lazyPower, aisrael   upper-- found some interesting bits with vagrant workflow (https://jujucharms.com/docs/devel/howto-vagrant-workflow)
<arosales> lazyPower, aisrael https://gist.github.com/anonymous/508af728f342ecc7da56
<lazyPower> ah, the genghis workflow. Probably needs some attention, the last time I'm aware that was touched was early 2014. I'm not surprised there's some bitrot there.
<arosales> lazyPower, if those comments looks ok perhaps upper-- would be interested in a merge request (ref https://jujucharms.com/docs/devel/contributing)
 * arosales grabs some coffee
<lazyPower> arosales: seems to be in order. If they get a PR issued against the docs to update those bits, aisreal or myself can run through them for validation and get it merged.
<lazyPower> upper--: ^ if you've got the time for a PR against the docs, it would be much appreciated.
<beisner> coffee indeed...
<upper--> lazyPower: sure, ill have a look when i get a minute :)
<pmatulis> tried to deploy n=4 nova-compute but 2 got stuck in 'allocating'. tried to remove machines but same 2 machines associated with stuck services now stuck 'pending / dying'. what to do? - http://paste.ubuntu.com/11412201/
<mbruzek> pmatulis: I haven't had much experience on maas
<mbruzek> pmatulis: But if that were local provider I would think your vm image is corrupted.
<mbruzek> pmatulis: Can you `juju destroy-environment maas --force` and start over?
<pmatulis> mbruzek: i'll keep that as a last resort. but thanks
<mbruzek> pmatulis: OK.  Again it reminds me of a local issue where the lxc images were only half downloaded.   A destroy-environment --force and deleting the cloud images off my machine usually clear up a problem like that.  Since this is maas it may not work.
<lazyPower> pmatulis: do your nodes provision properly through MAAS without juju spinning them up?
<lazyPower> pmatulis: also, which version of maas/juju?
<pmatulis> lazyPower: i haven't tried installing a pure 'buntu with this maas setup yet
<pmatulis> lazyPower: maas 1.7.4+bzr3366-0 + juju 1.23.3-0ubuntu1
<pmatulis> going to try 'juju remove-machine <#> --force 1'
<lazyPower> pmatulis: that should drop it from the juju env and force power it off, you dont need to pass 1 to force though
<lazyPower> juju destroy-machine # --force should do what you want
<pmatulis> ah ok
<lazyPower> pmatulis: however, i would ensure that booting the machine w/ maas works before you go the juju integration route, that will help you flush out any problems w/ the underlying maas provider
<pmatulis> lazyPower: yep, good idea
<lazyPower> and if the machines boot properly through maas, we can start looking at the cloud-init logs emitted from the machine to identify the issue juju may be causing. typically this is due to networking config
<lazyPower> at least in my experience
<lazyPower> but i've also got a weird vmaas setup that is hinky because I like to do things without reading instructions first :)
<pmatulis> thing is, 2 of my nova-compute services came up. just 2 got borked
<pmatulis> i didn't test anything though, just according to 'juju status'
<lazyPower> hmm
<lazyPower> that may or may not be symptomatic of the machines being bum in maas
<lazyPower> i would still give the broken machines a cold boot directly from teh maas ui and see what happens
<pmatulis> fyi, entire environment is housed in a single openstack instance (acting as kvm hypervisor)
<pmatulis> the load went over 9 on it when i deployed these 4 nova-compute. may be part of the problem. dunno
<lazyPower> thats possible pmatulis
<lazyPower> if it couldn't get the requested resources the VM boots may have gotten hung up, i know that happens to me occasionally in our over-subscribed openstack instance
<lazyPower> typically killing the machine and requesting again seems to have some merit as it works in 90% of the cases that happens, but its not ideal :)
<pmatulis> lazyPower: ok, --force worked on those 2 machines; they're gone and the maas GUI shows them as 'Ready' instead of 'Failed something or other'
<pmatulis> will try to deploy one at a time
<lazyPower> pmatulis: ok good, so it seems like it might have just been intermittant
<lazyPower> exactly my suggestion
<lazyPower> take it one at a time and see if they come online as they should
<evilnickveitch> just FYI, as there is now content for 1.23 in docs (GCE got added earlier) the new default version for stable docs is 1.23
<evilnickveitch> Anybody wanting to check out the combination of Juju and Google Compute Engine should take a look at: https://jujucharms.com/docs/stable/config-gce
<jcastro> Nice work dude!
<evilnickveitch> jcastro, thx
<hatch> I have a service that appears to be stuck 'dying' with two units - is there a way I can force it to destroy?
<jcastro> without just killing the machine out from underneath it?
<hatch> jcastro: trying that right now...doesn't appear to be destroying the machine either
<jcastro> I assume you tried to destroy the service first of course?
<hatch> jcastro: yeah - it doesn't appear to be doing anything
<hatch> no errors
<jcastro> anything in the machine logs?
<hatch> jcastro: when I try to destroy the unit I get this error
<hatch> ERROR no units were destroyed: state changing too quickly; try again soon
<hatch> it's been in pending for a long time
<jcastro> state changing too quickly sounds odd to me
<hatch> yeah... especially since it's not :
<hatch> :)
<hatch> jcastro: on the machine there is this error in the juju logs
<hatch> FATAL: Could not load /lib/modules/3.13.0-53-generic/modules.dep: No such file or directory
<jcastro> no clue on that one, pastebin then to the list?
<hatch> yeah I can do that
<hatch> thanks for the help
<lazyPower> hatch: is there a subordinate service on the unit?
<hatch> lazyPower: there wasn't
<hatch> it was just mysql
<lazyPower> weird
<lazyPower> is this 1.24?
<hatch> 1.24-beta5-trusty-amd64
<lazyPower> hmm ok, im' on beta4 atm
<lazyPower> i haven't run into that bu ti'll keep my eyes peeled
<lazyPower> link to bug if you file one plz, i'd like to track that
<hatch> well I'm not sure how to reproduce it
<hatch> so the bug report is going to suck :)
<hatch> but I guess maybe someone can trace it back
<firl> anyone able to help me verify if what I am seeing might be a bug or not with my juju / openstack set up?
<hatch> lazyPower: https://bugs.launchpad.net/juju-core/+bug/1459761 it's not much but maybe it'll help :)
<mup> Bug #1459761: Unable to destroy service/machine/unit <juju-core:New> <https://launchpad.net/bugs/1459761>
<marcoceppi> firl: we can try, what are you seeing?
<firl> Used juju to deploy juju gui
<firl> worked fine, then used juju gui to deploy owncloud. The box came up fine and everything
<firl> the security group wasnât configured to expose the ports though, had to manually configure it
<marcoceppi> firl: did you tell juju to expose owncloud?
<firl> that would probably do it
<firl> nope I didnât,
<marcoceppi> firl: in the GUI if you click on OwnCloud you'll see at the bottom left of the inspector the Expose option. In the command line its just "juju expose owncloud"
<firl> yeah; completely user error
<marcoceppi> no worries
<upper--> lazyPower: i submitted a pull request for the docs, not sure if i have to tell you or you or someone else will just notice
<firl> yep that did it, thanks for letting me waste your time marcoceppi
<marcoceppi> firl: it's never a waste! Glad it was something simple
<firl> haha
<lazyPower> upper--: we'll take a look shortly, thanks for the contribution!
<lazyPower> hatch: awesome, cheers
<marcoceppi> upper--: #431?
<upper--> uhhh..
<arosales_> aisrael, have you tried quickstart in vagrant?
<upper--> marcoceppi: yes
<marcoceppi> upper--: thanks for the contribution, one of us will take a look soon for sure
<arosales> if you are having issues with quickstart in vagrant perhaps give deployer a try
<arosales> specifically deployer -c <./path/to/bundle.yaml>
<arosales> upper--, chcking with aisrael or tvansteenburgh to see if they have had any issues with quickstart in vagrant
<upper--> ill try deployer
<arosales> upper--, hmm but your manual deploy should have worked if your mirrored the bundle yaml
<arosales> upper--, checking with asanjar on the timing
<jose> jcastro: want me to host office hours under ubuntuonair?
<jcastro> that sounds awesome to me
<jcastro> marcoceppi: you in for office hours?
<marcoceppi> sure
<jcastro> jose: dang, forgot to post a reminder to the list, on it now.
<jose> :P
<jose> cool, will be ready by then
<aisrael> arosales: upper-- I've used quickstart under vagrant, but not with bundles (successfully)
<arosales> aisrael, interesting something we should put a card out for to test
<arosales> ie testing vagrant/quickstart/bundles
<upper--> ok..
<upper--> ill see if i can get maas working properly
<arosales> upper--, suggest to stick with deployer -c <bundle-file>
<arosales> for now
<aisrael> arosales: definitely. I'm finding the documentation re launching from a bundle to be lacking
<arosales> upper--, also may be worth comparing to AWS
<upper--> arosales: okay.. yeah or aws
<arosales> and isolate if it is the charm or environment
<upper--> im about done for the day though
<arosales> upper--, understood
<arosales> been a good whack today
<arosales> aisrael, thanks
<jcastro> jose: can you make the IRC channel for the webapp go here instead of #u-o-a?
<jose> jcastro: definitely, just a matter of changing a line of html
<jcastro> jose: thanks for hosting, I was dreading getting made fun of by marco for not doing the onair properly.
<jose> what? what did you do to the page?
<jose> did you break it again?
 * jose scratches head
<jose> so, who's gonna join me today?
<jose> I know everyone wants to be on air, but don't get too excited
<jose> for anyone that wants to join, here's the link: https://plus.google.com/hangouts/_/hoaevent/AP36tYezWWMOvDIBerQVTv3ZjW4XO3xnVhVshfCm-HXeQlkdqnVBtg
<jcastro> ok everyone, office hours starts in 30 seconds or so
<jcastro> https://plus.google.com/hangouts/_/hoaevent/AP36tYezWWMOvDIBerQVTv3ZjW4XO3xnVhVshfCm-HXeQlkdqnVBtg
<jcastro> if you want to participate
<jcastro> http://ubuntuonair.com if you want to just listen in
<aisrael> ^^ that link isn't working for me. The video says "An error occurred. Please try again later."
<jcastro> I'll take questions in here if you have any
<jcastro> aisrael: try a hard refresh
<aisrael> nada
<jcastro> jose: ^^
<aisrael> jcastro: it just started working
<jose> aisrael: try again, youtube when we didn't start (a bit of lag)
<aisrael> http://imgur.com/gallery/q9njg40
<jose> refresh and try again
<hazmat> jcastro: question: are there any good presentations on juju for a business type audience / ie. high level benefits / whose using it /  etc
<hazmat> lazyPower: nice recovery (re kubes)
<hazmat> lazyPower: re kube is there a way (document?) to run kube e2e on the charms?
<hazmat> lazyPower: flannel does nesc. do overlays, in some cases its directly modifying the iaas substrate networking
<hazmat> er. doesn't
<lazyPower> hazmat: thats fair
<lazyPower> hazmat: i wasn't ready at all to give that update, so i shot from the hip
<hazmat> lazyPower: kube is targetting 1.0 end of june.. their already in feature freeze
<lazyPower> hazmat: also regarding kube e2e, thats coming in an action. we just landed the ptestore validation, so e2e is expecting (come pass or fail) by the end of the cycle. I'm guessing in 2 to 3 weeks time.
<lazyPower> *petstore
<kwmonroe> the core apache bits we're working on for big data: https://jujucharms.com/u/bigdata-dev/apache-core-batch-processing
<jcastro> hazmat: after kevin finishes we'll move on to your questions
<jcastro> sorry I missed them the first time
<hazmat> jcastro: no worries, lazyPower got to them already.. and re presentations .. email to the list would be great.
<hazmat> jcastro: new question.. where is kafka in the big data landscape?
<hazmat> i just see mine and samuel's old charms.
<hazmat> its an integral part of many data flow pipelines
<hazmat> jcastro: what's the state of monitoring services in the charm ecosystem?
<jcastro> keep the questions coming, this is awesome!
<hazmat> re monitoring what about grafana / statsd / heka / collectd / prometheus?
<hazmat> ;-)
<hazmat> pls let's all leave nagios in the 90s where it belongs ;-)
<jcastro> heh
<hazmat> marcoceppi: is the monitors interface blogged about or documented?
<hazmat> sounds like its trying to be a generic that different tools could plug into?
<hazmat> irc lag kills
<hazmat> marcoceppi: what's the state of networking?
<hazmat> leader elections.. yipee!
<hazmat> everyone rewrite your charms ;-)
<hazmat> or even a db upgrade from a common webapp.
<hazmat> the container networking in aws is kinda of bogus, only works with default vpc
<hazmat> marcoceppi: the aws tagging thing is pretty big as well
<hazmat> that's how you get chargeback / measure the cost of an environment in aws.
<jrwren> are there docs for how to update charms to use those new states?
<hazmat> 'need to know basis' lol
 * hazmat translates i could tell you how to status output on your env, but i'd have to terminate your environment after
<lazyPower> soudns about right
<hazmat> sweet!
<hazmat> re dockercon, link?
 * hazmat already signed up
<hazmat> jcastro: link? i don't see anything on insights.canonical.com
<jrwren> what was that charm with the status examples?
<kev_> What is best way to bridge  the private interface to make it accessible to to the public network
<hazmat> er.. i mean nothing on insights.ubuntu.com that i see
<jcastro> https://insights.ubuntu.com/event/conducting-systems-and-services-an-evening-about-orchestration/
<hazmat> jcastro: thanks
<jcastro> we haven't pushed it hard yet due to openstack news
<jcastro> but we'll be pushing/tweeting it way more over the next few weeks
<hazmat> jcastro: tweeted already https://twitter.com/kapilvt/status/604027510624501760
<jcastro> <3
<marcoceppi> jcastro: you still around?
#juju 2015-05-29
<jcastro> marcoceppi: do you have a link to your openstack presentation video
<marcoceppi> jcastro: https://www.openstack.org/summit/vancouver-2015/summit-videos/ and https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/repeatable-benchmarking-of-openstack-architectures
<marcoceppi> jcastro: the rally charm also has status in it ;)
<mbruzek> marcoceppi: Cool I am interested in  that myself.
<mbruzek> marcoceppi:  Are the status messages not backward compatible?
<mbruzek> What happens if you deploy the rally charm on juju 1.18 or something?
<marcoceppi> mbruzek: they are not, but the charm-helpers implementation of status-set is backwards compat
<marcoceppi> mbruzek: it fails
<mbruzek> weaksauce, I *wish* we could specify a minimum version of Juju in a charm.
<marcoceppi> mbruzek: I don't, I think that's silly
<marcoceppi> well, the potential for abuse is there
<mbruzek> It is better to have a charm fail because you try to use new featurs?
<marcoceppi> CI should just tell us what versions of juju the charm works with
<mbruzek> Users will not check ci before deploying
<mbruzek> I disagree
<marcoceppi> but the store can
<mbruzek> Does the store do that *now*?
<marcoceppi> a tighter feedback loop between CI and charmstore seems better than having effort working on min version stuff
<marcoceppi> mbruzek: no, but we don't ahve min version either and if I had to decide which to work on, I think yhou know where I stand
<mbruzek> You stand on benchmarking
<marcoceppi> yes, but the more we can do for the user, the better
<mbruzek> everything all the time
<mbruzek> Understand we have priorities, and limits on the work that can be done, but as we get more customers, and more features landing in Juju charms that don't deploy on older versions of Juju will cause us pain and is a "bad user experience"
<marcoceppi> mbruzek: I'd say the oinous is on the charm author
<marcoceppi> I care about my charm and will so build in a way to make it backwards compat by using the python charm helpers library
 * mbruzek checks the rally charm for a minimum version 
<mbruzek> in the readme
<marcoceppi> which will make sure that, when status_set is called, if the command doesn't exist it uses juju-log instead
<marcoceppi> that way it's transparent
<marcoceppi> the user can use the charm in any version of juju
<marcoceppi> and it just degrades nicely
<mbruzek> marcoceppi:  I have no doubt you can write EXCELLENT charms, but the other authors will not know what features were new or not backward compatible
<marcoceppi> mbruzek: well, if charm authors are using the charm-helpers library
<marcoceppi> we only have to encode that quality once
<marcoceppi> then everyone gets it
<marcoceppi> your point alone on this
<marcoceppi> if a charm author doesn't know what version of juju a feature is added
<marcoceppi> how will they know what to set the min-version to?
<marcoceppi> they don't and will just set it to the latest juju they're using
<marcoceppi> which may not acurately be the min version of juju it works for
<marcoceppi> which means that charm doesn't get delivered to users who could /potentially/ run it
<mbruzek> I found recently that the trusty/haproxy charm is version locked at charmhelpers revision 70.  I tried to sync charmhelpers and use the new functionality and found that it could not move beyond revision 70.  When I removed this lock, I found that charmhelpers is on revision 300 something.
<marcoceppi> mbruzek: that's an implementation detail, I have an email going to the list about charm-helpers being better packaged, versioned, and distributed
<marcoceppi> but even still that's not /that/ bad
<mbruzek> my point is if we give someone a way to make a mistake they might and then that would suck.
<marcoceppi> so we need smarter systems, better CI and charm store integration, and a better review process
<marcoceppi> so these mistakes get caught before they enter the store
<marcoceppi> min version is simply a bandaid to a larger concern in the system
<Tribaal> jamespage: I'm going to merge https://code.launchpad.net/~free.ekanayaka/charm-helpers/relation-set-file/+merge/260594 into charm-helpers. It will fix the python3 issue, and reintroduce the --file feature for set-relation
<Tribaal> stub: ^^ FYI. This includes your fixes from this morning
<bleepbloop> Hello everyone, I am trying to deploy openstack using the openstack installer onto 15.04 in multi install mode, however juju seems to be having trouble bootstraping to 15.04, when the maas default series is set to trusty it works fine however vivid just hangs and then gets a connection timeout error with ssh
<bleepbloop> Ahh I think this may be causing it: https://bugs.launchpad.net/cloud-installer/+bug/1442308 seems that the openstack installer currently does not work on vivid
<mup> Bug #1442308: Juju cannot create vivid containers <ci> <cloud-installer> <local-provider> <lxc> <ubuntu-engineering> <vivid> <cloud-installer:Confirmed> <juju-core:In Progress by cherylj> <juju-core 1.24:Fix Committed by cherylj> <https://launchpad.net/bugs/1442308>
<cherylj> bleepbloop: yeah, there  was a problem with creating containers with vivid
<bleepbloop> Wait no that doesn't fully make sense since it is the initial bootstrapping of juju that is failing, unless install is fully broken on vivid
<marcoceppi> bleepbloop: you need 1.23 to do vivid, not sure what version cloud-isntaller uses
<bleepbloop> marcoceppi: I'm currently using 1.23.3-trusty-amd64 and it is failing, as soon as I set it to bootstrap trusty it gets past that error though
<bleepbloop> When I run on trusty I get agent-version: 1.23.3 for the remote bootstrap version, so something else is going wrong there
<cherylj> bleepbloop: are you able to try the bootstrap with --debug so we could look at the log?
<bleepbloop> cherylj: sure, working on it
<bleepbloop> cherylj: http://paste.ubuntu.com/11436902/ is the log, at that point it just hangs until it finally gets a connection timeout error
<bleepbloop> cherylj: If I try connecting via the regular ssh command it just hangs as well and eventually times out
<bleepbloop> cherylj: Also if I restart the machine it is bootstrapping to manually, it comes up just fine
<cherylj> bleepbloop: can you tell me if there is anything in /var/lib/juju/containers/ on the machine it is bootstrapping to?  I'm not sure if using --to with maas will use a container or not.
<bleepbloop> cherylj: There is no containers directory there, it seems the issue is completely unrelated to containers unfortunately, I was wrong there
<cherylj> bleepbloop: I'd suggest opening up a bug for it.
<bleepbloop> cherylj: thanks, I've filed it https://bugs.launchpad.net/juju-core/+bug/1460184
<mup> Bug #1460184: Bootstrapping fails with Maas on Ubuntu Vivid <juju-core:New> <https://launchpad.net/bugs/1460184>
#juju 2015-05-30
<g3naro> hello
<g3naro> anyone have problem access chamr storE?
<g3naro> g3naro@shiva:~$ juju deploy juju-gui
<g3naro> ERROR Cannot access the charm store. Invalid response code: "504 Gateway Time-out"
<jrwren> g3naro: I know the infrastructure on which it runs had an outage recently, but it should be working. Indeed I was able to download fine just now.
<jrwren> g3naro: that deploy is going to try this: https://api.jujucharms.com/charmstore/v4/trusty/juju-gui-27/archive or this: https://api.jujucharms.com/charmstore/v4/precise/juju-gui-27/archive depending on trusty v. precise
<g3naro> what you mean going?
<g3naro> ahh ok, but would it be working if i downloaded the charm source first and then did a local charm apply ?
<jrwren> maybe.
<jrwren> did you try again?
<jrwren> i was just able to deploy with no issue.
#juju 2015-05-31
<scorpion> hi All
#juju 2016-05-30
<hackedbellini> Hi all. I'm having some trouble doing a manual provisioning on a machine. I have a lxc environment and I can create machines fine. All of those machines are trusty. I need to create a xenial one and, because `juju add-machine --series=xenial` gave me a "no matching tools available", I tried to create one by hand and manually provision it with `juju
<hackedbellini> add-machine ssh:user@ip`. That worked, but the state is "pending". When I check the log, it has a lot of "juju.state.api apiclient.go:250 error dialing "wss://localhost:17070/": websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused"
<hackedbellini> so, anyone knows how can I fix that error or even fix the "no matching tools available"?
#juju 2016-05-31
<maasIVE> topic needs changing ;) i am on xenial ask me for testing :)
<jamespage> gnuoy, two ticks for a sync +1 ?
<jamespage> https://review.openstack.org/#/c/322097/
<dimitern> when will juju-deployer or charm-tools/-helpers/amulet support juju 2.0 properly
<dimitern> :/
<gnuoy> jamespage, +1
<jamespage> icey, cholcombe: need one of you to pickup https://bugs.launchpad.net/charms/+source/ceph-radosgw/+bug/1577519 again
<mup> Bug #1577519: ceph-radosgw "Initialization timeout, failed to initialize" <landscape> <Landscape Server:Confirmed> <Landscape Server 16.05:Confirmed> <ceph-radosgw (Juju Charms Collection):Confirmed> <https://launchpad.net/bugs/1577519>
<jamespage> apparently our first fix did not resolve quite suffiently
<bbaqar> Hey guys .. I have a juju env which had some connectivity issues for short time .. hence i got the "agent is lost, sorry!" error
<bbaqar> now the nodes are back up ..
<bbaqar> i can ping and ssh into those nodes aswell .. using ssh ubuntu@ip
<bbaqar> how can i restart the jujud service on a node?
<D4RKS1D3> hi bbaqar, if you write "ls -la /etc/init | grep juju" you can see all the juju services and restarted
<bbaqar> D4RKS1D3: cool thanks alo t
<D4RKS1D3> Hi, I am trying to add a machine is in maas, but i received this message "ERROR juju.provisioner provisioner_task.go:655 cannot start instance for machine "40": cannot run instances gomaasapi: got error back from server: 409 CONFLICT (No available node matches constraints: name=imaginative-attention.datacentre tags=datacentre)"
<jamespage> gnuoy, https://review.openstack.org/#/c/323264/
<jamespage> pls :-)
<gnuoy> sure
<magicaltrout> can't you upgrade charms on a development branch?
<rick_h_> magicaltrout: yes, you should be able to.
<rick_h_> magicaltrout: what did you originally deploy?
<magicaltrout> hey rick_h_
<rick_h_> magicaltrout: howdy
<magicaltrout> just testing some homebrew stuff, but when I do "juju upgrade-charm drillbit2"
<magicaltrout> I get
<magicaltrout> ERROR cannot resolve URL "cs:~spicule/drillbit": charm or bundle not found
<magicaltrout> but then if I try and do: juju upgrade-charm drillbit2 cs:~spicule/drillbit
<magicaltrout> for example
<magicaltrout> I get invalid args
<rick_h_> magicaltrout: hmm, let's file a bug on jujucharms.com please. Looking at the urls for this: https://jujucharms.com/u/spicule/drillbit/11 is peachy
<rick_h_> but remove the 11 and it 404's
<rick_h_> magicaltrout: which is a bug in it resolving there
<magicaltrout> yeah i noticed it was being a bit funny there as well
<magicaltrout> will do
<rick_h_> magicaltrout: now for your original question, you're supposed to be able to deploy/upgrade following the development channel if it's public and if you deployed with the --channel flag w/ juju 2.0
<rick_h_> magicaltrout: this bug might be getting in the way, but not sure atm. The question is how you originally deployed it though and older Juju doesn't understand the channels
<rick_h_> they're always looking at the published stable channel
<magicaltrout> ah it seems to know  juju upgrade-charm drillbit2 --channel development
<rick_h_> magicaltrout: yea, that for if you want to cross channels
<rick_h_> e.g. go from stable to development
<magicaltrout> hmm well this would be same channel just new rev...
<magicaltrout> I'll file the bug and move on, its no big deal its all LXD anyway so its nearly as quick to tear it down and start again
<rick_h_> magicaltrout: ok, but let me know if things aren't working as expected. Or at least the steps to reproduce and I'll chase it down so it's set
<kjackal> magicaltrout: Hey Tom how is the Zookeeper issue going?
<magicaltrout> hey kjackal well it works, not sure why I'm only seeing one unit
<magicaltrout> and my understanding of debugging reactive hooks is lousy
<kjackal> magicaltrout: I am fairly sure you should be getting all three units
<magicaltrout> I have a vague memory of another service where I thought that was the case and it transpire it wasn't
<magicaltrout> but I'll trust you on that one
<magicaltrout> but I have logs in place and its only iterating once
<magicaltrout> or I've cocked up my function
<magicaltrout> which is perfectly likely
<magicaltrout> 2 mins I'll dump it in GH
<kjackal> magicaltrout: I could take a look if you point me to the charm
<kjackal> thanks magicaltrout
<magicaltrout> its nothing special, I just really want Apache Drill for Saiku so I figured I'd crack on with it :)
<magicaltrout> https://github.com/buggtb/layer-drillbit
<magicaltrout> https://github.com/buggtb/layer-drillbit/blob/master/reactive/drillbit.py#L37
<magicaltrout> watch out if you run it there is a blank line on line 45 where I was about to add some bootstrap stuff
<kjackal> magicaltrout: taking a look, thanks
<magicaltrout> the rest of it is pretty cool, drill installs and apart from the missing exec code, starts up with its configured ZK client in place
<lazyPower> look at all this collaboration first thing in the morning ;D
<lazyPower> \o/
<magicaltrout> its very much mid afternoon :P
<magicaltrout> until next week at which point i'll still be in bed
<lazyPower> well, in EDT its very much morning, and super cool to see this thread history on what by any other name, is my monday.
<lazyPower> so given that context... awww yeeee
<magicaltrout> made me sad how many emails i got from the USA yesteday :P
<lazyPower> I was only responsible for one, and Ben set me straight
<magicaltrout> anyway, yeah, kjackal is kindly unbreaking my understanding :)
<lazyPower> i was hoping my 2 hour stint of looking at code on a holiday would go un-noticed
 * lazyPower shakes a tiny fist @ magicaltrout
<magicaltrout> I'm on a big data <-> sql sprint so I can hook up Saiku 3.9 to loads of charms when its released in a week or 3
<lazyPower> nice!
<lazyPower> I'm working on a signifcant extraction and test coverage bump on etcd at the moment. x58 found some fun race conditions in there
<magicaltrout> we've finally built a half decent schema designer, so you should be able to deploy a big data bundle + Drill/Phoenix etc and then attach that to Saiku and inside saiku do a few click schema generation and be good to go
<magicaltrout> so 10 click analysis I'm hoping at most
<lazyPower> Wait isn't drill a MapR only thing?
<magicaltrout> its sponsored by MapR, but its not MapR only
<magicaltrout> its an ASF project
<lazyPower> ah ok. i thought it had the maprfs requirement
<magicaltrout> so its as generic as it comes
<lazyPower> #TIL
<magicaltrout> you can run over any hbase, parquet, csv, mongodb, generic jdbc etc
<magicaltrout> it works nicely as a data federator as well. If you have data in Hbase or somewhere and want to run a join on something in a mysql db
<magicaltrout> you can do exactly that
<lazyPower> since i'm moving in under a month, i may vanish on you magicaltrout. I have junk-takers showing up to grab the excess posessions in the next 20 minutes.
<magicaltrout> hehe
<magicaltrout> moving somewhere nice?
<lazyPower> Planning on going full nomad for the remainder of the year
<lazyPower> bouncing from AirBNB to AirBNB
<magicaltrout> nice
<lazyPower> We'll see. this was a bit more expensive than originally estimated
<lazyPower> i may bounce somewhere and find a lease just to save on living expenses
<lazyPower> but i'm stuffing all the good stuff in a POD. its like a shipping container (see what i did  there? container all the things?!) and have it shipped wherever i land
<magicaltrout> cool stuff
<lazyPower> its been a learning experience :)
<magicaltrout> staying in the US, or moving countries?
<lazyPower> closer to end of year I want to do a grand European tour
<lazyPower> start in oxford and migrate west over the course of a few months and see what i can see over there
<magicaltrout> well there's certainly some nice remote spots in the UK for nomadic working ;)
<kjackal> magicaltrout: http://pastebin.com/UaYB0LxB I can see all two units reporting their IP. What Zookeeper charm did you deploy?
<kjackal> lazyPower: So.... when are you visiting Greece?
<magicaltrout> https://jujucharms.com/apache-zookeeper/trusty/3
<kjackal> magicaltrout: how is it possible? I mean... I got my zookeeper instances reporting .... its in the pastebin....
<lazyPower> kjackal good question, lets figure out what my conf season looks like towards fall and see where i can land up :)
<magicaltrout> kjackal: dunno, just redeploying anyway, i'll grep the logs in a mo
<magicaltrout> kjackal: you just deployed a single service then add units?
<kjackal> magicaltrout: yes
<magicaltrout> kjackal: god knows
<magicaltrout> I only get 1 entry
<magicaltrout> "juju-log" ["Template:\"10.106.143.126:2181\""]
<kjackal> magicaltrout: let me see
<kjackal> you deployed apache-zookeeper
<kjackal> then you deployed drillbit
<kjackal> then you added the relation between ZK and drillbit
<kjackal> then you added a second ZK unit
<magicaltrout> not quite
<magicaltrout> I deployed ZK
<magicaltrout> then I added 2 more nodes
<kjackal> could you paste me the history of you rcommads
<magicaltrout> then i deployed drillbit
<magicaltrout> i'm tearing it down, i'll try again and log the input
<kjackal> magicaltrout: thank you
<beisner> jamespage, https://github.com/openstack-charmers/release-tools/pull/1
<magicaltrout> kjackal: http://pastebin.com/QE00v5wZ its still in flight
<magicaltrout> but thats the command list
<kjackal> magicaltrout: btw the signature of configure should look something like  http://pastebin.com/63ebzdwi
<magicaltrout> yeah in my published version its corrected
<magicaltrout> no its not
<magicaltrout> #fail
<kjackal> magicaltrout: I think I suspect what is going worng
<kjackal> magicaltrout: look....
<kjackal> the first ZK unit that comes online becomes a quorum by itself
<kjackal> at this point the configure method of drillbit is called and it sets the 'drillbit.configured'
<kjackal> then the rest of ZK units join the quorum but the  'drillbit.configured' is already configured so it does not get updated
<kjackal> so, how to fix this
<magicaltrout> ah yeah sounds sane
<kjackal> what if you do not set the 'drillbit.configured' at all?
<kjackal> or at least you do not have this when_not('drillbit.configured') at configure
<magicaltrout> yeah but then you're restart the drillbit on every execution
<kjackal> indeed, so you want to restart when you detect a change in ZK quorum
<magicaltrout> yeah
<magicaltrout> so I guess we could remove that and save the quorm dict to check against
<kjackal> have a look at this: https://github.com/juju-solutions/layer-apache-spark/blob/master/reactive/spark.py#L159
<magicaltrout> yeah
<magicaltrout> like that
<magicaltrout> okay cool
<magicaltrout> I can do that
<magicaltrout> thanks kjackal
<kjackal> cool...
<kjackal> lets see what do we say in the list...
<magicaltrout> https://ibin.co/2j3WCAhHi9Yn.png https://ibin.co/2j3WHn8H9RA1.png
<magicaltrout> there you go kjackal
<magicaltrout> need to tidy it up a bit but its up and running on the ZK cluster
<magicaltrout> but its certainly cool, i now have SQL over Mongo, CSV, Parquet, HDFS, S3, Hbase and Hive for free
<magicaltrout> although for HBase I certainly want to bring Phoenix into the CS as well
<magicaltrout> I'll also add some hooks hopefully to auto register various data sources
<magicaltrout> fscking balls
<magicaltrout> why can't LXD local set hostnames correctly yet
<magicaltrout> rick_h_: where to juju core tickets go github or launchpad?
<rick_h_> magicaltrout: launchpad please
<magicaltrout> grr
<magicaltrout> filed
<magicaltrout> woop multiple drillbits... aka a cluster \o/
<lazyPower> nice \o/
<magicaltrout> aye
<rick_h_> magicaltrout: <3
<magicaltrout> now i need some hooks so I don't have to google adding data sources every time ;)
<rick_h_> juju actions ftw
<magicaltrout> this is the stuff though. Juju makes it easy to setup a cool hadoop cluster, but until now there is no easy way for analyists to get the data back out unless they are Zeppelin/Spark/IPython "scientists"
<magicaltrout> providing SQL interfaces that are stable is key to getting people using the big data stuff Juju offers
<magicaltrout> because they can plugin they analytics tool of choice.
<magicaltrout> Of course I biased as I write one, but you can instantly hook the charms up to Tableau or whatever the big spenders want to connect to it
<magicaltrout> so here's a question rick_h_, do you use actions, or do you use relations or do you use a bit of both? :)
<rick_h_> magicaltrout: I guess it depends
<rick_h_> magicaltrout: on what the need is there, when you metion adding data sources, I got thinking of an action to add a new one
<magicaltrout> yeah, I think you end up with a combo, some charms like Mongo you can just drag to add a relation, there's not much drill needs to know. Some other stuff is far more involved. Also you could connect to services on different networks which wouldn't work with relations
<magicaltrout> so I reckon you end up with a mix of both. If relations work, it should be supported to make it really simple. If they don't you could defer to an action to pass it some additional information it might need
<magicaltrout> anyway mongo is the simplest, so we'll start there and see how we get on
<magicaltrout> i have 60 minutes to get it working before dinner.....
<magicaltrout> Go!
<kjackal> cory_fu: so, when we will be cheking out the bigtop branch, we will have to then copy/mv/link the layer directories under the LAYER_PATH to reach to a working workspace
<kjackal> I guess we could automate this process with a script or something.
<cory_fu> kjackal: Charm layers don't technically need to be under LAYER_PATH, only base layers.  So you should set your LAYER_PATH to the directory where your base layers reside (which, due to restrictions in the build tooling, cannot currently be a part of an upstream repo) but build your charm layers from the charm layer directory inside your bigtop repo checkout
<cory_fu> IOW, don't change your workspace at all, just clone bigtop somewhere else and build from there
<kjackal> cory_fu: yeap that makes sense
<petevg> cory_fu, kjackal, kwmonroe: In the zookeeper charm, we fire off a "rest_config" handler when the state "config.changed.rest" is set. I don't see that state getting set anywhere, though (I'm grepping in a dir that contains both the bigtop base charm, and the zookeeper charm).
<petevg> I see the same thing for the client_config handler, though in this case the mystery state is "zkclient.joined".
<petevg> Am I missing a charm that does relevant things, or are both of those handlers broken?
<cory_fu> petevg: They'll be set by base layers.
<petevg> Right ... I didn't see it set in the bigtop base layer, though.
<cory_fu> Specifically, the config.changed.X states get set here: https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L126
<cory_fu> petevg: And zkclient.joined is set by the interface layer: https://github.com/juju-solutions/interface-zookeeper/blob/master/requires.py#L24
<cory_fu> Sorry, zkclient.joined would actually be set by this: https://github.com/juju-solutions/interface-zookeeper/blob/master/provides.py#L25
<cory_fu> Since the Zookeeper charm is the one providing that relation, not requiring it
<petevg> Got it. That makes sense.
<petevg> Thx.
<arosales> mbruzek:
<mbruzek> arosales: pong?
<arosales> Have any documentation outstanding for terms?
<arosales> https://github.com/juju/docs/pull/1122
<mbruzek> arosales: aisrael did that part, let me find the link
<arosales>  only to be or resources but has a navigation bar entry
<arosales>  did Adam do term and you do resourcs
<arosales> ok
<mbruzek> https://github.com/juju/docs/pull/1048
<arosales>  I had those confused
<arosales> mbruzek:
<arosales> Thanks I'll see if any of the juju core folks can take a look
<mbruzek> arosales: Yes I believe that is the necessary next steps
<mbruzek> arosales: I saw you ping them already last week for this.
<mbruzek> arosales: I pinged them on the issue, so they should have got a notification, I also asked katco to review via IRC last week.
<arosales> mbruzek: i also pinged again in juju-dev
<arosales> mbruzek: thanks for the info and work on it
<mbruzek> arosales: ack.
<arosales> evilnickveitch: let us know if you see any major issues with https://github.com/juju/docs/pull/1122
<evilnickveitch> arosales, nothing major, was waiting for a +1 on technical content
<arosales> evilnickveitch: ack, and thanks for taking a look
<admcleod-> cory_fu: kwmonroe kjackal petevg what state should i be using from the bigtop plugin to ensure its ready before installing pig?
<kjackal> bigtop.available
<petevg> Beat me to it  ... it's in the new README :-)
<admcleod-> kjackal: petevg so if bigtop.available, hadoop is installed?
<kjackal> no wait, you need to run puppet apply after the bigtop.available
<kjackal> however for hadoop I guess you will need to wait for the hadoop.ready state of the plugin
<admcleod-> kjackal: ok, thanks
<admcleod-> kjackal: where does the hadoop.ready state come from?
<cory_fu> admcleod-: The hadoop.ready state comes from the plugin interface layer: https://github.com/juju-solutions/interface-hadoop-plugin#provides
<admcleod-> cory_fu: thanks
<magicaltrout> anyone know if the mongodb interface actually works?
<magicaltrout> it appears to be missing a provider
<magicaltrout> cmars: ?
<cmars> magicaltrout, it works for the requires side
<magicaltrout> okay thats all I need, but I don't seem to be getting hostnames and stuff
 * magicaltrout checks some more
<cmars> magicaltrout, use the .connection_string() method on the arg passed to your reactive handler
<cmars> magicaltrout, the state you'll want to handle is @when('<name of requires endpoint in your charm>.database.available')
<cmars> magicaltrout, for example: https://paste.ubuntu.com/16872701/
<magicaltrout> ah right, hadn't quite guessed the .connection_string() bit
<cmars> magicaltrout, i usually just update unitdata and re-run a setup() function that gets called on relation hooks, config-changed, etc
<magicaltrout> thanks for that
<cmars> magicaltrout, sure thing
<mbruzek> bdx:  ping
<j_king> odd behaviour with the MySQL charm on the Trusty vagrant juju image... says the InnoDB plugin cannot allocate memory for its buffer pools... the machine doesn't seem to be out of resources... anyone else getting this?
<j_king> maybe need to bump the box size.
<magicaltrout> j_king: dunno if its the same or if it even applies any more but: https://jujucharms.com/mysql/
<magicaltrout> caveats section
<j_king> magicaltrout: ah, ty. I'll check that out too... seems relevant given what the logs are spitting out.
<magicaltrout> cmars: i'm hitting the same error I had before with your tweaks: https://gist.github.com/buggtb/599e536da5e58d5180fe72e183f12c66
<magicaltrout> TypeError: Can't convert 'NoneType' object to str implicitly
<magicaltrout> seemingly its returning the None object
<magicaltrout> any idea what the requirements are for it to not return None ? :)
<cmars> magicaltrout, both hostname and port would need to be provided in the relation
<cmars> magicaltrout, you could get None if you've just joined the relation but the handshaking hasn't "settled" yet
<cmars> magicaltrout, wait, that's not right..
<magicaltrout> people often say that to me
<cmars> magicaltrout, if .available is set, connection_string() should not be None in the first place
<cmars> magicaltrout, i wonder if this charm is in a weird state from a series of upgrades in development?
<magicaltrout> could be
<magicaltrout> i shall tear it down and start again
<magicaltrout> thanks cmars
<cmars> magicaltrout, but i'd program defensively in this case, and test the connection_string() at the top of the function
<magicaltrout> k
<bdx> mbruzek: sup
<bdx> mbruzek: thanks for the review ... I fixed her up
<mbruzek> bdx: I already wrote tests for you
<mbruzek> bdx: https://code.launchpad.net/~mbruzek/charm-helpers/add_uid_gid/+merge/296132
<bdx> mbruzek: thats awesome, just seeing that now. rawk!
<mbruzek> I was meaning to put this merge in all morning but was swamped with meetings
<mbruzek> bdx: Thanks for the charm-helpers submission.
<mbruzek> Feel free to extend/enhance the tests
<mbruzek> bdx: Also I don't see the "<<<<< TREE" stuff in my host.py file, I think that is an artifact of the bzr diff.
<bdx> the tests look great, yea, that was the one question I had ... ok
<bdx> mbruzek: what does the patch decorator do?
<mbruzek> bdx: it makes it so if the code in that method call the class, python steps in and lets you define the return value or throwing exceptions
<bdx> nice, perfect
<mbruzek> bdx: We use that to patch out the system calls that would return different users on different systems.
<mbruzek> We can then check the patched objects were called with what we expected.
<mbruzek> And python does not make the call to subprocess and create a bunch of users on the test systems.
<bdx> ahh, so patch basically mocks os level ops?
<mbruzek> bdx: https://docs.python.org/3/library/unittest.mock.html
<mbruzek> bdx exactly!
<mbruzek> The patch() decorator / context manager makes it easy to mock classes or objects in a module under test.
<bdx> mbruzek: makes total sense, and is super cool. thanks for the heads up on that
<mbruzek> bdx: No problem. Thanks for putting in some work on charm-helpers, *we* really appreciate that
<bdx> entirely!
<bdx> the uid and gid specification will make it easier to nfs mount and match uid/gid for the provisioned/permissioned user across multiple hosts
<mbruzek> bdx: Right. I saw the merge proposals for the big data stuff using this stuff
<bdx> totally ... I want to create a user/groups provisioning layer .. I see myself lifting a bit from DistConfig in jujubigdata
<magicaltrout> i saw that chat. User provisioning layer would be super useful
<magicaltrout> but also making users a "thing" that juju can manage globally(outside of charms) would be very helpful as well
<bdx> magicaltrout: yea, I feel like juju-core is so close to providing that functionality .....
<bdx> the disconnect is model-users vs os-users on the machines
<bdx> model users all assume the ubuntu user with the addition of the model users key in authorized_keys .... which is a no no for PCI compliance :-(
<bdx> adding users as a first class citizen is a huge step for juju in general ... I  foresee the provisioning of model users down to the machine level to be a logical next step eh?
<magicaltrout> yeah absolutely. Charm builders need users for installing services in specific user spaces, thats granted, but hackish if you do it in python or whatever
<magicaltrout> charm consumers need users so they can grant access to boxes for specific users by ssh keys/passwords whatever
<magicaltrout> but the grail is also connectivity OOTB to LDAP or something more "enterprisey"
<bdx> magicaltrout: totally
<magicaltrout> when i do stuff with NASA for example, all their boxes are secured with Kerberos, unsurprisingly
<magicaltrout> and it would be great to roll out a charm and have it hook up to a kerberos realm without me pissing about with a bunch of hacks
<bdx> magicaltrout: yeah, a problem I face in my organization as well
<lazyPower> bdx - wanna tune into the fridge again later today? ~ 5:30 normal EOD time for me i'll kick up a stream
<magicaltrout> being able to say "here's my service/unit, here's the users/group in my kerberos setup I want to give access to, now make it so" would be fscking amazing
<lazyPower> magicaltrout - all that is theoretically doable. Kerb is controlled by env vars right?
<bdx> lazyPower: cheaaa!
<bdx> magicaltrout: yea, so a kerberos subordinate!
<lazyPower> bdx aight i may be a bit late. hacking on a layer for a blog post atm. I'll hit you with a link when its got frequency
<bdx> nicccce!
<magicaltrout> oooh it works cmars, must have been a failed upgrade
<cmars> magicaltrout, nice!
<magicaltrout> okay next random question for anyone who wants it
<magicaltrout> I'm creating a relation and I need to create a dynamic name for it, preferably based on the relation id
<magicaltrout> when i'm mid-hook in a reactive charm, can I get the ID?
<magicaltrout> does it even have an ID?
<magicaltrout> :)
<magicaltrout> my thinking being, say a model has 2 different mongo db services
<magicaltrout> a user creates a relation between both and drill
<magicaltrout> I need to create an entry for them within drill, but i also need to know to which relation it belongs so I can remove it
<magicaltrout> come on cory_fu you know crap like that! :P
<lazyPower> magicaltrout - you use the conversation scope and relation-name to give that clearly defined paths of behavior and communication
<cory_fu> magicaltrout: Each relation does have an ID, and you can get them, however in the reactive "world" there may be multiple different relations in a given state at a time, so you're not encouraged to deal with the relation IDs directly
<cory_fu> magicaltrout: I'm also not sure what you mean by "remove it"
<lazyPower> yeah, what cory_fu said
<magicaltrout> okay, so I create a drill service, and a mongo db service
<magicaltrout> I connect the two
<magicaltrout> on the drill side, i run a small rest call to the server to register the datasource
<magicaltrout> then when I remove the relation, i need to prod the same rest service with the name of my blob to delete it
<magicaltrout> this in a 1:1 model where you could only have 1 mongo and 1 drill for example is easy
<magicaltrout> but if I have 2 mongos and 1 drill, i need some dynamic naming convention that I can track to a relation
<magicaltrout> of course mongo could be anything, and the id can be anything, i just want a way to relate my datasources to a specific relation so i can de-register them
<cory_fu> Ok, so if you have 2 mongos connected, I'm going to assume that it will be two different mongo services connected and not the same one connected twice.  If that's true, you could use the name of the service to identify them (which is what lazyPower referenced when he said "conversation scope")
<magicaltrout> alrighty, sounds far more sensible
<cory_fu> magicaltrout: You could also generate a UUID and store that either on the relation data or in the conversation's local data (https://pythonhosted.org/charms.reactive/charms.reactive.relations.html#charms.reactive.relations.Conversation.set_local)
<magicaltrout> service name sounds far more sensible and human understandable
<lazyPower> I'm all for having a simple implementation!
<magicaltrout> indeed
<lazyPower> I'm happy that little blurt of jargon helped actually
<lazyPower> cory_fu *ta* for cleaning up another one of my messes :)
<magicaltrout> from an outsiders/newbie perspective its about trying to figure out the correct patterns
<magicaltrout> because I/we just make it up as we go along
<magicaltrout> mostly from prodding around in python docs and random stuff
<magicaltrout> so Service Name, if i want that lazyPower do I use hookenv.service_name ?
<lazyPower> that works
<lazyPower> make sure you're using distinct names in metadata.yaml for those relations too
<magicaltrout> hmm but the docs say the service this unit belongs to
<lazyPower> oh you're looking for remote_unit
 * lazyPower looks
<lazyPower> 1 sec
<magicaltrout> sounds better
<lazyPower> http://pythonhosted.org/charmhelpers/api/charmhelpers.core.hookenv.html#charmhelpers.core.hookenv.remote_service_name
<magicaltrout> oh yeah
<magicaltrout> what d'ya know
<magicaltrout> who gave it such a sane name
<cory_fu> Oh hey
<cory_fu> Be careful using that in reactive
<lazyPower> +1 to that sentiment as well
<cory_fu> That will only work in an active relation hook context, which may not be the case in reactive
<magicaltrout> what does that mean in english?
<cory_fu> You should instead use Conversation.units or Conversation.relation_ids
<lazyPower> for conv in self.conversations():
<lazyPower> and you can scope it with each conversation id and pull data in/out of the bag
<cory_fu> It means that reactive handlers might be triggered in, say, update-status, and remote_service_name will return None
<lazyPower> yeah, remote_service_name from hookenv relies heavilly on only being used in the hook context, and reactive is a large abstraction away from that.
<cory_fu> You can use conv.scope, as lazyPower suggests, but conv.units (a list) is probably better
<cory_fu> Ok, in a meeting
<lazyPower> i know enough about interfaces to be really dangerous
<lazyPower> cory hasn't hit me over the head about any of them yet... but i don't think he's seen them all
<magicaltrout> okay so help me out here lazyPower if you're not moving too much. I've seen self.conversation() in interfaces
<magicaltrout> so I can call that in a standard reactive charm as well?
<lazyPower> so long as you have an active instance of the interface, and that interface is scope: global
<lazyPower> i think i may be wrong on the last part
<lazyPower> but humor me until we find out otherwise
<magicaltrout> someone needs to write a book on this stuff
<magicaltrout> blimey its confusing
<magicaltrout> Reactive Juju Charms cookbook
<magicaltrout> that is whats needed in this world
<lazyPower> jose was going to then we changed literally -everything- on him
<bryan_att> gnuoy: ping
<magicaltrout> lazyPower: okay so i have a unit list like cory_fu suggests: {'', 'mongodb/0'}
<magicaltrout> so I should get a non null one and extract the service side of it, for a sane naming convention/
<icey> are charmstore revision numbers ever going to be useful anymore?
<lazyPower> zing!
<rick_h_> icey: not really, the goal is to move to channels being meaningful
<magicaltrout> ta
<rick_h_> icey: revisions are just to access stuff not stuck into a channel
<lazyPower> magicaltrout - sounds about right.
<icey> rick_h_: people sometimes refer to us with the rev number so that they can tell us what they had deployed :-/
<icey> oh well
<lazyPower> icey - i dont think that changes. revisions are still a linear thing right?
<rick_h_> icey: that's meaningful if it came from the store, you can stick that in a bundle and replicate their exact setup
<rick_h_> right
<rick_h_> revisions still go up up up
<lazyPower> yeah, the channel just references a revision number
<icey> uhm apparently nope: https://jujucharms.com/ceph-osd/
<icey> rev 2
<godleon> Hi folks, is there any IRC channel for discussing charm of solutions, e.g. OpenStack, Big Data ....?
<icey> after 2+ years of deploying...
<magicaltrout> godleon: you're in it
<rick_h_> godleon: here is as good as any :)
<lazyPower> icey it reset the revision number... did the charm recently change owners?
<lazyPower> that was a known bug at one point
<magicaltrout> all day the charm store has said no owners to a bunch of stuff
<godleon> maficaltrout, rick_h haha, really? I though it should be discussed in mailing list
<godleon> has someone ever tried to deploy multiple hypervisors OpenStack before ?
<rick_h_> godleon: there's a juju mailing list
<rick_h_> godleon: so the newest juju2 and the openstack team are working on multiple hypervisors with a lxd and kvm solution
<rick_h_> godleon: so the openstack folks have definitely been trying it and working on it
<godleon> rich_t oh? Canonical openstack team is working on multiple hypervisors(lxd + kvm) now?
<rick_h_> godleon: yes
<godleon> rick_t, I tried to do deploy that yesterday, but I found it's a little bit buggy.
<rick_h_> godleon: https://jujucharms.com/lxd/xenial/1 ?
<godleon> rick_t, yes, that the one of the charms.
<godleon> rick_t, I found the nova-scheduler can not work properly, maybe I just used the wrong charm relationship, but I am not sure about that.
<godleon> rich_t, I used the LXD openstack bundle as base to modify it to a multiple hypervisors bundle.
<beisner> godleon, we have a proof-of-concept (dev/test) multi-hypervisor test scenario that's in pretty good shape.  although, it is currently only validated with juju 1.25.x.  there are some specific configs and image attributes necessary in order to get the scheduler to place instances appropriately.
<godleon> rick_t, I can see the different hypervisors in Horizon, but it can not work correctly as I expected.
<beisner> godleon, ie.  we can fire up kvm and lxd instances and they do get scheduled to the right type of hypervisor based in image attributes.
<godleon> beisner: ok, what image attributes should I input? and where should I input???
<bdx> beisner: hey! thats awesome!
<bdx> beisner: where is that being developed?
<godleon> beisner, yes, I saw that in the youtube video, but bcz I didn't see the demo, so I don't know how to set the image attributes.
<beisner> as soon as launchpad comes back to life i can link you guys to the dev/test (ymmv/bleeding) bundle
<beisner> which includes a lil readme to describe the deploy/post-deploy config/basic test process
<beisner> hey bdx !
<godleon> beisner: do you mean readme for multiple hypervisors?
<beisner> godleon, it's a poc test scenario.  not official documentation, nor is it intended for production as it uses the tip/master charm set.  but this has been working since ~January so the stable charms should have the same basic functionality.
<beisner> one could substitute our git: blah  charm branches for pinned charmstore revisions (stable charms)
<beisner> i think at some point we may publish an official bundle, but i suspect seeing our test approach will give all the info one would need to take it for a spin.
<beisner> bdx, godleon, there is a network outage at the moment, not sure how long that will last.  i'll paste a link back here for reference later.  o/
<godleon> beisner: ok, thank you very much! :)
<magicaltrout> woop thanks lazyPower. That seems way harder than it should be (for a newb) but it appears I have a working mongodb relation
<magicaltrout> \o/
<lazyPower> magicaltrout the first one is always the trickiest :)
 * magicaltrout dumps some data into mongo to test SQL access
<lazyPower> and pat yourself on the back knowing you've accomplished one of the hardest things to do in juju according to > 3/4 of the people i've onboarded
<magicaltrout> like the actual code, I don't have a problem with its easy enough to grep your way around. But I come from a java world where when stuffs broken we just attach a remote debugger and step through it in the IDE. In python & debug-hooks whilst its a great way to stab stuff, its still pretty complex to be able to debug you code, especially now in reactive world
<magicaltrout> again thats probably more lack of understanding as opposed to it actually being stupidly complex, but it does make life hard
<magicaltrout> https://ibin.co/2j5wKx7V1x6C.png there you go lazyPower
<magicaltrout> sql over mongodb powered by some juju hacking
<lazyPower> nice!
<magicaltrout> i actually have a proposal in with a client to create an elastic search adaptor for drill
<magicaltrout> i don't think they'll go for it, but if they did, it could be SQL over beats ;)
<arosales> lazyPower: as I don't see mbruzek around atm I wanted to ask if there was a pull request for updating k8 upstream
 * arosales didn't see one @ https://github.com/kubernetes/kubernetes/pulls but I may have missed it
<arosales> lazyPower: also https://github.com/kubernetes/kubernetes/tree/master/cluster/juju/layers/kubernetes is missing a LICENSE file which I think needs to be Apache
<arosales> and copyright
<arosales> and I guess the bundles @ https://github.com/kubernetes/kubernetes/tree/master/cluster/juju/bundles should have something similar to https://api.jujucharms.com/charmstore/v5/bundle/hadoop-processing-3/archive/copyright
#juju 2016-06-01
<lazyPower> arosales iirc we were still pending making that PR to the upstream repo
<kjackal> admcleod-: So yes
<kjackal> almost working HBase
<kjackal> HBase is very cool
<admcleod-> kjackal: why is that!
<kjackal> I knew the internal indexing structure that they implement but i've never seen how it is setup
<magicaltrout> kjackal: you'll know this. If I want to use a 3rd party python lib in my reactive charm, how do I package it?
<admcleod-> ooh ooh i know
<magicaltrout> or you
<kjackal> what do you mean by third party? It cannot go to wheelhouse
<admcleod-> but .. oh, apparently i dont know
<admcleod-> never mind! ;)
<admcleod-> kjackal: how is it to actually use?
<magicaltrout> see, now I don't know what you're saying
<kjackal> lol
<admcleod-> magicaltrout: i was going to say, if you can pip install it, then you can just put it in wheelhouse
<magicaltrout> charm -> random python lib -> build -> deploy
<magicaltrout> okay, remember I stupid. How do you "just put it in wheelhouse"
<magicaltrout> clearly when you compile your charm, wheelhouse appears
<kjackal> let me find
<admcleod-> magicaltrout: well, again, i thought you could put it in wheelhouse.txt, e.g. https://github.com/juju-solutions/layer-apache-bigtop-resourcemanager/blob/master/wheelhouse.txt
<kjackal> https://github.com/juju-solutions/layer-apache-spark/blob/master/wheelhouse.txt
<magicaltrout> men of many links
<magicaltrout> thanks
<kjackal> :)
<admcleod-> kjackal: why did you say 'it _cannot_ go to wheelhouse'?
<kjackal> admcleod-: Sorry I was asking
<kjackal> forgot the "?"
<magicaltrout> the vital missing questionmark
<admcleod-> kjackal: ah, i see, so you used all your ?s up in the shortest conversation ever
<magicaltrout> english is a fickle language
<kjackal> yeap!
<admcleod-> yes. dont i know it.
<magicaltrout> indeed semi scot
<admcleod-> i got nothin
<magicaltrout> i had a blue cheese chocolate in my speakers gift from apachecon
<magicaltrout> it was awful
<admcleod-> lol
<magicaltrout> not speaking in vancouver again
<admcleod-> maybe they just assumed, from your sophisiticated queens english, that you would appreciate the finer things, and then gave you something else instead
<admcleod-> anyway i swear, it works if its done right.
<magicaltrout> lies
<admcleod-> i would never
<magicaltrout> kjackal: when you have working hbase
<magicaltrout> https://phoenix.apache.org/Phoenix-in-15-minutes-or-less.html build a phoenix subordinate
<magicaltrout> oh there is one in bigdata-dev
<kjackal> magicaltrout: That is cool! SQL!
<magicaltrout> what do i know
<magicaltrout> okay when you've finished hbase
<magicaltrout> make sure phoenix in bigdata-dev works ;)
<magicaltrout> ah that one is pretty old
<magicaltrout> okay we'll revamp that
<admcleod-> magicaltrout: i bet you a pint you could do it quicker
<magicaltrout> admcleod-: doubt it, I've got to see SaMnCo tomorrow, and fly to san diego on Friday followed by a week of hacking broken stuff
<magicaltrout> actually... you're probably right, but i should really do stuff that earns me money, not endlessly hack charms ;)
<admcleod-> yeah but a pint
<magicaltrout> i know, its tempting! ;)
<kjackal> magicaltrout: Phoenix seems to be in bigtop, but it does not have puppet scripts. Thats cool!
<kjackal> magicaltrout: cool in the sence we can contribute the puppet scripts as well!
<magicaltrout> kjackal: you basically just need to chuck the right libs in the libs dir and it sorts it out
<admcleod-> it shouldnt take us long but we'd have to backlog it for a bit until we get some other higher priority bits done
<magicaltrout> so it should be pretty straight forward to bootstrap in bigtop
<admcleod-> kjackal: its probably in a feature branch
<magicaltrout> https://drill.apache.org/docs/hbase-storage-plugin/ I also need to figure out how to crowbar juju hbase into phoenix
<magicaltrout> s/phoenix/drill
<kjackal> Oh come on magicaltrout this is a piece of cake for you now!
<magicaltrout> hehe its certainly getting easier, doesn't make me a living though does it? :P
<magicaltrout> not yet at least. But this is why I'm working on the Drill/SQL side of things because it means we do get that all in one end to end solution, that makes it easy to demo to clients
<admcleod-> eating blue cheese chocolate doesnt make ANYONE a living, but we still do it.
<magicaltrout> hehe, indeed
<admcleod-> magicaltrout: so this talks about inserting this storage plugin info via the web ui - i guess from a charm perspective its an insert statement (or maybe even just appending to a config file)
<magicaltrout> admcleod-: yeah, it has a rest API, so for my mongo test I just prod it in python with some connection details
<admcleod-> magicaltrout: ill make a note to discuss both of these things @ our next sync
<admcleod-> magicaltrout: in a few hours
<magicaltrout> you could write a file, but you'd need to cycle your drill cluster, so I use the rest api instead which just writes to ZK and updates the cluster
<magicaltrout> in reality, I'm more interested in HDFS and Filesystem based connectivity initially, so I'll be working on those later
<magicaltrout> so I can dump GB's of Parquet files into HDFS and have distributed Drill query them
<admcleod-> right
<magicaltrout> if you install Drill onto your slave nodes, it will keep the data for that node on that node, whilst doing some distributed SQL to keep the data local, which gives a good performance boost
<magicaltrout> data locality and all that
<admcleod-> who'da thought
<magicaltrout> well its logical, but its hard for SQL engines to do
<magicaltrout> distrtibuting a query and running it on different nodes then collating the result
<admcleod-> yep
<magicaltrout> whats the deal with juju storage
<magicaltrout> is it worth my while adding it to the charm?
<magicaltrout> like is it enough of a *thing*?
<admcleod-> babbageclunk: so, tell us, whats the deal with juju storage, is it worth _someones_ while adding it to their charms? like.. is it enough of a __**thing**__?
<admcleod-> magicaltrout: ;}
<magicaltrout> pfft
<magicaltrout> so drill also supports filesystem based access of CSV's/JSON stuff, so I was thinking of adding Storage support
<admcleod-> magicaltrout: well, i know very little about it so i was asking babbageclunk
<babbageclunk> admcleod-, magicaltrout: I'm pretty new, so I don't know *that* much about it either. What kinds of things are you wanting to know?
<magicaltrout> not much, i'm just writing a charm for apache drill. One thing it supports is SQL analysis over local CSV/JSON/Parquet files. Now, this is entirely optional and probably not used *that* much, but if someone did use it, I was thinking about juju storage support for it
<magicaltrout> but was wondering a) if it was worth it (this is just idle gossip, I realise) b) if its enough of a *thing* that it wont go missing in a few releases time
<babbageclunk> magicaltrout: I'm fairly sure it's not going anywhere - it's really a requirement for more careful deployments.
<admcleod-> magicaltrout: at a lower (infrastructure) level, how would you envisage using it/
<admcleod-> ?
<magicaltrout> admcleod: something like, person deploys charm in EC2 XLarge or something, but then tacks on a couple of TB of SSD/High performance disks or something
<magicaltrout> for example, Drill supports querying of multiple CSVs as a single table. So your app writes to a high performance filestore in various directories and files. At which point Drill has a plugin configured to use that folder. So you can then run
<magicaltrout> select * from my_files
<magicaltrout> and it will traverse your entire file storage pool
<magicaltrout> not everyone in this world wants to run a HDFS cluster ;)
<babbageclunk> magicaltrout: I might be wrong, but I think the juju storage features are less about machines that get storage added later, and more for restricting where a charm gets deployed to.
<magicaltrout> fair enough
<magicaltrout> i'll skip it then
<admcleod> magicaltrout: are you saying, kind of 'preferential' storage utilisation, i.e., you add 10TB SSD, and then it 'prefers' to use that because its tagged as high-iops, for example
<magicaltrout> yup
<admcleod> magicaltrout: or, just that that new disk would be part of a larger...
<admcleod> ..storage array
<magicaltrout> well it makes no odds to me, I was just making sure I wasn't missing a trick there :)
<babbageclunk> magicaltrout: Or if you're deploying to AWS or OpenStack then the charm can grab storage from EBS or Cinder when it's being deployed.
<admcleod> magicaltrout: actually i think it sounds like a good idea for io intensive stuff
<magicaltrout> because its hook based
<magicaltrout> I can, it appears, add the pool to Drill via a hook just like I do with any other data source
<admcleod> magicaltrout: yeah so you could ideally have your charm deploy and go 'ok ill use whatever disk is available but prefer something tagged SSD' for example - then on hook 'oh ssd has been added' *charm stuff*
<magicaltrout> yup
<magicaltrout> if someone adds storage to a drill node, you'd assume its for data processing, so create a datasource storage entry within drill to use it
<admcleod> magicaltrout: sounds like a very nice idea. (with lots of further potential too)
<babbageclunk> magicaltrout: I think I was wrong about that - I'm only familiar with the constraint/deploying parts, but adding extra storage to the unit later sounds really handy.
<magicaltrout> the other case as well, is, the amount of times I've deployed a MySQL staging DB with what I thought was enough storage.......
<magicaltrout> and 6 months later when my client has gone mental and used the DB for stuff they shouldn't
<magicaltrout> you blow your disk space and end up with random unmanaged mount points all over the place, tacking on extra storage
<magicaltrout> which you know full well if the server dies you're screwed because you couldn't replicate it in a month of sundays :)
<admcleod> magicaltrout: yep for sure, seems like there may be a few ways to achieve that too
<magicaltrout> okay back to more mundane matters. I want to implement an HDFS relation admcleod
<magicaltrout> is there an interface that will provide me with the namenode ip and port?
<magicaltrout> https://github.com/juju-solutions/interface-namenode-cluster ?
<admcleod> magicaltrout: thats the peer relation.. you want...
<admcleod> magicaltrout: https://github.com/juju-solutions/interface-dfs
<magicaltrout> cool thanks
<admcleod> magicaltrout: or actually https://github.com/juju-solutions/interface-dfs-slave
<admcleod> magicaltrout: or.. use the plugin
<admcleod> magicaltrout: cos if you use the plugin itll install hadoop for you, configure hadoop correctly.. and the interface-plugin will give you the namenodes and port
<magicaltrout> yeah so I see
<magicaltrout> I don't need hadoop installed but lets run with that
<magicaltrout> where's charms.templating gone in juju2?
<magicaltrout> gaa
<magicaltrout> wtf
<magicaltrout> admcleod: https://github.com/juju-solutions/interface-hadoop-plugin
<magicaltrout> in my charm to interface with the plugin I want something like:
<magicaltrout> https://gist.github.com/buggtb/ff2d2e26b45657bfcc7566a393bb9b7d ?
<magicaltrout> i think you sold me a lie admcleod
<magicaltrout> because I don't provide hadoop stuff, but similarly I don't connect to hadoop client, pig etc
<lazyPower> kjackal congrats on the +2 on your ~charmer app
<kjackal> lazyPower: Thank you! I can now offload cory and kevin from some of the promulgation tasks
<lazyPower> if anyone missed it and has worked with kjackal and would like to endorse his application - https://lists.ubuntu.com/archives/juju/2016-May/007273.html   :) the more the merrier i always say!
<kjackal> lazyPower: Thank you for your vote of confidence
<lazyPower> its firmly seated though :D you're comin with us to the front lines
<admcleod> magicaltrout: sorry, i got caught up in diagnosing some io problems + lunch, did you get anywhere?
<magicaltrout> yeah no worries admcleod
<magicaltrout> I ended up using the dfs interface
<magicaltrout> got it mostly strung together I think
<admcleod> magicaltrout: right... just as a note, in this case drill is the client, attaching to hadoop, so if it did need hadoop installed it would be appropriate.
<magicaltrout> yeah, I have used the plugin layer elsewhere
<admcleod> cool
<magicaltrout> but in this instance its just prodding a hdfs endpoint somehow
<admcleod> yup
<magicaltrout> okay well the relation seems to work
<magicaltrout> time to find out if it can actually query any data
<LiftedKilt> has anyone deployed cephfs with juju?
<LiftedKilt> I don't see a metadata server charm - unless I'm just completely blind
<admcleod> cory_fu: are there any other bigtop layers which are including apache-bigtop-plugin as a layer?
<magicaltrout> https://ibin.co/2jB6YH1bwE6G.png
<magicaltrout> woop
<magicaltrout> very boring sample data out of hdfs
<admcleod> magicaltrout: nice one.
<magicaltrout> aye, needs some tidying up and yet more config options, but not bad
<cory_fu> admcleod: Yeah, should be.  One second
<cory_fu> admcleod: Spark is using it via hadoop-client: https://github.com/juju-solutions/bigtop/blob/spark/bigtop-packages/src/charm/spark/layer-spark/layer.yaml
<cory_fu> admcleod: Note that you should not be adding 'layer:hadoop-plugin' to layers.yaml; instead you should add 'layer:hadoop-client'.  Or, if you want to do it manually, 'interface:hadoop-plugin' and then add the relation to metadata.yaml
<admcleod> cory_fu: ah, i see - thanks :)
<kwmonroe> petevg: really nice job on the bigtop layer readme!  https://github.com/juju-solutions/layer-apache-bigtop-base/pull/11 is merged.
<LiftedKilt> rick_h_ marcoceppi: have you seen anyone working on a metadata server charm for cephfs?
<marcoceppi> LiftedKilt: not sure, but icey or cholcombe would be the ones who knew if someone was
<LiftedKilt> marcoceppi: thanks for the heads up - wasn't sure who to direct the question to
<cholcombe> LiftedKilt, yes that's on the roadmap
<cholcombe> LiftedKilt, https://github.com/openstack-charmers/charm-specs/pull/2
<cholcombe> LiftedKilt, do you have a few cycles to help or want to be on the review once it's posted?
<LiftedKilt> cholcombe: I'm always happy to help
<LiftedKilt> cholcombe: so the current plan is to release the cephfs charm concurrent with the newton cycle?
<lazyPower> magicaltrout - you still kicking around over there?
<cholcombe> LiftedKilt, Hopefully much sooner
<LiftedKilt> cholcombe: awesome - I need to start deploying ceph immediately, but I can wait on cephfs for a little bit during the transition
<LiftedKilt> have a 250 node lizardfs cluster that had some...ahem...data loss last week
<cholcombe> LiftedKilt, ok.  We just started a review on the ceph base layer.  https://review.openstack.org/#/c/323574/  Once that is settled we can leverage that for the ceph-fs layer which should be very small
<cholcombe> LiftedKilt, lizardfs sounds familiar.  I seem to remember that being a fork of something
<LiftedKilt> it's a fork of moosefs
<cholcombe> right!
<cholcombe> how did it sustain data loss?
<cholcombe> i'm just curious.  i know almost nothing about it
<petevg> kwmonroe: Cool. Thx for the review/merge :-)
<LiftedKilt> the primary metadata server went down because of some unrelated network problems. It failed over to the backup metadata server, which it turns out had pretty stale metadata
<LiftedKilt> the backup then said "I have 250,000 more chunks than I should - better start deleting them!"
<LiftedKilt> oops haha
<cholcombe> wow
<cholcombe> i really despise metadata servers in distributed filesystems
 * cholcombe remembers much pain with hadoop
<cholcombe> LiftedKilt, so the plan is to start breaking off chunks of lizard and converting them to ceph?
<cholcombe> LiftedKilt, if you need NFS you're prob better served using glusterfs
<aroundabout> What constraint on juju bootstrap can be set to select a specific AWS EC2 region?
<aroundabout> I'm able to select instance-type=t2.micro
<aroundabout> But region= throws an error unknown constraint "region"
<aroundabout> Using juju version 2.0-beta7-xenial-amd64
<rick_h_> aroundabout: what version of Juju?
<aroundabout> Using juju version 2.0-beta7-xenial-amd64
<rick_h_> aroundabout: http://askubuntu.com/questions/172643/can-juju-be-used-in-other-region-than-the-us shows for 1.25
<rick_h_> aroundabout: and for juju 2.0 you should be able to bootstrap with --config region=eu-west-1
<rick_h_> to follow the examples from there
<aroundabout> Thanks I'll run it. I was using --bootstrap-constraints
<rick_h_> aroundabout: ah, yes that's the old way. It's simpler with the --config key=value syntax
<aroundabout> The command is not working.
<aroundabout> It still punts the juju agent to us-east-1
<aroundabout> `sudo juju bootstrap --config region=eu-west-1 aws-devenv-controller aws`
<rick_h_> aroundabout: sorry, looking
<rick_h_> aroundabout: oh so sorry, I lead you wrong there
<aroundabout> I may have just noticed something vital
<aroundabout> # juju bootstrap [options] <controller_name> <cloud_name>[/region]
<aroundabout> That usage has an optional [/region] part I've never used.
<aroundabout> I also think that's new since 1.0
<aroundabout> Yup, worked
<aroundabout> I'll update that SO question.
<magicaltrout> you rang lazyPower
<lazyPower> magicaltrout - http://54.175.167.243/app/kibana#/dashboard/Packetbeat-Dashboard
<lazyPower> you had made mention of packetbeat? here's where i'm at with the layer
<lazyPower> might want to expand the data-range to ~ 1 hr or greater
 * magicaltrout stabs some buttons
<magicaltrout> looking sweet lazyPower
<magicaltrout> thats very useful
<bdx> admcleod: hey, just diving into your puppet refactor/merge now
<bdx> admcleod: I've a few things to run by you when you have a moment
<lazyPower> o/ bdx so i hear you'r einterested in packetbeat. https://github.com/juju-solutions/layer-packetbeat is current if you'd like to get in early on the comment threads/issue tracker :)
<bdx> you know it
<lazyPower> no readme, its for the intrepid explorer
<lazyPower> #noregrets
<bdx> ha, perfect
<mbruzek> arosales: ping. I addressed the issues you created with the Kubernetes readme in https://github.com/juju-solutions/bundle-observable-kubernetes/pull/15
<mbruzek> arosales: please review when you get a chance, so we can update and get the bundle promulgated
<mbruzek> Assuming it passes your review
<arosales> mbruzek: hello, thanks for working on that. I'll take a look this afternoon
<lazyPower> mbruzek - i took liberty of some prelim review nits. I wont merge until arosales has taken a look though
<bdx> lazyPower: what to do about geo_points?
<lazyPower> bdx - https://www.digitalocean.com/community/tutorials/how-to-map-user-location-with-geoip-and-elk-elasticsearch-logstash-and-kibana
<bdx> yeah, I know ...
<lazyPower> bdx - if you have time, plugging that in would be choice
<lazyPower> even if you rough cut it, i can throw finishing touches on it
<bdx> lazyPower: what I'm thinking is a modification to the logstash http-relation-joined?
<bdx> such that it would write out 11-nginx-filter.conf
<bdx> if config['log_geo_point']:
<bdx> render_nginx_geo_point_filter_conf
<bdx> mmmm
<lazyPower> currently logstash isn't shipping with any configuration for transforms. I see this being a config-addition to layer-logstash. packetbeat already supports shipping through logstash by virtue of beats-base
<lazyPower> so i dont think you can get away with the nginx-filter.conf
<bdx> lazyPower: but logstash needs to extract the client ip, and convert it using the geoipdatabase
<lazyPower> this will need to be leveraging whatever the beats protocol mandates for geoip data. none of the graphs in the default setup uses anything than the beats shippers, so we should look closer at the docs. I think that do article i got from jcastro is a red herring
<bdx> looks like that is done with the nginx-filter.conf, no?
<lazyPower> bdx - https://github.com/elastic/beats/issues/60
<lazyPower> this looks applicable to our topic.
<lazyPower> they're using the geoip-database package, and just configured packetbeat with teh path to the db
<lazyPower> i think the shipper does this all already, we just need to tell it to do so, and make sure we've got the package installed
<bdx> yea, same as the link you linked me
<bdx> lazyPower: what I'm getting at is the other part of the implementation ... how to tell logstash to provision that file
<lazyPower> bdx - you dont need to tell logstash anything :)
<lazyPower> if you configure it on the beat shipper, it ships w/ all the required data needed. the dash is already setup to read and translate that lat/long data
<bdx> yeah, but logstash has to get that data
<bdx> from what I can tell, that is done with nginx-filter.conf -> http://paste.ubuntu.com/16902035/
<lazyPower> bdx - hrm, i think there's a disconnect here in what i'm thinking and you're thinking.
<lazyPower> Thats only if you need to transform teh data coming from the beat...
<lazyPower> if the beat is already encoding that geo-ip data, why do you need to ngrok it?
<bdx> lazyPower: I see that, I'm unclear on where the geoip data is being generated, how does it exists?
<lazyPower> its a lookup between the ip and whatever the geo database has for where that ip originates
<lazyPower> ipv4 is a very final database at this point, the last ipv4 address having been sold a few months ago
<lazyPower> not sure how this will stand up to ipv6 geo-ip data, but for ipv4 this database they're listing for curl has all that for us. its basically a lookup table for the golang shipper to compare client_ip with that db and pull out the lat/long of its origin
<lazyPower> curl http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz -o /usr/share/GeoIP/GeoIP.dat.gz <- this thing
<bdx> I see .... if nginx is logging to nginx-access.log, and you have nginx-access.log shipping to elastic/kibana via filebeat
<lazyPower> i would hook up packetbeat for that, its reading the http headers
<lazyPower> 1 sec let me get you a link of what the packetbeat monitor is actually sending
<bdx> i see http://54.175.167.243/app/kibana#/settings/indices/packetbeat-*?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-15m,mode:quick,to:now))&_a=(tab:indexedFields)
<lazyPower> http://54.175.167.243/app/kibana#/discover
<lazyPower> search for "mediawiki"
<bdx> lazyPower: hmmm, no results show
<jrwren> you should be aware that the maxmind geoip db is not very accurate. If you need accurate geoip databases, they are out there, often for purchase. neustar has a pretty good one.
<lazyPower> jrwren - that was my initial response to the problem domain. Free by default is fine, i think what we'll do is resource it, and provide the db as an interchangeable thing
<magicaltrout> Juju GUI should support charm configuration pagination.... that is all.
<lazyPower> you start with free, and can provide your own if you've got a fancy geoip db
<jrwren> sounds great.
<lazyPower> unless we're in good with a geoip provider and i dont know this? :D
<jrwren> I've seen a lot of folks expect a bit too much from the free maxmind data and be disappointed when things are incorrect.
<lazyPower> yeah, i wonder what those vendors will do now that the database is basically done and the ipv6 rollout has to happen
<lazyPower> bdx - hang on, i'm modifying the packetbeat install by hand on the unit
<lazyPower> we'll see if this works and then i'll land some code if it does
<jrwren> its far from done. really good database track ip moves down to the customer DHCP lease. e.g. I get a new IP from my ISP, the geo ip database vendor detects this and updates that data.
<lazyPower> yeah?
<jrwren> yup
<lazyPower> i didnt know you were so tapped into the wire
<lazyPower> hook me up jrwren
<jrwren> previous job.
<jrwren> i can send you 2+yr old data ;]
<lazyPower> ;_;
<jrwren> see the pretty animated red dots on the map: http://atlas.arbor.net ? ;]
<jrwren> also, keep in mind: http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/
<arosales> mbruzek: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/15 lgtm
<arosales> mbruzek:  before promulgating the bundle I think we just need to address issue 9 and 10
<mbruzek> arosales: thanks
<arosales> mbruzek: cory_fu has an update to add a config option to kibana to load the dashboard. So you would need to make a charm update in the bundle as well as set the config option. We will need to add instructions in the bundle readme on how to access the kibana dashboard
<arosales> mbruzek: also suggest to expose the services, per issue 10, which is a bundle.yaml update
<petevg> cory_fu, kwmonroe: do we have a shortcut in the charm tools for getting the ip address of the unit that you're running a command from?
<arosales> mbruzek: lazyPower: most of my comments are UX polish, thanks for your work on those bundles.
<mbruzek> arosales: the bundle already exposes those charms.
<mbruzek> I am adding words to unexpose them now
<lazyPower> arosales on that veign, i saw the repository had a non-obvious naming. i've renamed it and its here: https://github.com/juju-solutions/bundle-swarm-core
<arosales> mbruzek: ah excellent, was that a recent update?
<arosales> lazyPower: it was obvious before. I just missed it
<lazyPower> bundle-swarm-consul doesn't tell me its swarm-core in the store :/
<lazyPower> i shouldn't be allowed to name things
<kwmonroe> petevg: charmhelpers.core.hookenv.unit_get('private-address')
<mbruzek> arosales: I don't know there were some merges to the bundle that were queued up, butI don't think any of them were specifically for exposing the charms.
<arosales> well I was looking for observable-swarm
<petevg> kwmonroe: thank you.
<arosales> lazyPower: which I found. I was just mult-tasking and logged issues under the wrong repo
<arosales> lazyPower: I think https://github.com/juju-solutions/bundle-observable-swarm/issues is the correct location for the issues against the observable-swarm bundle
<lazyPower> ah
<lazyPower> well that one was obvious, clearly i didnt name it
<lazyPower> :)
<arosales> mbruzek: ack, i see those now @ https://github.com/juju-solutions/bundle-observable-kubernetes/blob/master/bundle.yaml
<arosales> mbruzek:  thanks, so some instructions on accessing the kibana console and ensuring your are using the latest kibana with cory_fu config option to load the dashboard and that should resolve my issues
<arosales> mbruzek: lazyPower, cory_fu: we should use the same verbage on how to access the kibana dashboard as swarm, k8, and spark bundles all use beats for logging
<lazyPower> i can make some pretty gifs to do it
<lazyPower> http://imgur.com/tgYFSjM
<arosales> lazyPower: do animated gifs render in the charmstore readmes?
<lazyPower> i'm not sure. There's an open bug against jujucharms.com to support GFMD
<lazyPower> i know the docker icon showed up when i had that embedded in the docker charm, no reason to think thats changed unless they are now explicitly blocking image tags
<arosales> and most admins should have access to a web browser to read the instructions if they are viewing them locally
<arosales> or query the charm store if they are new to kibana and want to see instrucitons
<arosales> lazyPower: that would be great if the charm store renders it. I guess we could test it in /u/containers
<lazyPower> or /u/arosales :D
<lazyPower> \o/ charm push liberates us to experiment
<arosales> mmmm, no ingestion wait times :-)
<lazyPower> i realize thats an optimistic goal, to have you push the test :) you're a busy dude
<magicaltrout> sat, writing charms when I should be packing
<magicaltrout> what have I forgotten?
<magicaltrout> i'll ask here instead of just looking in my suitcase
<arosales> lazyPower: no worries at all, you guys are busy too :-)
<lazyPower> so long as you hvae your gutchies you'll do fine magicaltrout
<arosales> lazyPower: I am looking at https://jujucharms.com/u/containers/observable-swarm/bundle for a refresh
<magicaltrout> you know i had to google that lazyPower :P
<arosales> magicaltrout: as long as you have your charms, power adapter, and computer your set
<magicaltrout> arosales's answer is more accurae
<magicaltrout> t
<lazyPower> I dunno man, i could do a lot more with gutchies  than i can a power adapter when things are going sideways
<magicaltrout> supposedly my plane has at seat power, so i might get the ultimate amount of work done
<magicaltrout> i love flights to just get backlog stuff cleared
<arosales> lazyPower: really gutchies, SW Pennsylvanian slang for underwear.
<arosales> magicaltrout: seat power and wireless. I love it when that happens
<arosales> lazyPower: lolz
<magicaltrout> ah no you see. I'm happy i'm on flights w/o internet
<magicaltrout> because it makes you do the stuff you keep putting off
<lazyPower> i use flights as the opportunity to unplug
<magicaltrout> yup
<lazyPower> and if i can load up some beats and just chill on the flight, thats ok by me
<magicaltrout> i'm not usually on flights w/ power
<arosales> magicaltrout: ah interesting, no network distraction, but power still
<lazyPower> magicaltrout - want 54 minutes of triphop to keep you company on the flight?
<magicaltrout> arosales: it could be a lie, i could get on and find no power and 5 hrs battery life
<mbruzek> arosales: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/16 <-- Please review
<magicaltrout> hook me up lazyPower
<lazyPower> https://slack-files.com/T04G0GYCP-F1D9BUE57-0209e54ffd
<arosales> magicaltrout: note lazyPower's beats are addictive
<magicaltrout> hehe
<lazyPower> you flatter me :)
<arosales> lazyPower: where is your gif readme pushed to? I was looking at https://jujucharms.com/u/containers/observable-swarm/bundle
<lazyPower> arosales - we're testing it out now. but all signs point go awesome when the next k8s readme goes up
<lazyPower> sorry, observable-k8s-bundle
<arosales> lazyPower: probably also need to apply the updated kibana dashboard config to https://jujucharms.com/beats-core/bundle with same readme instructions
<arosales> mbruzek: hammering on it huh :-)
 * arosales will take a look @ https://github.com/juju-solutions/bundle-observable-kubernetes/pull/16
<magicaltrout> here's a random question thats more useful than discussing underwear
<lazyPower> debateable
<magicaltrout> with lazyPower et al  working on beats
<magicaltrout> will it one day become like juju gui, and just something that happens?
<lazyPower> i think with cross environment relations, sure
<lazyPower> sorry
<lazyPower> cross model
<lazyPower> old habits die had
<lazyPower> *hard
<lazyPower> in the fact you can relate it to something thats not physically in your model map, but is related to
<lazyPower> you basically deploy the beats you want, and relate it to whatever your central collector is running elsewhere
<lazyPower> i think there will still be a lot  of room fo rthis ot be hot pluggable. Beats isn't the only metrics game in town. I've been questioned about monitoring using promethius
<lazyPower> but now i'm rambling
<magicaltrout> cool. Seeing Beats within or alongside GUI along with extended stuff like Status within GUI would be cool. Not that I'm a  big Juju  GUI user but adding something like beats just adds to the usability
<lazyPower> oh certainly. I'm still a fan of tools like weave-scope to visualize the container topology running in the cluster
<lazyPower> its not as powerful as juju, but just being able to visualize the network map is a strangely handy tool
<magicaltrout> yeah thats for certain
<lazyPower> and sure, you win. this was more useful than talking about gutchis
<arosales> mbruzek: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/16 lgtm
<magicaltrout> hehe
<magicaltrout> I'm waiting slowly for Drill & Hadoop on EC2 to check it works so I can blog it tomorrow
<magicaltrout> more stuff I can get done whilst sat on a train
<arosales> mbruzek: cory_fu, lazyPower we just need to coordinate the kibana updates to the observable-swarm bundle and the spark-processing bundle
<mbruzek> arosales: let mine be the template and all is good
<arosales> cory_fu: and lazyPower note ^
<marcoceppi>  or, progressively
<skay> bloodearnest: hey, thanks for https://gist.github.com/bloodearnest/ebf044476e70c4baee59c5000a10f4c8
<skay> bloodearnest: I'm still in the process of learning set up a dev environment in lxd for my work, and that helped
<bloodearnest> skay, no worries, it's working well for me
<skay> bloodearnest: <picture a mug of beer or some favorite beverage here>
<bloodearnest> skay, are you using it with juju?
<skay> bloodearnest: not yet.
<bloodearnest> it does work, fwiw
<bloodearnest> I have a setup that works, using manual provider, and manually creating the lxd
<bloodearnest> then deploying the charm onto that
<magicaltrout> https://github.com/apache/incubator-joshua/tree/master/distribution/joshua-full there you go arosales, we're still working on the implementation details as the incubator project works through the paces, but a charm in another ASF project
<arosales> cory_fu: is zookeeper not promulgated ?
<arosales> cory_fu: https://jujucharms.com/u/bigdata-dev/apache-zookeeper/trusty/20
<magicaltrout> https://jujucharms.com/apache-zookeeper/trusty/
<magicaltrout> i've been using that for the last 2 days
<arosales> magicaltrout: ah thanks :-)
<arosales> magicaltrout: and great to see joshua-full and I hear your working on drill
<arosales> magicaltrout: ramping up the apache projects :-)
<magicaltrout> yeah drill is up and running sorta. enough for people to use at least
<lazyPower> jcastro http://i.imgur.com/Yk4GHhs.png
<magicaltrout> some patchy relations to mongodb and HDFS
<magicaltrout> need to clean that up a bit, but the actual setup is pretty straightforward, of course I could spend months adding config options
<lazyPower> jcastro mbruzek - sorry i fixed it http://i.imgur.com/1RDywtV.png
<mbruzek> we rock
<mbruzek> assult cube is a punk
<aisrael> I had a juju 1.25 env running on trusty, and upgraded to xenial. Now, when I boot up, I can't get juju to run (no api server). Specifically, `sudo service juju-db-stone-local start` throws the error "Failed to start juju-db-stone-local.service: Unit juju-db-stone-local.service not found." Any ideas where to start debugging that?
<cmars> aisrael, sounds like the upgrade didn't successfully navigate upstart -> systemd
<cmars> i'm not even sure if that's supported tbh
<cmars> aisrael, hmm, maybe try `sudo service jujud-machine-0 start` ?
<cmars> aisrael, that's what the systemd unit is named on my xenial controller
<cmars> oh, but that's 2.0, nvrmind
<cmars> aisrael, does `systemctl list-units` show anything juju-related?
<aisrael> There's only two scripts in /etc/init, juju-agent and juju-db
<aisrael> cmars: no juju
<cmars> aisrael, scripts in /etc/init or upstart confs?
<aisrael> cmars: /etc/init. Where else should I be looking?
<cmars> aisrael, if there's no juju showing up in `systemctl list-units`... i think you'll need to create these units on your system to start the agent & db as the upstart confs used to
<cmars> aisrael, i'm not sure to what extent 1.25 supports post-upstart distros. i thought it did, but even so, it might only set up the init on bootstrap
<aisrael> cmars: ack, thanks. So on Xenial, juju should be using systemd, and those script(s) are missing for me
<cmars> aisrael, yeah. i think this might be a bug worth opening
<aisrael> cmars: Will do, thanks for the debug help!
<rloloc> I want to drop a controller, but I get stuck with repeating "Waiting on 1 model, 2 machines" notification.
<rloloc> How can I flush everything. These are machines seem to be misbehaving or not configured.
<rloloc> I opted to just drop the lxd container manually and re-bootstrap. Was there another way?
<lazyPower> and on the topic of beats, they just keep multiplying
<lazyPower> https://www.elastic.co/guide/en/beats/metricbeat/master/metricbeat-overview.html
<aisrael> nice
#juju 2016-06-02
<admcleod> bdx: hello
<magicaltrout> f* me I'm tired. Stupid bloody kids
<magicaltrout> dont have 'em
<kjackal> magicaltrout: what would you prefer human cloning or time travel?
<magicaltrout> hmm its a good question
<magicaltrout> like I worry about dying because I'll miss out on stuff. So I guess time travel falls into the same bucket
<magicaltrout> but at the same time, cloning only works, if I can merge at the far end ;)
<kjackal> magicaltrout: you could outsource your kids to your other you!
<magicaltrout> i could simplify it and just get a nanny :P
<magicaltrout> that said... the mrs wont even let us get a cleaner because... and I quote "our house is too dirty"......
<admcleod> magicaltrout: may i make a suggestion
<magicaltrout> sure admcleod! ;)
<admcleod> actually i better not
<magicaltrout> does it involve me replacing my kids, mrs or both? ;)
<admcleod> yes. :D
<magicaltrout> yeah
<magicaltrout> its tempting
<admcleod> i do know several people who clean their houses before their cleaner comes
<magicaltrout> yeah its nut
<magicaltrout> s
<magicaltrout> like, our house isn't bad, its just lived in, when you have 2 kids.  so why would a cleaner expect anything else?
<admcleod> you're not in london right? i could give you the contact for this russian cleaner... help you with all your problems...
<magicaltrout> hehe, maybe when they get really annoying. anyway, I have 7 days off, er, i mean hard work in the states, so I don't care ;)
<admcleod> ah so thats the problem. your travelling causes you to neglect your cleaning duties. well, fair enough
<magicaltrout> its not far off. I've been told off  quite a few times just after getting home for the state of the house, or the kids etc
<magicaltrout> which is impressive as I've usually be in the US
<admcleod> and the very next headline i see (and no, its not buzzfeed) is: 'Intelligent People Stay Up Late, Are Messy And Love To Swear'
<magicaltrout> lol
<magicaltrout> the mrs goes to bed about 9:00pm and tells me off for saying bloody and knackered as they are supposedly "swear words"
<admcleod> so, this russian cleaner i was talking about
<magicaltrout> she asked yesterday if at a parents evening I'd be upset with the kid if the teach said she keeps saying stuff is "bloody knackaered"
<admcleod> hahaha
<magicaltrout> don't see the problem myself
<admcleod> get her a frankie boyle bluray
<admcleod> infact just take her to scotland
<magicaltrout> hehe
<admcleod> ...or like, basically outside
<magicaltrout> you'd think growing up in Leeds and Bradford she'd be used to that stuff
<magicaltrout> clearly not, thats the problem with private education
<admcleod> maybe the problem is you're not wearing the right rugby league shirt
<admcleod> while you swear
<magicaltrout> hehe
<lovea> Hi, I'm using Juju 2.0 and MAAS 2.0. I have a MAAS server and 5 commissioned nodes (physical). I've configured a maas provider for Juju. If I juju bootstrap one of my physical nodes is utilised in maas to create the controller. That node is then no longer available for any other juju deployment. In my case that is a serious piece of kit for just a juju controller. Is there any way I can "juju deploy --to" the controller node to co-locate other charms?
<jcastro> fginther: have you tried just deploying --to 0?
<rick_h_> jcastro: it was a different user as I read it
<rick_h_> jcastro: and they ahve to juju switch admin first
<rick_h_> jcastro: to get machine 0 to deploy to
<jcastro> oh
<jcastro> so if you add-model foo
<jcastro> then you can't deploy to 0?
<rick_h_> jcastro: no, the state server is only shown/listed in the admin model since that is the controller
<jcastro> and a --to 0 intends to put something in the admin model?
<jcastro> I guess I am just confused on why I can't have model foo on the same physical hardware as the admin model?
<rick_h_> jcastro: so each model has its own machines for what's deployed into that model
<rick_h_> rather than show 0, the bootstrap/state server on every model, it's only on the controller one
<jcastro> ahhhh, I didn't know that
<rick_h_> especially since you can give users access to models
<rick_h_> you don't want them adding stuff to your machine 0
<jcastro> ok so basically the admin model needs a dedicated machine
<fginther> jcastro, I'm missing something, did you intend to ping me?
<jcastro> I was just discussing your issue with rick_h_
<fginther> jcastro, sorry, do you have the bug # handy so I can have a closer look?
<rick_h_> jcastro: it was a different person, not fginther
<fginther> rick_h_, ah, I'll move on then :)
<jcastro> oh sorry, I misread my irc client when you joined right as someone was asking that
<kjackal> kwmonroe: Hey Kevin, is this bundle going to be depricated? https://jujucharms.com/apache-processing-mapreduce/
<jcastro> marcoceppi: got a minute? I'd like for us to unpromulgate the old mediawiki bundles
<jcastro> mramm tried one yesterday and the scalable one for sure doesn't work anymore
<mramm> true that
<marcoceppi> jcastro: sure, eco-wx
<mramm> jcastro, marcoceppi, arosales:  Is there a bug for the mysql charm's brokenness?
<mramm> (which is what caused mediawiki-scalable to be broken)
<jcastro> not sure
<jcastro> iirc it was a feature we used
<jcastro> and then was unsupported in that charm
<jcastro> so I think it's more of the bundle not following the feature set of the charm
<arosales> mramm: I think we need to set the mem % on the media wiki bundle
<jcastro> that's a different bug
<arosales> And possible change the reference example
<jcastro> the master/slave config in that bundle is what isn't working
<jcastro> the mem% thing only affects mysql on local containers
<arosales> Oh I guess we should define brokenness
<arosales> I think mem would affect small mem machined
<arosales> mramm: what are the symptoms?
<jcastro> the database doesn't come up at all in the bundle
<jcastro> because it's trying to set up mysql in a master/slave configuration
<arosales> Gotcha, and sounds like there is no bug for that
<arosales> Should we consider changing the example to spark/zep or observable swarm
<arosales> I guess swarm doesn't work in LXC
<mramm> the mem percentage issue seems interesting also
<mramm> lxd/local is definitely the first use case most people touch
<mramm> arosales: definitely we shouldn't use an example for getting started that is broken
<mramm> that will not get us good results
<marcoceppi> mramm: I tried fixing that, because Juju does silly things on upgrade it got nix'd
<mramm> marcoceppi: thanks for trying!
<mramm> marcoceppi: just trying things in the order that I think newbies would, and reporting issues as I run into them
<jcastro> mramm: your bug is http://pad.lv/1294334
<jcastro> arosales: the mysql master/slave thing isn't a problem in the get-started, it's the lxc memory bug that is
<jcastro> the master/slave feature isn't in the bundle featured on get-started
<jcastro> all: it seems some people have tab completion in the juju betas, and some do not
<mramm> marcoceppi: I don't see anything about juju upgrade issues blocking a fix in the bug. Can you provide a bit more detail, what is the upgrade/juju problem with the proposed fix?
<jcastro> if you don't have working tab completion in juju 2.0 betas, please see this bug: http://pad.lv/1588403
<jcastro> mramm: it was discussed on the list, let me find it and put it in the bug
<mramm> tab completion is working for me (at least for second level commands) on a completely fresh juju install (from the PPA), will try from Xenial repo in a min.
<marcoceppi> mramm: customers deploying mysql today under the defaults would get a change to the way the charm runs, which was viewed as unacceptable
<jcastro> marcoceppi: is tab completion working for you?
<marcoceppi> jcastro: yes
<kjackal> Hey lazyPower, the ELK bundle under review is not pointing to logstash https://jujucharms.com/logstash/trusty/0
<kjackal> Here is the bundle http://bazaar.launchpad.net/~lazypower/charms/bundles/elk-stack/v1/view/head:/bundle.yaml
<lazyPower> kjackal - i think that was proposed long before any of the stack started landing
<lazyPower> i'll get that updated though, is that the only thing you see?
<kjackal> I havent checked the rest of the charms
<kjackal>  let me see
<lazyPower> looks like Es can use a bump
<lazyPower> i think thats it
<lazyPower> oh and kibana ;)
<kjackal> Do you want to update them now or should we wait for the next round (next week)?
<lazyPower> honestly can we push it back to next week?
<lazyPower> i've had a lot of stuff land and i've got a fire to put out with etcd
<cory_fu> lazyPower: Sure, kjackal can just nack the review ;)
<lazyPower> cory_fu i'm good with that. ta
<mramm> jcastro:  on a completely fresh xenial container -- no tab completion so not sure what's wrong on my laptop.  Haven't tried the new desktop yet.
<aisrael> jcastro: no tabcompletion here either
<lazyPower> same
<jcastro> ok I'm going to ask for feedback
<petevg> Hi, magicaltrout. I'm taking a look at the saikuanalytics-enterprise charm in the review queue. I'm following the README, and the action that generates a license seems to execute, but I get an error when logging in ("could not find license"). Are there any steps to fetching the license that are missing from the README?
<petevg> (Looking at logs, I see the error about not being able to find the license, but not necessarily any errors related to fetching it in the first place ...)
<magicaltrout> good find on the tab completetion jcastro !
<magicaltrout> it makes me sad everytime I press tab
<magicaltrout> petevg: don't worry about it for now, I'm gonna get 3.9 into the review queue and prod someone to do it in a quicker fashion as it will have much improved juju/big data integration once my drill stuff is finished
<petevg> magicaltrout: Sounds good. I look forward to seeing the new charm :-)
<magicaltrout> you and me both! :P
<magicaltrout> although 4.0 later in the year will be the stuff. Nice new React.js responsive UI, pluggable datasources and UI elements etc
<magicaltrout> thats like the holy grail ;)
<lazyPower> big data with a front end that doesn't look like java?
<lazyPower> \o/
<magicaltrout> hehe. Well our UI is starting to get a bit old, its all Backbone and HTML, but web tech moves so fast its a pain to keep up
<magicaltrout> but we also wanted to build a new setup built upon server and UI OSGI modules, so people can write OSGI compliant 3rd party plugins and just have the app register them
<magicaltrout> which will make extendability and updates much nicer
<lazyPower> not bad obama
<magicaltrout> because you'll be able to do OSGI updates from a maven repo over the wire
<magicaltrout> rather than downloading a new 700mb distro
<lazyPower> Thats a win
<roadmr> hey folks, is there a "cron" charm? say I want an existing unit with e.g. apache to run a cron entry to generate some static content. Do I have to write a custom charm for that or is there something I can just deploy --to the unit with the command to run as a "juju set" parameter?
<lazyPower> no but that sounds like a great subordinate service. the ability to provide it with a crontab and have it bolt that into the unit
<lazyPower> my initial grep of the charm store yields no results that look relevant. i think you've found some golden territory roadmr
<roadmr> \o/ /o\
<roadmr> thanks lazyPower
<arosales> jcastro: I have a bug opened for tab completion let me find the number
<arosales> https://bugs.launchpad.net/bugs/1582018
<mup> Bug #1582018: Tab completion for file system paths and in general for stock Ubuntu cloud image <bash-completion> <charms> <juju-core:Triaged> <https://launchpad.net/bugs/1582018>
<LiftedKilt> turns out juju add-unit {charm} -n {#} --to lxc:{machine} creates one lxc container and then tells maas it needs physical machines for the rest
<natefinch> fwereade: think I figured it out. Or rather, dpb1_ figured it out - the error message looks like it's coming from the local machine agent, but since it's actually an error in state, it must be on the controller, and passed back to the machine agent, which logs it without indicating it's logging an error from an API call to the controller :/
<dpb1_> let's hope so
<alexisb> natefinch, ug
<alexisb> though good on the progress
<kjackal> kwmonroe: Hey Kevin, is this bundle going to be depricated? https://jujucharms.com/apache-processing-mapreduce/
<kjackal> cory_fu you might know as well ^
<cory_fu> Yes, it is
<cory_fu> In favor of hadoop-processing
<kjackal> hadoop processin
<kjackal> let me see
<cory_fu> That's the Bigtop bundle
<kjackal> it the apache-processing-mapreduce going to be removed from the store?
<kjackal> Panagiotis has a reference on the bundle on his paper and I just want to make sure his link points to something
<kjackal> cory_fu?
<cory_fu> How is it being referenced?  cs:bundle/apache-processing-mapreduce?
<cory_fu> I think we were considering unpromulgating it, but leaving it in the ~bigdata-charmers namespace
<kjackal> hm... I will try to rephrase that part so that it references our bigdata landing page then....
<kjackal> I think this is the safest....
<kjackal> jog: I am with the bigdata team. What is the customer impact of the "Hadoop install hooks fail behind restricted network" ?
<kjackal> jog: the issue is already in the "doing" state, I wonder who is deploying the bundle in restricted environments. DO we have a customer?
<mbruzek> cmars: Is there a way to list the terms I have already accepted?
<cmars> mbruzek, juju list-agreements
<mbruzek> []
<mbruzek> cmars: then how was I able to deploy a local charm with terms for loren-ipsum/1 ?
<cmars> mbruzek, locally deployed charms do not check terms
<cmars> mbruzek, terms are required by the charmstore
<mbruzek> Oh I see
<jog> kjackal, any enterprise installation is most certainly going to have their data center behind a firewall
<kjackal> jog: understood, I was hoping for a specific enterprise name where we failed tp deploy
<kjackal> jog: how did you discover the fault in that bundle?
<jog> kjackal, even Canonical's own data center is an example... the system test hardware the cdo-qa team uses is on a restricted IS provided network
<kjackal> I see, thank you. Again reviewing all our bundles to filter out all similar isues in in doing "state"
<mbruzek> cmars: Do you have a minute?
<cmars> mbruzek, sure
<mbruzek> cmars: Is it possible to make a resource "optional" ?
<mbruzek> We are trying to charm push a charm with one optional resource and it is complaining that we don't give it any resources
<cmars> mbruzek, hmm that's a good question. I'm not too familiar with the finer details there. i can definitely see the usefulness in that
<mbruzek> cmars: That is right you implemented terms
<cmars> alexisb, who's around today who would know about mbruzek's resources question? ^^
<mbruzek> cmars: Who would know... ahh
<alexisb> wallyworld or natefinch-afk can answer mbruzek q
<mbruzek> wallyworld: We are trying to "charm publish" a charm and the error message is telling us we must have both resources referenced when we publish.  The last resource is optional
<cmars> mbruzek, i suppose you *could* do some hacky thing like rc=/dev/null but that's less than ideal
<cmars> well, on publish, it's not too bad to do that
<mbruzek> cmars: Yes that is what kwmonroe and I were thinking, but less than ideal.
<cmars> it's unixy
<wallyworld> mbruzek: it may be that at the moment, all resources do need to be defined
<wallyworld> from memory, i don't think optional resources were considered in the requirements
<mbruzek> wallyworld: thank you
<cmars> mbruzek, i can see both sides to this.. on one hand, you might have forgotten to specify the resource when you publish the charm
<wallyworld> can you raise a bug?
<cmars> mbruzek, on the other, you might want it to be optional
<cmars> for the first case, i'd appreciate the error, for the second, i wouldn't
<mbruzek> cmars: Yes I see both sides of the coin.
<cmars> maybe the resource ought to declare default behavior?
<cmars> or that it's optional
<mbruzek> cmars: wallyworld: well we coded the charm to have the second resource optional
<mbruzek> we worked around this problem by pushing zero length files, but that feels weird.
<cmars> mbruzek, true, but the flip side is, you don't get empty files when you forget resources. i think we'd need an optional: attribute in the metdata
<mbruzek> cmars: wallyworld: I will raise a bug and we can think about the best way to implement this
<wallyworld> sounds good
<cmars> mbruzek, cool, thanks. just thinking out loud..
<mbruzek> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1588555
<mup> Bug #1588555: Can resources be optional? <juju-core:New> <https://launchpad.net/bugs/1588555>
<wallyworld> mbruzek: ty
<rick_h_> mbruzek: answered
<rick_h_> wallyworld: ^
<mbruzek> thanks rick_h_
<magicaltrout> why is the mongodb charm running such an ancient version of mongo? operational reasons or just no one got around to updating it?
<lazyPower> magicaltrout - thats the case yes :(
<lazyPower> i'm the listed maintainer but i have not touched mongodb in quite some time
<lazyPower> and it was in a state of mostly working in smaller cluster but constantly a headache at scale. With reactive it should turn into a  much nicer charm to maintain, and we can model the individual components of the charm as top layers instead of a single catch-all multi-role charm
<lazyPower> which in all honestly makes the charm code abysmal to read through
<magicaltrout> no problem lazyPower i just noticed it was well old
<magicaltrout> i'll see if I can get around to it at some point
<lazyPower> yeah, i really want someone to adopt that one and give it a good home
<lazyPower> i've been a crappy parent of that charm
<lazyPower> sorry :(
<magicaltrout> I don't have much of a use for it, but clearly there is a lot of mongo use in the real world
<magicaltrout> be ashame to put people off because its 2.4
<lazyPower> our resident mongo master has been busy hacking on snappy related stuff
<magicaltrout> I was saying to SaMnCo today as well, we(everyone where possible) should make a bigger effort to make the charms centos/rhel compatible as well
<magicaltrout> for the enterprisey folk. It was a sticky issue with the guys we were having lunch with
<lazyPower> matt was just looking at a MP for charmhelpers from cloudbase introducing the centos abstractions for charmhelpers.core.host
<lazyPower> its getting close but has some wrap up fixes needed
<magicaltrout> cool
<lazyPower> i really want to try to start the migration process from charmhelpers into a trim charms.host lib and thinks of that nature
<lazyPower> extracting them and making it all travisy and publish frequently if the tests pass
<lazyPower> but thats a way bigger project than i'm making it out to be
<lazyPower> and i have a habit of wanting to take on the world every time i get a second
<magicaltrout> aye
<magicaltrout> i have that problem
<lazyPower> what can i say, we <3 this stuff
 * lazyPower wanders off to brew some tea
<magicaltrout> http://spicule.co.uk/2016/06/02/apache-drilll-juju.html brain dump on Apache Drill charm
<magicaltrout> started it at 8am and finished at midnight with a 12 hour gap in between
<lazyPower> not bad
<lazyPower> impressive actually
<magicaltrout> to many l's in drill
<magicaltrout> arse
<magicaltrout> that was an 8am error ironically
<magicaltrout> lack of morning coffee
<lazyPower> What did hemmingway say? write intoxicated, edit sober.
<magicaltrout> aye,he had a very valid point
<aisrael> lazyPower: indeed
<lazyPower> ;)
<lazyPower> didnt know you were lurking around over there aisrael o/
<lazyPower> all unpacked?
#juju 2016-06-03
<thumper> lazyPower: o/
<lazyPower> hey thumper!
<thumper> lazyPower: your b'day today for you right?
<lazyPower> in a couple hours ye
<thumper> so it is today for me, not you
<thumper> happy birthday from the future
<lazyPower> xD
<magicaltrout> how old ya gonna be lazyPower ?
<lazyPower> 33
<magicaltrout> awww we become the same age yet again......
<lazyPower> ;)
<lazyPower> I'm cool with following in your footsteps. I've had worse role models
<lazyPower> zing!
<magicaltrout> here you go lazyPower, I have your beats lined up for the flight tomorrow, in the mean time, you can learn a lot from this: https://www.youtube.com/watch?v=5pidokakU4I
<magicaltrout> ;)
<lazyPower> THIS IS FANTASTIC!
<magicaltrout> hehe
<magicaltrout> its pretty clever
<aisrael> lazyPower: I am so far from unpacked!
<lazyPower> i hear ya i'm on the other end of that, as in not packed.
<menn0> lazyPower: you still around?
<lazyPower> menn0 i am. hacking on etcd - whats up?
<menn0> lazyPower: I have a potentially stupid question about charm revisions
<lazyPower> i have an equally potentially stupid answer :)
<lazyPower> go for it
<menn0> lazyPower: in the charm store the ubuntu charm has a rev of 0
<menn0> if you install it the charm URL is cs:ubuntu-0
<menn0> yet it has a revision file with 7 in it
<menn0> what's up with that?
<lazyPower> When a charm is published it goes into the unpublished channel, and these entities increase n+1 everytime you push
<lazyPower> when you "publish" a charm into a channel, that creates a new revision for that channel, again, n+1 that is a reference to the charm-revision in the unpublished channel.
<lazyPower> so its likely there is a cs:ubuntu-0 through cs:ubuntu-7 in the unpublished channel, while the stable release is pointed at cs:ubuntu-7, thus resulting in cs:ubuntu-0 having a revision file with the contents of "7"
<menn0> lazyPower: ok right
<menn0> lazyPower: this is causing me some headaches with model migrations... but I think I can work around it
<lazyPower> https://jujucharms.com/docs/devel/authors-charm-store
<lazyPower> i think this is a temorary headache while we start to roll things over in teh new store
<lazyPower> s/temorary/temporary/   s/teh/the/
<menn0> lazyPower: ttvm... this explains a lot
<menn0> I will have to accomodate this in model migrations
<lazyPower> happy to help menn0
<gnuoy> tinwood, I'd be really grateful if you could take a look at these http://paste.ubuntu.com/16942097/ when you have sometime. The charms.openstack pull request is probably the more important/contentious
<tinwood> gnuoy, sure no problem.
<tinwood> gnuoy, sneaky :) Four reviews in one paste!
<gnuoy> yeah, sorry
<gahan> Hi, is it safe to use logroate on juju's logs?
<gahan> does juju has some built-in mechanism for log rotation or can I go ahead and add a logrotate script?
<gahan> do i need to reload rsyslogd post rotation?
<tinwood> gnuoy, review on charms.openstack done.  Now moving on the others.
<tinwood> gnuoy, reviews done.  I'm busy from 1pm till about 2pm, but otherwise free, if you want to push back on those comments! :)
<marcoceppi> gahan: it is safe to logrotate, but juju should do that for you. What version of juju are you using?
<magicaltrout> marcoceppi: i'd like to revamp the mongo charm to make it suck less, but its in ~charmers and owned by lazyPower etc
<magicaltrout> do i need to do anything other than fork it to make it happen?
<marcoceppi> magicaltrout: you could use the layer I started but never got around to finishing as a base
<magicaltrout> cool
<marcoceppi> magicaltrout: the old charm is gross, best to just start fresh for Xenial
<magicaltrout> yeah
<marcoceppi> https://github.com/marcoceppi/layer-mongodb
<magicaltrout> excellent
<marcoceppi> magicaltrout: I got installing and switching between versions pretty much done, next was to figure out how to replica set
<marcoceppi> magicaltrout: it's a few months old, so the reactive file needs some love to drop the abuse of @hook, happy to help where I can (just as soon as I finish up my gitlab changes ;)
<magicaltrout> yeah im not in a huge hurry for it but 2.4 is ancient and it just needs some love
<magicaltrout> 2.4 is pre agg framework wihch will make a lot of apps like drill quite sad
<magicaltrout> also marcoceppi whats the status on decoupling layer basic from ubunut?
<magicaltrout> ubuntu
<marcoceppi> magicaltrout: just some talk, we're not sure how to really decouple, there's a bunch of ways to do it. I was thinking we could possibly have a layer:ubuntu, layer:centos, layer:windows approach
<marcoceppi> which would all inherit the "basic" layer which would simply be the bits required to install reactive
<magicaltrout> yup
<marcoceppi> cory_fu: ^ thoughts?
<magicaltrout> i'd like ot make a concerted effor to build cross platform charms for people who are crazy and run centos etc
<marcoceppi> magicaltrout: well that becomes a little more difficult
<magicaltrout> but of course apart from saiku every charm i write inherits layer basic
<marcoceppi> really it boils down to linux and windows, and it starts getting messy with package management
<marcoceppi> so, excluding windows for a hot min
<magicaltrout> windows I can get over
<marcoceppi> httpd vs apache2
<marcoceppi> there's not standard package names for ubuntu vs centos
<marcoceppi> which means, without an abstraction layer like puppet, chef, anisble, etc, making a cross-linux charm is going to be tough
<magicaltrout> yeah but in part thats your competition so why not at least come up with a plan as to how to leverage centos based charms alongside ubuntu ones
<magicaltrout> in puppet its easy enough to alias that type of stuff
<marcoceppi> magicaltrout: you can, you just use puppet, chef, ansible, whomever inside your charm ;)
<magicaltrout> thats a crap answer :P
<marcoceppi> why re-invent configuration management whene there's N+1 tools already doing it?
<marcoceppi> its' the reason charms are langauge agnostic
<lazyPower> ^ this
<marcoceppi> we really don't care how you set up the machine, you just need to set the machine up so it can participate in the model
<magicaltrout> yeah but you're telling me as a charm author if I want to support non ubuntu i need to use puppet to configure it or write a centos specific charm
<magicaltrout> in which case as a service provider i might as well just write a puppet module and stick it in puppet forge
<magicaltrout> of course i'm just playing devils advocate here, but i think its valid reasoning
<marcoceppi> magicaltrout: puppet doesn't get you what juju does. In the same way that docker doesn't get you waht puppet does
<marcoceppi> why is wrapping a charm around a docker container valid but wrapping a charm around a puppet module not?
<marcoceppi> furthermore, there's nothing stopping you from writing a bit of python that does this feature from all the other CM tools
<magicaltrout> i dislike wrapping docker containers as well :P
<lazyPower> yeah?
<marcoceppi> you don't have to use any of these CM, just that it's a solved problem - right tool for the job kind of thing
<lazyPower> magicaltrout - one of these days i want to talk to you about that :) get your insights there
<marcoceppi> why wrap a charm around a java application?
<marcoceppi> why wrap a charm around anything at that point?
<magicaltrout> you wrap a charm around an app to provide actions and relations
<magicaltrout> but i could install saiku on any java running platform with no change in code
<marcoceppi> you wrap a charm around a puppet script to provide it actions and relations ;)
<magicaltrout> my thinking is why do i need to wrap puppet in a charm to do the same, I don't want to learn juju & puppet to do the job
<magicaltrout> I just want to learn juju
<magicaltrout> hell
<marcoceppi> I think you have a valid point
<magicaltrout> i hate ruby :P
<marcoceppi> ultimately, this functionality, installing packages across distributions of linux, isn't unique to juju/charms. I would have hoped that by now someone had found a tasteful way to do it in python, either by extracting it from a CM tool, or just spear heading it
<magicaltrout> i'm not saying i wont figure out a way to do it, but I do think there should be at least some basics in charmhelpers or somewhere
<marcoceppi> (there's also a pull request on charm-helpers to add transparent switching between apt and yum based on the linux you're on)
<marcoceppi> but that means you'll have to maintain logic in your layers to say this list of packages are APT, this list is YUM
<magicaltrout> i'm not trying to absolve myself of responsibility, and also you lot work for canonical so I wouldn't see it being top of your lists either
<lazyPower> well i think with the proper abstractions, and amenities to the charm - you could do some build matrices of a layer.yaml that would give you pretty good results in 'just juju and python'.
<magicaltrout> but having talks to people at strata hadoop and stuff yesterday, its a pertinent question
<lazyPower> we will however need to do that 3 tier breakout of basic => series
<magicaltrout> yeah
<marcoceppi> magicaltrout: https://code.launchpad.net/~dbuliga/charm-helpers/charm-helpers/+merge/296320
<magicaltrout> i think it would be pretty easy to prototype though
<magicaltrout> even if it doesn't cover all use cases
<marcoceppi> magicaltrout: if you want to help shepard some of the underpinnings for this in
<lazyPower> and sorry for using the word abstraction there, when i mean - using the same patterns with the same state mechanics. Just  replacing the  bits you cant make generic.
<magicaltrout> yeah
<magicaltrout> okay marcoceppi i'll try and pick some of that up and see what I can do
<magicaltrout> lazyPower: sounds like you have layer basic -> layer:ubuntu, layer:centos which inherit it and just override any functions you can't genericise
<lazyPower> yeah
<lazyPower> and i htink if you do something like layer_options for the package list, and override that as required...
<marcoceppi> magicaltrout: I imagine it'd be something like (layer:ubuntu,layer:centos) -> layer:linux -> layer:basic
<lazyPower> it seems like it could work
<magicaltrout> also i remember talk of Windows getting and APT like package manager
<magicaltrout> could work over there as well
<magicaltrout> yeah valid point marcoceppi
<marcoceppi> where if you want to jump into a non-distro specific charm, layer:linux is what you'd use
<lazyPower> disregard i said that... it sounds worse now that i've read it out loud
<magicaltrout> hehe
<marcoceppi> and with custom tactics, we could do some clever things
<marcoceppi> lazyPower: did you ever get custom layer tactics working?
<lazyPower> uhhhhhh
<lazyPower> yes
<lazyPower> but its not shipped
<lazyPower> its in layer-docker branches somewhere
<magicaltrout> what's custom tactics?
<magicaltrout> dare i ask?
<marcoceppi> cool, just curious
<marcoceppi> magicaltrout: another knife for which you can poke your eye with ;)
<lazyPower> things the builder does when building charms
<lazyPower> so like, i want to wheelhouse *all the thingggssss*
<lazyPower> i need to customize the venv in which its buliding the wheelhouse :P
<lazyPower> a-la even more sticks in even more eyes
<marcoceppi> right, so a tactic is what the builder uses to process files during the build process
<magicaltrout> got ya
<magicaltrout> cool
<magicaltrout> http://pastebin.com/3TsBLLG8 from where I'm sitting (heathrow terminal 5 quiet zone.....) it seems like thats not too far removed as an implmentation technique that could be done in juju
<magicaltrout> and would make sense without getting too far down the line into reinventing puppet
<magicaltrout> in the dependencies yaml you could easily do something like
<magicaltrout> https://gist.github.com/buggtb/1805107403835aa897657cfa0ac08f8c
<magicaltrout> which would be pretty clean
<marcoceppi> it'd be great if there was like an online registry of every "software" name and it's corrosponding package name in an OS so that you could have it populate this mapping during charm build
<magicaltrout> packages.juju.solutions ;)
<gahan> marcoceppi: regarding logrotate -> using juju 1.25
<marcoceppi> magicaltrout: <3
<marcoceppi> gahan: this was fixed in 1.25.5, what does `juju version` say explicitly?
<tasdomas> is there a preferred way for handling relation departures with interface layers?
<tasdomas> i.e. what's a good practice for this?
<gahan> marcoceppi: 1.25.5-trusty-amd64
<gahan> marcoceppi: how often are they rotated? monthly? depending on size?
<marcoceppi> gahan: i think it's size dependant
<lazyPower> tasdomas - i'm actually working through that right now
<lazyPower> tasdomas - i can step you through what i'm implementing shortly, its not pushed anywhere. I can ping you then?
<tasdomas> lazyPower, sure!
<lazyPower> tasdomas - but before i skip the basics. Have you read the interface-layers doc page?
<tasdomas> lazyPower, yeah
<lazyPower> tasdomas - https://github.com/juju-solutions/interface-namenode-cluster/blob/master/peers.py#L36 - may answer your question before i do as well
<tasdomas> lazyPower, perhaps I should have asked a better question
<tasdomas> lazyPower, I'm thinking about the charm layer - basically - when a relation is broken/departed, the *_available state gets removed from the conversation
<tasdomas> lazyPower, but if I need e.g. to remove some entry from a file
<tasdomas> is there a way to get data on which conversation got broken?
<lazyPower> there is, this is what i was just testing
<marcoceppi> magicaltrout: can drill ingest data sources from elastic search?
<magicaltrout> not yet marcoceppi there is an open ticket for that. Also I have a proposal in with a client to build that connector
<magicaltrout> i don't know if they'll say yes or not, but it will arrive sooner or later
<marcoceppi> magicaltrout: sweet, that'd be awesome
<magicaltrout> yeah, its not hard to build either because elastic searches query lanugage isn't that expressive
<magicaltrout> so you'd push some filtering down to ES and do the aggregations and grouping in memory i suspect
<magicaltrout> a bit like mongo pre-aggregate framework
<magicaltrout> the underlying calcite engine will allow you to run SQL over the resultset that isn't technically supported by the source data
<magicaltrout> which is pretty cool
<magicaltrout> it was something me and SaMnCo touched on briefly yesterday, the ability to do full analytics and reporting over beats and other ES data sources
<tasdomas> lazyPower, so maybe the way to handle departures is to set a _departed state on the conversation?
<tasdomas> lazyPower, that way at least the conv object would get passed to the state handler
<lazyPower> tasdomas - That works, The one thing i did find is that i had to leverage the -departed hook as my source of who was actually leaving the conversation
<lazyPower> the -broken triggers on every unit. In my specific case i'm deregistering and terminating a unit, before it goes it has to self unregister. It was neat to see every unit but the leader drop offline
<tasdomas> lazyPower, is there a snippet of a source file you could point me at?
<lazyPower> https://gist.github.com/e8fe095b99a17038d399ee6776cfb2b7
<lazyPower> line 37
<lazyPower> and https://gist.github.com/anonymous/f157083d14a930493a4cafcd2b1da7ae#file-etcd-py-L316 - is where i handle it in the reactive code.
<tasdomas> lazyPower, I  see that you don't call depart() on the conversation - is that something that needs to be done?
<lazyPower> Thats news to me. I'll look in a sec. I'm seeing the proper behavior but i may be leaving things open.
<lazyPower> s/open/incomplete
<magicaltrout> okay so 10 hours on a flight *if* i have at seat power, I need to a) add some more config to Drill b) write some PDI charm tests c) listen to lazyPower's beats d) write some Saiku relations for other data sources e) finish off Saiku schema stuff so it hooks in juju properly for 3.9
<magicaltrout> should keep me busy
<lazyPower> saved the beats for the plane huh? bold move
<magicaltrout> hehe
<magicaltrout> i also want to write a Pentaho BI server charm as well
<magicaltrout> so i have their stuff downloaded for the flight
<lazyPower> I've been told the jams were rocket fuel for charming. this is per kwmonroe_
<magicaltrout> hehe
<jrwren> it is lazyPower music beats, or is it lazyPower talking about elasti.co products?
<lazyPower> its music jrwren  :)
<jrwren> cool. oontz oontz oontz.
<lazyPower> trip hop actually
<lazyPower> but oontz indeed :)
<gahan> marcoceppi: thanks
<jrwren> i was thinking: tshuk tshuk -- thump
<magicaltrout> alrighty time to find some caffiene and a flight
<magicaltrout> see ya'll in 12 hours
<lazyPower> jrwren niiice, even better
<Anita_> I am trying to install JUJU 2.0 as non-root
<Anita_> But "juju bootstrap lxd-test lxd" giving error
<Anita_> tried logging off and loggin in again as nonroot user
<Anita_> but problem is still not solved
<jrwren> Anita_: can you create an lxc/lxd instance using `lxc launch ubuntu:` ?
<Anita_> ok let me try
<Anita_> root@c277-pkvm-vm62:~# su - charm charm@c277-pkvm-vm62:~$ lxc launch ubuntu: error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: permission denied charm@c277-pkvm-vm62:~$
<Anita_> charm@c277-pkvm-vm62:~$ groups charm lxd charm@c277-pkvm-vm62:~$
<Anita_> root@c277-pkvm-vm62:~# su - charm charm@c277-pkvm-vm62:~$ lxc launch ubuntu: error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: permission denied charm@c277-pkvm-vm62:~$
<jrwren> Anita_: does `id |grep lxd` output anything or is it blank?
<Anita_> charm@c277-pkvm-vm62:~$ id |grep lxd uid=1001(charm) gid=1001(charm) groups=1001(charm),116(lxd) charm@c277-pkvm-vm62:~$
<Anita_> are you able to get my message jrwren?
<Anita_> Yes I am able to get your message
<Anita_> charm@c277-pkvm-vm62:~$ id |grep lxd uid=1001(charm) gid=1001(charm) groups=1001(charm),116(lxd) charm@c277-pkvm-vm62:~$
<jrwren> Anita_: yes. I read you. is lxd running? `ps auxw | grep [/]usr/bin/lxd`
<Anita_> charm@c277-pkvm-vm62:~$ `ps auxw | grep [/]usr/bin/lxd` The program 'root' is currently not installed. To run 'root' please ask your administrator to install the package 'root-system-bin' charm@c277-pkvm-vm62:~$
<Anita_> Shall I install root-system-bin?
<jrwren> don't paste my backticks. I included those only to be clear about what command I wanted you to run.
<jrwren> run only: ps auxw | grep [/]usr/bin/lxd
<Anita_> k
<Anita_> sorry ok
<Anita_> charm@c277-pkvm-vm62:~$ ps auxw | grep [/]usr/bin/lxd root     12249  0.0  0.6 492736 25152 ?        Ssl  04:48   0:05 /usr/bin/lxd --group lxd --logfile=/var/log/lxd/lxd.log charm@c277-pkvm-vm62:~$
<jrwren> no worries. I write too much markdown ;]
<Anita_> :)
<jrwren> hrm, well, those are all of the simple things to check. I do not know what to check next.
<jrwren> Anita_: ls -al /var/lib/lxd/unix.socket
<Anita_> charm@c277-pkvm-vm62:~$ ls -al /var/lib/lxd/unix.socket srw-rw---- 1 root root 0 Jun  3 02:52 /var/lib/lxd/unix.socket charm@c277-pkvm-vm62:~$
<Anita_> charm@c277-pkvm-vm62:~$  juju bootstrap lxd-test lxd ERROR invalid config: can't connect to the local LXD server: Permisson denied, are you in the lxd group?  Please configure LXD by running:         $ newgrp lxd         $ lxd init
<Anita_> charm@c277-pkvm-vm62:~$ newgrp lxd charm@c277-pkvm-vm62:~$
<Anita_> newgrp lxd is successful
<jrwren> looks like that socket is owned incorrectly.
<jrwren> Anita_: sudo chgrp lxd /var/lib/lxd/unix.socket
<jrwren> Anita_: and try lxc launch command again.
<Anita_> ok
<Anita_> lxc launch command is means initializing lxc?
<Anita_> sudo dpkg-reconfigure -p medium lxd?
<jrwren> Anita_: it starts an lxc instance using lxd just like juju would.
<jrwren> Anita_: that probalby wouldn't hurt, but no, by "try lxc launch command again" i mean run `lxc launch ubuntu:` like I said in my first reply.
<Anita_> Ok I will try
<bryan_att> gnuoy: ping
<gnuoy> hi bryan_att
<bryan_att> gnuoy: hi, I had a question about the Congress charm you showed working
<gnuoy> sure
<Anita_> charm@c277-pkvm-vm62:~$ lxc launch ubuntu: Creating legal-enid Starting legal-enid charm@c277-pkvm-vm62:~$
<Anita_> This time its giving some output
<jrwren> Anita_: that worked. you can `lxc stop legal-enid ; lxc delete legal-enid` and juju bootstrap now.
<Anita_> ok
<bryan_att> gnuoy: per http://paste.ubuntu.com/16729946/ I was not able to duplicate this and want to know more about the test
<gnuoy> bryan_att, sure, what would you like to know?
<gnuoy> which bit is not working for you?
<bryan_att> gnuoy: there are no trusty packages for Congress. Where did you get the packages from?
<gnuoy> bryan_att, I built from git branch
<gnuoy> bryan_att, line 23 of the pastebin
<Anita_> juju bootstrap is running... taking sometime
<Anita_> charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd
<bryan_att> gnuoy: OK, when I tried that I had an error - I will paste the bin link again
<Anita_> charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd Creating Juju controller "local.lxd-test" on lxd/localhost Bootstrapping model "admin" Starting new instance for initial controller Launching instance WARNING error copying image: Failed to create ZFS snapshot: cannot create snapshot 'lxd/images/5a2cd3b9793fb066f28399deb294da31c56a7f18c577c73b6bfae1a1918fb007@readonly': dataset already exists no snapshots were created  unable to get L
<Anita_> charm@c277-pkvm-vm62:~$ juju bootstrap lxd-test lxd Creating Juju controller "local.lxd-test" on lxd/localhost Bootstrapping model "admin" Starting new instance for initial controller Launching instance WARNING error copying image: Failed to create ZFS snapshot: cannot create snapshot 'lxd/images/5a2cd3b9793fb066f28399deb294da31c56a7f18c577c73b6bfae1a1918fb007@readonly': dataset already exists no snapshots were created  unable to get L
<bryan_att> gnuoy: OK, that was an earlier error. But where I am is I don't see how you were able to get the service running with the charm as-is. I had to modify the chsrm for the build process as it did not include all the necessary steps.
<bryan_att> gnuoy: I will paste the current procedure - hang on
<gnuoy> sounds good
<bryan_att> gnuoy: let's talk about this procedure from congress.py https://www.irccloud.com/pastebin/hMMamRRJ/
<bryan_att> gnuoy: there are several things there that were not in your original, but are necessary for the service to be activated (as you showed by the datasource creation step)
<Anita_> jrwren_: lxd/images/5a2cd3b9793fb066f28399deb294da31c56a7f18c577c73b6bfae1a1918fb007 is looks like some previous image which couldnot delete due to read-only
<Anita_> is that causing issue?
<jrwren> Anita_: that would be a different issue.
<bryan_att> gnuoy: not that this all works yet - I just don't see how you were able to activate the service without the full sequence of steps, e.g. congress-db-manage
<gnuoy> bryan_att, those two commented out lines look like mistakes
<Anita_> jrwren_: after this bootstrap should pass?
<gnuoy> bryan_att, having said that there is a congress-db-manage step
<bryan_att> gnuoy: they are earlier attempts - ignore them
<bryan_att> gnuoy: OK, let's compare to your original
<gnuoy> ok
<Anita_> jrwren_: what is the steps to clean a lxd when we uninstall juju 2.0?
<Anita_> jrwren_: what is the step to uninstall juju 2.0 ?
<bryan_att> gnuoy: hang on, relocating the original
<gnuoy> bryan_att, sure, no problem
<jrwren> Anita_: i do not know. I only know a little about getting to running.
<bryan_att> gnuoy: here is your original https://www.irccloud.com/pastebin/2OJIMozC/
<Anita_> jrwren_: wants to retry after proper clean up
<bryan_att> gnuoy: there is no congress-db-manage step in that - how did you init the schema?
<beisner> tinwood, gnuoy - so with tempest charm now in gerrit, i'm trying to add a very basic unit test.  i immediately hit the namespace conflict between lib/charm/openstack/foo (charm.openstack.tempest vs charm.openstack layer, which i presume is why charm_openstack is the new module name)
<gnuoy> bryan_att, if you look in reactive/handlers.py you'll see that when the database is ready the schema is initialised
<gnuoy> bryan_att, http://paste.ubuntu.com/16948479/
<bryan_att> gnuoy: when I tried your example that did not work
<jrwren> Anita_: if `lxc list` shows an empty list, I've `rm -rf /var/lib/lxd/`  and then run `sudo lxd init`
<Anita_> Thanks a lot jrwren... will retry after uninstall of juju 2.0
<beisner> so after switching to the charms.openstack (charms_openstack) module in the tempest charm, import issues are solved.  now it complains that i've not declared a release.  i want the charm to declare that it works with all releases, but stumbling on how to express that.  https://github.com/openstack-charmers/charms.openstack/blob/master/charms_openstack/charm.py#L110   seems to accept only one.
<bryan_att> gnuoy: I assumed that these were missing steps that had to be manually included in the src_install script
<Anita_> may be after proper clean up, it will work with the steps that you provided
<Anita_> Ok
<gnuoy> bryan_att, no, the charm is setup to do the migration
<Anita_> charm@c277-pkvm-vm62:~$ lxc list +---------------+---------+------+------+------------+-----------+ |     NAME      |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS | +---------------+---------+------+------+------------+-----------+ | claylike-doug | STOPPED |      |      | PERSISTENT | 0         | +---------------+---------+------+------+------------+-----------+ charm@c277-pkvm-vm62:~$
<bryan_att> gnuoy: understood that by intent it is - but it did not work for me
<gnuoy> bryan_att, ok, we need to work through where you hit a problem
<bryan_att> gnuoy: I was trying this last week and not able to replicate your results - so I tried to do those steps scripted to get further. When I ran your example as-is the database schema did not get setup
<tinwood> beisner, yes, that's basically what we were up against.
<gnuoy> bryan_att, did you add the relation between  congress and mysql?
<bryan_att> gnuoy: I got the error "no policy table" when trying to start congress-server - it never successfully started
<bryan_att> gnuoy: yes, I added all the relations
<bryan_att> gnuoy: if I try your example again, what debug logs do your need? I can provide the syslog from the congress-server at least where you can see the failure.
<gnuoy> bryan_att, /var/log/juju/* from the congress server would be good
<bryan_att> gnuoy: OK, I'll collect those this weekend and post them. Maybe we can talk again next week? I'm trying to get this done before the 19th (OPNFV Summit) and really no later than next week.
<gnuoy> bryan_att, sure, I will redeploy using the steps I posted
<gnuoy> as well
<bryan_att> gnuoy: OK, thanks for your help
<gnuoy> bryan_att, np
<beisner> tinwood, where did OpenStackCharmFactory wind up?   tempest  charm previously extended openstack.charm.OpenStackCharmFactory but no bueno with charms_openstack
<tinwood> beisner, it disappeared.  A new funky singleton has replaced it, along with get_charm().
<beisner> well f_
<beisner> tinwood, i think i'll just add a no-op unit test that passes instead of having to refactor this whole charm.  i just need the charm as a vehicle.
<admcleod> cory_fu: so, im writing this bigtop pig charm, and i need to define 2 bigtop roles: hadoop-client (to install the hadoop components) and pig-client. however, that results in having the hadoop head node overwritten with what appears to be a default fqdn. i suppose i need to get the namenode and resourcemanager from the plugin relation and then render_site_yaml with those hosts?
<tinwood> beisner, sure.  -- I kind of pulled the rug out of OS layered charms with this change, but wanted to do it now rather than later.
<gnuoy> bryan_att, found an issue with keystone not knowing about congress. I fixed that locally before and the pastebin I sent you does not include how to deploy the fixed icehose. Sorry about that.
<gnuoy> s/icehose/keystone.
<beisner> tinwood, ack agree breaking before we really ramp up using it :-)
<bryan_att> gnuoy: thanks! that's one of the issues I did see persistently from JuJu.
<cory_fu> admcleod: That is correct.  When I finish the non-install version of the hadoop-plugin relation, you'll want to use that instead as well, so that you don't end up with hadoop-plugin fighting with pig over the site.yaml
<cory_fu> admcleod: So you'll need a @when('hadoop.ready') decorator and the handler should have `def foo(hadoop): bigtop.render_site_yaml(hosts={'namenode': hadoop.namenodes()[0]})`
<cory_fu> Something like that
<gnuoy> bryan_att, ooi what version of juju are you using?
<bryan_att> gnuoy: not 2.0 1.x something
<gnuoy> bryan_att, are you on 1.25.?
<cory_fu> admcleod: The code would be similar to this: https://github.com/juju-solutions/bigtop/pull/3/files?diff=unified#diff-5006dc573a0911f6248e72dc6974038dR7  With the main difference being that the @when would be 'hadoop.ready' (or 'hadoop-plugin.ready' or whatever you call your relation to plugin)
<gnuoy> bryan_att, ok, cool, thanks
<cory_fu> Otherwise, the code of the handler should be nearly identical
<bryan_att> gnuoy: let me look back thru the logs - i pasted it. I'm not near my test machine at the moment.
<admcleod> cory_fu: ok cool, got it
<gnuoy> bryan_att, don't orry, 1.x is good enough
<beisner> tinwood, fyi @ https://github.com/openstack/charm-tempest  but lmk if that looks like more than a quick redux and i'll just do the noop thing for now.
<tinwood> beisner, okay, will do.
<beisner> tinwood, thx much
<jose> hey lazyPower, happy birthday!
<tinwood> beisner, just out of interest, on review.openstack, how do I get into the charms-core group?  Everybody else is :(
<lazyPower> Thanks Jose :) o/
<beisner> tinwood, ah you wanna land code? ;-)
<tinwood> I thought that was just charm-release group.  Or can core land code too?
<dimitern> lazyPower: hey, I managed to get bundletester to work with existing juju 2.0 model to run my layer tests!
<lazyPower> \oo/, Nice dimitern!
<dimitern> lazyPower: but I found out the charm builder assumes I'm using py34 and py35 only, unless I override that with a tox.ini in the layer
<dimitern> lazyPower: it's ok though - just initially frustrating until I found that workaround
<beisner> tinwood, yep charms-core can land.  release has some other perms that i'm not completely sure of just yet.   i think you should be in charms-core -- gnuoy ok with you?
<tinwood> beisner, ah, I see. Sure, I'd like to be apart of the core group if that's okay with everyone.
<dimitern> lazyPower: oh man! just noticed! happy birthday indeed! \o.
<lazyPower> jose thanks  :D \o
<lazyPower> dimitern thanks buddy :)
<jcastro> openstackers, I have some hotness for you: http://askubuntu.com/questions/tagged/juju?sort=featured&pageSize=50
<jcastro> I have many internet points to give away
<beisner> tinwood, added you to openstack charms-core
<beisner> tinwood, shall we put those new powers to work right away? ;-)   https://review.openstack.org/#/c/325398/  ;-)    need to land that so i can proceed to add a very basic func test.  then we'll be clear to automate layer build/test flows using this as subject matter.
<gnuoy> bryan_att, I just redeployed again and was able to create a datasource. http://paste.ubuntu.com/16952298/ shows the script I used. It'd be better as a bundle but I wanted to include the build step
<gnuoy> bryan_att, I'm at my EOD but I'll check in later if you have any questions
<beisner> hi thedac, can you give this tactical thing of beauty a look and a kick for me?  :)  https://review.openstack.org/#/c/325398/
<thedac> beisner: just got off of calls. I'll take a look shortly
<beisner> thedac, thx much
<beisner> jhobbs, fyi, we're moving charm-tempest into gerrit, so the openstack-charmers git repo will be removed soon.  that repo has already been pulled into openstack git/gerrit.  we're just ironing out CI around it.  but wanted to alert you to the new location in case you have mods in-flight.
<jhobbs> beisner: ok - can you give me a url to the new location?
<beisner> jhobbs, fyi https://github.com/openstack/charm-FOO is the general format.    so for this one:  https://github.com/openstack/charm-tempest
<jhobbs> ah
<jhobbs> that's easy
<beisner> :)
<jhobbs> thanks!
<thedac> beisner: +2
<beisner> jhobbs, yw.  the downside is that now we can't land anything until we add tests and make 'em pass.  working on that now.  welcome to the bloody bleeding new tempest charm yah?
<beisner> thedac, thx sir
<tinwood> beisner, sorry, just came back online after dinner (or 'tea' as we call it hered).  Thanks for adding me; sorry thedac beat me to it.
<tinwood> s/hered/here/
<beisner> tinwood, np and yw!   i'm sure i'll have another tactical solution to merge soon ;-)
<jhobbs> beisner: add tests - so each new MP needs a test? or you have to go back and add some tests for existing stuff?
<beisner> jhobbs, the landing gate won't land without passing tests so we're working on getting some really basic tests in the charm.  then it's a dive into the unknown:   git/gerrit/layer/ci ;-)
<jhobbs> k
<beisner> jhobbs, fwiw, we're using this tempest charm as 'the first' layered charm through ci so it'll be paving the way through, making some noise for a bit.
<beisner> as an unreleased thing which not many people (you and i) depend on, it seems like the best first candidate through.
<beisner> thedac, wow upstream job queue is high, still catching up from the outage last night it seems.
<beisner> gnuoy, asking in infra if they can re-init that repo from https://github.com/openstack-charmers/charm-hacluster, or whether we need to revert that infra change and resubmit.  hopefully they can just re-init for us but i'll let you know.
<beisner> gnuoy, fixed-up :-D https://github.com/openstack/charm-hacluster
<j_king> Friends... I'm having trouble finding documentation on the contribution process. I've added an amulet test to a charm and would like to submit it for review. Anyone have a link to point me in the right direction pls?
<rick_h_> j_king: what charm?
<j_king> rick_h_: mongodb.
<rick_h_> j_king: so the code for the charm is here: https://code.launchpad.net/~charmers/charms/trusty/mongodb/trunk I'd submit a MP on that
<rick_h_> j_king: and when you ahve that up let me know and I'll make sure to poke folks to look at and see about landing.
<j_king> rick_h_: forgive me but it's been a dogs age since I've used bzr. :) what's an MP?
<rick_h_> j_king: sorry, pr = github, mp = merge proposal in launchpad terms :)
<rick_h_> pull request by other names
<arosales> cargonza: jamespage, gnuoy ^ note we need to improve https://github.com/openstack-charmers/openstack-community  page
<petevg> Question: if I want a list of the attributes that I can fetch with unit-get, where should I look? ('man unit-get' isn't helpful)
<cargonza> arosales, ack... we need to work on it... will definitely be on the list asap
<arosales> j_king: https://jujucharms.com/docs/stable/authors-charm-store#submitting  --> looking under "Submitting a fix to an existing Charm"
<j_king> arosales: ty
<arosales> j_king: in post 2.0 world we un-tie charms from launchpad
<arosales> and the charm store has the preferred area to submit pulls/mps or what ever the community decides to use
<arosales> petevg: man we need to improve https://jujucharms.com/docs/1.25/reference-hook-tools and https://jujucharms.com/docs/1.25/authors-hook-environment
<petevg> arosales: Aha. They do have the info that I need. We should probably mention elsewhere that unit-get is only useful for getting two pieces of information.
<petevg> I'll make a note to make tickets/submit patches.
<arosales> petevg: +1
<j_king> rick_h_: https://code.launchpad.net/~james-agentultra/charms/precise/mongodb/join-replicaset-test/+merge/296466 ?
<j_king> I have to run, kids waking from their nap... I'll check my backlog in an hour or two. :) Cheers!
<kjackal> cory_fu kwmonroe petevg: are we merging the work we are doing against bigtop or are we on-hold until the main contribution is accepted by bigtop?
<kjackal> merging: for example the work on ignite should we merge it in to our juju-solutions/bigtop master?
<petevg> kjackal: I've got the zookeeper stuff in a separate repo, as it was my understanding that we're holding off. I could be wrong, though.
<chimeric> quick question regarding charm benchmark
<chimeric> i'm trying to load the charm module in ubuntu 14.04 and i'm getting an import error saying charm.core.benchmark does not exist
<chimeric> is there a prebuilt package for this, or is source the only option?
<cory_fu> kjackal: I think we're somewhat holding off, but we could also submit them as separate Jiras and mark them as dependent
<kjackal> petevg: seperate repos.... this is what I was doing also last week :)
<kjackal> petevg: we now move everything under branches in bigtop repo
<petevg> kjackal: got it. I will move my stuff over, then :-)
<kjackal> the layers go under bigtop-packages/src/charms/....
<kjackal> note that the name of the layer (defined inside metadatayaml) matches the directory of the service you are charming
<ryebot> What's the trick to juju2 deploying an in-development bundle with local charms?
#juju 2016-06-04
<j_king> I must be proposing a merge to the wrong branch... https://code.launchpad.net/~james-agentultra/charms/precise/mongodb/join-replicaset-test/+merge/296480
<j_king> I've only modified 1 file. :S
<j_king> https://bazaar.launchpad.net/~james-agentultra/charms/precise/mongodb/join-replicaset-test/revision/87#tests/03_deploy_replicaset.py but when I create the MP there's like a million extra files and lines. what I do? :(
<SaltyVeryMuch> Hi, I got an issue with juju2.0 and maas, I can deploy it via a work around, but then the commands don't do anything
<magicaltrout> lazyPower: loving the tunes
#juju 2016-06-05
<j_king> I think I might've fixed it. pebkac.
<j_king> https://code.launchpad.net/~james-agentultra/charms/precise/mongodb/join-replicaset-test/+merge/296497
<bodie_> how does Juju compare to Kubernetes?
<jrwren> bodie_: something still needs to deploy all of your systems that are going to run k8s and juju is excellent at that.
<jrwren> bodie_: https://jujucharms.com/kubernetes/trusty/
<bodie_> jrwren, I see, so Juju is more of a PaaS orchestrator and then actually scheduling containers on the platform might be the role of something like Kube?  Can't Juju also handle container scheduling?  I might have misunderstood a bit
<magicaltrout> hey bodie_ I don't use k8s so you're talking to the uneducated here, but what you write is my understanding of it
<bodie_> magicaltrout, do you use a different container scheduler on top of juju, or just juju?  My understanding was that Juju can also handle container scheduling via lxd on units
<bodie_> I think that's where my confusion is: do you even need kube if you're running juju?
<magicaltrout> sorry bodie_ you caught me watching youtube instead of monitoring IRC ;)
<magicaltrout> personally in production deployments I just use plain Juju, that said I am working on DC/OS support for Juju for one client
<magicaltrout> for development and testing I often use LXD & Juju because it provides a pretty good simulation on my development server
<magicaltrout> but LXD support is currently LXD local not LXD remote, so you cant do it in a cluster or anything like that
<magicaltrout> that said of cause plenty of people do use Juju and K8S just as it underpins a large number of openstack deployments
<bodie_> Ah, I see
<bodie_> Thanks magicaltrout
<jrwren> bodie_: I think it is definitely true that for many workloads you don't need k8s if you are running juju.
<jrwren> bodie_: That said, they are different things. Juju is an universal modeling system for software application workflows. K8s is a management control system for docker.
<jrwren> bodie_: e.g. k8s self-healing, service disco and load balancing features, afaik, juju has no such equivalent. A charm might provide it, but juju itself does not.
<bodie_> I think that makes sense
<bodie_> Juju is more for modeling a specific arrangement of services where Kube is more for scheduling containers on some platform
<jrwren> *whew* good. I do not feel confident in my ability to explain the differences, so I'm happy it makes some sense.
<bodie_> I think it's a complicated topic, lol
<magicaltrout> you know when you're on the road with work and the your partner isn't replying to texts probably cause the kids are being really annoying, so you ask how her day has been and tell her to call whenever if she wants a chat. But secretly you hope she doesn't because its going to involve a lot of complaining and you're sat 1000's of miles away.......
#juju 2017-05-29
<kjackal> Good morning Juju world!
<cnf> ohai
<Naz> Hi, I am deploying a charm in Juju, and watching Juju debug-log status. Z Message for related unit is waiting for machine &state of z machine is Pending. Normally, after z machine starts; logs in z watch debug-log starts flowing. My question is : How to check the logs of the undergoing actions prior having the machine started , I mean the logs of machine STARTING-UP? (PS: juju ssh -m controller 0 and tail -f /var/log/juju/logsink.log is wai
<kjackal> hi Naz, are you able to ssh into the machine?
<kjackal> Naz: if the machine is stuck on provisioning you can retry-rpovisioning
<kjackal> Â juju retry-provisioning
<kjackal> if you can ssh into the machine all juju logs should under /var/log/juju
<Naz> Hi Kjackal, Thank you for your reply. In fact, I am interested in seeing the logs prior allocating the IP Address for the machine, i.e. the machine is still in state PENDING
<kjackal> ok... so if it does not have an Ip.... I would look at the console of you cloud(?) provider?
<kjackal> Naz: ^
<admcleod> Naz: you could also try debug-log without any switches, or all-machines.log on the controller
<Naz> Yes, for example: id: 19       State: pending  10.187.111.207  juju-8aa58b-19  xenial
<Naz> Even If the ip address is allocated, I still cannot ssh it until it's started.. In fact:
<Naz> juju ssh 19 ERROR retrieving SSH host keys for "19": keys not found
<Naz> Hi Admcleod, let me try please, one sec
<Naz> @Kjackal, I am working on local Cloud (LXD)
<Naz> @Admcleod, where is the all-machines.log? In fact, after sshing into the controller, I get ubuntu@juju-b99076-0:/var/log/juju$ ll total 48172 drwxr-xr-x 2 syslog adm           5 May 16 13:13 ./ drwxrwxr-x 8 root   syslog       23 May 25 06:25 ../ -rw------- 1 syslog syslog        0 May 16 13:13 audit.log -rw------- 1 syslog syslog 47220599 May 29 09:15 logsink.log -rw------- 1 syslog syslog  1846025 May 29 09:07 machine-0.log
<Naz> @Admcleod, where is the all-machines.log? In fact, after sshing into the controller, I get ubuntu@juju-b99076-0:/var/log/juju$ ll ---> audit.log and logsink.log and machine-0.log
<Zic> lazyPower: hi, respawning the cluster which had the race-condition on etcd unit, crossfingered \o/
<kjackal> Naz: then your lxc logs are under /var/log/lxc (or lxd?) also have a look here to get access to the the lxc contaners spawed by juju http://lzone.de/cheat-sheet/LXC
<kjackal> Naz: you sill probably need something like sudo lxc list and sudo lxc exec -- /bin/sh (I hope)
<Naz> @Kjackal, let me try it please :)
<Naz> @Kjackal, HP:/var/log/lxd/juju-8aa58b-19$ ll  ====> forkstart.log and lxc.conf and lxc.log and lxc.log.old , all with NOT An UP-TO-DATE Timestamp.
<Naz> @Kjackal, $more lxc.log ===>             lxc 20170529090737.930 WARN     lxc_start - start.c:signal_handler:322 - Invalid pid for  SIGCHLD. Received pid 10124, expected pid 10129.
<kjackal> Naz: so you see the container in lxc list?
<Naz> @kjackal, yes, I see it in lxc list
<kjackal> can you get a shell inside the container?
<kjackal> Naz: something like lxc execute juju-8aa58b-19 -- /bin/sh (I hope)
<Naz> @kjackal: last line is ===> error: unknown command: execute
<Naz> $ lxc execute juju-8aa58b-19 -- /bin/sh ---> Usage: lxc <command> [options]  ====> Available commands: ---> 	config     - Manage configuration.....
<Naz> ok
<kjackal> Naz: lxc exec  juju-8aa58b-19 -- /bin/bash
<Naz> it should be lxc-execute
<Naz> $ lxc-execute juju-8aa58b-19 -- /bin/sh The program 'lxc-execute' is currently not installed. You can install it by typing: sudo apt install lxc1
<kjackal> can you please try lxc exec ?
<Naz> Yes, :) lxc exec  juju-8aa58b-19 -- /bin/bash ====> Works :)
<Naz> I got the shell inside the machine although its pending !, now what? :)
<kjackal> Naz: is there anything interesting under /var/logs?
<kjackal> do you have network interfaces up?
<Naz> @kjackal, you are the man :), Yes, in the /var/log, there is an up-to-date syslog file that captures the ongoing event while the machine is pending
<kjackal> :)
<Naz> @Admcleod, I didnt find all-machines.log neither of the host nor on the controller: ===> $ sudo find / -name *all-machines.log ===> NOTHING.... But fortunately, now my issue is solved by: lxc exec juju-xyz-<id> -- /bin/bash and tail -f /var/log/syslog
<Naz> Thank you Kjackal and Thank you Admcleod.
<erik_lonroth> Hello. I'm trying once again to get a charm python-django get get out of a "stuck" situation. I'm trying the things I've learned by "remove-application", "resolved"  etc. But I'm stuck and cant get out of it. Seems my only way forward is to purge the environment (again). This is a pain since it takes a while to re-create the situation and I'm in a debug mode at the moment. Is there any trix you use to get a unit out of a "deadlock/s
<erik_lonroth> tuck" situation so I don't end up in a debug cycle that takes forever?
<Budgie^Smore> o/ juju world
<Catalys> Does the charm of openstack-base support configurating the root password injection too?
<Budgie^Smore> Catalys for the underlying system? or for the UI?
<Budgie^Smore> OpenStack UI*
<Catalys> Budgie^Smore I believe that the dashboard has a variable for the injection in its local_settings.py and compute has it in the nova.conf, so I assume both then.
<Catalys> Budgie^Smore That said the dashboard says it has it on by default though.
<Budgie^Smore> so which root password are we talking? juju sets up password-less login and injects an ssh key into the underlying os root account
<Catalys> Budgie^Smore Oh sorry I should have mentioned that I am talking about the root password of instances created by Openstack which runs on Juju :).
<Catalys> Budgie^Smore Normally I would run "juju config compute-nova" to change a setting though.
<Catalys> https://docs.openstack.org/admin-guide/compute-admin-password-injection.html
<Budgie^Smore> Catalys ah yes
<Budgie^Smore> Catalys been a long time since I cared about passwords like that :)
<Catalys> Budgie^Smore Yes I guess SSH keys are the norm but passwords are still easy for development stuff, at least so I feel about it. Btw I did try "juju config openstack-dashboard retrieve-password=true" but that didn't seem to much affect do I have to do something additional to activate that?
<Catalys> Budgie^Smore And when I ssh into a compute node and add it myself into the config, won't it reset upon reboot though?
<Budgie^Smore> Catalys that has been my experience of "manual" config changes, could the image used to create the VM be turning it off? disclaimer: not a juju dev but like to help if I can :)
<Catalys> Budgie^Smore Do you mean turn off the retrieve password option or injection :)?
<Budgie^Smore> Catalys no, you can build an image that turns off password login in ssh so regardless of a password injection or not it will fail to log in with a password
<Catalys> Budgie^Smore Oh true but it doesn't generate a password in the first place, it only seems to inject key pairs at the moment.
<Catalys> Budgie^Smore That said there is cloud-init though.
<Budgie^Smore> Catalys but even then in the companies I have work in we used keys or certs for all environments (even our work systems only used local passwords), that way no passwords were transmitted across the network, and sshkeys / certs had local passphrases
<Catalys> Budgie^Smore Turns out the easiest for now might be using scripts which run post installation, now I move on to figuring out why my external network doesn't work haha.
<Catalys> Budgie^Smore It gets a IP from the DHCP server, feel free to jump in if you've got an idea though.
#juju 2017-05-30
<bdx> http://paste.ubuntu.com/24709556/
<bdx> hehehe
<bdx> anyone who can see whats going on there gets a gold star
<kjackal> Good morning Juju world!
<BlackDex> hello there
<BlackDex> i'm getting this message
<BlackDex> ERROR some agents have not upgraded to the current model version 2.1.3.1: machine-1
<BlackDex> i have a ha juju running
<BlackDex> and apperently one agent wasn't up/failed
<BlackDex> how can i fix this?
<SimonKLB> is it possible to run the etcd charm without persistent storage?
<SimonKLB> nvm, just skip the --to flag =)
<kwmonroe> hey lazyPower, arch question for ya... do you know why k8s went with etcd vs something like zookeeper?
<lazyPower> kwmonroe: that question has come up quite a bit on their lists, but with consul instead of zookeeper. I think it was because coreos was in there early and did that heavy lifting but its hard to say
<kwmonroe> ah, roger dodger.  just curious.  not saying zookeeper is some kind of panacea by any stretch ;)
<lazyPower> kwmonroe: yeah, there was talk at one time of doing a libkv that would abstract the providers
<kwmonroe> something with a small footprint like https://jujucharms.com/hadoop-hbase/ would have fit the kv bill nicely.
<kwmonroe> because why have a microservice when you can just have 10 machines
<lazyPower> :) no comment
<kwmonroe> :)
<admcleod> kwmonroe: probably go vs java
<Budgie^Smore> o/ juju world!
<rick_h> what's up Budgie^Smore
<Budgie^Smore> not much, still evangelising juju in interviews :)
<rick_h> :)
<Budgie^Smore> had someone say the master / slave model is bad though :-/
<Budgie^Smore> has anyone figured out what juju's performance is in terms of cpu & mem per host managed?
<rick_h> yea, 2.2 does a lot of work on that as it's a limiting factor in JAAS being effective
<rick_h> so there's regular testing of scalability and chattiness and such
<Budgie^Smore> yeah it is a limiting factor in any master / slave environment... is the testing documented anywhere?
<rick_h> Budgie^Smore: hmm, there's notes in the bugs/etc where things are identified but yea, nothing really to point to other than the various bugs as things are identified.
<Budgie^Smore> rick_h it would definitely be useful to have since there is a fear that master / slave environments are not scalable, which we both know is bull and makes it impossible to auto scale in and out
<rick_h> Budgie^Smore: fair enough. I might take some time to show off the 2.2 improvements in a visible way or something.
<rick_h> Budgie^Smore: thanks for the nudge
<Budgie^Smore> rick_h no worries, just giving back the feedback that I am getting when talking about Juju :)
<rick_h> good stuff
<Budgie^Smore> rick_h at the very least it would be good to have documentation on scaling controllers beyond a minimal ha setup
<rick_h> Budgie^Smore: yes, that's firmly in my current working list
<rick_h> Budgie^Smore: I'm doing the troubleshooting, but the goal post-troubleshooting is to turn into the "best practices" for juju taking expected scale into account
<rick_h> Budgie^Smore: so look for "operating Juju" documentation
<rick_h> in the near future
<Budgie^Smore> rick_h is there anything else I haven't though about that is in your work list ? ;-)
<rick_h> Budgie^Smore: let's see, I've got some metrics, blogs posts, and 2.2 testing on my todo list :P
<urulama> Budgie^Smore: adding cpu cores scales how many units a controller can operate pretty much linearly. last updates to 2.2, a 8-core machine was able to run 1400 machines with 2300 units, using 10GB of RAM and 70% of CPU
<urulama> (as an example)
<Budgie^Smore> urulama oh awesome, thanks :) that funnily enough is in line with the example of about 1000 slaves / master that I was talking about in an interview last week
<urulama> Budgie^Smore: there are some changes before RC1 is out, that will help lower CPU usage from what you've seen with 2.1.x even more. 2.2 will be awesome :D
<Budgie^Smore> it is worth knowing that I am usually dealing with networks of systems in the 10k+ range
<urulama> we'll get there :)
<Budgie^Smore> urulama I don't doubt it, but I do think 10 masters for 10k system is not a bad ratio to start with
<urulama> hm.
<Budgie^Smore> but that depends if the controllers can share the world load or if HA is more a active / passive affair
<Budgie^Smore> work*
<urulama> HA doesn't do full load balancing atm
<Budgie^Smore> ah ... on the roadmap?
<urulama> yep
<Budgie^Smore> :P
<urulama> and not "some distant future" either :D
<Budgie^Smore> oh if you are talking being able to hand hyperscale it better not be :P
<urulama> but until then, current HA is not so much about scaling as it is about redundancy
<Budgie^Smore> handle*
<Budgie^Smore> sometimes I wish I was a stronger dev than I am, just this discussion has given me ideas :)
<NicolinoCuralli> hi there: how can set an EIP on AWS for the controller at bootstrap phase? juju bootstrap set a dinamic public ip and if i reboot machin i can' login again
<NicolinoCuralli> i understand that becuase there is HA configuration it is not necessary to have a EIP : is it correct?
#juju 2017-05-31
<jac_cplane> is there anyway to change the admin_domain for keystone ?    it seems that keystone charm creates admin_domain as default.  I need to have this charm create the domain "default" instead of admin_domain
<kjackal> Good morning Juju world!
<Hetfield> morning all. i have deployed an openstack cloud via juju. now i want to deploy services adding the same openstack in the juju cloud
<Hetfield> unfortunately it fails
<Hetfield> juju add-cloud openstack1 tenant-demo-env.yaml ERROR cannot unmarshal yaml cloud metadata: yaml: unmarshal errors:   line 4: cannot unmarshal !!str `userpass` into []cloud.AuthType
<Hetfield> this is the yaml
<Hetfield> https://paste.ubuntu.com/24724275/
<Hetfield> ok, i fixed it by using [userpass] syntax
<Naz> Hi, Whenever I create an new service, the first TYPICAL ERROR message I get from juju debug-log reads like follows:  "unit-name-1: 11:54:06 ERROR juju.worker.dependency "metric-collect" manifold worker returned unexpected error: failed to read charm from: /var/lib/juju/agents/unit-name-1/charm: stat /var/lib/juju/agents/unit-name-1/charm: no such file or directory"
<Naz> However, Sshing to the related machine, and checking the full, it's found indeed however, the owner and the group are ROOT:ROOT
<Naz> root@juju-8aa58b-21:/var/lib/juju/agents/unit-name-1/charm# pwd /var/lib/juju/agents/unit-name-1/charm
<Naz> root@juju-8aa58b-21:/var/lib/juju/agents/unit-name-1/charm# ll total 583 drwxr-xr-x 15 root root     30 May 31 08:54 ./ drwxr-xr-x  4 root root      7 May 31 08:54 ../ drwxr-xr-x  2 root root      8 May 31 08:54 actions/ -rw-r--r--  1 root root    670 May 31 08:54 actions.yaml drwxr-xr-x  2 root root      3 May 31 08:54 bin/ -rw-r--r--  1 root root 249687 May 31 08:54 name.svg -rw-r--r--  1 root root   6659 May 31 08:54 config.yaml -rw-r--r
<Naz> Is it because, no metrics are yet defined on such charm? But why would it necessitates to call metric-collect as first thing?
<mattyw> Naz, that looks like this bug: https://bugs.launchpad.net/juju/+bug/1656258
<mup> Bug #1656258: metric-collect returned unexpected error <logging> <metrics-collector> <juju:Fix Committed by cmars> <juju 2.1:Won't Fix> <https://launchpad.net/bugs/1656258>
<Naz> @Mattyw, Yes, correct, thank you, it's mentioned that this bug is fixed in 2.2.rc1 and won't be fixed in 2.1.2
<mattyw> Naz, I don't think it's a problem though - the unit should continue working as expected
<Naz> @Mattyw, Yup, correct :)
<Naz> Excuse me, I am still learning, I shall check the issues in bug repositories next time :)
<mattyw> Naz, no problem - I only knew the bug was there because I remember discussing it a few weeks ago
<Naz> @Mattyw, Great, thank you my friend, you are the man :)
<Naz> I see: "The current stable version of Juju is 2.1.3 and is recommended for everyday production use."
<Naz> I am running on 2.1.2! How could I upgrade to latest stable without losing my models/apps?
<Naz> https://jujucharms.com/docs/stable/reference-install, isn't it for install from scratch?
<Naz> Found it :), juju upgrade-juju --agent-version 2.1.3
<chrome0> Question regarding network spaces: afaict juju/state/machine_linklayerdevices.go , it seems that in order for a space to be considered as available on a host, that host must have a iface *with an ipaddr* in the spaces subnet, is that correct?
<chrome0> The problem is, I'd like to have a metal deployed by maas 2.2, with a bridge iface in a vlan'ed space but w/o ipaddr, and handing out ipaddr only in containers
<chrome0> Those are pub ipv4 addr and therefore scarce
<chrome0> Getting an error message when deploying a test container -- cannot start instance for machine "1/lxd/2": unable to setup network: host machine "1" has no available device in space(s) "space-api"
<chrome0> But, icb reading that source wrong, IANAGoDeveloper
<chrome0> Fwiw, this is maas 2.2 and juju 2.1.3
<chrome0> Interestingly, in the above ^^ ctxt, the constraints matcher seems less picky. I can add-machine --constraints spaces=space-api and get the machine deployed (it warns about an address-less device though)
<rick_h> chrome0: so I know that the goal is to support what you're doing. I don't think we're there to support it yet. jam is the best person to confirm if there's any trick to getting it working under current conditions
<rick_h> maybe wpk
<jam> rick_h: I'm missing the context from chrome0 had to restart my comp
<rick_h> jam: ah sorry, he's wanting to use maas to get the host w/o an ipaddr on the device passed to the container
<jam> rick_h: chrome0: wpk has been digging more closely into being able to represent what space a device is in when it doesn't have an IP address, but right now, when we try to link up charms to devices, etc
<jam> we explicitly enumerate devices, find their IP addresses, and then compare them to the subnets we know about
<jam> we want to change that, but its the current logic
<jam> so again, you can probably get the right machine
<jam> but things like binding the charm to the right device won't quite work right
<rick_h> ty jam
<burton-aus> axw_ develop branch seems in a high activity right now...
<burton-aus> axw_ Updates were rejected because the tip of your current branch is behind its remote counterpart.
<burton-aus> axw_ solved
<chrome0> Thanks rick_h and jam , was afraid you'd say that. Is there a bug filed about this? If not I'll create one
<jam> chrome0: there is a bug, but i'd have to look it up
<chrome0> Cheers, I'll see if I can find it
<jam> chrome0: https://bugs.launchpad.net/juju/+bug/1659376
<mup> Bug #1659376: should be a way to specify space binding for maas "unconfigured" interface <cdo-qa-feature> <network> <oil> <oil-2.0> <uosci> <OpenStack neutron-gateway charm:New> <juju:Triaged> <neutron-gateway (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1659376>
<jam> I think is the one I was thinking
<chrome0> Yup, my usecase is a bit different but this should cover it
<lazyPower> SimonKLB: i summon thee (if you're summonable)
<SimonKLB> lazyPower: whats up?
<lazyPower> SimonKLB: i'm tapping Cynerva to lend a hand with our networking conundrum while i step away to run some quick errands
<Cynerva> o/
<SimonKLB> hey!
<lazyPower> Cynerva: this is simon, he's got an issue with pod networking in lxd
<Cynerva> howdy
<Cynerva> okay
<lazyPower> i thought it was kube-proxy related but that doesn't appear to be the case
<lazyPower> cant resolve VIP's in a lxd worker's pods :|
<Cynerva> hmm
<SimonKLB> i am able to access the service IPs from the worker host
<SimonKLB> so i think the forwarding is fine
<SimonKLB> service -> pod that is
<SimonKLB> but pod -> service is not working
<Cynerva> okay, thinking for a bit
<SimonKLB> also, i can see the traffic on the cni0 interface
<Cynerva> i'm trying to remember, i've seen something like this before but don't remember the circumstances
<Cynerva> is this across workers? or pod->service within a single worker?
<SimonKLB> single worker
<Cynerva> okay, i dunno
<Cynerva> i'm suspicious kube-proxy is still doing something weird
<Cynerva> with traffic that comes from the pod IP range
<Cynerva> SimonKLB: can you send me the output of `iptables-save` and `cat /var/snap/kube-proxy/current/args` from the worker?
<SimonKLB> yup
<roadmr> hello jujuers. I have a couple of subordinate charms in "allocating - waiting for machine" state (weird for a subordinate! the machine it's being deployed to has already been provisioned and the main service is ok). The log says this: 2017-05-31 08:29:17 ERROR juju.worker.proxyupdater proxyupdater.go:164 can't connect to the local LXD server: LXD socket not found; is LXD installed & running?
<roadmr> any ideas why it seems to want lxd?
<Hetfield> hi all, i had to open a bug for kubernetes bundle not honoring proxy settings
<Hetfield> https://bugs.launchpad.net/bugs/1694743
<mup> Bug #1694743: kubernetes-[master,worker] snap install fail due to missing proxy <Juju Charms Collection:New> <https://launchpad.net/bugs/1694743>
<Budgie^Smore> o/ juju world
<vlad_> Hey quick question if anyone has the time... I'm just running the base openstack bundle on juju and wondering how I connect to the cloud it deploys? I can figure out how to shell into the nodes, but have no idea where the credentials are for the openstack cloud
<mmcc> hi vlad_ - there are notes in the Readme for the openstack-base bundle about how to connect. See the section "Accessing the cloud" at https://jujucharms.com/openstack-base/
<mmcc> actually, start two paragraphs earlier at "Ensuring it's working" :)
<mmcc> it suggests you download the bundle, but you could alternatively just get this file https://api.jujucharms.com/charmstore/v5/openstack-base/archive/novarc
<mmcc> for the default env vars that'll let the clients log in
<vlad_> Ahhh that's the exact file I was looking for sorry didn't see the link to it my mistake
<vlad_> mmcc: thanks kindly
<mmcc> vlad_: you're welcome, glad I could help!
<tychicus> I realize that this probably goes against the cattle vs pet convention, but is it possible to specify the hostname or naming convention for a new machine?
#juju 2017-06-01
<kjackal> Good morning Juju world!
<Zic> hi here
<Zic> lazyPower: hmm, I have a problem with a juju upgrade-charm kubernetes-worker : http://paste.ubuntu.com/24737881/
<Zic> running apt-get update manually on the unit machine does not return any error, I don't understand
<lazyPower> Zic: thats fun. if you run apt-get upgrade does it complain about the 404's now that you've run the upgrade?
<lazyPower> typically when i see that, its because i have a stale cache lying around
<lazyPower> *update
<Zic> lazyPower: nop, if I run apt-get update directly on the unit machine all is fine :(
<lazyPower> Zic: thats funky. if you re-execute upgrade-charm does it work?
<lazyPower> is this in aws or your on-prem solution?
<Zic> this is the fully-AWS cluster
<Zic> lazyPower: I see in juju debug-log that the upgrade-charm still retrying the apt-get update, but with the same error 404
<lazyPower> Zic: hang on, so you ran the apt-get update && apt-get upgade on that host thats currently locked trying to do the same operation in upgrade-charm?
<Zic> running it after it give-up in juju debug-log yup
<Zic> hmmmm
<Zic> solved \o/
<Zic> lazyPower: I just did what it advices : apt-get update --fix-missing
<Zic> upgrade-charm is now unlocked and proceed
<lazyPower> good deal
<Zic> did an "apt update --fix-missing" earlier before alerting you, but as the charm use apt-get and not apt, it seems to not be the same cache
<Zic> I have just one error left, but don't know it is important: unit-kubernetes-master-0: 14:33:22 ERROR juju.worker.metrics.sender could not remove batch "6009d068-6c17-4403-8c4e-bf186e66b8ea" from spool: remove /var/lib/juju/metricspool/6009d068-6c17-4403-8c4e-bf186e66b8ea: no such file or directory
<Zic> lazyPower: hmm, upgrade-charm kubeapi-load-balancer literally broke Juju, don't know what happened : http://paste.ubuntu.com/24738034/
<Zic> the juju controller machine suddenly froze then came back with this
<lazyPower> Zic: that smells like the juju db stopped.
<pathcl> hey anybody using vsphere with distributed virtual switch having this bug ? 1619812
<Zic> lazyPower: happily it seems to recover automatically
<Zic> all machine agent was in "unknown" but they just came back
<Zic> and all is green, even the kube-apilb
<Zic> -> don't know what happens but it works
<mattyw> lazyPower, ping?
<lazyPower> mattyw: pong
<mattyw> lazyPower, hey there, the problem Zic saw about with juju.worker.metrics - that was following a charm upgrade on k8s right?
<lazyPower> yeah, i think so
<lazyPower> Zic: i'm going to talk about you like you're not here ;)
<Zic> :D
<Zic> yup
<Zic> was after a juju upgrade-charm on kubernetes-master
<Zic> (or maybe just after juju config channel=1.6/stable)
<mattyw> any idea what the before and after versions were?
<mattyw> and if metrics had been added
<mattyw> because if so I believe that's a known bug - just want to make sure there's not a new bug I should know about
<Zic> mattyw: hmm, if I can find the old revision number of charm somewhere, say it to me but if it does not exist: this was a CDK cluster last fully-upgraded a month ago
<Zic> was already in 1.6.2, just upgrade Juju operationnal code
<mattyw> lazyPower, latest version should be recording metrics right?
<lazyPower> mattyw: yeah, we've had metric support in the k8s charms for the last 3 releases that i'm aware of
<Zic> unit-kubernetes-master-0: 15:07:09 INFO unit.unit-kubernetes-master-0.collect-metrics error: persistentVolume is not namespaced
<Zic> it's not in INFO instead of ERROR
<Zic> s/not/now/
<mattyw> Zic, what happens if you run juju collect-metrics kubernetes-master/0 ?
<Zic> ERROR "kubernetes-master/0" is not a local charm
<Zic> (it is... in fact)
<Zic> lazyPower: multi-master is still considered "not for production usage"?
<Zic> I'm asking myself if I switch this production cluster to multimaster again now it is upgraded to the latest charms
<lazyPower> Zic: its supported
<lazyPower> well, supported in our solution as you're using the load balancer
<lazyPower> Zic: sorry about the delay was out getting my walk in before the day turned up the heat :)
<Zic> np :)
<tvansteenburgh> cmars: i think you were right about zetcd
<lazyPower> what'd i miss about zetcd?
<cmars> tvansteenburgh, ok :) yeah, i was trying to get it to work with the etcd charm. ended up with https://github.com/cmars/charm-zetcd but couldn't get the tls stuff working
<tvansteenburgh> lazyPower: i snapped it, cmars has been playing with it
<cmars> lazyPower, just some hacking around. i was thinking it'd be neat to use kafka with etcd instead of zookeeper
<lazyPower> interesting
<lazyPower> ok :) i thought maybe this was something i should be tracking
<bdx> new use case popping up
<bdx> I'm just having my users add their local vms to JAAS models
<bdx> this eliminates each user needing to bootstrap and know how to operate a controller
<bdx> and alleviates the load of a controller on their on their dev vms
<bdx> this has allowed users to hop right in and deploy things to a local vm from their osx hosts
<bdx> I have a lxd-proxy charm that I'm having users deploy to the the local vm
<bdx> then they just access the lxd services on the vm via the lxd proxy
<bdx> super streamlines the osx dev use case
<lazyPower> :o you can do that?
<lazyPower> #TIL
<tvansteenburgh> bdx: blog post please :P
<bdx> I am so backed up as far as blog posts go, oh man
<bdx> creating some quality blog content is going to be my summer project
#juju 2017-06-02
<kjackal> Good morning Juju World!
<bkc_> I am unable to conjure-up kubernetes on vsphere, getting "Insufficient resources to satisfy configured failover level for vSphere HA." probably because I cannot specify the datastore and network to use. How do I specify the datastore and network in vsphere cloud config?
<tvansteenburgh> bkc_: i'm not sure but maybe this will help https://hackernoon.com/vmware-vsphere-kubernetes-and-gpus-of-course-a7a06c87c51d ?
<tvansteenburgh> bkc_: SaMnCo might have other pointers
<bkc_> thanks, its confusing the relationship between conjure-up and juju.. If I bootstrap juju, will conjure-up use the existing controller?
<bkc_> also in the example, it only shows how to specify the root disk size, but still no way to specify the datastore or network to use
<stokachu> bkc_: you can only specify external network to use
<bkc_> k, how does juju choose the datastore to use?
<stokachu> bkc_: also if you bootstrap juju, conjure-up can use that existing controller
<stokachu> bkc_: good question that I dont have an answer for
<stokachu> bkc_: SaMnCo when he's around will, or perhaps axw
<bkc_> I wonder, if I bootstrap the controller, then later move it to a different datastore, will conjure-up re-use that datastore for the remaining k8s nodes..
<bkc_> in the juju vsphere go code, I do see mention of datastore, but I haven't figured out where that value is coming from
<stokachu> bkc_: conjure-up just uses whatever is defined in juju model
<SaMnCo> bkc_: can you try bootstrap then start conjure-up?
<SaMnCo> As conjure-up can plug to an existing controller
<bkc_> I will try it, but I need explicit control over datastore
<SaMnCo> You shouldn't have to specify the data store or network
<bkc_> I do need to be explicit about which datastore to use.. we have many other vms and managed san..
<SaMnCo> Ok. Sorry I don't have much time right now but maybe you can create a data center, allocate storage and network thrre
<SaMnCo> And then tell juju to use only that
<SaMnCo> Using Juju bootstrap vSphere/dc
<SaMnCo> Datacenters are regions for Juju in vSphere
<bkc_> to do that I would have to allocate an entire vm host to the new datacenter.
<bkc_> unfortunately I cannot do that.. this is on-prem deployment with only 3 hosts, 256GB ram each but I cannot free up a host. Also I wouldn't be able to have failover with only one host
<bkc_> thanks for answering my questions, I think I will have to try k8s-anywhere instead.
<tvansteenburgh> bdx: <3 for your blog post
<bdx> tvansteenburgh: thx, you gave me the motivation
<Budgie^Smore> o/ juju world
<lazyPower> \o Budgie^Smore
#juju 2017-06-03
<Catalys> Would anyone be able to tell whether I can change the IP of a Juju unit in case the current one is no longer available though?
#juju 2017-06-04
<lazyPower> Catalys: So, the agents report the ip address of the unit during its init phase. If the IP address changes, the unit should be reporting the new ip address if you cycle that unit/machine agent.
<Catalys> @lazypower: Alright and by cycle you mean doing a simple reboot of that specific unit then?
<lazyPower> Catalys: thats one way, but you should be able to just cycle the systemd unit. `systemctl restart jujud-unit-mysql-0` for example
<lazyPower> that was from memory, pardon me if the systemd naming schema is a little off, like instead of unit, its 'agent'
<Catalys> Thanks it was just some bothering me for a bit and not clearly described in the documentation, or I might be blind lol.
<Catalys> At least the question has now been answered haha.
<Catalys> lazypower: However to be clear, say I move to a new subnet then Juju will fully take care of itself and pick a new IP on it own though?
<Catalys> Or do you still have to go into the SSH and edit the interfaces file there.
<lazyPower> so long as that new subnet can reach the controller there shouldn't be any additional action on your part
<lazyPower> there might be some holdover issues with certain charms that dont handle the ip update correctly
<lazyPower> like if you move mysql to a new subnet and say keystone doesn't have any logic to handle the updated ip once the config is written, that may cause you some heartburn
<lazyPower> but its reasonably safe to do so in most cases.
<Budgie^Smore> o/ juju world are we having fun yet?
#juju 2018-05-28
 * thumper goes to make a coffee and think
<veebers> thumper, babbageclunk also add go-errcheck and go-unconvert to that list too (as it's all done by metalinter at push time)
<babbageclunk> veebers: yeah, but I like getting some of those warnings earlier
<veebers> babbageclunk: ack, fair enough. So far I've found go-lint and go-vet catch what I need, but everyones needs differ :-) I noticed errcheck hits my machine hard cpu-wise
<babbageclunk> veebers: yeah, fair enough - might try turning it off and see how I feel then
<veebers> babbageclunk: if you turn it off and you start feeling nauseous I would, uh, consider triple checking what settings you have in your .emacs!
<babbageclunk> *not an emacs doctor
<veebers> ^_^
<blahdeblah> ^ but he plays one on television
<veebers> blahdeblah: :-)
<Couaque> Hello guys !
<manadart> For review: https://github.com/juju/juju/pull/8774
<manadart> Going to system test a few more cases, but it looks good so far.
<manadart> Aaand. Nope. Changes required.
<Guest91417> manadart: does that mean you don't want a review yet?
<manadart> Guest91417: What is there is unlikely to change, so it can be reviewed. Additional changes will almost certainly be required elsewhere.
<jam> manadart: reviewed
<manadart> jam:
<manadart> Ta.
<mcsmash> Hello all. I'm trying to provision a manual cloud. I successfully bootstrapped the controller. I started the command 'juju add-machine ssh:user@ip' 45 minutes or so ago, it asked me for my password, and it's still sitting there ever since. There's no output, just a cursor, blinking at me... mocking me.
<pmatulis> mcsmash, did you follow
<pmatulis> https://docs.jujucharms.com/2.3/en/clouds-manual
<mcsmash> Yes
<mcsmash> I confirmed that I have full ssh access to the machine that I want to add.
<mcsmash> I re-ran that command with the `--verbose` flag, and it's giving me the following output.
<mcsmash> Adding contents of "/home/mcsmash/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-keys
<mcsmash> Adding contents of "/home/mcsmash/.ssh/id_rsa.pub" to authorized-keys
<mcsmash> after that it stalls
<pmatulis> mcsmash, what version of juju? i may try to reproduce tomorrow
<pmatulis> 2.3?
<pmatulis> 2.3.8
<mcsmash>  2.3.7-bionic-amd64
<mcsmash> all machines are running bionic
<mcsmash> I just realized that I had bootstrapped from a machine that's running 16.04. I unprovisioned my controller and I'm re-bootstrapping from another 18.04 instance.
<mcsmash> Looks like that fixed my problem.
<veebers> Morning o/
<veebers> Anyone keen for a simple PR? :-) https://github.com/juju/juju/pull/8775
<babbageclunk> veebers: approved!
<babbageclunk> would that all PRs were so easy
<veebers> babbageclunk: cheers
#juju 2018-05-29
<kelvinliu_> hi veebers mind to take a look these 3 PRs when u got some time? thx https://github.com/juju/juju/pull/8777  https://github.com/CanonicalLtd/juju-qa-jenkins/pull/38/files https://github.com/CanonicalLtd/juju-qa-jenkins/pull/43/files
<veebers> kelvinliu_: can do :-)
<kelvinliu_> veebers, thx :)
<veebers> kelvinliu_: for nw-bootstrap-caas-lxd did you land your fixes for it?
<kelvinliu_> veebers, yes, it's in dev branch now
<veebers> sweet
<kelvinliu_> i set all the two test running on goodra only for now.
<veebers> kelvinliu_: for https://github.com/juju/juju/pull/8777 am I right in thinking that other than assess_caas_bootstrap.py and assess_caas_deploy_charms.py the rest i the charm inclusion?
<veebers> kelvinliu_: cool, once we've done the full move to lxd 3.0 we can change that to include all the lxd-slave machines
<kelvinliu_> veebers, yes, u r right, we only need to look on the first two changed files, the rest are all charm files
<veebers> kelvinliu_: ack, reviewed. I'm not reviewing the charm code ^_^
<kelvinliu_> veebers, i also didnot read the files, but just checked all the changes files are at `charms` dir
<babbageclunk> wallyworld: can we chat? I'm a bit lost and confused
<kelvinliu_> veebers, i was planning to do(assert) http health-check after gitlab stabilised, but that needs expose the app which is a little bit difficult to achieve here for now, so instead, I use `wait_for_workloads` to ensure all the app are `active` or it will fail at timeout.
<kelvinliu_> veebers, do u think it's reasonable ?
<veebers> kelvinliu_: what's the complexity in exposing the app?
<kelvinliu_> veebers, we need to expose the k8s node ip
<veebers> kelvinliu_: I don't think that just deploying the app is quite sufficient, it's possible the deploy 'works' and status states it happy but then nothing actually works for whatever reason
<kelvinliu_> wallyworld, any thoughts about how to solve this?
<veebers> kelvinliu_: how is this normally done (by a person) it seems getting access to the deployed app should already be an achievable thing, unless I misunderstand
<wallyworld> kelvinliu_: tail the log and wait for "gitlab ready". kubectl logs -f ....
<kelvinliu_> wallyworld, currently, the test could ensure all the apps are in ready status now
<veebers> wallyworld: is that sufficient enough to ensure the application is responsive? Could we do something similar to where we're using mediawiki and make a url request to the address and check the response
<kelvinliu_> wallyworld, do we need expose gitlab then curl the service to do health check in the test?
<wallyworld> veebers: gitlab will only print that final message once it has properly initialised itself, created alll the db tables, set things up etc. for now i think that's ok
<wallyworld> we could expose and check the url though
<wallyworld> kelvinliu_: any reason why we can't get the worker ip address and expose via xip.io?
<veebers> even a check for a 200 response would be good, but as soon as you're that far it's just a little more to check the output in some meaningful way
<veebers> wallyworld: I think I'm missing some knowledge, is a caas deployed app different in it's ability to expose access than an IAAS app?
<wallyworld> yes, you need to provide a FQDN for ingress
<wallyworld> so we fudge that using xip.io and the ip address of a worker node
<wallyworld> in production it would be set up properly
<wallyworld> it's explained a bit more in the getting started doc
<kelvinliu_> wallyworld, we might be able to get the node ip from juju status -m base-model
<veebers> ack I see. we would need to check with IS to see if we could get the right firewall holes poked for access to xip.io. I'll run an initial question past them now
<wallyworld> kelvinliu_: that's right, that's what we need to do
<babbageclunk> wallyworld: have a moment to chat about these benchmarks? I'm v confused.
 * babbageclunk taps his mic. This thing on?
<babbageclunk> hey, axw_, I'm having some trouble with some raft stuff... ;)
<axw_> babbageclunk: o/
<babbageclunk> how's it going?
<axw_> what's the issue?
<axw_> babbageclunk: pretty good thanks, and yourself?
<babbageclunk> yeah, mostly good, other than bashing my head on some benchmarking stuff.
<axw_> babbageclunk: so my raft code is all falling apart right on schedule?
<babbageclunk> heh
<veebers> wallyworld, kelvinliu_ I think we should be ok with xip.io in the lab (assuming I understood properly :-)).
<wallyworld> sgtm
<kelvinliu_> veebers, awesome! i am adding features on CaasClient to do http health check on apps
<veebers> kelvinliu_: awesome!
<kelvinliu_> wallyworld, i am thinking we might be able to let `juju expose` do the `juju-external-hostname` config by itself (before creating ingress resource, juju describes facts from k8s api server)
<wallyworld> kelvinliu_: that's essentially what happens. for k8s models, juju expose will read the app config to get the external hostname as configured and willuse that
<kelvinliu_> wallyworld, i mean we can let juju figure out(describefrom k8s api) what the node ip that this app is running on is
<wallyworld> kelvinliu_: that's hard coding behaviour to one specific deployment scenario
<wallyworld> kelvin: not sure if you saw my last message as there was a netsplit. we can't assume any particular deployment scenario. for our simple test case, there's only 1 worker and so yes the ip and xip.io work. but in general no, so juju can't guess. it needs to be told the external host name
<kelvin> wallyworld, yes, u r right. And when we have more than one ingress backend available in the cluster, we will need to specify the ingress class to use for example, not sure yet if we are able to fetch the host name from there as we can find the related ingress by the ingress class annotation now.
<wallyworld> kelvin: for the CI test, we simply need to get the IP address of the single worker node, set the juju-external-hostname application config accordingly, and then we can expose and connect
<kelvin> wallyworld, this potentially could be a very later feature. we can discuss in the future
<wallyworld> the ingress class to use defaults correctly to xginex
<wallyworld> there's no extra config needed
<wallyworld> for the CI test
<kelvin> wallyworld, yes, for ci test, i will just fetch the node ip from status output which will be suffucient for us
<wallyworld> yup
<veebers> How can I run all the tests in apiserver/facades/controller/? ./... doesn't work it complains about no go files (which is fair enough there are none, but I want it to recurse from there down
<wallyworld> veebers: go test ./...
<wallyworld> jam: babbageclunk need to get your input on some benchmarking if you are free at some point
<babbageclunk> wallyworld: I added that recording - the times are consistent between the two request methods, so it's the way apache bench is calculating things that is different
<wallyworld> interesting ok
<wallyworld> so raft is worse at lower volumes
<babbageclunk> The other possibility is that the lease claimer is doing less than I thought it was - I'm looking into that at the moment.
<babbageclunk> wallyworld: but otherwise, seems like it
<wallyworld> ok
<jam> hey babbageclunk are you around now?
<jam> veebers: go test -check.v github.com/juju/juju/apiserver/facades/controller/... ?
<jam> veebers: ah sorry, -check.v must come *after* the '...'
<veebers> jam, wallyworld cheers will try that
<jam> because there are 2 processes, one is the 'go test' and the other is the compiled binary. once 'go test' reads an arg it doesn't understand (like -check.v) it stops parsing the rest
<wallyworld> jam: i'm here, i wanted to talk about the raft stuff as well. babbageclunk will hopefully be back soon
<wallyworld> if not maybe you and i can talk
<jam> wallyworld: yeah, but I don't like talking to you... :)
<wallyworld> :-(
<jam> just a sec and I'll jump on a HO
<wallyworld> jam: which HO?
<jam> wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/juju?authuser=1
<babbageclunk> oops got distracted, coming too!
<babbageclunk> I didn't word that well, I mean I'm joining the hangout as well.
<jam> babbageclunk: ^^
<veebers> jam, wallyworld sweet thanks I had the ./... in the wrong place it seems. Cheers!
<wallyworld> great
<jam> wallyworld: your PR is bundled with other code that is bumping the Version ?
<wallyworld> jam: there's a separate juju pr under develipment by vino which will
<jam> wallyworld: ok. cause you're changing the format of App v3,but that will be covered elsewhere?
<wallyworld> jam: app v3 was done to cater for caas stuff which hasn't shipped yet, ie for juju 2.4
<wallyworld> juju 2.3 doesn't export any caas stuff
<wallyworld> thanks jam
<thedac> Can I get a review of https://github.com/juju/layer-index/pull/30 ?
<thedac> cory_fu perhaps?
<thedac> kwmonroe:
<kwmonroe> thedac: would you please run ./update-readme.py from your thedac:keystone-admin-github repo, and then push?
<thedac> kwmonroe: will do
<kwmonroe> gracias thedac!
<thedac> kwmonroe: done
<kwmonroe> merged thedac.  thanks!
<thedac> thank you, kwmonroe
<erik_lonroth> @rick_h https://github.com/juju/docs/pull/2726
<erik_lonroth> The pull request above contains a series 1,2,3 of beginner level charming. I hope you can test it and eventually add something like this to the tutorial.canonical.com (?) perhaps. Regardless, this hopefully can help some people get through the first agonizing phases of development in juju.
<pmatulis> erik_lonroth, thanks for that
<rick_h_> erik_lonroth:  amazing! I look forward to checking it out
<TheAbsentOne> rick_h_: could you relink what erik_lonroth said? Seems interesting. I'm finishing a getting started guide as well ^^
<TheAbsentOne> inbefore it's completely the same
<rick_h_> TheAbsentOne: https://github.com/juju/docs/pull/2726
<TheAbsentOne> holy it really is x) fml
<TheAbsentOne> haha
<TheAbsentOne> it's good stuff though, would have saved me a lot of time if I had that to start out with a couple of months ago
<TheAbsentOne> nicely done erik_lonroth
<pmatulis> TheAbsentOne, perhaps you can comment on his PR. i'm sure you must have some stuff to add
<TheAbsentOne> pmatulis: I'll take a look!
<TheAbsentOne> pmatulis: erik_lonroth: I made a comment with some suggestions. I'll try to finish my roadmap as well and part of it could function as a part 4 if you guys are up for that
<erik_lonroth> TheAbsentOne: I'll update taking your comments and suggestions into it. Thanx for the feedback! Also, I think more beginner level tutorials would be needed. Consider if "Part 4 - interfaces"  would be a beginner level, or, perhaps a intermediate level tutorial. Splitting tutorials into "Beginner" - "Intermediate" - "Experienced" would help the community to add more tutorials on more topics around juju. Also, having all tutorials follow a "
<erik_lonroth> format-template" to make them feel easy to follow would be great. Have a look at how Android tutorials are built. Those are really awesome example on how to growe a community with tutorials.
<TheAbsentOne> I completely agree erik_lonroth, I'll share a markdown page (and github url) once I'm finished and you guys can decide later ^^
<erik_lonroth> go for it!
<pmatulis> erik_lonroth, also https://tutorials.ubuntu.com/
<pmatulis> but the official docs could use a lot of attention re charm writing
<TheAbsentOne> besides something that I don't know: if I deploy a charm how much freedom do I have in terms of cpu, ram, storage actually? At design time and at controller time?
<pmatulis> TheAbsentOne, you can use "constraints". what do you mean by 'design' and 'controller' time?
<TheAbsentOne> Well I haven't actually worked with a juju controller directly. All I got were models to work with. But pmatulis I assume you can't say "I want to deploy a mysql charm on a centos that has X RAM and 64 bits and Y Gb worth of storage" right? Or how does that actually work? Sorry if it's a stupid question
<TheAbsentOne_> Damnit internet broke x(
<TheAbsentOne_> kinda found my answer pmatulis with the constraints
<TheAbsentOne_> Im off to bed now, I hope to finish the "small" tutorial in the next 24 hours depending on some other stuff
#juju 2018-05-30
<wallyworld> babbageclunk: any chance of a juju/description review to unblock vino? https://github.com/juju/description/pull/40
<wallyworld> or thumper? ^^^
 * thumper looks
<thumper> wallyworld: lgtm with one minor comment
<wallyworld> thumper: ty
<thumper> which I'm sure you have already thought about
<kelvin_> veebers, i just moved the health check to the assess script
<wallyworld> thumper: i did, was being lazy :-)
 * thumper nods
<thumper> wallyworld: non-exported constant is fine
 * thumper thinks
<wallyworld> already merged, can fix next time
<thumper> perhaps exported constants would be better
<thumper> since they are passed in from outside
<wallyworld> yeah, they are exported
<thumper> also, we'd want to validate on type, which I think we may do already
<thumper> ah... ack
<wallyworld> we do in various places
<wallyworld> there could be more checks though
<anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/8782
<anastasiamac> wallyworld: this is just the context construction (not the f=worker flag and reaction bit yet)
<anastasiamac> wallyworld: i've sparated these bits into separate PRs but need to land this one first because of <reasons>
<wallyworld> anastasiamac: sure, after meetings
<wallyworld> anastasiamac: sorry about delay, got caught up, done
<anastasiamac> wallyworld: thnx for review, the follow up PRs r going to be a lot more interesting :)
<wallyworld> can't wait
<anastasiamac> wallyworld: just one more boring one coming up for cmd but I'll probably do it next week or smth...
<anastasiamac> wal :D
<anastasiamac> wallyworld: even ^^ dunno how it happened :) tab completion on a t-break...
<manadart> stickupkid: How is it going. Want to have a quick chat about lp:1771887 ?
<stickupkid> sure, lets
<rick_h_> bdx: give me a decent sized bundle of something I can show off that runs in lxd
<rick_h_> magicaltrout: ? ^
<magicaltrout> Hadoop Spark should
<manadart> rick_h_: So it's up now?
<bdx> rick_h: https://jujucharms.com/u/omnivector/slurm-openfoam/
<bdx> rick_h: add-units of slurm-node as needed
<bdx> rick_h_:^
<rick_h_> manadart: yep it's up
<manadart> rick_h_: Sweet.
<manadart> rick_h_: So how does one see the Juju Show live?
<stickupkid> yeah, i'd be interested?
<stickupkid> rick_h_: ^
<rick_h_> stickupkid: manadart https://www.youtube.com/watch?v=CidoBy3iqUw in an hour
<stickupkid> rick_h_: i'll see what i can do
<rick_h_> Juju Show in 1hr, watch rick_h_ blow something up!
<rick_h_> bdx: kwmonroe cory_fu magicaltrout zeestrat erik_lonroth ^
<rick_h_> bdx: ty, installing it now
<bdx> np
<rick_h_> bdx: you'll have to tell me how to make it do something impressive :P
<zeestrat> bdx: How's the development going?
<bdx> rick_h_: give me a min, I'll grab you something
<bdx> zeestrat: I'll be starting work with some other developers here in the coming weeks
<bdx> zeestrat: it would be great to have you join too
<bdx> if you are interested
<zeestrat> bdx: Cool. Got some other stuff on the plate atm, but I'll subscribe to the repos and see where I can help.
<bdx> sweet
<bdx> rick_h_: https://gist.github.com/jamesbeedy/ccad9defa3898494b2750594670d7168 - this will run the openFoam demos
<bdx> ssh into either the worker or scheduler and run ^
<bdx> takes a while for them all to run though
<bdx> you may just want to run it for a few moments and ctrl-c out
<rick_h_> bdx: checking
<rick_h_> bdx: how long is "a while"
<bdx> possibly 10 mins ... you could just run a single test
<rick_h_> 10min is ok, running now
<rick_h_> bdx: does it go faster with more workers?
<bdx> ahh, well this is just verifying openfoam
<bdx> not openfoam + slurm
<rick_h_> bdx: oic
<rick_h_> 15min Juju Show warning!
<rick_h_> go fill those glasses
<rick_h_> for those wanting to participate in the show check out https://hangouts.google.com/hangouts/_/dqa6fcjqpferdh6pphu3nanscme
<rick_h_> for viewers hit up https://www.youtube.com/watch?v=CidoBy3iqUw
<rick_h_> anyone else coming along?
<bdx> there is an open bug with lxd for the lxc list taking so long on a cluster
<bdx> https://github.com/lxc/lxd/issues/4548
<rick_h_> bdx: ah, gotcha
<rick_h_> ty bdx and zeestrat for hanging out!
<rick_h_> and ty manadart and folks for making it work out and demo'able :)
<manadart> rick_h_: I missed the participation link. Nice job though. Demo gods were appeased.
<rick_h_> manadart: :)
<zeestrat> thanks for the invite rick :)
 * rick_h_ goes to get lunch now that it's all working/done
<bdx> f3rdy: welcome
#juju 2018-05-31
<wallyworld> thumper: here's that PR to get the final caas things ready for 2.4. pretty please :-) https://github.com/juju/juju/pull/8784
 * thumper looks
<thumper> wallyworld: just a few small things
<wallyworld> tyvm
<thumper> I kept getting distracted while reviewing
<thumper> email etc.
<wallyworld> i also have a feature test to fix
<wallyworld> no rush i am waiting for another pr to land first
<wallyworld> before i can land this
<thumper> wallyworld: ping
<wallyworld> yo
<thumper> hangout again?
<wallyworld> sure
<wallyworld> thumper: small one? https://github.com/juju/os/pull/2
<wallyworld> needed for caas series checking to be able to give nice errors deploying a caas charm to an iaas model
<veebers> wallyworld: just sorting out a merge conflict and will be proposing the tomb v1 -> v2 PR
<veebers> wallyworld: https://github.com/juju/juju/pull/8785 just noticed it could do with a commit squash, as I've merged develop in there a couple times too.
<wallyworld> veebers: ok, looking
<vino> wallyworld: i want u to take a look at mine as well. Made few commits
<wallyworld> ok
<wallyworld> vino: comments left. main issue is there are mssing tests for application tools methods
<wallyworld> plus we don't need any tests for the CLI bit as there's nothing to test really
<vino> wallyworld: yes i am writing that now in application_test.go
<wallyworld> great!
<wallyworld> almost there
<vino> Yes. Wallyworld. I verified that with dump-db command as well. No IAAS and CAAS difference.
<vino> i will revert the chnages made in dump-db_test
<wallyworld> ty
<wallyworld> veebers: reviewed, a mighty effort. i have aquestion, it's in the review comment
<veebers> wallyworld: wow, I can't believe how many deletemes slipped through muy intial scan of the diff :-\
<stickupkid> manadart: can I get a code review of this PR please https://github.com/juju/juju/pull/8787
<manadart> stickupkid: Ja.
<manadart> stickupkid: Reviewed.
<stickupkid> manadart: thanks
<stickupkid> manadart: i've updated the PR, we require a few hoops to jump through to now get the bridgeName - not sure if it's 100% right, but works for bionic on first try
<stickupkid> https://github.com/juju/juju/pull/8787
<manadart> stickupkid: Looking.
<elox> bdx: elox -> erik_lonroth
<manadart> stickupkid: Approved; couple of minor suggestions.
<stickupkid> manadart: nice, i'll fix those, before merging
<bissa> Is there a way to specify a subnet when using juju to bootstrap a controller?
<pmatulis> bissa, MAAS and AWS backing clouds support "Juju network spaces"
<scoobitywoops> @pmatulis doesn't that require a controller to already be up?
<pmatulis> scoobitywoops, no
<scoobitywoops> juju add-space devqa 10.0.10.0/24
<scoobitywoops> ERROR cannot connect to the API server: No controllers registered.
<pmatulis> scoobitywoops, now i see what you mean. what *i* meant was that you can apply a space during the creation of a controller
<pmatulis> of course, almost all commands require a controller
<hml> bissa: what cloud are you using?
<bissa> aws
<scoobitywoops> I'm working with bissa, we're trying to build the controller in a specific vpc and subnet
<scoobitywoops> vpc is fine, but can't get it to stick to a subnet
<scoobitywoops> tried --to subnet= but that didn't work
<chquark> hello all
<chquark> I need a bit of help in juju
<chquark> I was following this guide
<chquark> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-maas.html
<chquark> while deploying all of the nodes on Virtualbox
<chquark> as a test environment
<chquark> user@user:~/.local/share$ sudo juju bootstrap mymaas maas-cloud-controller --constraints "mem=1G"
<chquark> [sudo] password for user:
<chquark> Creating Juju controller "maas-cloud-controller" on mymaas Looking for packaged Juju agent version 2.3.8 for amd64 No packaged binary found, preparing local Juju agent binary
<chquark> Launching controller instance(s) on mymaas...ERROR failed to bootstrap model: cannot start bootstrap instance in any availability zone (default, Test)
<chquark> ^^ that is the error i get, and im at my wits end.
<hml> chquark: are you running with âdebug ?
<chquark> sorry Iá¸¿ not that experienced with juju.
<chquark> juju debug-log
<chquark> you mean this ?
<hml> chquark: no
<hml> chquark: you can add a âdebug flag (dash dash) to bootstrap for additional data
<chquark> got it
<chquark> https://pastebin.com/RuGhfVrV
<hml> chquark: juju isnât finding a machine to use to match the constrainsts given:  line 36
<hml> chquark: do you want juju to pick a specifc machine?  you can bootstrap specifying a tag as a constraint instead
<hml> chquark: https://docs.jujucharms.com/2.3/en/reference-constraints
<chquark> well I have 2 VMÅ
<chquark> one for MAAS and another for JUJU
<chquark> so which machine is it trying to get ?
<hml> chquark:it couldnât find a machine based on the 1G mem constraint -
<hml> chquark: try bootstraping without the mem piece
<hml> chquark: youâll need additional VMs, with the current setup, youâll be able to bootstrap, but there wonât be any machines available to deploy a charm
<chquark> I have also deployed 2 Nodes on VM, let me try it again without any contraints
<chquark> https://pastebin.com/YWEGMvZg
<chquark> https://i.stack.imgur.com/HSNAp.png
<hml> chquark: how much memory do the nodes commissioned by MAAS have?
<chquark> 1GB each
<chquark> https://imgur.com/a/GAQQnHt
<hml> chquark: juju usually looks for nodes with a min mem size of 4Gâ¦ i  wonder why juju didnât find the commissioned node when constraints were 1G
<hml> chquark: the min controller requirements are 2G:  https://docs.jujucharms.com/2.3/en/controllers
<hml> chquark: though the message youâre getting doesnât indicated that.. juju is still trying with only 1G
<chquark> is this not reffering to the Juju server ?
<hml> chquark: what do you mean by juju server?
<chquark> https://imgur.com/tC6vITo
<chquark> the Nodes have 1G ram, but MAAS and JUJU have 2G ram..
<hml> chquark:  in the example, node os-juju01.maas will be used as the juju controller
<hml> chquark: per your screen shotsâ¦ is the Juju VM commissioned in maas?
<chquark> no Juju vm not commisioned in maas
<chquark> so iá¸¿ to understand that i must add it.. let me do that right now..
<hml> chquark: per the example, there are 5 machines commissioned in maas for juju to use,
<hml> one will be the juju controller, the others are for charms to be deployed to
<chquark> ah, crap i see where my mistake can be..
<hml> chquark: if you add the juju tag to node os-juju01.maas â¦ then you can bootstrap with the tag as a constraintâ¦.
<chquark> yes i understand, i did not add the juju node, and had manually deployed the OS..
<chquark> so think i will have to redeploy that node again..
<hml> chquark: if you have the nodes commissioned in maas, and bootstrap juju with the maas âcloudâ - juju will do the work on those nodes for you.
<chquark> @hml, thank you for your help. I will get back to you once i have commissioned the juju in maas :)
<TheAbsentOne> erik_lonroth: https://github.com/Ciberth/MP-appendix-a/blob/master/appendixA.md this was the guide I was working on btw!
<TheAbsentOne> If people are btw interested in reading my master thesis, I would love to receive feedback on wrong or unclear things. I have one more week to finish it so I'm trying to wrap things up. Ping me here if I'm here or on github/twitter: Ciberth if you want to receive the pdf!
<TheAbsentOne> The title is: management of polyglot persistent integrations with virtual administrators (hence the generic database use case in juju!)
<veebers> Morning o/
<thumper> morning
<wallyworld> thumper: small review? https://github.com/juju/os/pull/2 and there's a juju one that depends on it https://github.com/juju/juju/pull/8788
<thumper> ack
<wallyworld> polishing the user experience before release
 * thumper nods
<wallyworld> it used have a have a crap message
<veebers> wallyworld: FYI I addressed your comments on PR: https://github.com/juju/juju/pull/8785
<wallyworld> veebers: yeah, just looking :-) found at least one more case of Stop() doing the err != tomb.ErrStillAlive thing
<wallyworld> in ping batcher
<wallyworld> i think there's 7 cases
<veebers> ah man, dropped the ball a couple times on this PR. just too eager to push it up. WIll fix
<veebers> ah I know why, faulty grep
<wallyworld> no worries, it was a monster
<wallyworld> veebers: also, i do think we replace donewhendying() with just <-w.Tomb.Dying
<wallyworld> more explicit and less overhead, no need for a func now
<veebers> wallyworld: agreed, making it so now
<wallyworld> awesome sauce
<veebers> wallyworld: have pushed up the changes
<wallyworld> veebers: looking
<wallyworld> veebers: lgtm! also, don't forget to regenerate dependemcies.tsv before landing
<wallyworld> and push that change
<wallyworld> ensure that tomb.v1 is missing
<veebers> wallyworld: tomb.v1 is needed for /juju/worker.v1 :_|
<wallyworld> oh bollocks
<wallyworld> do we have w worker.v2
<wallyworld> i guess that's next
<veebers> wallyworld: indeed, has a target on it's back :-) Diff of godeps -t $(go list ./...) and deps.tsv is no changes
<bdx> hey guys
<bdx> say my maas controller ip changes
<wallyworld> thumper: we couldn't think of a different name for the OS (also called Distro in the charmstore). discussed with john and jaas guys. ideally "Kubernetes" would be the OS and we'd have "1.8" or whatever for series but the versions change too quickly for that to be managable
<bdx> is there a way I can update the maas cloud credentials on the controller?
<bdx> specifically the endpoint
<wallyworld> not easily (yet) sadly
<wallyworld> the only way i know is to update mongo directly - shut down the controller agent(s) first
<wallyworld> it's something being worked on this cycle
<wallyworld> thumper: if we think of something better, we can change it as the charm side of things is still under development etc. fresh ideas welcome :-)
<bdx> wallyworld: thanks
<wallyworld> bdx: let us know if you need help etc. it's a big gap we know we need to fix
<bdx> wallyworld: thanks, I think its going to be easier for me to just give my new maas server the ip of the old maas server
<wallyworld> ok
<thumper> wallyworld: sure
<bdx> some ability to modify a cloud definition via `update-clouds` or other means would be great though
<bdx> just super actually
<bdx> I'm sure more people will hit this as they upgrade
<bdx> as maas 2.4 is bionic only
<bdx> users will need to add a new controller and switch to it when they upgrade
<wallyworld> bdx: yeah, controller clouds and credentials both need to be managed better. the first thing being done is having juju better manage credentials which expire or become invalid. at the moment, things don't go well when that happens
<wallyworld> especially on a jaas controller with lots of models
<bdx> I can only imagine
<veebers> wallyworld: ah, "if err := pb.tomb.Err(); err != tomb.ErrStillAlive {" is needed for PingBatcher Stop(), that's something you pointed out to me but I'm not 100% certain why it's needed
<wallyworld> is that the only place?
<veebers> it seems it, will re-run tests to confirm
<veebers> yeah looks like it. pushing fix now, PR will have a full unit test run
<veebers> wallyworld: yay merged :-)
<wallyworld> awesome. i would still like to look into why ping batcher needed that change
<veebers> wallyworld: indeed, will look into it when I get a moment
<wallyworld> veebers: we're moving to pubsub anyway soon so may not be worth the effort
<veebers> wallyworld: ack ok
<wallyworld> veebers: i suspect it's because someting is calling Stop() twice
<veebers> yeah I would suspect so too
#juju 2018-06-01
<wallyworld> vino: my PR which needs yours has now landed. so dump model etc should work. i've pushed to dicker hub the new operator image which sets application tools on startup
<wallyworld> sigh, *docker
<vino> i am checking now wallyworld
<icey> is it possible to configure cloud-init to _not_ mount the secondary disk on /mnt, preferably for only some applications?
<manadart> PR for review: https://github.com/juju/juju/pull/8790. First in a series unifying container management across provider and container manager.
<stickupkid> manadart: looking
<stickupkid> manadart: done
<manadart> stickupkid: Ta.
<manadart> What mongo should we install when developing on Bionic?
#juju 2018-06-03
<srihas> k
<srihas> nvm
#juju 2020-05-25
<hpidcock> Small PR https://github.com/juju/juju/pull/11623
 * thumper looks
<hpidcock> thumper: I think we should probably just be targeting this to 2.8.1
<thumper> sure
<thumper> given +1 anyway
<thumper> hpidcock: I don't suppose you could look at the constant failure emails from jenkins?
<thumper> seems to be snap-edge-build and z-clean-resources-oracle
 * thumper wonders if oracle one may be failing because we are still trying to do something with their old removed cloud
<hpidcock> thumper: sure thing
<thumper> wallyworld: took a good look at bug 1879992
<mup> Bug #1879992: update-status hook error with very little log informaion <cdo-qa> <cdo-release-blocker> <foundation-engine> <juju:Invalid> <https://launchpad.net/bugs/1879992>
<thumper> it was a bit confusing\
<thumper> because the fcb has logging-config set in model-defaults.yaml, but fkb does not
<thumper> and due to the change in logging, both now need to add "unit=DEBUG" to get what they had before
<wallyworld> thumper: it also seems though that something set <root>=WARNING, at least in one of the log files i looked at
<thumper> yeah, that is the logging worker getting the information from the controller when it starts
<thumper> all agents start with --debug for initialization
<thumper> then get the logging-config from the model
<kelvinliu> wallyworld: got this PR for adding EKS support, tested AKS/GKE/EKS as well https://github.com/juju/juju/pull/11614 could u take a look?
<wallyworld> kelvinliu: will do, just need a few minutes
<kelvinliu> wallyworld: im thinking to setup CI test for bootstrapping to EKS
<wallyworld> +1
<kelvinliu> so I will probably spend rest of today and next Mon on this.
<wallyworld> yup. sgtm
<bdx9> hello!
<bdx> I have a few blockers I want to talk about if possible
<bdx> discourse might be a better place actually
<bdx> I've taken a stab at communicating our predicament https://discourse.juju.is/t/using-the-add-image-command-with-the-maas-provider/3111
<thumper> simple review for someone https://github.com/juju/loggo/pull/38
<thumper> wallyworld: ^^
<thumper> makes a lot of my futzing around yesterday unnecessary :(
<wallyworld> otp, sec
<thumper> ack
<thumper> well, not entirely unnecessary
<thumper> but it'll make it a lot simpler
<josephillips> hey hi i was here recently i talk with someone that told me that LXD was deprecated for openstack
<josephillips> what another real solution i can use for containers inside of openstack
<wallyworld> josephillips: as far as i know nova-lxd is deprecated, but you can still deploy workloads to hosted lxd or kvm containers
#juju 2020-05-26
<wallyworld> thumper: here's a 2.7 PR https://github.com/juju/juju/pull/11627
<wallyworld> thumper: so that other related bug... this will fix part of that also, but there's a similar issue with destroy model, but that will probably take a bit of thought to fix as coordination which doesn't exist yet will likely be required between the various moving parts
<tlm> wallyworld: what does it mean when a worker is in a "Starting" state in the engine report ?
<wallyworld> tlm: is it stuck in that state?
<tlm> wallyworld: yeah
<wallyworld> i'd have to check - i think it may be waiting for a dependency
<wallyworld> is that plausible?
<tlm> k
<tlm> i'll check
<timClicks_> 3 new tutorials available - Postgres, RabbitMQ, ElasticSearch https://discourse.juju.is/t/3117
<wallyworld> tlm: you talking about the httpserver worker?
<tlm> wallyworld: yeah
<wallyworld> that attribute seems bespoke to that worker
<tlm> oh ?
<wallyworld> it goes from starting to running after it gets the mutex inside the worker loop
<wallyworld> see juju/worker/httpserver/worker.go
<wallyworld> the Worker struct has a status attribute
<wallyworld> which is printed in hte Report() method
<tlm> ah  yep,
<tlm> cheers
<wallyworld> manadart: for bug 1831580, it seems like we just loop over all addresses recorded against a machine and splat those out as ingress-addresses, without regard for the fact that 127.x.x.x should probably be filtered out?
<mup> Bug #1831580: wrong etcd_connection_string on kubernetes-master charm <network> <sts> <juju:Triaged> <https://launchpad.net/bugs/1831580>
 * thumper looks at wallyworld's PR
<thumper> hey team
<thumper> the github actions seem to still be using go 1.10, but an azure library has brought in strings.ReplaceAll
<timClicks_> thumper: hi
<thumper> which seems to not be in go 1.10
<thumper> so all github actions are failing to build
<tlm> hmmmm
<tlm> all the github action files seem to say 1.14
<thumper> tlm: ah... wallyworld's PR is from 2.7
<thumper> branch
 * thumper wonders why that'd have issues
<thumper> did something get backported there?
<thumper> for azure updates?
<wallyworld> thumper: the azure focal fix landed in 2.7 and was forward ported
<wallyworld> IIANM
<wallyworld> i think it is likely the actions are out of date in 2.7
<thumper> hpidcock: I tried to go get -u the loggo repo from juju but it didn't change go.mod file
<hpidcock> and your loggo change was merged?
<thumper> hpidcock: yep
<hpidcock> GOCACHE=direct go get -u github.com/juju/loggo
<hpidcock> try that
<hpidcock> oh
<hpidcock> GOMODCACHE=direct
<hpidcock> no
<hpidcock> GOPROXY=direct
<hpidcock> hah
<hpidcock> brain isn't working today
<thumper> ... ok, will try that
<thumper> it noticed that time
<thumper> hpidcock: should I care that go.sum lists multiple versions?
<hpidcock> no
<thumper> ok
<thumper> why are they there?
<hpidcock> go.sum is all the versions that have been seen AFAIK
<hpidcock> as in, its like an append only log
<wallyworld> thumper: thanks for review, i left a comment around the facade version bump, or lack thereof
<manadart> wallyworld: I will take a look at the ingress-address bug. Thanks for the reviews on my patches.
<wallyworld> manadart: no worries. we had that perhaps naiive approach in mind for the ingress bug but wanted to check in case we had missed some intended modelling etc
<manadart> wallyworld: The correct thing to do will be to ensure that it is correctly identified as machine-local at detection, and omitted based on that characteristic.
<wallyworld> manadart: yeah, that was what was discussed, but we weren't sure why those 127 addresses weren't being classified that way
<manadart> wallyworld: I think I know. The addresses for link-layer devices are different from those on the machines collection and don't have scope classification (?) It should be easy to sort out.
<manadart> stickupkid: https://github.com/juju/juju/pull/11626
<stickupkid> manadart, sure, just writing up a essay, will get to that in a bit
<stickupkid> wallyworld, whilst you're here https://github.com/juju/juju/pull/11627#discussion_r430230340
<wallyworld> stickupkid: ty for comment. a little while ago, all facades were at a top level, and the categorisation into agent/client/controller was rather arbitrary. but i think we are at a stage where we could adopt more formal expectations around the cateorisations
<stickupkid> wallyworld, 100% agreed, I believe we could really cleanup libjuju as well
<wallyworld> yes indeed
<wallyworld> libjuju shold ony really use the client facades, but there's also Ping() and maybe others that are excpetions
<stickupkid> wallyworld, we could have agent, controller, client and common maybe
<wallyworld> yeah. we do that for controller vs model (at the apiserver level)
<stickupkid> manadart, payback https://github.com/juju/juju/pull/11621
<stickupkid> manadart, when you get a sec, ping-a-rooney
<manadart> stickupkid: I'm in Daily.
<achilleasa> manadart: so the traffic from the container goes eth0 (container) -> veth (host) -> ens4 (host)
<achilleasa> lxc profile show default on the host shows lxdbr0 as the parent of eth0
<achilleasa> but the juju logs lines from the getContainerSpec show eth0 having ovsbr0 as the parent of eth0...
<achilleasa> ...and brctl show has lxdbr0 but nothing under the interfaces column
<achilleasa> looks like I broke it :D
<stickupkid> achilleasa, https://github.com/caseykneale/VIMKiller
<manadart> achilleasa: I think we are going to have issues with the fact that we always create lxdbr0.
<manadart> achilleasa: Actually no, because we already explicitly bridge NICs when container-networking-method=provider and it works fine.
<stickupkid> manadart, https://github.com/juju/juju/pull/11628
<stickupkid> took longer to install the dependencies :sigh:
<stickupkid> manadart, shall I fix the ReplaceAll whilst I'm here in 2.7 hell?
<manadart> stickupkid: Might as well.
<stickupkid> manadart, https://github.com/juju/juju/pull/11628/commits/fbb98cd20bd2f270185f30198a75e3f251cd1445
 * manadart nods.
<achilleasa> manadart: getting closer... https://pastebin.canonical.com/p/x7VBZxBnHr/
<stickupkid> haha "profit"
<achilleasa> ;-)
<manadart> achilleasa: This will be a good chance to sanitise some of that flow if you're all up in it.
<achilleasa> manadart: could do but I am not sure if I understand how it all works... also traffic still does not seem to flow through my bridge :-(
<stickupkid> it's trolling you
<achilleasa> is there any tool to show the parent configuration?
<achilleasa> stickupkid: yeah... the packets are practicing social distancing from the bridge apparently...
<stickupkid> achilleasa, haha, funny very funny
 * achilleasa wonders if veth should be added to the ovs bridge manually...
<stickupkid> achilleasa, bug fixes in real life https://preview.redd.it/6dgzo0qor1151.jpg?width=960&crop=smart&auto=webp&s=4cc65a4b3744c1f79a230218f30fad674f78b6fa
<manadart> achilleasa: The veth devices show up for each container NIC connected via bridge to its parent NIC on the host.
<achilleasa> manadart: I've edited the lxd profile and after deploying --to lxd:X I see the veth as a port in my ovs... https://pastebin.canonical.com/p/nX7zzBnxyV/
<stickupkid> manadart, I'll check the bindings issue on aws
<rick_h> manadart:  stickupkid_ petevg just a heads up I need to take over guimaas this week. Anything running that folks care deeply about?
<manadart> rick_h: All clear here.
<petevg> rick_h: we are good w/ whatever you do to guimaas.
<rick_h> ok ty
<stickupkid_> manadart, it's building goodra instead of grumpig
<manadart> stickupkid_: Great.
<stickupkid_> manadart, pingy mc ping ping
<manadart> stickupkid_: Pong.
<stickupkid_> daily
<rick_h> kjackal:  ping, I'm trying to bootstrap on microk8s and getting hung up on the connecting to the new address space? Any hints on issues/working out the networking bits I need to figure out?
<rick_h> kjackal_:  this is for a demo I need to do and appreciate the help. I get stuck at: "Contacting Juju controller at 10.152.183.207 to verify accessibility..." and nothing I'm seeing in notes speaks to network bits other than enable dns and storage?
<rick_h> guild ^ if anyone has any hints
<stickupkid_> sorry rick_h not touched microk8s from that perspective...
<rick_h> stickupkid_:  :( ok be that way
<rick_h> petevg:  wheee, have enough VMs setup on guimaas to get a CK deploy going...here's hoping it settles lol
<petevg> rick_h: woot!
<rick_h> petevg:  I'm hitting some lease errors in an HA controller on the RC. I know there was some conversations around that on the standup the other day. Known issue?
<petevg> rick_h: is this on k8s? I thought that we had solved most of those issues w/ the latest rc.
<rick_h> petevg:  no, no gcp
<rick_h> ruh roh, might have broken the world now...
<petevg> rick_h: uh-oh. We don't have any open bugs against a release candidate milestone, so I think that we closed out all the known issues ...
<petevg> rick_h: I'm having a really hard time getting a controller to bootstrap on MicroStack in guimaas, though that might just be DNS stuff being unhappy. (e.g., related to my config, not to juju)
<rick_h> petevg: filing a bug, will send you the link
<petevg> cool cool
<rick_h> petevg:  https://bugs.launchpad.net/juju/+bug/1880751
<rick_h> petevg:  :( on bootstrap issue
<mup> Bug #1880751: flapping HA controller machine with lease issue on 2.8-rc2 on GCP <juju:New> <https://launchpad.net/bugs/1880751>
<rick_h> petevg:  ok, have to tear this down, it's fubar (and the 4 models of demo stuff with it :( )
<kjackal_> rick_h: sorry, I just saw that.
<kjackal_> rick_h: here is how we bootstrap for kubeflow https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/actions/enable.kubeflow.sh#L183
<kjackal_> this is after enabling dns storage
<kjackal_> I am not aware of any issues, but I am not testing bootstran regularly
<kjackal_> asking aroung
<rick_h> kjackal_:  ok, thanks. I'll grab APAC folks when they're around to help as well
<rick_h> kjackal_:  yea that's all I'm doing atm but something's missing
<kjackal_> rick_h: what versions (microk8s and juju) do we have?
<kjackal_> latest/stable both?
<knkski> rick_h: kjackal_ said you were having issues with bootstrapping juju onto microk8s?
<rick_h> knkski:  yea, I get hung on when the client reaches out to the controller IP
<rick_h> knkski:  so then it fails
<knkski> rick_h: what commands are you running to bootstrap?
<rick_h> knkski:  16:47:32 INFO  cmd controller.go:89 Contacting Juju controller at 10.152.183.215 to verify accessibility...
<rick_h> knkski:  so I added the k8s and then "juju bootstrap k8s --debug
<knkski> rick_h: how did you add the k8s?
<rick_h> knkski:  juju add-k8s k8s (after I setup the .kube/config)
<rick_h> knkski:  so I did the microk8s.config > ~/.kube/config
<knkski> rick_h: the issue is probably that you're attempting to bootstrap onto microk8s remotely. see here for an issue i raised about it: https://bugs.launchpad.net/juju/+bug/1841960
<mup> Bug #1841960: Juju requires Kubernetes cluster to generate external IP for bootstrapping <k8s> <juju:Fix Released by wallyworld> <https://launchpad.net/bugs/1841960>
<knkski> rick_h: the `--controller-service-*` config options should let you bootstrap remotely, but i never got them working since it was easier to just use juju's built-in local microk8s bootstrapping
<knkski> rick_h: so if you get that working i'd like to hear about it
<kjackal_> bootstraping the internal microk8s cloud seemes to worked here https://pastebin.ubuntu.com/p/S7wSYM5XDR/
<kjackal_> let me try the add-k8s
<rick_h> knkski:  kjackal_ so it's all on my laptop but does that count as "remote" since it was through add-k8s?
<rick_h> knkski:  kjackal_ ah you're right. So I didn't see microk8s as a cloud at first. I bet I had to restart after the usermod command to have the right perms/etc
<rick_h> kjackal_:  knkski so I can bootstrap with just "juju bootstrap microk8s"
<rick_h> petevg:  ^
<knkski> rick_h: yep
<rick_h> I'll file a bug on the add-k8s path because it seems like that "should" work but guess not
<petevg> Aha! Glad that got sorted :-)
<rick_h> ok, bug filed, ty knkski and kjackal_ for having me look at the built in cloud option again
<knkski> ð
<kjackal_> rick_h: adding the clud also worked https://pastebin.ubuntu.com/p/M2bhw9hH3d/
<rick_h> kjackal_:  lol boooo you cheater :P
<rick_h> kjackal_:  did you previous bootstrap microk8s? I wonder if there's some setup that it does on that path that isn't done on the other
<rick_h> kjackal_:  and so once you bootstrap microk8s once, it works with the cloud then after
<kjackal_> :) I snap removed and re-installed microk8s
<kjackal_> rick_h: here it is https://pastebin.ubuntu.com/p/NFQrqgfRPh/
<rick_h> kjackal_:  or fine, maybe it just hates me then :P
<rick_h> kjackal_:  knkski one other question, anyone know who does the k8s mongodb charm? It was mentioned it does HA with "enable-ha config set" but I don't see the config and wondering the right path
<knkski> rick_h: looks like it's the charmed-osm team, and i think tvansteenburgh would be the person to talk to about that
<rick_h> knkski:  yea, email sent ty
#juju 2020-05-27
<babbageclunk> wallyworld_: is this the raft bug you were talking about? https://bugs.launchpad.net/juju/+bug/1880751
<mup> Bug #1880751: flapping HA controller machine with lease issue on 2.8-rc2 on GCP <juju:New> <https://launchpad.net/bugs/1880751>
<wallyworld_> babbageclunk: yeah
<babbageclunk> Could the events be getting blocked by the error being logged by the hubwatcher?
<babbageclunk> (I mean the lease operations)
<wallyworld_> babbageclunk: i haven't looked at it at all so have no insight
<babbageclunk> wallyworld_: ok, I think that's the issue from reading the hubwatcher code - it waits up to 10s for the other end to accept the event but all the lease ops queued after that time out after 5s.
<babbageclunk> Don't understand why the machineUnitsWatcher isn't unwatching though
<wallyworld_> babbageclunk: is there a suggestion as to how to fix?
<wallyworld_> manadart: would appreciate a review on https://bugs.launchpad.net/juju/+bug/1880797 to fix bug 1880797 for inclusion in 2.7.7 (customer issue)
<mup> Bug #1880797: model migration fails from upgraded 2.6 model to 2.7 controller <juju:In Progress by wallyworld> <https://launchpad.net/bugs/1880797>
<babbageclunk> well, the fix would be to make sure machineUnitsWatcher always unwatches the ids it watches
<mup> Bug #1880797: model migration fails from upgraded 2.6 model to 2.7 controller <juju:In Progress by wallyworld> <https://launchpad.net/bugs/1880797>
<babbageclunk> ;)
<wallyworld_> babbageclunk: i need to read the code, can you point me to the file with the watcher?
<babbageclunk> yup yup - the watch call is at state/watcher.go:2455
<wallyworld_> babbageclunk: HO?
<babbageclunk> yup just getting dressed
<wallyworld_> :-)
<tlm> quick PR if anyone has a few seconds https://github.com/juju/juju/pull/11629
<hpidcock> tlm: approved
<manadart> wallyworld_: Will look in a bit.
<wallyworld_> ty
<elox> Is there something wrong with the charmstore? I'm just released my next revision of nextcloud charm, when I try to deploy it, it can't seem to find it.
<elox> https://discourse.juju.is/t/charmstore-releases-takes-a-long-time-to-appear/3123
<stickupkid> manadart, The last piece before I tackle the machiner API https://github.com/juju/juju/pull/11631
<manadart> stickupkid: Yep.
<rick_h> stickupkid:  manadart either of you free to give me a demo hand with an issue please?
<manadart> rick_h: What's up?
<rick_h> manadart:  agent stuck in "initializing" and restarted it but blanking on unblocking it
<rick_h> https://pastebin.canonical.com/p/SGBHSnfQY6/
<rick_h> might be doomed I guess https://pastebin.canonical.com/p/nWKnmXyhfK/
<rick_h> the other unit had a different error, trying restarting but not sure how I can kick it as it's not in an error state to retry https://pastebin.canonical.com/p/vMj23Zfp5z/
<manadart> rick_h: Not doomed in the first case. Can the machine access the controller? When doing the fallback connect, if you get any error such as a time-out, it appears to bug out.
<rick_h> manadart:  yes, the machine 1 is a controller machine
<rick_h> it's a monitoring setup on a controller
<rick_h> the fact that it thinks it's a bad auth and unusable I wasn't sure how to get it to retest that assumption
<rick_h> I'm trying to get rid of the telegraf but it's also not removing as it's stuck in a bad state that Juju won't try to touch it, it seems
<rick_h> of course this is my controller so just blasting machines is :( as it tears the rest of the demo work down
<manadart> rick_h: Yes, I see.
<rick_h> ok, going to tear down. I need to get another build started asap
<manadart> rick_h: Sorry; stumped.
<rick_h> manadart:  yea, all good just bummed, second controller to have to diaf :/
<rick_h> petevg:  howdy, just wanted to check in if you get time for demo sync
<petevg> rick_h: in a meeting now ... want to sync up in fifteen minutes?
<rick_h> petevg:  rgr
<petevg> rick_h: I'm in the juju daily.
<rick_h> petevg:  sorry, on calls on my end my bad, timne slipped away
<petevg> rick_h: no worries. I'm going to go get some lunch. I've got a MicroStack running Kubernetes for you, but as I went to share the controller with you, I realized that it's all locked inside MicroStack's private little network. I'm working on rewiring said network so that you can get to it from outside the box. (Doing a test run with some local stuff first, because it's easy to kill network access, and I don't want to start
<petevg> all over again.)
<pmatulis> why is it that even after this command: 'juju model-default default-space=public-space' i still get deploy errors like:
<pmatulis> << no obvious space for container "0/lxd/0", host machine has spaces: "public-space", "undefined" >>
<rick_h> petevg:  did you run across this at all? https://pastebin.canonical.com/p/t6nW9jykPK/ any hints on what it's saying?
<petevg> rick_h: I did not run across that message. Interesting.
<petevg> rick_h: I did most of my testing w/ three keystone units. I'm 99% certain that I did a final deploy w/ the one unit bundle I sent you, though ...
<rick_h> petevg:  hmmn ok, tear down and try again
<petevg> cool cool
<rick_h> petevg:  almost have the CMR version of the bundle going wheeee
<petevg> Woot!
<rick_h> though I should dress it up some more with telegraf/etc but one thing at a timne
<rick_h> petevg:  hmmm, I expect this isn't a CMR ready application ugh
<rick_h> ok, different tact
<rick_h> petevg:  ok, CMR is ready. I'm goinmg to walk the dog but will you be around in 30 to sync on the openstack/etc?
<rick_h> petevg:  if the k8s kills it just leave it out
<petevg> rick_h: congrats! I've got a release standup @ 17:30, but I'm around before and after then.
<rick_h> petevg:  ok cool ty, will ping when back from the walk
#juju 2020-05-28
<wallyworld> thumper: https://github.com/juju/juju/pull/11633
 * thumper looks
<thumper> https://github.com/juju/juju/pull/11635 for some more cleanup
<thumper> wallyworld: I'm heading inside, you may need to get kelvinliu or tlm to approve the 2.7 merge forwards into RC branc
<thumper> h
<wallyworld> ok
<wallyworld> almost done landing in 2.7
<tychicus> was running through the 20.05 openstack install and hit the following error, which seems like maybe a charm configuration issue
<tychicus> Executing changes:
<tychicus> - upload charm cs:ceph-mon-48 for series focal
<tychicus> - deploy application ceph-mon on focal using cs:ceph-mon-48
<tychicus> ERROR cannot deploy bundle: ceph-mon is not available on the following series: focal not supported
<tychicus> when I look here focal is listed a supported https://jaas.ai/ceph-mon/48
<wallyworld> tychicus: unless the charm declares it supports focal, you will need to use  --force and hope it works regardless
<wallyworld> hmm, interesting
<wallyworld> maybe the bundle has some series config which conflicts
<wallyworld> oh, what release of juju is this
<tychicus> checking
<tychicus> 2.7.1-mojave-amd64
<wallyworld> ah, you may need a later version. 2.7.6 is recommended
<wallyworld> i think focal was added around that time, can't recall if it was 2.7.1 or 2.7.2
<tychicus> thanks, I'll give that a whirl
<wallyworld> if no luck let us know
<tychicus> Will do, thanks for the quick response
<tlm> wallyworld: need me to approve ?
<wallyworld> still waiting for 2.7 to land, then forward port
<wallyworld> soon hopefully
<wallyworld> FFS, another trasient failure
<tychicus> so I updated the client and controller to 2.7.6, but I get the same error that focal is not supported
<wallyworld> tychicus: can you share the bundle being used and repor steps? a bug would be useful so everything is together in one spot
<wallyworld> *repro
<wallyworld> it maybe a set up issue or whtever, we can comment on the bug and close it if it gets resolved
<tychicus> https://github.com/openstack-charmers/openstack-bundles/blob/master/stable/openstack-base/bundle.yaml
<tychicus> juju deploy ./bundle.yaml
<tychicus> should the bug be filed against the charm or the bundle?
<wallyworld> juju
<wallyworld> https://bugs.launchpad.net/juju
<wallyworld> bundle looks ok to me at first glance
<wallyworld> you could try and work around it by setting the series in the bundle to bionic and see if that helps
<tychicus> I can give that a go, that will just tell MaaS to deploy a 18.04 machine rather than 20.04, is that correct?
<wallyworld> yeah
<wallyworld> might get you unstuck until it is figured out
<wallyworld> tychicus: you definitely have focal images in your maas?
<tychicus> doublechecking
<wallyworld> it does look like a juju error message though
<tychicus> yes indeed 20.04 is synced on MaaS
<wallyworld> weird, no idea at this stage without digging into it
<wallyworld> --force will work also i think
<wallyworld> juju deploy <bundle> --force
<tychicus> I'll give force a try and in the mean time I'll get a bug filed
<wallyworld> ty
<tychicus> wallyworld: https://bugs.launchpad.net/juju/+bug/1881071
<mup> Bug #1881071: ceph-mon-48 does not support focal <juju:New> <https://launchpad.net/bugs/1881071>
<tychicus> if there is anything else that you would like to see in the bug report please let me know
<wallyworld> manadart: sorry, got a bit over zealous getting bugs in order for the rc3 release, lining up those that will be in 2.8 since we're forward porting 2.7 for rc3
<manadart> wallyworld: If we are doing RC3, I would like to back-port some performance patches: 11570, 11606 and 11608. This is a nice combo that deliver performance improvements.
<wallyworld> manadart: just looked at those, they look fine to me for backporting
<manadart> wallyworld: How soon do we need the hash?
<wallyworld> i'm currently landing a cmr fix in 2.7, after which i have a forward port lined up to pick it and a couple of other small fixes
<wallyworld> i was hoping to have rc3 ready for QA in a few hours but am having issues landing the 2.7 patch
<wallyworld> timeouts etc in some full stack tests
<wallyworld> if we can get it to QA for their SOD that would be good
<manadart> wallyworld: Let me do the hack we've been using. It's `dep ensure` for the 2.7 branch that takes all the test time.
<wallyworld> it's the tests themselves :-(
<wallyworld> last run was some container init tests
<wallyworld> and before that some agent ones
<wallyworld> always happens when you need to get stuff done urgently
<manadart> wallyworld: OK.
<wallyworld> manadart: so the rc3 trigger was bug 1881021 which i diagnosed and fixed but as per email from tim, we also need to confirm that the other observations are fixed or not
<mup> Bug #1881021: inappropriate "relation-joined" for unit bounces untiter repeatedly <cdo-qa> <cdo-release-blocker> <foundations-engine> <uniter-worker> <vsphere-provider> <juju:Fix Committed by wallyworld> <https://launchpad.net/bugs/1881021>
<wallyworld> i ran out of time to go and dig
<stickupkid> manadart, did you see my updates?
<stickupkid> manadart, https://github.com/juju/juju/pull/11631
<manadart> stickupkid: Will look in a bit.
<stickupkid> cheers
<wallyworld> stickupkid: here's a foward port of 2.7 into 2.8rc to pick up a few key PRs for rc3. you guys may have one or two more to land, but landing this now will ensure the diff is a bit more managale https://github.com/juju/juju/pull/11636
<wallyworld> ty in advance :-)
<stickupkid> wallyworld, "##[error]state/cleanup.go:1227:54: undefined: machineId"
<wallyworld> stickupkid: ah, missed that, one sec
<wallyworld> stickupkid: fixed, there was obviously a variable rename in the uprade series cleanupjob and that instance was from a change added in 2.8
<stickupkid> wallyworld, looks good to me
<wallyworld> tyvm
<manadart> wallyworld or stickupkid: https://github.com/juju/juju/pull/11637
<stickupkid> wallyworld, another failure around params package https://github.com/juju/juju/pull/11636/checks?check_run_id=716013943
<tychicus> is there any way to force the mysql-router to bootstrap?
<tychicus> MySQL Router not yet bootstrapped
<wallyworld> manadart: lgtm
<tychicus> juju actions mysql-router reports
<tychicus> ERROR application "mysql-router" not found
<wallyworld> tychicus: i assume mysql-router is a deployed charm for which you want to list the actions?
<tychicus> yeah, I thought it was part of the bundle but it looks like maybe not
<tychicus> juju deploy mysql-router
<tychicus> Located charm "cs:mysql-router-0".
<tychicus> Deploying charm "cs:mysql-router-0".
<tychicus> so it looks like there is a mysql router for a number of services
<tychicus> maybe these questions are better aimed at #openstack-charms
<stickupkid> manadart, ping
<manadart> stickupkid: Pong.
<stickupkid> daily?
<stickupkid> manadart, at some point in the future https://github.com/juju/juju/pull/11639
<madFren> hello everyoneapologies if this has been asked before, however i've searched the net far and wide and still can't get my issue fixed.i'm trying to deploy openstack from a charm bundle (tried various revisions of openstack-base and openstack-telemetry) and juju doesn't bind the applications to network spacesi keep getting `failed to start machine
<madFren> 0/lxd/0 (unable to setup network: no obvious space for container "0/lxd/0", host machine has spaces:`
<hpidcock> wallyworld: any merge conflicts on the 2.8-rc -> 2.8 pr?
<thumper> https://github.com/juju/juju/pull/11635 awaiting someone to approve it
<tlm> I can take a look thumper
<thumper> thanks tlm
<Eryn_1983_FL> hi guys
<Eryn_1983_FL> we keep getting ovn errors on our openstack roll out
<Eryn_1983_FL> currently we got certificates missing errors.
<Eryn_1983_FL> any ideas of whats going on..
#juju 2020-05-29
<tychicus> did you initialize vault?
<tychicus> I ran into this when testing the new 20.05 stable bundle
<tychicus> there are 2 sets of instructions that I needed to get things moving forward
<tychicus> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-vault.html
<tychicus> first initialize and install vault
<tychicus> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
<tychicus> second retrieve and sign the csr
<wallyworld> thumper: i give up, 2.7 landing is broken, here's a forward port of the 2.7 PR directly to 2.8-rc3 (with legacy lease stuff removed) https://github.com/juju/juju/pull/11641
<wallyworld> or hpidcock or kelvinliu ^^^^^
<wallyworld> kust got to get 2.8-rc unblocked
<kelvinliu> looking
<kelvinliu> approved since the original one has been approved already wallyworld
<wallyworld> ty
<kelvinliu> nws
<timClicks> I'm receiving a "no matching agent binaries available" message when deploying a focal workload to AWS
<wallyworld> juju version?
<timClicks> this is JAAS (2.6.10), client is Juju 2.8-rc2
<thumper> timClicks: jaas doesn't know about focal
<thumper> that is 2.7
<thumper> wallyworld: where are we at with the landings?
<wallyworld> gave up on 2.7 and forward ported the last PR directly to 2.8-rc, waiting for CI now
<thumper> wallyworld: can I try to merge my 2.8 branch?
<wallyworld> sure, i'm just landing a 2.8rc->2.8 port and then i was going to merge yours
<thumper> all good, if you want to do the mergy thing then that's all good
<wallyworld> i can
<thumper> looks like I'll be helping with a customer issue
<wallyworld> what juju version?
<thumper> don't know yet
<hpidcock> forward port to develop https://github.com/juju/juju/pull/11642
<suke> hi Guys,
<wallyworld> hpidcock: did you pick up the just landed pr from tim?
<hpidcock> wallyworld: let me check
<wallyworld> hpidcock: also, GetByHardwareAddress isn't used
<wallyworld> i suspect it's been replaced by Filter whichis whwere the conflict was
<hpidcock> GetByHardwareAddress was only added 10 days ago
<wallyworld> hpidcock: ah, i suspect it's for the work to filter out machine local addresses, and there's a PR which will use it
<hpidcock> wallyworld: yep, can always delete it later. I'd rather not break manadart's WIP if he has any using it
<wallyworld> yup
<wallyworld> hpidcock: the changes look  as expected to me based on working with the other branches of late
<hpidcock> wallyworld: awesome thanks, just waiting for a green run then I'll merge
<wallyworld> i was 1/2 way thriugh doing it myself then i saw your pr :-)
<hpidcock> wallyworld: ahah
<wallyworld> was looking at the nic conflict
<hpidcock> sorry
<wallyworld> all good, you saved me a lot6 of typing
<thumper> https://github.com/juju/juju/pull/11644
<thumper> the last of the uniter package level loggers
<thumper> phew
<manadart> wallyworld, hpidcock: GetByHardwareAddress was indeed a utility added for a patch in progress.
<manadart> wallyworld: This is the fix for network_get and local-machine addresses: https://github.com/juju/juju/pull/11638
<manadart> Just have to put together some QA.
<wallyworld> gr8 ty
<Eryn_1983_FL> tychicus:  he got some handful of keys
<Eryn_1983_FL> i think he did
 * thumper sighs
<thumper> more problems
<thumper> but yay, users??
<wallyworld> thumper: anything serious?
<thumper> wallyworld: nothing blocking
<thumper> but enough that we'll want to include a patch in 2.7.7
<wallyworld> got a bug?
<thumper> https://bugs.launchpad.net/juju/+bug/1881242
<mup> Bug #1881242: Missing error check results in panic - apiserver <apiserver> <panic> <juju:Triaged> <https://launchpad.net/bugs/1881242>
<thumper> the fix for this bug is trivial... add an error handling
<thumper> the other problem, for which we are also getting a bug, is how did it get into this status
<thumper> state
<wallyworld> sigh
<thumper> wallyworld: did you see my PR above?
<thumper> wallyworld: nm, hpidcock reviewed it for me
<thumper> thanks hpidcock
<wallyworld> that's why i didn't look :-)
<wallyworld> already +1
<thumper> hey... https://jenkins.juju.canonical.com/job/github-make-check-juju/5933/consoleText
<thumper> look for "oops"
<thumper> api/uniter fails
<thumper> but I don't see a filure in the output?
<hpidcock> thumper: might be teardown failure?
<thumper> succeeds locally
<thumper> and I only see 118 passed and 1 skipped
<thumper> hpidcock: could be
<thumper> wallyworld: I see the email you just forwarded to me
<thumper> but I don't see the original
<wallyworld> thumper: yeah, go figure, maybe the email lists are stuck
<thumper> could be
<thumper> wallyworld: you message to the list has come through now
<wallyworld> so it has
<Laney> hey, quick bit of help needed hopefully. i've got a controller running on lxd locally, but juju has somehow got the wrong idea about what its ip addresses are (maybe the container got restarted?). how can I get it to learn the right ones?
<Laney> (made a topic on discourse)
<achilleasa> Laney: you can point the cli to the right IP by editing the endpoint values in ~/.local/share/juju/controllers.yaml for your controller (as always backup first before editing ;-)
<Laney> achilleasa: wtf, that has the right addresses in it
<Laney> uh
<Laney> there's some duplication here, how did that happen
<achilleasa> Laney: you mean you have the same IP twice in the endpoint list? Not sure how that could happen but it should not have any impact in connection attempts
<Laney> no I had the same controller in there twice, once right and once wrong
<Laney> but deleted the wrong one now and 'juju status' works again
<Laney> 'juju ssh' doesn't though, it seems to be trying to connect to my public IP instead of the container's IP ...
<Laney> works with --proxy but not without
<achilleasa> manadart: can you take a look at https://github.com/juju/juju/pull/11645?
<manadart> achilleasa: Approved it.
<achilleasa> manadart: do we rewrite the agent config files when upgrading?
<manadart> achilleasa: Yes, we have to in order to set the version.
<Eryn_1983_FL> hi
<tychicus> with the nova-cloud-controller charm, is there bit of additional config that needs to be performed to get console-access-protocol to use TLS?
<tychicus> I ensured that the vault relation is there juju add-relation nova-cloud-controller:certificates vault:certificates
<tychicus> but openssl s_client -connect shows that TLS is not enabled
<tychicus> If I switch from https to http the page renders with an error "Something went wrong, connection is closed "
<pmatulis> tychicus, are you talking about the dashboard?
<tychicus> yes, the console in the dashboard
<tychicus> dashboard loads with https no problem
<tychicus> in previous releases to enable ssl you had to supply a console-ssl-cert  to nova-cloud-controller
<tychicus> but console-ssl-cert was removed in the 19.07 charm release
<tychicus> Please use ssl_cert configuration option or the vault certificates relation
<pmatulis> tychicus, where do you see that?
<tychicus> https://jaas.ai/nova-cloud-controller/345#charm-config-console-ssl-cert
<pmatulis> tychicus, thanks
<tychicus> pmatulis: np, just trying to figure out if I missed something trivial in my config
<pmatulis> tychicus, what about the value of 'console-access-protocol'?
<tychicus> pmatulis: uju config nova-cloud-controller console-access-protocol=novnc
<tychicus> s /uju/juju
<pmatulis> tychicus, k
<pmatulis> tychicus, well, based on what you've said you've done and based on the documentation it should work. can you open a bug on nova-cloud-controller?
<tychicus> sure
<pmatulis> tychicus, did you try logging out and back in to the dashboard after having made that config change (to 'novnc')?
<tychicus> I did
<pmatulis> k
<pmatulis> well, like i recommend: https://bugs.launchpad.net/charm-nova-cloud-controller/+filebug
<tychicus> I'm working on the bug report now, but I need to do a little more digging
<tychicus> it looks like novnc is not proxied by apache, all of the stuff proxied by apache is fine
<tychicus> looks like the issue is that there is an issue with the nova.console.websocketproxy
#juju 2020-05-31
<hpidcock> wallyworld: getting an error on uniter api tests but no error message ```OOPS: 118 passed, 1 skipped, 1 FAILED
<hpidcock> --- FAIL: TestAll (10.94s)
<hpidcock> FAIL
<hpidcock> fail	github.com/juju/juju/api/uniter	10.967s```
<wallyworld> hmmm
<wallyworld> running locally?
<hpidcock> had this on jenkins I think on friday
<hpidcock> I'll see if its reproducible
<wallyworld> what branch
<hpidcock> develop
<hpidcock> possibly a bug in teardown?
<wallyworld> could be. a lot of stuff has landed in 2.8 and been forward ported. not sure how much develop work has been done of late
<hpidcock> wallyworld: running the test package with https://godoc.org/golang.org/x/tools/cmd/stress results in the error
<hpidcock> cd api/uniter && go test -c && stress ./uniter.test -test.cpu=10
<wallyworld> but no error printed?
